From owner-xfs@oss.sgi.com Sat Dec 1 05:04:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Dec 2007 05:04:38 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46 autolearn=no version=3.3.0-r574664 Received: from mail.integraonline.com (relay1.integra.net [204.130.255.180]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB1D4STk015160 for ; Sat, 1 Dec 2007 05:04:31 -0800 Received: (qmail 22988 invoked from network); 1 Dec 2007 13:04:37 -0000 Received: from unknown (HELO ?192.168.1.107?) (76.164.13.124) by 0 with SMTP; 1 Dec 2007 13:04:37 -0000 In-Reply-To: <20071130230435.GA12626@puku.stupidest.org> References: <20071114070400.GA25708@puku.stupidest.org> <20071125163014.GA17922@infradead.org> <474FBA21.4070201@sgi.com> <165B249C-FE97-4B27-927B-B39DE316CB23@xfs.org> <20071130230435.GA12626@puku.stupidest.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Timothy Shimmin , Christoph Hellwig , linux-xfs@oss.sgi.com, LKML Content-Transfer-Encoding: 7bit From: Stephen Lord Subject: Re: [PATCH] xfs: revert to double-buffering readdir Date: Sat, 1 Dec 2007 07:04:27 -0600 To: Chris Wedgwood X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.91.2/4967/Sat Dec 1 03:21:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13834 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: xfs On Nov 30, 2007, at 5:04 PM, Chris Wedgwood wrote: > On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: > >> Looks like the readdir is in the bowels of the btree code when >> filldir gets called here, there are probably locks on several >> buffers in the btree at this point. This will only show up for large >> directories I bet. > > I see it for fairly small directories. Larger than what you can stuff > into an inode but less than a block (I'm not checking but fairly sure > that's the case). I told you I did not read any code..... once a directory is out of the inode and into disk blocks, there will be a lock on the buffer while the contents are copied out. > >> Just rambling, not a single line of code was consulted in writing >> this message. > > Can you explain why the offset is capped and treated in an 'odd way' > at all? > > + curr_offset = filp->f_pos; > + if (curr_offset == 0x7fffffff) > + offset = 0xffffffff; > + else > + offset = filp->f_pos; > > and later the offset to filldir is masked. Is that some restriction > in filldir? Too long ago to remember exact reasons. The only thing I do recall is issues with glibc readdir code which wanted to remember positions in a dir and seek backwards. It was translating structures and could end up with more data from the kernel than would fit in the user buffer. This may have something to do with that and special values used as eof markers in the getdents output and signed 32 bit arguments to lseek. In the original xfs directory code, the offset of an entry was a 64 bit hash+offset value, that really confused things when glibc attempted to do math on it. I also recall that the offsets in the directory fields had different meanings on different OS's. Sometimes it was the offset of the entry itself, sometimes it was the offset of the next entry, that was one of the reasons for the translation layer I think. Steve From owner-xfs@oss.sgi.com Sat Dec 1 07:21:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Dec 2007 07:21:42 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,URIBL_GREY autolearn=no version=3.3.0-r574664 Received: from umail.ru (fe01-umail.mtu.ru [62.5.255.15]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB1FLZjl030135 for ; Sat, 1 Dec 2007 07:21:37 -0800 Subject: Undeliverable mail: Delivery reports about your e-mail From: To: Date: Sat, 01 Dec 2007 18:06:41 +0300 Message-ID: X-MAPI-Message-Class: REPORT.IPM.Note.NDR MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===296660670====fe01-umail.umail.ru===_" X-Virus-Scanned: ClamAV 0.91.2/4969/Sat Dec 1 06:24:46 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13835 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@umail.ru Precedence: bulk X-list: xfs --_===296660670====fe01-umail.umail.ru===_ Content-Type: text/plain; charset="utf-8" Failed to deliver to 'olgaefimova@mtu-net.ru' LOCAL module(account olgaefimova@mtu-net.ru) reports: account is full (quota exceeded) --_===296660670====fe01-umail.umail.ru===_ Content-Type: message/delivery-status Reporting-MTA: dns; fe01-umail.umail.ru Original-Recipient: rfc822; Final-Recipient: LOCAL; Action: failed Status: 4.0.0 --_===296660670====fe01-umail.umail.ru===_ Content-Type: text/rfc822-headers Received: from [195.34.34.242] (HELO so01.mtu.ru) by fe01-umail.umail.ru (CommuniGate Pro SMTP 5.1.10) with ESMTP id 296660668 for olgaefimova@mtu-net.ru; Sat, 01 Dec 2007 18:06:41 +0300 Received: from localhost (localhost.mtu.ru [127.0.0.1]) by so01.mtu.ru (Postfix) with ESMTP id 5ADA6BA9A48 for ; Sat, 1 Dec 2007 18:06:40 +0300 (MSK) X-Spam-Flag: YES X-Spam-Yversion: Spamooborona 1.7.0-isp Received: from smtp04.mtu.ru (alt-proxy-1.mtu.ru [62.5.255.74]) by so01.mtu.ru (Postfix) with ESMTP id 4EB8ABA9A32 for ; Sat, 1 Dec 2007 18:06:40 +0300 (MSK) Received: from oss.sgi.com (ppp128-106.dialup.mtu-net.ru [62.118.128.106]) by smtp04.mtu.ru (Postfix) with ESMTP id EBC967FFFB0 for ; Sat, 1 Dec 2007 18:06:14 +0300 (MSK) From: linux-xfs@oss.sgi.com To: olgaefimova@mtu-net.ru Subject: Delivery reports about your e-mail Date: Thu, 7 Sep 2006 06:38:22 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_F8133FED.84A7BAAB" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20071201150614.EBC967FFFB0@smtp04.mtu.ru> --_===296660670====fe01-umail.umail.ru===_-- From owner-xfs@oss.sgi.com Sun Dec 2 14:31:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 14:31:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB2MV6kc029272 for ; Sun, 2 Dec 2007 14:31:10 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06581; Mon, 3 Dec 2007 09:31:11 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB2MV9dD129824881; Mon, 3 Dec 2007 09:31:10 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB2MV5ZE127129737; Mon, 3 Dec 2007 09:31:05 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 3 Dec 2007 09:31:05 +1100 From: David Chinner To: Jan Engelhardt Cc: xfs@oss.sgi.com Subject: Re: ACL limit Message-ID: <20071202223105.GS119954183@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4976/Sun Dec 2 12:00:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13836 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Nov 30, 2007 at 07:07:26PM +0100, Jan Engelhardt wrote: > Hi, > > > is there any way to raise the number of ACLs that can be stored? The > current limit of 25 is quite tight, where ext3 allows 124 and jfs 8192. > Would increasing XFS_ACL_MAX_ENTRIES work (yes, using potentially more > memory), i.e. not interfering with the on-disk format? It would be an on disk format change - older kernels would error out (-EINVAL) on > 25 ACLs and not check any of them. Hence we'd probably need a superblock feature bit to indicate that >25 ACEs are supported in a given ACL. But we can work around that (superblock feature bit) and should be able to extend this out to ~8190 entries. We're doing an ACL rework ATM, so > 25 entry support should fall out of that.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Dec 2 15:39:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 15:39:39 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB2NdT88008780 for ; Sun, 2 Dec 2007 15:39:32 -0800 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07548; Mon, 3 Dec 2007 10:23:25 +1100 Message-ID: <47533E6E.1010508@sgi.com> Date: Mon, 03 Dec 2007 10:23:26 +1100 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: current cvs doesn't compile References: <20071130101153.GA4150@lst.de> <20071130101824.GA4419@lst.de> In-Reply-To: <20071130101824.GA4419@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4978/Sun Dec 2 14:38:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13837 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Nov 30, 2007 at 11:11:53AM +0100, Christoph Hellwig wrote: >> xfs_mark_inode_dirty_sync is used in xfs_inode_item_format but isn't >> actually declared anywhere. > > Sorry, this was due to me having some old patch applied still. > >> Btw, we also still have the bug that fs/xfs/Kbuild exists as an empty >> files and without removing it nothing is recompiled at all. > > But this is still a real issue.. Hi Christoph, http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/ Doesn't snow fs/xfs/Kbuild (except in the archives). I also did a fresh cvs checkout of linux-2.6-xfs and its not there ether. Seems like this is only happening when updating an existing workarea. There could be a stale entry in fs/xfs/CVS/Entries that is not being removed by an update/checkout. Could you send us your Entries file so we can figure out whats happening? Don From owner-xfs@oss.sgi.com Sun Dec 2 15:45:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 15:45:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB2NiwK3009939 for ; Sun, 2 Dec 2007 15:45:00 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07908; Mon, 3 Dec 2007 10:45:00 +1100 Message-ID: <475343FB.3060902@sgi.com> Date: Mon, 03 Dec 2007 10:47:07 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jan Engelhardt CC: David Chinner , xfs@oss.sgi.com Subject: Re: ACL limit References: <20071202223105.GS119954183@sgi.com> In-Reply-To: <20071202223105.GS119954183@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4978/Sun Dec 2 14:38:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13838 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Fri, Nov 30, 2007 at 07:07:26PM +0100, Jan Engelhardt wrote: >> Hi, >> >> >> is there any way to raise the number of ACLs that can be stored? The >> current limit of 25 is quite tight, where ext3 allows 124 and jfs 8192. >> Would increasing XFS_ACL_MAX_ENTRIES work (yes, using potentially more >> memory), i.e. not interfering with the on-disk format? > > It would be an on disk format change - older kernels would error out > (-EINVAL) on > 25 ACLs and not check any of them. Hence we'd > probably need a superblock feature bit to indicate that >25 ACEs are > supported in a given ACL. > > But we can work around that (superblock feature bit) and should > be able to extend this out to ~8190 entries. We're doing an ACL > rework ATM, so > 25 entry support should fall out of that.... > > Cheers, > > Dave. Yeah, it's just an array of entries in an EA value. The EA value is limited to 64K so it's a question of how many entries you can fit into that. (64K - 4)/12 = 5461 (So just have to sort out the ondisk change as mentioned above) --Tim From owner-xfs@oss.sgi.com Sun Dec 2 16:12:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 16:12:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB30CAMR014453 for ; Sun, 2 Dec 2007 16:12:11 -0800 Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 369D91803F71F; Mon, 3 Dec 2007 01:12:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 2E7A71CE2615F; Mon, 3 Dec 2007 01:12:19 +0100 (CET) Date: Mon, 3 Dec 2007 01:12:19 +0100 (CET) From: Jan Engelhardt To: Timothy Shimmin cc: David Chinner , xfs@oss.sgi.com Subject: Re: ACL limit In-Reply-To: <475343FB.3060902@sgi.com> Message-ID: References: <20071202223105.GS119954183@sgi.com> <475343FB.3060902@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4978/Sun Dec 2 14:38:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13839 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@computergmbh.de Precedence: bulk X-list: xfs On Dec 3 2007 10:47, Timothy Shimmin wrote: > > Yeah, it's just an array of entries in an EA value. > The EA value is limited to 64K so it's a question of how > many entries you can fit into that. > (64K - 4)/12 = 5461 > > (So just have to sort out the ondisk change as mentioned above) I'd already be happy if the ext3 ACL limit (~120) was possibe :-) The rest I can solve with groups (which is also probably faster than 1600 ACL entries). From owner-xfs@oss.sgi.com Sun Dec 2 16:23:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 16:23:53 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB30NjaP020779 for ; Sun, 2 Dec 2007 16:23:48 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08796; Mon, 3 Dec 2007 11:23:52 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB30NpdD130060790; Mon, 3 Dec 2007 11:23:52 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB30NnXe129886603; Mon, 3 Dec 2007 11:23:49 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 3 Dec 2007 11:23:49 +1100 From: David Chinner To: Timothy Shimmin Cc: Jan Engelhardt , David Chinner , xfs@oss.sgi.com Subject: Re: ACL limit Message-ID: <20071203002349.GV119954183@sgi.com> References: <20071202223105.GS119954183@sgi.com> <475343FB.3060902@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475343FB.3060902@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4978/Sun Dec 2 14:38:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13840 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Dec 03, 2007 at 10:47:07AM +1100, Timothy Shimmin wrote: > David Chinner wrote: > >On Fri, Nov 30, 2007 at 07:07:26PM +0100, Jan Engelhardt wrote: > >>Hi, > >> > >> > >>is there any way to raise the number of ACLs that can be stored? The > >>current limit of 25 is quite tight, where ext3 allows 124 and jfs 8192. > >>Would increasing XFS_ACL_MAX_ENTRIES work (yes, using potentially more > >>memory), i.e. not interfering with the on-disk format? > > > >It would be an on disk format change - older kernels would error out > >(-EINVAL) on > 25 ACLs and not check any of them. Hence we'd > >probably need a superblock feature bit to indicate that >25 ACEs are > >supported in a given ACL. > > > >But we can work around that (superblock feature bit) and should > >be able to extend this out to ~8190 entries. We're doing an ACL > >rework ATM, so > 25 entry support should fall out of that.... > > Yeah, it's just an array of entries in an EA value. > The EA value is limited to 64K so it's a question of how > many entries you can fit into that. > (64K - 4)/12 = 5461 Confused - I thought the ACE was 8 bytes: struct posix_acl_entry { short e_tag; unsigned short e_perm; unsigned int e_id; }; Also, JFS only allows 64k for the xattr as well (jfs_xattr.h): /* Macros for defining maxiumum number of bytes supported for EAs */ #define MAXEASIZE 65535 #define MAXEALISTSIZE MAXEASIZE And (64k - 4)/8 = 8191 which is what JFS supports. Oh: typedef __uint16_t xfs_acl_perm_t; typedef __int32_t xfs_acl_type_t; typedef __int32_t xfs_acl_tag_t; typedef __int32_t xfs_acl_id_t; #define XFS_ACL_MAX_ENTRIES 25 #define XFS_ACL_NOT_PRESENT (-1) typedef struct xfs_acl_entry { xfs_acl_tag_t ae_tag; xfs_acl_id_t ae_id; xfs_acl_perm_t ae_perm; } xfs_acl_entry_t; typedef struct xfs_acl { __int32_t acl_cnt; xfs_acl_entry_t acl_entry[XFS_ACL_MAX_ENTRIES]; } xfs_acl_t; An *XFS* ACE is 12 bytes and hence can't be passed directly to the generic code. Tim - are we adding a translation layer or storing the generic posix acl format on disk? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Dec 2 16:32:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 16:33:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB30WBa6022211 for ; Sun, 2 Dec 2007 16:32:12 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09029; Mon, 3 Dec 2007 11:32:14 +1100 Message-ID: <47534F0D.4040606@sgi.com> Date: Mon, 03 Dec 2007 11:34:21 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Chinner CC: Jan Engelhardt , xfs@oss.sgi.com Subject: Re: ACL limit References: <20071202223105.GS119954183@sgi.com> <475343FB.3060902@sgi.com> <20071203002349.GV119954183@sgi.com> In-Reply-To: <20071203002349.GV119954183@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4978/Sun Dec 2 14:38:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13841 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Mon, Dec 03, 2007 at 10:47:07AM +1100, Timothy Shimmin wrote: >> David Chinner wrote: >>> On Fri, Nov 30, 2007 at 07:07:26PM +0100, Jan Engelhardt wrote: >>>> Hi, >>>> >>>> >>>> is there any way to raise the number of ACLs that can be stored? The >>>> current limit of 25 is quite tight, where ext3 allows 124 and jfs 8192. >>>> Would increasing XFS_ACL_MAX_ENTRIES work (yes, using potentially more >>>> memory), i.e. not interfering with the on-disk format? >>> It would be an on disk format change - older kernels would error out >>> (-EINVAL) on > 25 ACLs and not check any of them. Hence we'd >>> probably need a superblock feature bit to indicate that >25 ACEs are >>> supported in a given ACL. >>> >>> But we can work around that (superblock feature bit) and should >>> be able to extend this out to ~8190 entries. We're doing an ACL >>> rework ATM, so > 25 entry support should fall out of that.... >> Yeah, it's just an array of entries in an EA value. >> The EA value is limited to 64K so it's a question of how >> many entries you can fit into that. >> (64K - 4)/12 = 5461 > > Confused - I thought the ACE was 8 bytes: > > struct posix_acl_entry { > short e_tag; > unsigned short e_perm; > unsigned int e_id; > }; > > Also, JFS only allows 64k for the xattr as well (jfs_xattr.h): > > /* Macros for defining maxiumum number of bytes supported for EAs */ > #define MAXEASIZE 65535 > #define MAXEALISTSIZE MAXEASIZE > > And (64k - 4)/8 = 8191 which is what JFS supports. > > Oh: > > typedef __uint16_t xfs_acl_perm_t; > typedef __int32_t xfs_acl_type_t; > typedef __int32_t xfs_acl_tag_t; > typedef __int32_t xfs_acl_id_t; > > #define XFS_ACL_MAX_ENTRIES 25 > #define XFS_ACL_NOT_PRESENT (-1) > > typedef struct xfs_acl_entry { > xfs_acl_tag_t ae_tag; > xfs_acl_id_t ae_id; > xfs_acl_perm_t ae_perm; > } xfs_acl_entry_t; > > typedef struct xfs_acl { > __int32_t acl_cnt; > xfs_acl_entry_t acl_entry[XFS_ACL_MAX_ENTRIES]; > } xfs_acl_t; > > An *XFS* ACE is 12 bytes and hence can't be passed directly to the > generic code. Tim - are we adding a translation layer or storing > the generic posix acl format on disk? > There is a translation layer and we have preserved the XFS ACL format on disk since the irix days. The only exception to that is on IRIX it actually always stores an array with 25 entries in it (irrespective of the count) which meant for default inode size the irix acls were always out of line - a bit silly. Decided not to continue with that on Linux ;-) So yes, it's the xfs_acl (12 byte aces) we have on disk. --Tim From owner-xfs@oss.sgi.com Sun Dec 2 19:24:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 19:24:28 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB33OLZp011778 for ; Sun, 2 Dec 2007 19:24:23 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12091 for ; Mon, 3 Dec 2007 14:24:30 +1100 Message-ID: <47537709.9040406@sgi.com> Date: Mon, 03 Dec 2007 14:24:57 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> In-Reply-To: <20071130223154.GB13589@luba> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4980/Sun Dec 2 18:28:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13842 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Okay, sounds like it might be a corrupt log. Can you run xfs_logprint on the device or saved log? Also give xfs_logprint -t -i a go. You've saved the log into a file? You can get the filesystem mounted again by deleting the log with xfs_repair -L . You'll probably need to run xfs_repair over the filesystem to be safe. KELEMEN Peter wrote: > * Lachlan Mcilroy (lachlan@sgi.com) [20071129 10:56]: > > Lachlan, > >> This looks like a problem we've just fixed, try this patch. >> We'll get this to mainline soon. > > Thanks for the patch. Unfortunately, it does not seem to fix my > problem. Attempting to mount the filesystem still results in an > oops. > > Peter > > -----8<--- > SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled > SGI XFS Quota Management subsystem > XFS mounting filesystem sdc > Starting XFS recovery on filesystem: sdc (logdev: internal) > Unable to handle kernel paging request at ffffc20001c9b000 RIP: > [] :xfs:xlog_recover_add_to_trans+0x64/0xef > PGD 15781d067 PUD 15781c067 PMD 130fd3067 PTE 0 > Oops: 0000 [1] SMP > CPU 1 > Modules linked in: xfs sd_mod 3w_9xxx scsi_mod ohci_hcd uhci_hcd ehci_hcd ipv6 bnx2 sky2 r8169 ns838 > 20 dl2k acenic e100 tg3 e1000 mii > Pid: 2431, comm: mount Not tainted 2.6.24-rc3-xfsbuf #2 > RIP: 0010:[] [] :xfs:xlog_recover_add_to_trans+0x64/0xef > RSP: 0018:ffff8101320d9728 EFLAGS: 00010286 > RAX: ffffc20001c9c000 RBX: 000000000020bd78 RCX: 00000000001cc280 > RDX: 0000000000000000 RSI: ffffc20001c9b000 RDI: ffffc20001cdbaf8 > RBP: ffff8101320d9758 R08: ffff810157801652 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000002 R12: ffff8101324633b8 > R13: ffffc20001c5b508 R14: ffff810132463110 R15: ffffc20001c5b4fc > FS: 00002abba6e87b00(0000) GS:ffff810157801708(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: ffffc20001c9b000 CR3: 000000013252a000 CR4: 00000000000006e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process mount (pid: 2431, threadinfo ffff8101320d8000, task ffff810131972000) > Stack: 0020bd785769c5e8 000000005769c5e8 000000000000000a ffffc20001c5b508 > 000000000000011e ffffc20001c5b4fc ffff8101320d97b8 ffffffff881c79db > ffffc20001c6a000 00000001881da0bc ffff81013188f000 ffff8101320d9828 > Call Trace: > [] :xfs:xlog_recover_process_data+0x184/0x1d9 > [] :xfs:xlog_do_recovery_pass+0x74b/0x795 > [] :xfs:xlog_do_log_recovery+0x3d/0x82 > [] :xfs:xlog_do_recover+0x12/0x11c > [] :xfs:xlog_recover+0x84/0x92 > [] :xfs:xfs_log_mount+0x8c/0xe4 > [] :xfs:xfs_mountfs+0x67d/0x97b > [] :xfs:xfs_mru_cache_create+0x170/0x1d5 > [] :xfs:xfs_fstrm_free_func+0x0/0x81 > [] :xfs:xfs_ioinit+0xb/0xd > [] :xfs:xfs_mount+0x2bb/0x36b > [] :xfs:xfs_fs_fill_super+0xd2/0x245 > [] get_filesystem+0x17/0x39 > [] sget+0x3fb/0x418 > [] sget+0x403/0x418 > [] set_bdev_super+0x0/0x14 > [] get_sb_bdev+0x123/0x16f > [] :xfs:xfs_fs_fill_super+0x0/0x245 > [] :xfs:xfs_fs_get_sb+0x13/0x18 > [] vfs_kern_mount+0x8f/0x11c > [] do_kern_mount+0x44/0xf4 > [] do_mount+0x6d8/0x71e > [] __up_read+0x93/0x9b > [] up_read+0x23/0x27 > [] do_page_fault+0x42e/0x7c7 > [] zone_statistics+0x64/0x69 > [] __alloc_pages+0x6b/0x311 > [] sys_mount+0x8a/0xcc > [] system_call+0x7e/0x83 > > Code: f3 a4 49 89 c7 49 8b 54 24 08 8b 42 18 85 c0 74 0e 3b 42 14 > From owner-xfs@oss.sgi.com Sun Dec 2 21:32:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 21:32:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB35W5eu001380 for ; Sun, 2 Dec 2007 21:32:07 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14700; Mon, 3 Dec 2007 16:32:14 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 31B2358C4C0F; Mon, 3 Dec 2007 16:32:14 +1100 (EST) To: xfs@oss.sgi.com, xfs-bugs-internal@sgi.com Subject: TAKE update acl/attr man pages re symlinks Message-Id: <20071203053214.31B2358C4C0F@chook.melbourne.sgi.com> Date: Mon, 3 Dec 2007 16:32:14 +1100 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/4980/Sun Dec 2 18:28:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13843 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Update man pages about tree walking and symlinks. Provided by Andreas G. Date: Mon Dec 3 16:30:10 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/tes/xfs-cmds Inspected by: agruen@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:30185a acl/doc/CHANGES - 1.98 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.98&r2=text&tr2=1.97&f=h acl/man/man1/getfacl.1 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/man/man1/getfacl.1.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h acl/man/man1/setfacl.1 - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/man/man1/setfacl.1.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h attr/doc/CHANGES - 1.85 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h attr/man/man1/getfattr.1 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/man/man1/getfattr.1.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h - Update man pages about tree walking and symlinks. From owner-xfs@oss.sgi.com Sun Dec 2 23:43:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 23:43:50 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB37hi1R017708 for ; Sun, 2 Dec 2007 23:43:46 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA17039; Mon, 3 Dec 2007 18:43:49 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB37hmdD130131407; Mon, 3 Dec 2007 18:43:49 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB37hjQ8130291321; Mon, 3 Dec 2007 18:43:45 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 3 Dec 2007 18:43:45 +1100 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: Fix xfs_ichgtime mainline breakage. Message-ID: <20071203074345.GW119954183@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4980/Sun Dec 2 18:28:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13844 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Folks, Just noticed with the mainline merge (2.6.24-rc3) to xfs-dev that xfs_ichgtime + xfs_ichgtime_fast are broken. if (!(inode->i_state & I_SYNC)) mark_inode_dirty_sync(inode); that check used to be against I_LOCK, which was arguably broken, but this one will mean newly created files are not put on the dirty list and hence not written back by pdflush. Patch to fix this attached. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/linux-2.6/xfs_iops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-12-03 18:39:52.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c 2007-12-03 18:40:54.408998073 +1100 @@ -134,7 +134,7 @@ xfs_ichgtime( */ SYNCHRONIZE(); ip->i_update_core = 1; - if (!(inode->i_state & I_SYNC)) + if (!(inode->i_state & I_NEW)) mark_inode_dirty_sync(inode); } @@ -186,7 +186,7 @@ xfs_ichgtime_fast( */ SYNCHRONIZE(); ip->i_update_core = 1; - if (!(inode->i_state & I_SYNC)) + if (!(inode->i_state & I_NEW)) mark_inode_dirty_sync(inode); } From owner-xfs@oss.sgi.com Mon Dec 3 07:47:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 07:47:17 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB3Fl98x018190 for ; Mon, 3 Dec 2007 07:47:12 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1IzCxR-0004oU-QW; Mon, 03 Dec 2007 15:11:42 +0000 Date: Mon, 3 Dec 2007 15:11:41 +0000 From: Christoph Hellwig To: Stephen Lord Cc: Timothy Shimmin , Christoph Hellwig , Chris Wedgwood , linux-xfs@oss.sgi.com, LKML Subject: Re: [PATCH] xfs: revert to double-buffering readdir Message-ID: <20071203151141.GB18082@infradead.org> References: <20071114070400.GA25708@puku.stupidest.org> <20071125163014.GA17922@infradead.org> <474FBA21.4070201@sgi.com> <165B249C-FE97-4B27-927B-B39DE316CB23@xfs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <165B249C-FE97-4B27-927B-B39DE316CB23@xfs.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4980/Sun Dec 2 18:28:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13845 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: > Wow, was it really that long ago! > > Looks like the readdir is in the bowels of the btree code when filldir gets > called > here, there are probably locks on several buffers in the btree at this > point. This > will only show up for large directories I bet. Chris saw it with block-form directories. I've verified it works fine with short-form directories, and the leaf code looks like it could happen aswell. I also remember gfs2 running into a similar problem. > The xfs readdir code has the complete xfs inode number in its hands at this > point > (filldir is not necessarily getting all the bits of it). All we are doing > the lookup > for really is to get the inode number back again so we can get the inode > and get the attributes. Rather dumb really. There has got to be a way of > doing a callout structure here so that the inode number can be pushed > through filldir and back into an fs specific call. The fs then can do a > lookup > by id - which is what it does most of the time for resolving nfs handles > anyway. Should be more efficient than the current scheme. Yes, a lot more efficient. But it means adding a new operation for use by the nfs server. From owner-xfs@oss.sgi.com Mon Dec 3 07:48:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 07:48:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB3Fm9f9018429 for ; Mon, 3 Dec 2007 07:48:10 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1IzCuw-0004lT-1B; Mon, 03 Dec 2007 15:09:06 +0000 Date: Mon, 3 Dec 2007 15:09:05 +0000 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , Chris Wedgwood , linux-xfs@oss.sgi.com, LKML Subject: Re: [PATCH] xfs: revert to double-buffering readdir Message-ID: <20071203150905.GA18082@infradead.org> References: <20071114070400.GA25708@puku.stupidest.org> <20071125163014.GA17922@infradead.org> <474FBA21.4070201@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474FBA21.4070201@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4980/Sun Dec 2 18:28:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13846 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Nov 30, 2007 at 06:22:09PM +1100, Timothy Shimmin wrote: > Hmmm, don't see the point of "eof" local var now. > Previously bhv_vop_readdir() returned eof. > I presume if we don't move the offset (offset == startoffset) then > we're done and break out? > So we lost eof when going to the filldir in the getdents code etc... Yes, it's just copy & paste. We can trivially kill the variable. From owner-xfs@oss.sgi.com Mon Dec 3 13:16:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 13:16:21 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB3LGEfE013330 for ; Mon, 3 Dec 2007 13:16:16 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA06743; Tue, 4 Dec 2007 08:16:22 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB3LGLdD130513410; Tue, 4 Dec 2007 08:16:21 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB3LGKPH131022564; Tue, 4 Dec 2007 08:16:20 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 4 Dec 2007 08:16:20 +1100 From: David Chinner To: xfs-oss Cc: xfs-dev Subject: [Patch] xfs_lowbit64 broken on ia32 Message-ID: <20071203211620.GN115527101@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4984/Mon Dec 3 09:37:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13847 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs The recent change to the internals of xfs_lowbit64 broke it on ia32 - the code treats the 64bit value as an unsigned long which is only 32 bits on ia32 and hence throws away the high 32 bits. 64 bit platforms are not affected. Tested with a userspace implementation comparing the original code with the new code. Signed-off-by: Dave Chinner --- fs/xfs/xfs_bit.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 13:44:45.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 @@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ /* Get low bit set out of 64-bit argument, -1 if none set */ static inline int xfs_lowbit64(__uint64_t v) { - unsigned long t = v; - return (v) ? find_first_bit(&t, 64) : -1; + unsigned long long t = v; + return (v) ? find_first_bit((unsigned long *)&t, 64) : -1; } /* Return whether bitmap is empty (1 == empty) */ From owner-xfs@oss.sgi.com Mon Dec 3 14:02:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 14:02:10 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from ninsei.hu (ninsei.hu [212.92.23.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB3M21ja018837 for ; Mon, 3 Dec 2007 14:02:05 -0800 Received: from luba (lns-bzn-35-82-250-243-147.adsl.proxad.net [82.250.243.147]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id B941D7A8D for ; Mon, 3 Dec 2007 23:01:27 +0100 (CET) Received: by luba (Postfix, from userid 32266) id 7AB7910B4C1; Mon, 3 Dec 2007 23:01:59 +0100 (CET) Date: Mon, 3 Dec 2007 23:02:00 +0100 From: KELEMEN Peter To: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs Message-ID: <20071203220200.GC13667@luba> Mail-Followup-To: xfs@oss.sgi.com References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47537709.9040406@sgi.com> Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03 X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356 7BF0 8F3E CAB6 9FF0 CABE X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: ClamAV 0.91.2/4984/Mon Dec 3 09:37:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13848 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: xfs * Lachlan Mcilroy (lachlan@sgi.com) [20071203 14:24]: Lachlan, > Okay, sounds like it might be a corrupt log. Yep. > Can you run xfs_logprint on the device or saved log? Sure. http://cern.ch/fuji/lxfsre1103/xfs_logprint1.txt.bz2 It aborted though, with the following message: xfs_logprint: unknown log operation type (343b) Bad data in log > Also give xfs_logprint -t -i a go. http://cern.ch/fuji/lxfsre1103/xfs_logprint2.txt.bz2 > You've saved the log into a file? You can get the filesystem > mounted again by deleting the log with xfs_repair -L . > You'll probably need to run xfs_repair over the filesystem to be > safe. I conserved this filesystem away for further analysis, I'm not sure how helpful it can be. Thanks, Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-xfs@oss.sgi.com Mon Dec 3 16:08:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 16:08:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB408ka2002388 for ; Mon, 3 Dec 2007 16:08:48 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11891 for ; Tue, 4 Dec 2007 11:08:55 +1100 Message-ID: <47549B1A.4070508@sgi.com> Date: Tue, 04 Dec 2007 11:11:06 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> In-Reply-To: <20071203220200.GC13667@luba> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4987/Mon Dec 3 14:00:21 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13849 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Hi Peter, FYI Just a couple of things in case you weren't aware. Often it is simplest to save the log using the -C option to a file. -C filename Copy the log from the filesystem to the file filename. The log itself is not printed. The log can then be analysed in various ways later. Running logprint in operation mode (the default mode without options) (non-transaction mode without -t) is really pretty useless without the -s option. If you use the -s option then one needs to know where to seek to (you can use -t to find the head/tail or -d to see where log records start). The problem here is that if you do logprint like this (no options) then it will start at offset zero and will invariably have trouble decoding if the log has wrapped around (the general case) as you'll start in the middle of a record. So the -t option is often a more interesting starting point as it will operate more like the file system recovery does, finding the head and tail, and processing from the tail to the head of the log. If you want to save the filesystem away for possible metadata debugging later, then xfs_metadump is your friend. Cheers, Tim. KELEMEN Peter wrote: > * Lachlan Mcilroy (lachlan@sgi.com) [20071203 14:24]: > > Lachlan, > >> Okay, sounds like it might be a corrupt log. > > Yep. > >> Can you run xfs_logprint on the device or saved log? > > Sure. > > http://cern.ch/fuji/lxfsre1103/xfs_logprint1.txt.bz2 > It aborted though, with the following message: > > xfs_logprint: unknown log operation type (343b) > Bad data in log > >> Also give xfs_logprint -t -i a go. > > http://cern.ch/fuji/lxfsre1103/xfs_logprint2.txt.bz2 > >> You've saved the log into a file? You can get the filesystem >> mounted again by deleting the log with xfs_repair -L . >> You'll probably need to run xfs_repair over the filesystem to be >> safe. > > I conserved this filesystem away for further analysis, I'm not > sure how helpful it can be. > > Thanks, > Peter > From owner-xfs@oss.sgi.com Mon Dec 3 19:21:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 19:21:28 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB43LKGr030936 for ; Mon, 3 Dec 2007 19:21:23 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA16095; Tue, 4 Dec 2007 14:21:25 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 352D358C4C0F; Tue, 4 Dec 2007 14:21:25 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 973591 - attr update for tree walking Message-Id: <20071204032125.352D358C4C0F@chook.melbourne.sgi.com> Date: Tue, 4 Dec 2007 14:21:25 +1100 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/4990/Mon Dec 3 16:38:56 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13850 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Add some code to the tree walking to better handle file descriptors. Date: Tue Dec 4 14:19:53 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/tes/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:30192a attr/VERSION - 1.71 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/VERSION.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h attr/doc/CHANGES - 1.86 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.86&r2=text&tr2=1.85&f=h xfstests/062.out - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/062.out.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h attr/getfattr/getfattr.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/getfattr/getfattr.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h attr/test/getfattr.test - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/test/getfattr.test.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h attr/libmisc/walk_tree.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libmisc/walk_tree.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h attr/include/walk_tree.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/include/walk_tree.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-xfs@oss.sgi.com Mon Dec 3 20:09:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 20:09:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB449hAI005525 for ; Mon, 3 Dec 2007 20:09:45 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA17103; Tue, 4 Dec 2007 15:09:49 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id C5EF658C4C0F; Tue, 4 Dec 2007 15:09:49 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 973591 - add more code to acl tree walking Message-Id: <20071204040949.C5EF658C4C0F@chook.melbourne.sgi.com> Date: Tue, 4 Dec 2007 15:09:49 +1100 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/4990/Mon Dec 3 16:38:56 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13851 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Add some code to the tree walking to better handle file descriptors. Provided by Andreas G. Date: Tue Dec 4 15:08:45 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/tes/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:30195a acl/VERSION - 1.87 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/VERSION.diff?r1=text&tr1=1.87&r2=text&tr2=1.86&f=h acl/doc/CHANGES - 1.99 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.99&r2=text&tr2=1.98&f=h acl/setfacl/setfacl.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/setfacl.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h acl/setfacl/do_set.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/do_set.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h acl/getfacl/getfacl.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/getfacl/getfacl.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h acl/libmisc/walk_tree.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libmisc/walk_tree.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h acl/include/walk_tree.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/include/walk_tree.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-xfs@oss.sgi.com Mon Dec 3 23:07:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 23:08:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB477qsW008591 for ; Mon, 3 Dec 2007 23:07:55 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA20893; Tue, 4 Dec 2007 18:07:57 +1100 Message-ID: <4754FCEC.30906@sgi.com> Date: Tue, 04 Dec 2007 18:08:28 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Timothy Shimmin CC: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> In-Reply-To: <47549B1A.4070508@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4990/Mon Dec 3 16:38:56 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13852 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs The transactional view appears to be truncated. ============================================================================ TRANS: tid:0x5769cb28 type:STRAT_WRITE #items:5 trans:0x0 q:0x56dfa0 INO: cnt:3 total:3 a:0x56f5e0 len:56 a:0x56f570 len:96 a:0x56df80 len:16 INODE: #regs:3 ino:0x1400005c flags:0x5 dsize:16 CORE inode: magic:IN mode:0x8180 ver:1 format:2 onlink:1 uid:14029 gid:1474 nlink:1 projid:0 atime:1192671344 mtime:1192672095 ctime:1192672095 flushiter:20 size:0x20700000 nblks:0x20740 exsize:0 nextents:1 anextents:0 forkoff:0 dmevmask:0x0 dmstate:0 flags:0x0 gen:4 DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x56dc50 len:24 a:0x56dca0 len:128 BUF: #regs:2 start blkno:0x24610701 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x56ddc0 len:28 a:0x56dd30 len:128 BUF: #regs:2 start blkno:0x24610708 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:3 total:3 a:0x56df20 len:28 a:0x56f010 len:128 a:0x56f160 len:256 BUF: #regs:3 start blkno:0x24610710 len:8 bmap size:2 flags:0x0 BUF DATA BUF DATA BUF: cnt:2 total:2 a:0x56ddf0 len:24 a:0x56f0a0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: LOG REC AT LSN cycle 154 block 5248 (0x9a, 0x1480) ... just stops there. Looking at the non-transactional view at this point: ============================================================================ cycle: 154 version: 2 lsn: 154,5248 tail_lsn: 153,253056 length of Log Record: 61440 prev offset: 5120 num ops: 303 uuid: b02fc6bd-662f-40a5-8f0c-e260a881a3e7 format: little endian linux h_size: 262144 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ---------------------------------------------------------------------------- Oper (0): tid: 5769cd60 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (1): tid: 5769cd60 len: 16 clientid: TRANS flags: none TRAN: type: STRAT_WRITE tid: 0 num_items: 5 ---------------------------------------------------------------------------- Oper (2): tid: 5769cd60 len: 56 clientid: TRANS flags: none INODE: #regs: 3 ino: 0x1400005c flags: 0x5 dsize: 16 blkno: 610338736 len: 16 boff: 4096 Oper (3): tid: 5769cd60 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100600 version 1 format 2 nlink 1 uid 14029 gid 1474 atime 0x4716b870 mtime 0x4716bade ctime 0x4716bade size 0x1ce00000 nblocks 0x1c840 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x4 Oper (4): tid: 5769cd60 len: 16 clientid: TRANS flags: none EXTENTS inode data ---------------------------------------------------------------------------- Oper (5): tid: 5769cf18 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 610338561 (0x24610701) len: 1 bmap size: 1 flags: 0x0 Oper (6): tid: 5769cf18 len: 128 clientid: TRANS flags: none AGF Buffer: XAGF ver: 1 seq#: 5 len: 15258464 root BNO: 1 CNT: 2 level BNO: 1 CNT: 1 1st: 0 last: 3 cnt: 4 freeblks: 2491090 longest: 581471 ---------------------------------------------------------------------------- Oper (7): tid: 5769cf18 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 610338568 (0x24610708) len: 8 bmap size: 2 flags: 0x0 Oper (8): tid: 5769cf18 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (9): tid: 5769cf18 len: 28 clientid: TRANS flags: none BUF: #regs: 3 start blkno: 610338576 (0x24610710) len: 8 bmap size: 2 flags: 0x0 Oper (10): tid: 5769cf18 len: 128 clientid: TRANS flags: none BUF DATA Oper (11): tid: 5769cf18 len: 256 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (12): tid: 5769cf18 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 8647474234504773632 (0x7802000000000000) len: 1 bmap size: 1 flags: 0x0 Oper (13): tid: 5769cf18 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (14): tid: 5769cf18 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (15): tid: 5769c5e8 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (16): tid: 5769c5e8 len: 16 clientid: TRANS flags: none TRAN: type: STRAT_WRITE tid: 0 num_items: 5 ---------------------------------------------------------------------------- Oper (17): tid: 5769c5e8 len: 2145656 clientid: TRANS flags: none ********************************************************************** * ERROR: data block=5255 * ********************************************************************** We should have 5 more items in this transaction plus the commit and then another 286 operations. The operation number and transaction id are correct but the length is bogus. The first item in a STRAT_WRITE transaction should be an inode and the length should be 56. Tim, does this ring any bells with you? The only validation we do on the length is an ASSERT in xlog_recover_process_data() which isn't much good here. I don't know why the value is wrong but we can do better than crashing the system. I would like to know how much more data is corrupt beyond this point. Peter, can you try xfs_logprint -c ...? Timothy Shimmin wrote: > Hi Peter, > > FYI > > Just a couple of things in case you weren't aware. > Often it is simplest to save the log using the -C option to a file. > -C filename > Copy the log from the filesystem to the file filename. > The log itself is not printed. > The log can then be analysed in various ways later. > > Running logprint in operation mode (the default mode without options) > (non-transaction mode without -t) > is really pretty useless without the -s option. > If you use the -s option then one needs to know where to seek to > (you can use -t to find the head/tail or -d to see where log records > start). > The problem here is that if you do logprint > like this (no options) then it will start at offset zero and will > invariably have > trouble decoding if the log has wrapped around (the general case) as > you'll start in the middle of a record. > So the -t option is often a more interesting starting point as it > will operate more like the file system recovery does, finding the head > and tail, > and processing from the tail to the head of the log. > > If you want to save the filesystem away for possible metadata debugging > later, > then xfs_metadump is your friend. > > Cheers, > Tim. > > KELEMEN Peter wrote: >> * Lachlan Mcilroy (lachlan@sgi.com) [20071203 14:24]: >> >> Lachlan, >> >>> Okay, sounds like it might be a corrupt log. >> >> Yep. >> >>> Can you run xfs_logprint on the device or saved log? >> >> Sure. >> >> http://cern.ch/fuji/lxfsre1103/xfs_logprint1.txt.bz2 >> It aborted though, with the following message: >> >> xfs_logprint: unknown log operation type (343b) >> Bad data in log >> >>> Also give xfs_logprint -t -i a go. >> >> http://cern.ch/fuji/lxfsre1103/xfs_logprint2.txt.bz2 >> >>> You've saved the log into a file? You can get the filesystem >>> mounted again by deleting the log with xfs_repair -L . >>> You'll probably need to run xfs_repair over the filesystem to be >>> safe. >> >> I conserved this filesystem away for further analysis, I'm not >> sure how helpful it can be. >> >> Thanks, >> Peter >> > > > From owner-xfs@oss.sgi.com Tue Dec 4 01:57:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 01:57:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from ninsei.hu (ninsei.hu [212.92.23.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB49v6ps007078 for ; Tue, 4 Dec 2007 01:57:09 -0800 Received: from luba (pb-d-128-141-57-222.cern.ch [128.141.57.222]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id C0E9C7A97 for ; Tue, 4 Dec 2007 10:56:38 +0100 (CET) Received: by luba (Postfix, from userid 32266) id E488710A790; Tue, 4 Dec 2007 10:57:10 +0100 (CET) Date: Tue, 4 Dec 2007 10:57:10 +0100 From: KELEMEN Peter To: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs Message-ID: <20071204095710.GD2074@luba> Mail-Followup-To: xfs@oss.sgi.com References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> <4754FCEC.30906@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4754FCEC.30906@sgi.com> Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03 X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356 7BF0 8F3E CAB6 9FF0 CABE X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: ClamAV 0.91.2/4991/Tue Dec 4 00:18:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13854 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: xfs * Lachlan Mcilroy (lachlan@sgi.com) [20071204 18:08]: Lachlan, > The transactional view appears to be truncated. [...] > Peter, can you try xfs_logprint -c ...? xfs_logprint -c -t -i produces an identical transactional dump than what you have seen. http://cern.ch/fuji/lxfsre1103/xfs_logprint_c_t_i.txt You can grab the whole saved log from here (128M uncompressed): http://cern.ch/fuji/lxfsre1103/sdc.xlg.bz2 88a6906567ab44994a0b5c4255c5c619428405dc sdc.xlg HTH, Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-xfs@oss.sgi.com Tue Dec 4 01:57:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 01:57:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from ninsei.hu (ninsei.hu [212.92.23.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB49v6Op007074 for ; Tue, 4 Dec 2007 01:57:09 -0800 Received: from luba (pb-d-128-141-57-222.cern.ch [128.141.57.222]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id 6656F7A92 for ; Tue, 4 Dec 2007 10:56:37 +0100 (CET) Received: by luba (Postfix, from userid 32266) id 4581210A958; Tue, 4 Dec 2007 10:42:28 +0100 (CET) Date: Tue, 4 Dec 2007 10:42:29 +0100 From: KELEMEN Peter To: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs Message-ID: <20071204094229.GC2074@luba> Mail-Followup-To: xfs@oss.sgi.com References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47549B1A.4070508@sgi.com> Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03 X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356 7BF0 8F3E CAB6 9FF0 CABE X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: ClamAV 0.91.2/4991/Tue Dec 4 00:18:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13853 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: xfs * Timothy Shimmin (tes@sgi.com) [20071204 11:11]: Timothy, Thanks for the recommendations. > Often it is simplest to save the log using the -C option to a > file. -C filename [...] The log can then be analysed in various > ways later. I did that (I played with it and did the same thing with dd(1), too). > If you want to save the filesystem away for possible metadata > debugging later, then xfs_metadump is your friend. I'll check this out. I watched Barry implement the thing but we were stuck in the past for a while with xfsprogs-2.6.x. Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-xfs@oss.sgi.com Tue Dec 4 18:11:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 18:11:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB52AvuZ015172 for ; Tue, 4 Dec 2007 18:11:00 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA22820; Wed, 5 Dec 2007 13:11:03 +1100 Message-ID: <475608D8.4070402@sgi.com> Date: Wed, 05 Dec 2007 13:11:36 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 References: <20071203211620.GN115527101@sgi.com> In-Reply-To: <20071203211620.GN115527101@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5001/Tue Dec 4 16:37:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13855 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > The recent change to the internals of xfs_lowbit64 broke it on > ia32 - the code treats the 64bit value as an unsigned long > which is only 32 bits on ia32 and hence throws away the high 32 > bits. 64 bit platforms are not affected. > > Tested with a userspace implementation comparing the original > code with the new code. > > Signed-off-by: Dave Chinner > --- > fs/xfs/xfs_bit.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 13:44:45.000000000 +1100 > +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 > @@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > /* Get low bit set out of 64-bit argument, -1 if none set */ > static inline int xfs_lowbit64(__uint64_t v) > { > - unsigned long t = v; > - return (v) ? find_first_bit(&t, 64) : -1; > + unsigned long long t = v; Why create a local copy? Why not just pass v into find_first_bit()? > + return (v) ? find_first_bit((unsigned long *)&t, 64) : -1; > } > > /* Return whether bitmap is empty (1 == empty) */ > > > From owner-xfs@oss.sgi.com Tue Dec 4 18:31:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 18:31:35 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB52VOVU018143 for ; Tue, 4 Dec 2007 18:31:30 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA23338; Wed, 5 Dec 2007 13:31:30 +1100 Message-ID: <47560DA4.4090605@sgi.com> Date: Wed, 05 Dec 2007 13:32:04 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-dev , xfs-oss Subject: Re: Fix xfs_ichgtime mainline breakage. References: <20071203074345.GW119954183@sgi.com> In-Reply-To: <20071203074345.GW119954183@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5001/Tue Dec 4 16:37:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13856 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Looks good Dave. Thanks for catching that. David Chinner wrote: > Folks, > > Just noticed with the mainline merge (2.6.24-rc3) to xfs-dev that > xfs_ichgtime + xfs_ichgtime_fast are broken. > > if (!(inode->i_state & I_SYNC)) > mark_inode_dirty_sync(inode); > > that check used to be against I_LOCK, which was arguably broken, > but this one will mean newly created files are not put on the dirty > list and hence not written back by pdflush. > > Patch to fix this attached. > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Tue Dec 4 19:21:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 19:21:33 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB53LPY8024338 for ; Tue, 4 Dec 2007 19:21:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA24352; Wed, 5 Dec 2007 14:21:30 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB53LTdD131726475; Wed, 5 Dec 2007 14:21:29 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB53LSGT132723036; Wed, 5 Dec 2007 14:21:28 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 5 Dec 2007 14:21:28 +1100 From: David Chinner To: Lachlan McIlroy Cc: David Chinner , xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 Message-ID: <20071205032128.GB115527101@sgi.com> References: <20071203211620.GN115527101@sgi.com> <475608D8.4070402@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475608D8.4070402@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5003/Tue Dec 4 18:25:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13857 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Dec 05, 2007 at 01:11:36PM +1100, Lachlan McIlroy wrote: > David Chinner wrote: > >The recent change to the internals of xfs_lowbit64 broke it on > >ia32 - the code treats the 64bit value as an unsigned long > >which is only 32 bits on ia32 and hence throws away the high 32 > >bits. 64 bit platforms are not affected. > > > >Tested with a userspace implementation comparing the original > >code with the new code. > > > >Signed-off-by: Dave Chinner > >--- > > fs/xfs/xfs_bit.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > >Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > >=================================================================== > >--- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 > >13:44:45.000000000 +1100 > >+++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 > >@@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > > /* Get low bit set out of 64-bit argument, -1 if none set */ > > static inline int xfs_lowbit64(__uint64_t v) > > { > >- unsigned long t = v; > >- return (v) ? find_first_bit(&t, 64) : -1; > >+ unsigned long long t = v; > Why create a local copy? Why not just pass v into find_first_bit()? Because I thought that taking the address of a function parameter was a big no-no because the result is undefined (i.e. platform and compiler dependent)? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 4 21:36:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 21:36:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB55aMrf013615 for ; Tue, 4 Dec 2007 21:36:24 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA26779; Wed, 5 Dec 2007 16:36:27 +1100 Message-ID: <475638FD.9090208@sgi.com> Date: Wed, 05 Dec 2007 16:37:01 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 References: <20071203211620.GN115527101@sgi.com> <475608D8.4070402@sgi.com> <20071205032128.GB115527101@sgi.com> In-Reply-To: <20071205032128.GB115527101@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5004/Tue Dec 4 19:43:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13858 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Wed, Dec 05, 2007 at 01:11:36PM +1100, Lachlan McIlroy wrote: >> David Chinner wrote: >>> The recent change to the internals of xfs_lowbit64 broke it on >>> ia32 - the code treats the 64bit value as an unsigned long >>> which is only 32 bits on ia32 and hence throws away the high 32 >>> bits. 64 bit platforms are not affected. >>> >>> Tested with a userspace implementation comparing the original >>> code with the new code. >>> >>> Signed-off-by: Dave Chinner >>> --- >>> fs/xfs/xfs_bit.h | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h >>> =================================================================== >>> --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 >>> 13:44:45.000000000 +1100 >>> +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 >>> @@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ >>> /* Get low bit set out of 64-bit argument, -1 if none set */ >>> static inline int xfs_lowbit64(__uint64_t v) >>> { >>> - unsigned long t = v; >>> - return (v) ? find_first_bit(&t, 64) : -1; >>> + unsigned long long t = v; >> Why create a local copy? Why not just pass v into find_first_bit()? > > Because I thought that taking the address of a function parameter > was a big no-no because the result is undefined (i.e. platform and > compiler dependent)? > Really? Didn't occur to me but then I can't say for sure I've ever used the address of an argument. If we need a local copy then why not use __unit64_t instead of unsigned long long? From owner-xfs@oss.sgi.com Tue Dec 4 21:44:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 21:44:37 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB55iG6T015068 for ; Tue, 4 Dec 2007 21:44:21 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA26957; Wed, 5 Dec 2007 16:44:22 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB55iMdD130080993; Wed, 5 Dec 2007 16:44:22 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB55iLXb132842042; Wed, 5 Dec 2007 16:44:21 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 5 Dec 2007 16:44:21 +1100 From: David Chinner To: Lachlan McIlroy Cc: David Chinner , xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 Message-ID: <20071205054421.GD115527101@sgi.com> References: <20071203211620.GN115527101@sgi.com> <475608D8.4070402@sgi.com> <20071205032128.GB115527101@sgi.com> <475638FD.9090208@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475638FD.9090208@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5004/Tue Dec 4 19:43:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13859 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Dec 05, 2007 at 04:37:01PM +1100, Lachlan McIlroy wrote: > David Chinner wrote: > >On Wed, Dec 05, 2007 at 01:11:36PM +1100, Lachlan McIlroy wrote: > >>David Chinner wrote: > >>>The recent change to the internals of xfs_lowbit64 broke it on > >>>ia32 - the code treats the 64bit value as an unsigned long > >>>which is only 32 bits on ia32 and hence throws away the high 32 > >>>bits. 64 bit platforms are not affected. > >>> > >>>Tested with a userspace implementation comparing the original > >>>code with the new code. > >>> > >>>Signed-off-by: Dave Chinner > >>>--- > >>>fs/xfs/xfs_bit.h | 4 ++-- > >>>1 file changed, 2 insertions(+), 2 deletions(-) > >>> > >>>Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > >>>=================================================================== > >>>--- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 > >>>13:44:45.000000000 +1100 > >>>+++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 > >>>@@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > >>>/* Get low bit set out of 64-bit argument, -1 if none set */ > >>>static inline int xfs_lowbit64(__uint64_t v) > >>>{ > >>>- unsigned long t = v; > >>>- return (v) ? find_first_bit(&t, 64) : -1; > >>>+ unsigned long long t = v; > >>Why create a local copy? Why not just pass v into find_first_bit()? > > > >Because I thought that taking the address of a function parameter > >was a big no-no because the result is undefined (i.e. platform and > >compiler dependent)? > > > > Really? Didn't occur to me but then I can't say for sure I've ever > used the address of an argument. If we need a local copy then why > not use __unit64_t instead of unsigned long long? Whatever. They are both the same. xfs/xfs_types.h 41 typedef unsigned long long int __uint64_t; Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 4 21:46:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 21:47:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB55kqRF015590 for ; Tue, 4 Dec 2007 21:46:55 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA27144; Wed, 5 Dec 2007 16:46:58 +1100 Message-ID: <47563B73.2030403@sgi.com> Date: Wed, 05 Dec 2007 16:47:31 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: lachlan@sgi.com CC: Timothy Shimmin , xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> <4754FCEC.30906@sgi.com> In-Reply-To: <4754FCEC.30906@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5004/Tue Dec 4 19:43:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13860 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs > ============================================================================ > > cycle: 154 version: 2 lsn: 154,5248 tail_lsn: 153,253056 > length of Log Record: 61440 prev offset: 5120 num ops: 303 > uuid: b02fc6bd-662f-40a5-8f0c-e260a881a3e7 format: little endian linux > h_size: 262144 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ---------------------------------------------------------------------------- > > Oper (0): tid: 5769cd60 len: 0 clientid: TRANS flags: START > ---------------------------------------------------------------------------- > > Oper (1): tid: 5769cd60 len: 16 clientid: TRANS flags: none > TRAN: type: STRAT_WRITE tid: 0 num_items: 5 > ---------------------------------------------------------------------------- > > Oper (2): tid: 5769cd60 len: 56 clientid: TRANS flags: none > INODE: #regs: 3 ino: 0x1400005c flags: 0x5 dsize: 16 > blkno: 610338736 len: 16 boff: 4096 > Oper (3): tid: 5769cd60 len: 96 clientid: TRANS flags: none > INODE CORE > magic 0x494e mode 0100600 version 1 format 2 > nlink 1 uid 14029 gid 1474 > atime 0x4716b870 mtime 0x4716bade ctime 0x4716bade > size 0x1ce00000 nblocks 0x1c840 extsize 0x0 nextents 0x1 > naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 > flags 0x0 gen 0x4 > Oper (4): tid: 5769cd60 len: 16 clientid: TRANS flags: none > EXTENTS inode data > ---------------------------------------------------------------------------- Another interesting point is that the transaction id has changed between these operations from 5769cd60 to 5769cf18. It should stay the same. We may be reading old log data. > > Oper (5): tid: 5769cf18 len: 24 clientid: TRANS flags: none > BUF: #regs: 2 start blkno: 610338561 (0x24610701) len: 1 bmap size: > 1 flags: 0x0 > Oper (6): tid: 5769cf18 len: 128 clientid: TRANS flags: none > AGF Buffer: XAGF > ver: 1 seq#: 5 len: 15258464 > root BNO: 1 CNT: 2 > level BNO: 1 CNT: 1 > 1st: 0 last: 3 cnt: 4 freeblks: 2491090 longest: 581471 > ---------------------------------------------------------------------------- > > Oper (7): tid: 5769cf18 len: 28 clientid: TRANS flags: none > BUF: #regs: 2 start blkno: 610338568 (0x24610708) len: 8 bmap size: > 2 flags: 0x0 > Oper (8): tid: 5769cf18 len: 128 clientid: TRANS flags: none > BUF DATA > ---------------------------------------------------------------------------- > From owner-xfs@oss.sgi.com Tue Dec 4 22:36:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 22:36:26 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB56a3HG022599 for ; Tue, 4 Dec 2007 22:36:05 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA28209; Wed, 5 Dec 2007 17:36:09 +1100 Message-ID: <47564761.9070805@sgi.com> Date: Wed, 05 Dec 2007 17:38:25 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: lachlan@sgi.com CC: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> <4754FCEC.30906@sgi.com> <47563B73.2030403@sgi.com> In-Reply-To: <47563B73.2030403@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5004/Tue Dec 4 19:43:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13862 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Lachlan, An aside... I think I see why we couldn't get "xfs_logprint -t" to work on a file (-f). > xfs_logprint -t -f ~/debug/sdc.xlg xfs_logprint: data device: 0xffffffffffffffff log device: 0xffffffffffffffff daddr: 0 length: 262144 XFS: Log inconsistent (didn't find previous header) XFS: failed to find log head xfs_logprint: failed to find head and tail, error: 5 The problem is that it is using the superblock to determine if it is version 1 or version 2 logs in order to find out the maximum size of the iclog (log record). And for -f there is no superblock to look at. The version number is, however, in the log record header. So when it looks in the undefined data it comes up with _not_ version 2, and so assumes to look back for the hdr to only 32K when it really needs to look back to 64k (for v2 it would limit at 256K). Hence, it can't find the magic# in the header. The debugging... ==================================================== Breakpoint 1, xlog_find_verify_log_record (log=0x607ffffffea96be0, start_blk=5312, last_blk=0x607ffffffea96bc0, extra_bblks=0) at xfs_log_recover.c:234 234 if (!(bp = xlog_get_bp(log, num_blks))) { (gdb) bt #0 xlog_find_verify_log_record (log=0x607ffffffea96be0, start_blk=5312, last_blk=0x607ffffffea96bc0, extra_bblks=0) at xfs_log_recover.c:234 #1 0x4000000000092020 in xlog_find_head (log=0x607ffffffea96be0, return_head_blk=0x607ffffffea96bd0) at xfs_log_recover.c:527 #2 0x4000000000094000 in xlog_find_tail (log=0x607ffffffea96be0, head_blk=0x607ffffffea96bd0, tail_blk=0x607ffffffea96bd8, readonly=0) at xfs_log_recover.c:616 #3 0x40000000000100a0 in xfs_log_print_trans (log=0x607ffffffea96be0, print_block_start=-1) at log_print_trans.c:49 #4 0x4000000000003600 in main (argc=, argv=) at logprint.c:240 (gdb) print *last_blk $1 = 5376 start_blk = 5312 last_blk = 5376 extra_bblks = 0 Goes from 5376..5312 looking for magic# at start of sector. Errors out if can't find one. Which is true since the next magic# is at 5248. logprint -d output: 4992 HEADER Cycle 154 tail 153:253056 len 61440 ops 105 5120 HEADER Cycle 154 tail 153:253056 len 61440 ops 344 5248 HEADER Cycle 154 tail 153:253056 len 61440 ops 303 <--- previous block 5376 HEADER Cycle 153 tail 153:253056 len 0 ops 0 <--- hdr [00000 - 05376] Cycle 0x0000009a New Cycle 0x00000099 5377 HEADER Cycle 153 tail 153:253056 len 0 ops 0 5378 HEADER Cycle 153 tail 153:253056 len 0 ops 0 So why is it using a start_blk of 5312? 522 num_scan_bblks = XLOG_REC_SHIFT(log); 523 if (head_blk >= num_scan_bblks) { 524 start_blk = head_blk - num_scan_bblks; /* don't read head_blk */ 525 526 /* start ptr at last block ptr before head_blk */ ->527 if ((error = xlog_find_verify_log_record(log, start_blk, 528 &head_blk, 0)) == -1) { #define XLOG_REC_SHIFT(log) \ BTOBB(1 << (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? \ XLOG_MAX_RECORD_BSHIFT : XLOG_BIG_RECORD_BSHIFT)) #define XLOG_BIG_RECORD_BSHIFT 15 /* 32k == 1 << 15 */ #define XLOG_MAX_RECORD_BSHIFT 18 /* 256k == 1 << 18 */ Number of blocks between rec-hdrs from -d output: 5376-5248 = 128 BB Looks like it used 5312 = 5376 - num_scan_bblks => num_scan_bblks = 64 Yep (gdb) p num_scan_bblks $3 = 64 32K i.e. it thinks it has v1 logs (gdb) p *(log->l_mp) $9 = {m_sb = {sb_magicnum = 0, sb_blocksize = 0, sb_dblocks = 0, sb_rblocks = 0, sb_rextents = 0, sb_uuid = '\0' , sb_logstart = 2305843009213997776, sb_rootino = 6953557824646229696, sb_rbmino = 6953557824646229688, sb_rsumino = 6953557824646229680, sb_rextsize = 284472, sb_agblocks = 536870912, sb_agcount = 4281151176, sb_rbmblocks = 1619001343, sb_logblocks = 0, sb_versionnum = 0, sb_sectsize = 0, sb_inodesize = 38256, sb_inopblock = 4, sb_fname = "\000\000\000 H?\a\000\000\000\000 ", sb_blocklog = 0 '\0', etc... it is not set Okay, need to file a bug for this part so that -f can be useful here. It needs to be using a LR h_version number for this somehow. --Tim Lachlan McIlroy wrote: >> ============================================================================ >> >> cycle: 154 version: 2 lsn: 154,5248 tail_lsn: 153,253056 >> length of Log Record: 61440 prev offset: 5120 num ops: 303 >> uuid: b02fc6bd-662f-40a5-8f0c-e260a881a3e7 format: little endian linux >> h_size: 262144 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ---------------------------------------------------------------------------- >> >> Oper (0): tid: 5769cd60 len: 0 clientid: TRANS flags: START >> ---------------------------------------------------------------------------- >> >> Oper (1): tid: 5769cd60 len: 16 clientid: TRANS flags: none >> TRAN: type: STRAT_WRITE tid: 0 num_items: 5 >> ---------------------------------------------------------------------------- >> >> Oper (2): tid: 5769cd60 len: 56 clientid: TRANS flags: none >> INODE: #regs: 3 ino: 0x1400005c flags: 0x5 dsize: 16 >> blkno: 610338736 len: 16 boff: 4096 >> Oper (3): tid: 5769cd60 len: 96 clientid: TRANS flags: none >> INODE CORE >> magic 0x494e mode 0100600 version 1 format 2 >> nlink 1 uid 14029 gid 1474 >> atime 0x4716b870 mtime 0x4716bade ctime 0x4716bade >> size 0x1ce00000 nblocks 0x1c840 extsize 0x0 nextents 0x1 >> naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 >> flags 0x0 gen 0x4 >> Oper (4): tid: 5769cd60 len: 16 clientid: TRANS flags: none >> EXTENTS inode data >> ---------------------------------------------------------------------------- > > > Another interesting point is that the transaction id has changed between > these operations from 5769cd60 to 5769cf18. It should stay the same. > We may be reading old log data. > >> >> Oper (5): tid: 5769cf18 len: 24 clientid: TRANS flags: none >> BUF: #regs: 2 start blkno: 610338561 (0x24610701) len: 1 bmap >> size: 1 flags: 0x0 >> Oper (6): tid: 5769cf18 len: 128 clientid: TRANS flags: none >> AGF Buffer: XAGF >> ver: 1 seq#: 5 len: 15258464 >> root BNO: 1 CNT: 2 >> level BNO: 1 CNT: 1 >> 1st: 0 last: 3 cnt: 4 freeblks: 2491090 longest: 581471 >> ---------------------------------------------------------------------------- >> >> Oper (7): tid: 5769cf18 len: 28 clientid: TRANS flags: none >> BUF: #regs: 2 start blkno: 610338568 (0x24610708) len: 8 bmap >> size: 2 flags: 0x0 >> Oper (8): tid: 5769cf18 len: 128 clientid: TRANS flags: none >> BUF DATA >> ---------------------------------------------------------------------------- >> From owner-xfs@oss.sgi.com Tue Dec 4 22:35:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 22:35:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB56ZDcw022473 for ; Tue, 4 Dec 2007 22:35:18 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA28193; Wed, 5 Dec 2007 17:35:18 +1100 Message-ID: <475646C8.6070700@sgi.com> Date: Wed, 05 Dec 2007 17:35:52 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 References: <20071203211620.GN115527101@sgi.com> <475608D8.4070402@sgi.com> <20071205032128.GB115527101@sgi.com> <475638FD.9090208@sgi.com> <20071205054421.GD115527101@sgi.com> In-Reply-To: <20071205054421.GD115527101@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5004/Tue Dec 4 19:43:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13861 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Wed, Dec 05, 2007 at 04:37:01PM +1100, Lachlan McIlroy wrote: >> David Chinner wrote: >>> On Wed, Dec 05, 2007 at 01:11:36PM +1100, Lachlan McIlroy wrote: >>>> David Chinner wrote: >>>>> The recent change to the internals of xfs_lowbit64 broke it on >>>>> ia32 - the code treats the 64bit value as an unsigned long >>>>> which is only 32 bits on ia32 and hence throws away the high 32 >>>>> bits. 64 bit platforms are not affected. >>>>> >>>>> Tested with a userspace implementation comparing the original >>>>> code with the new code. >>>>> >>>>> Signed-off-by: Dave Chinner >>>>> --- >>>>> fs/xfs/xfs_bit.h | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h >>>>> =================================================================== >>>>> --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 >>>>> 13:44:45.000000000 +1100 >>>>> +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 >>>>> @@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ >>>>> /* Get low bit set out of 64-bit argument, -1 if none set */ >>>>> static inline int xfs_lowbit64(__uint64_t v) >>>>> { >>>>> - unsigned long t = v; >>>>> - return (v) ? find_first_bit(&t, 64) : -1; >>>>> + unsigned long long t = v; >>>> Why create a local copy? Why not just pass v into find_first_bit()? >>> Because I thought that taking the address of a function parameter >>> was a big no-no because the result is undefined (i.e. platform and >>> compiler dependent)? >>> >> Really? Didn't occur to me but then I can't say for sure I've ever >> used the address of an argument. If we need a local copy then why >> not use __unit64_t instead of unsigned long long? > > Whatever. They are both the same. > > xfs/xfs_types.h 41 typedef unsigned long long int __uint64_t; > Figured they would be. Using the same type probably would have avoided the bug in the first place. Otherwise the change is good. From owner-xfs@oss.sgi.com Tue Dec 4 23:03:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 23:04:09 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB573rkl027788 for ; Tue, 4 Dec 2007 23:03:56 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28759; Wed, 5 Dec 2007 18:03:59 +1100 Message-ID: <47564D81.2040204@sgi.com> Date: Wed, 05 Dec 2007 18:04:33 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Timothy Shimmin CC: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> <4754FCEC.30906@sgi.com> <47563B73.2030403@sgi.com> <47564761.9070805@sgi.com> In-Reply-To: <47564761.9070805@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5007/Tue Dec 4 22:29:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13863 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Thanks Tim. Timothy Shimmin wrote: > Lachlan, > > An aside... > > I think I see why we couldn't get "xfs_logprint -t" to work on a file (-f). > > xfs_logprint -t -f ~/debug/sdc.xlg > xfs_logprint: > data device: 0xffffffffffffffff > log device: 0xffffffffffffffff daddr: 0 length: 262144 > > XFS: Log inconsistent (didn't find previous header) > XFS: failed to find log head > xfs_logprint: failed to find head and tail, error: 5 > > The problem is that it is using the superblock to determine if it is > version 1 > or version 2 logs in order to find out the maximum size of the iclog > (log record). > And for -f there is no superblock to look at. The version number is, > however, in the > log record header. > So when it looks in the undefined data it comes up with _not_ version 2, > and so assumes to look back for the hdr to only 32K when it really needs > to look back to 64k (for v2 it would limit at 256K). > Hence, it can't find the magic# in the header. > > The debugging... > > ==================================================== > Breakpoint 1, xlog_find_verify_log_record (log=0x607ffffffea96be0, > start_blk=5312, last_blk=0x607ffffffea96bc0, extra_bblks=0) > at xfs_log_recover.c:234 > 234 if (!(bp = xlog_get_bp(log, num_blks))) { > (gdb) bt > #0 xlog_find_verify_log_record (log=0x607ffffffea96be0, start_blk=5312, > last_blk=0x607ffffffea96bc0, extra_bblks=0) at xfs_log_recover.c:234 > #1 0x4000000000092020 in xlog_find_head (log=0x607ffffffea96be0, > return_head_blk=0x607ffffffea96bd0) at xfs_log_recover.c:527 > #2 0x4000000000094000 in xlog_find_tail (log=0x607ffffffea96be0, > head_blk=0x607ffffffea96bd0, tail_blk=0x607ffffffea96bd8, readonly=0) > at xfs_log_recover.c:616 > #3 0x40000000000100a0 in xfs_log_print_trans (log=0x607ffffffea96be0, > print_block_start=-1) at log_print_trans.c:49 > #4 0x4000000000003600 in main (argc=, argv= optimized out>) at logprint.c:240 > > (gdb) print *last_blk > $1 = 5376 > > start_blk = 5312 > last_blk = 5376 > extra_bblks = 0 > > Goes from 5376..5312 looking for magic# at start of sector. > Errors out if can't find one. > Which is true since the next magic# is at 5248. > > logprint -d output: > 4992 HEADER Cycle 154 tail 153:253056 len 61440 ops 105 > 5120 HEADER Cycle 154 tail 153:253056 len 61440 ops 344 > 5248 HEADER Cycle 154 tail 153:253056 len 61440 ops 303 <--- > previous block > 5376 HEADER Cycle 153 tail 153:253056 len 0 ops 0 <--- hdr > [00000 - 05376] Cycle 0x0000009a New Cycle 0x00000099 > 5377 HEADER Cycle 153 tail 153:253056 len 0 ops 0 > 5378 HEADER Cycle 153 tail 153:253056 len 0 ops 0 > > So why is it using a start_blk of 5312? > > > 522 num_scan_bblks = XLOG_REC_SHIFT(log); > 523 if (head_blk >= num_scan_bblks) { > 524 start_blk = head_blk - num_scan_bblks; /* don't > read head_blk */ > 525 > 526 /* start ptr at last block ptr before head_blk */ > ->527 if ((error = xlog_find_verify_log_record(log, > start_blk, > 528 > &head_blk, 0)) == -1) { > > #define XLOG_REC_SHIFT(log) \ > BTOBB(1 << (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? \ > XLOG_MAX_RECORD_BSHIFT : XLOG_BIG_RECORD_BSHIFT)) > > #define XLOG_BIG_RECORD_BSHIFT 15 /* 32k == 1 << 15 */ > #define XLOG_MAX_RECORD_BSHIFT 18 /* 256k == 1 << 18 */ > > Number of blocks between rec-hdrs from -d output: > 5376-5248 = 128 BB > > Looks like it used 5312 = 5376 - num_scan_bblks > => num_scan_bblks = 64 > > Yep > (gdb) p num_scan_bblks > $3 = 64 > 32K > i.e. it thinks it has v1 logs > > (gdb) p *(log->l_mp) > $9 = {m_sb = {sb_magicnum = 0, sb_blocksize = 0, sb_dblocks = 0, > sb_rblocks = 0, sb_rextents = 0, sb_uuid = '\0' , > sb_logstart = 2305843009213997776, sb_rootino = 6953557824646229696, > sb_rbmino = 6953557824646229688, sb_rsumino = 6953557824646229680, > sb_rextsize = 284472, sb_agblocks = 536870912, sb_agcount = > 4281151176, sb_rbmblocks = 1619001343, sb_logblocks = 0, sb_versionnum = 0, > sb_sectsize = 0, sb_inodesize = 38256, sb_inopblock = 4, sb_fname = > "\000\000\000 H?\a\000\000\000\000 ", sb_blocklog = 0 '\0', > etc... > it is not set > > Okay, need to file a bug for this part so that -f can be useful here. > It needs to be using a LR h_version number for this somehow. > > --Tim > > > Lachlan McIlroy wrote: >>> ============================================================================ >>> >>> cycle: 154 version: 2 lsn: 154,5248 tail_lsn: 153,253056 >>> length of Log Record: 61440 prev offset: 5120 num ops: 303 >>> uuid: b02fc6bd-662f-40a5-8f0c-e260a881a3e7 format: little endian linux >>> h_size: 262144 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ---------------------------------------------------------------------------- >>> >>> Oper (0): tid: 5769cd60 len: 0 clientid: TRANS flags: START >>> ---------------------------------------------------------------------------- >>> >>> Oper (1): tid: 5769cd60 len: 16 clientid: TRANS flags: none >>> TRAN: type: STRAT_WRITE tid: 0 num_items: 5 >>> ---------------------------------------------------------------------------- >>> >>> Oper (2): tid: 5769cd60 len: 56 clientid: TRANS flags: none >>> INODE: #regs: 3 ino: 0x1400005c flags: 0x5 dsize: 16 >>> blkno: 610338736 len: 16 boff: 4096 >>> Oper (3): tid: 5769cd60 len: 96 clientid: TRANS flags: none >>> INODE CORE >>> magic 0x494e mode 0100600 version 1 format 2 >>> nlink 1 uid 14029 gid 1474 >>> atime 0x4716b870 mtime 0x4716bade ctime 0x4716bade >>> size 0x1ce00000 nblocks 0x1c840 extsize 0x0 nextents 0x1 >>> naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 >>> flags 0x0 gen 0x4 >>> Oper (4): tid: 5769cd60 len: 16 clientid: TRANS flags: none >>> EXTENTS inode data >>> ---------------------------------------------------------------------------- >> >> >> >> Another interesting point is that the transaction id has changed between >> these operations from 5769cd60 to 5769cf18. It should stay the same. >> We may be reading old log data. >> >>> >>> Oper (5): tid: 5769cf18 len: 24 clientid: TRANS flags: none >>> BUF: #regs: 2 start blkno: 610338561 (0x24610701) len: 1 bmap >>> size: 1 flags: 0x0 >>> Oper (6): tid: 5769cf18 len: 128 clientid: TRANS flags: none >>> AGF Buffer: XAGF >>> ver: 1 seq#: 5 len: 15258464 >>> root BNO: 1 CNT: 2 >>> level BNO: 1 CNT: 1 >>> 1st: 0 last: 3 cnt: 4 freeblks: 2491090 longest: 581471 >>> ---------------------------------------------------------------------------- >>> >>> Oper (7): tid: 5769cf18 len: 28 clientid: TRANS flags: none >>> BUF: #regs: 2 start blkno: 610338568 (0x24610708) len: 8 bmap >>> size: 2 flags: 0x0 >>> Oper (8): tid: 5769cf18 len: 128 clientid: TRANS flags: none >>> BUF DATA >>> ---------------------------------------------------------------------------- >>> > > > From owner-xfs@oss.sgi.com Wed Dec 5 04:26:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 04:26:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,J_CHICKENPOX_23, J_CHICKENPOX_24,J_CHICKENPOX_25,J_CHICKENPOX_27,J_CHICKENPOX_38, J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from yergi.telenet-ops.be (yergi.telenet-ops.be [195.130.132.36]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB5CQ4OR010596 for ; Wed, 5 Dec 2007 04:26:06 -0800 Received: from astra.telenet-ops.be (unknown [195.130.132.58]) by yergi.telenet-ops.be (Postfix) with ESMTP id EA2BF5CA424 for ; Wed, 5 Dec 2007 13:16:00 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id 6AEBC38103 for ; Wed, 5 Dec 2007 13:15:55 +0100 (CET) Received: from [81.164.41.199] (d51A429C7.access.telenet.be [81.164.41.199]) by astra.telenet-ops.be (Postfix) with ESMTP id C9F26380F4 for ; Wed, 5 Dec 2007 13:15:52 +0100 (CET) Message-ID: <475696D3.60007@pandora.be> Date: Wed, 05 Dec 2007 13:17:23 +0100 From: Denis Wegge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: XFS unable to mount, recover data Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5011/Wed Dec 5 01:42:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13864 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: denis_wegge@pandora.be Precedence: bulk X-list: xfs Hello I am having trouble with the XFS filesystem on a 320GB Western Digital SATA harddisk. For no obvious reason the partition can no longer be mounted. The following error occurs: knoppix@Knoppix:~$ sudo mount /dev/sda1 /mnt/sda1 mount: /dev/sda1: can't read superblock I tried to repair the filesystem with xfs_repair, but that didn't work. knoppix@Knoppix:~$ sudo xfs_repair /dev/sda1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... xfs_repair: read failed: Input/output error I would like to recover the data on that disk. Unfortunately there isn't enough space on any other disk to copy the partition to. I tried to copy it partially with dd, but the image wouldn't mount. Is there any way to recover the data on the partition? The SMART info of the disk doesn't look very good either. Below you can find the following information: - dmesg messages after the failed mount - the output of xfs_repair -n - some outputs of a check for bad blocks - SMART information (with errors!) dmesg: ===================================================================== XFS mounting filesystem sda1 ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) sd 2:0:0:0: SCSI error: return code = 0x08000002 sda: Current: sense key=0x3 ASC=0x11 ASCQ=0x4 end_request: I/O error, dev sda, sector 312632262 ata3: EH complete I/O error in filesystem ("sda1") meta-data dev sda1 block 0x12a26387 ("xlog_bread") error 5 buf count 512 XFS: failed to find log head XFS: log mount/recovery failed: error 5 XFS: log mount failed xfs_repair -n ===================================================================== knoppix@Knoppix:~$ sudo xfs_repair -n /dev/sda1 Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. badblocks ===================================================================== knoppix@0[knoppix]$ sudo badblocks -v /dev/sda1 10000000 Checking blocks 0 to 10000000 Checking for bad blocks (read-only test): done Pass completed, 0 bad blocks found. knoppix@0[knoppix]$ sudo badblocks -v /dev/sda1 299879969 299879649 Checking blocks 299879649 to 299879969 Checking for bad blocks (read-only test): 299879649879649/ done Pass completed, 12 bad blocks found. knoppix@0[knoppix]$ sudo badblocks -v /dev/sda1 300013300 300013113 Checking blocks 300013113 to 300013300 Checking for bad blocks (read-only test): 300013113013113/ done Pass completed, 15 bad blocks found. knoppix@3[knoppix]$ sudo badblocks -v /dev/sda1 312568641 310000000 Checking blocks 310000000 to 312568641 Checking for bad blocks (read-only test): done 641 Pass completed, 0 bad blocks found. SMART ===================================================================== denis@athena64:~$ sudo smartctl -a /dev/sda smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Western Digital Caviar SE16 family Device Model: WDC WD3200KS-00PFB0 Serial Number: WD-WCAPD1467148 Firmware Version: 21.00M21 User Capacity: 320,072,933,376 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Wed Dec 5 13:00:40 2007 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: FAILED! Drive failure expected in less than 24 hours. SAVE ALL DATA. See vendor-specific Attribute list for failed Attributes. General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 73) The previous self-test completed having a test element that failed and the test element that failed is not known. Total time to complete Offline data collection: (9600) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 111) minutes. Conveyance self-test routine recommended polling time: ( 6) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0003 239 223 021 Pre-fail Always - 3041 4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 1142 5 Reallocated_Sector_Ct 0x0033 104 104 140 Pre-fail Always FAILING_NOW 763 7 Seek_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0 9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 4326 10 Spin_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1139 194 Temperature_Celsius 0x0022 120 001 000 Old_age Always - 30 196 Reallocated_Event_Count 0x0032 001 001 000 Old_age Always - 763 197 Current_Pending_Sector 0x0012 200 187 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 200 190 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0009 001 001 051 Pre-fail Offline FAILING_NOW 55696 SMART Error Log Version: 1 ATA Error Count: 17663 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 17663 occurred at disk power-on lifetime: 4323 hours (180 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 ce 63 a2 e0 Error: UNC 1 sectors at LBA = 0x00a263ce = 10642382 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 01 ce 63 a2 12 00 16:06:59.549 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:59.549 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:57.499 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:57.499 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:55.264 READ DMA EXT Error 17662 occurred at disk power-on lifetime: 4323 hours (180 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 ce 63 a2 e0 Error: UNC 1 sectors at LBA = 0x00a263ce = 10642382 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 01 ce 63 a2 12 00 16:06:57.499 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:57.499 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:55.264 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:55.264 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:53.212 READ DMA EXT Error 17661 occurred at disk power-on lifetime: 4323 hours (180 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 ce 63 a2 e0 Error: UNC 1 sectors at LBA = 0x00a263ce = 10642382 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 01 ce 63 a2 12 00 16:06:55.264 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:55.264 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:53.212 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:53.212 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:51.165 READ DMA EXT Error 17660 occurred at disk power-on lifetime: 4323 hours (180 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 ce 63 a2 e0 Error: UNC 1 sectors at LBA = 0x00a263ce = 10642382 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 01 ce 63 a2 12 00 16:06:53.212 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:53.212 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:51.165 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:51.165 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:49.280 READ DMA EXT Error 17659 occurred at disk power-on lifetime: 4323 hours (180 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 ce 63 a2 e0 Error: UNC 1 sectors at LBA = 0x00a263ce = 10642382 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 01 ce 63 a2 12 00 16:06:51.165 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:51.165 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:49.280 READ DMA EXT 25 00 01 be 63 a2 12 00 16:06:49.280 READ DMA EXT 25 00 01 de 63 a2 12 00 16:06:49.264 READ DMA EXT SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: unknown failure 90% 4324 - # 2 Conveyance offline Completed: unknown failure 90% 4324 - # 3 Short offline Completed: unknown failure 90% 4323 - # 4 Extended offline Completed: read failure 90% 53 158966062 SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. From owner-xfs@oss.sgi.com Wed Dec 5 04:46:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 04:47:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB5Ckt75013901 for ; Wed, 5 Dec 2007 04:46:58 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id C54681C00023F; Wed, 5 Dec 2007 07:47:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id C34884019AA0; Wed, 5 Dec 2007 07:47:05 -0500 (EST) Date: Wed, 5 Dec 2007 07:47:05 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Denis Wegge cc: xfs@oss.sgi.com Subject: Re: XFS unable to mount, recover data In-Reply-To: <475696D3.60007@pandora.be> Message-ID: References: <475696D3.60007@pandora.be> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/5011/Wed Dec 5 01:42:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13865 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Wed, 5 Dec 2007, Denis Wegge wrote: > Hello > > I am having trouble with the XFS filesystem on a 320GB Western Digital > SATA harddisk. For no obvious reason the partition can no longer be > mounted. The following error occurs: > > knoppix@Knoppix:~$ sudo mount /dev/sda1 /mnt/sda1 > mount: /dev/sda1: can't read superblock Looks like your disk is dying or dead from your logs. You can try putting it in a plastic airtight bag then put it in the freezer and try again but otherwise if that does not work, its time for the trash bin (after you try) a dd and overwrite the disk but with that many bad sectors it looks like it has really gone south. Insert new disk, restore from backup. Justin. From owner-xfs@oss.sgi.com Wed Dec 5 05:20:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 05:20:56 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB5DKoKN021684 for ; Wed, 5 Dec 2007 05:20:51 -0800 Received: from mtv-amer002e--3.americas.sgi.com (unknown [192.26.64.114]) by relay1.corp.sgi.com (Postfix) with ESMTP id 006A68F805F for ; Wed, 5 Dec 2007 05:01:27 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Patch] xfs_lowbit64 broken on ia32 Date: Wed, 5 Dec 2007 04:14:02 -0800 Message-ID: In-Reply-To: <20071205032128.GB115527101@sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Patch] xfs_lowbit64 broken on ia32 Thread-Index: Acg27iE7ZjejYK+FTOKNqLQattWgwQASYgFA From: "Alex Elder" To: "David Chinner" , "Lachlan Mcllroy" Cc: "xfs-oss" , "xfs-dev" X-Virus-Scanned: ClamAV 0.91.2/5011/Wed Dec 5 01:42:23 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id lB5DKpKN021689 X-archive-position: 13866 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aelder@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: . . . > > >Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > > >=================================================================== > > >--- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 > > >13:44:45.000000000 +1100 > > >+++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 > 14:43:33.169851481 +1100 > > >@@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > > > /* Get low bit set out of 64-bit argument, -1 if none set */ > > > static inline int xfs_lowbit64(__uint64_t v) > > > { > > >- unsigned long t = v; > > >- return (v) ? find_first_bit(&t, 64) : -1; > > >+ unsigned long long t = v; > > Why create a local copy? Why not just pass v into find_first_bit()? > > Because I thought that taking the address of a function parameter > was a big no-no because the result is undefined (i.e. platform and > compiler dependent)? I've never heard of this, and it's incorrect--at least with respect to standard C. (But that's not to say in practice some compiler does it wrong.) Unless it's a real (details known) problem you shouldn't try to work around it. -Alex From owner-xfs@oss.sgi.com Wed Dec 5 05:55:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 05:55:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from poptart.bithose.com (poptart.bithose.com [24.97.26.52]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB5DtPFJ001538 for ; Wed, 5 Dec 2007 05:55:26 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.10/8.12.10) with ESMTP id lB5DiVbO113486 for ; Wed, 5 Dec 2007 08:44:31 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.10/8.12.10/Submit) with ESMTP id lB5DiVuB113379 for ; Wed, 5 Dec 2007 08:44:31 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Wed, 5 Dec 2007 08:44:31 -0500 (EST) From: Jameel Akari To: xfs-oss Subject: Which (lib)acl for 2.4.35? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/5011/Wed Dec 5 01:42:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13867 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: xfs The story: We have some old RH7.3 machines that had been running the old 2.4.18_SGI_XFS1.1 from back in the day. Moving these to a new version of VMware requires upgrading to something more recent, and 2.4.35.3/SMP was built from the mainline. The situation: Seems to work, except ACL support is broken. I'm pretty sure this is due to the userland libraries and tools being so out of date (machine has 2.0.9-0). Which versions do I need, and where do I get them? CVS? I assume that all the other utilities (things in xfsprogs like mkfs, and xfsdump) will need similar updates as well. The immediate need is to get ACLs working, but it'd be nice if I can patch up the rest of it one last time until we can rebuild these VMs. -- Jameel Akari From owner-xfs@oss.sgi.com Wed Dec 5 16:02:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 16:02:15 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB6025YB003564 for ; Wed, 5 Dec 2007 16:02:09 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23110; Thu, 6 Dec 2007 11:02:07 +1100 Message-ID: <47573C8A.1060902@sgi.com> Date: Thu, 06 Dec 2007 11:04:26 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alex Elder CC: David Chinner , Lachlan Mcllroy , xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5014/Wed Dec 5 12:24:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13868 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Alex Elder wrote: > David Chinner wrote: > . . . >>>> Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h >>>> =================================================================== >>>> --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 >>>> 13:44:45.000000000 +1100 >>>> +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 >> 14:43:33.169851481 +1100 >>>> @@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ >>>> /* Get low bit set out of 64-bit argument, -1 if none set */ >>>> static inline int xfs_lowbit64(__uint64_t v) >>>> { >>>> - unsigned long t = v; >>>> - return (v) ? find_first_bit(&t, 64) : -1; >>>> + unsigned long long t = v; >>> Why create a local copy? Why not just pass v into find_first_bit()? >> Because I thought that taking the address of a function parameter >> was a big no-no because the result is undefined (i.e. platform and >> compiler dependent)? > > I've never heard of this, and it's incorrect--at least with respect > to standard C. (But that's not to say in practice some compiler > does it wrong.) Unless it's a real (details known) problem you > shouldn't try to work around it. > > -Alex > I've never heard of that either. (Then again, I didn't know until recently that they changed C to allow "flexible array members" in C99 http://tigcc.ticalc.org/doc/gnuexts.html#SEC75) --Tim From owner-xfs@oss.sgi.com Wed Dec 5 17:55:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 17:55:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB61tplE020993 for ; Wed, 5 Dec 2007 17:55:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25549; Thu, 6 Dec 2007 12:55:55 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB61tsdD134208948; Thu, 6 Dec 2007 12:55:55 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB61trEQ134099930; Thu, 6 Dec 2007 12:55:53 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 6 Dec 2007 12:55:53 +1100 From: David Chinner To: Alex Elder Cc: David Chinner , Lachlan Mcllroy , xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 Message-ID: <20071206015553.GI115527101@sgi.com> References: <20071205032128.GB115527101@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5015/Wed Dec 5 14:49:07 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13869 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Dec 05, 2007 at 04:14:02AM -0800, Alex Elder wrote: > David Chinner wrote: > . . . > > > >Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > > > >=================================================================== > > > >--- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 > > > >13:44:45.000000000 +1100 > > > >+++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 > > 14:43:33.169851481 +1100 > > > >@@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > > > > /* Get low bit set out of 64-bit argument, -1 if none set */ > > > > static inline int xfs_lowbit64(__uint64_t v) > > > > { > > > >- unsigned long t = v; > > > >- return (v) ? find_first_bit(&t, 64) : -1; > > > >+ unsigned long long t = v; > > > Why create a local copy? Why not just pass v into find_first_bit()? > > > > Because I thought that taking the address of a function parameter > > was a big no-no because the result is undefined (i.e. platform and > > compiler dependent)? > > I've never heard of this, and it's incorrect--at least with respect > to standard C. (But that's not to say in practice some compiler > does it wrong.) Unless it's a real (details known) problem you > shouldn't try to work around it. It caused me pain about 10 years ago with gcc 2.? and m68k platform, so I've just avoided doing it ever since. IMO, taking the address of a function parameter is also bad coding practice because it usually indicates a bug in the code. i.e. you should have passed a pointer to the function or you should be using a local variable rather than abusing the function parameter in strange ways. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 5 19:13:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 19:13:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB63CxtL028406 for ; Wed, 5 Dec 2007 19:13:01 -0800 Received: from mtv-amer002e--3.americas.sgi.com (unknown [192.26.64.114]) by relay1.corp.sgi.com (Postfix) with ESMTP id 03A428F8065 for ; Wed, 5 Dec 2007 19:13:07 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Patch] xfs_lowbit64 broken on ia32 Date: Wed, 5 Dec 2007 18:15:41 -0800 Message-ID: In-Reply-To: <47573C8A.1060902@sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Patch] xfs_lowbit64 broken on ia32 Thread-Index: Acg3m0KQDutovHuET567HbjpQWpf9AAEZBbg From: "Alex Elder" To: "Timothy Shimmin" Cc: "David Chinner" , "Lachlan Mcllroy" , "xfs-oss" , "xfs-dev" X-Virus-Scanned: ClamAV 0.91.2/5015/Wed Dec 5 14:49:07 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id lB63D1tL028454 X-archive-position: 13870 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aelder@sgi.com Precedence: bulk X-list: xfs Timothy Shimmin wrote: > I've never heard of that either. > (Then again, I didn't know until recently that they changed C > to allow "flexible array members" in C99 > http://tigcc.ticalc.org/doc/gnuexts.html#SEC75) Yeah there's lots of fancy new stuff in C99. Like variable length arrays, language-supported complex (sqrt(-1)) data types, C++ style initializations (mid-functions). And you can declare your loop index variable inside a for loop's parentheses (its scope is defined only for the loop). I'm not ready to use most of that; it has less value than some of the "old" extensions like (void *) and 0-length arrays. But some things are defined very precisely and that's good. -Alex From owner-xfs@oss.sgi.com Wed Dec 5 19:30:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 19:30:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB63UpAR031884 for ; Wed, 5 Dec 2007 19:30:51 -0800 Received: from mtv-amer002e--3.americas.sgi.com (unknown [192.26.64.114]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 2D004908A9 for ; Wed, 5 Dec 2007 19:11:02 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Patch] xfs_lowbit64 broken on ia32 Date: Wed, 5 Dec 2007 18:22:04 -0800 Message-ID: In-Reply-To: <20071206015553.GI115527101@sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Patch] xfs_lowbit64 broken on ia32 Thread-Index: Acg3qydYcgjRYNBUTfmQIM6OVt3regAA4bgg From: "Alex Elder" To: "David Chinner" Cc: "Lachlan Mcllroy" , "xfs-oss" , "xfs-dev" X-Virus-Scanned: ClamAV 0.91.2/5015/Wed Dec 5 14:49:07 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id lB63UpAR031889 X-archive-position: 13871 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aelder@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Wed, Dec 05, 2007 at 04:14:02AM -0800, Alex Elder wrote: > > David Chinner wrote: > > . . . > > > > >Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > > > > > >=================================================================== > > > > >--- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 > > > > >13:44:45.000000000 +1100 > > > > >+++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 > > > 14:43:33.169851481 +1100 > > > > >@@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > > > > > /* Get low bit set out of 64-bit argument, -1 if none set */ > > > > > static inline int xfs_lowbit64(__uint64_t v) > > > > > { > > > > >- unsigned long t = v; > > > > >- return (v) ? find_first_bit(&t, 64) : -1; > > > > >+ unsigned long long t = v; > > > > Why create a local copy? Why not just pass v into > find_first_bit()? > > > > > > Because I thought that taking the address of a function parameter > > > was a big no-no because the result is undefined (i.e. platform and > > > compiler dependent)? > > > > I've never heard of this, and it's incorrect--at least with respect > > to standard C. (But that's not to say in practice some compiler > > does it wrong.) Unless it's a real (details known) problem you > > shouldn't try to work around it. > > It caused me pain about 10 years ago with gcc 2.? and m68k platform, > so I've just avoided doing it ever since. I figured an experience like this was behind it. > IMO, taking the address of a function parameter is also bad coding > practice because it usually indicates a bug in the code. i.e. you > should have passed a pointer to the function or you should be using > a local variable rather than abusing the function parameter in strange > ways. I'm undecided. I agree there's something aesthetically wrong about it. Technically I'm not so sure. Maybe a longjmp() can lead bad things happening when you do this, I don't know. Anyway, this is pretty picky. The change was fine. -Alex From owner-xfs@oss.sgi.com Wed Dec 5 21:18:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 21:18:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB65Hsqr015425 for ; Wed, 5 Dec 2007 21:17:59 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA00980; Thu, 6 Dec 2007 16:17:56 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id A822558FA1B8; Thu, 6 Dec 2007 16:17:56 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 973377 - cleanup to use generic linux filldir causes nfsd hang Message-Id: <20071206051756.A822558FA1B8@chook.melbourne.sgi.com> Date: Thu, 6 Dec 2007 16:17:56 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5017/Wed Dec 5 20:09:47 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13872 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs revert to double-buffering readdir The current readdir implementation deadlocks on a btree buffers locks because nfsd calls back into ->lookup from the filldir callback. The only short-term fix for this is to revert to the old inefficient double-buffering scheme. Signed-off-by: Christoph Hellwig Date: Thu Dec 6 16:17:12 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30201a fs/xfs/linux-2.6/xfs_file.c - 1.159 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.159&r2=text&tr2=1.158&f=h - revert the readdir code to using double buffering to work around a deadlock with nfsd calling back into the lookup code from filldir. From owner-xfs@oss.sgi.com Wed Dec 5 21:29:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 21:29:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB65Tdix016568 for ; Wed, 5 Dec 2007 21:29:46 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA01163; Thu, 6 Dec 2007 16:29:46 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 0F59358FA249; Thu, 6 Dec 2007 16:29:46 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 974005 - xfs_lowbit64 broken on 32bit platforms Message-Id: <20071206052946.0F59358FA249@chook.melbourne.sgi.com> Date: Thu, 6 Dec 2007 16:29:46 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5017/Wed Dec 5 20:09:47 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13873 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Fix xfs_lowbit64 xfs_lowbit64 was broken on 32 bit platforms in a recent cleanup of the xfs bitops. Fix it back up again. Date: Thu Dec 6 16:28:59 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: lachlan@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30202a fs/xfs/xfs_bit.h - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bit.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h - make the temporary variable in xfs_lowbit64 the correct type so that 32bit platforms work as well. From owner-xfs@oss.sgi.com Wed Dec 5 21:39:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 21:39:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB65dmUU017556 for ; Wed, 5 Dec 2007 21:39:51 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA01519; Thu, 6 Dec 2007 16:39:50 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id CDF2258FA249; Thu, 6 Dec 2007 16:39:50 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 974224 - xfsbufd doesn't freeze Message-Id: <20071206053950.CDF2258FA249@chook.melbourne.sgi.com> Date: Thu, 6 Dec 2007 16:39:50 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5017/Wed Dec 5 20:09:47 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13874 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Make xfsbufd threads freezable Fix breakage caused by commit 831441862956fffa17b9801db37e6ea1650b0f69 that did not introduce the necessary call to set_freezable() in xfs/linux-2.6/xfs_buf.c . Signed-off-by: Rafael J. Wysocki Date: Thu Dec 6 16:38:20 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: rjw@sisk.pl The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30203a fs/xfs/linux-2.6/xfs_buf.c - 1.252 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.252&r2=text&tr2=1.251&f=h - Make xfsbufd freezable again. From owner-xfs@oss.sgi.com Wed Dec 5 22:00:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 22:00:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB660TnY019466 for ; Wed, 5 Dec 2007 22:00:45 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA02088; Thu, 6 Dec 2007 17:00:35 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 428E258FA249; Thu, 6 Dec 2007 17:00:35 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 974225 - Fix xfs_ichgtime()s broken usage of I_SYNC Message-Id: <20071206060035.428E258FA249@chook.melbourne.sgi.com> Date: Thu, 6 Dec 2007 17:00:35 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5017/Wed Dec 5 20:09:47 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13875 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Fix xfs_ichgtime()s broken usage of I_SYNC The recent I_LOCK->I_SYNC changes mistakenly changed xfs_ichgtime to look at I_SYNC instead of I_LOCK. This was incorrect and prevents newly created inodes from moving to the dirty list. Change this to the correct check which is for I_NEW, not I_LOCK or I_SYNC so that behaviour is correct. Date: Thu Dec 6 16:59:52 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: lachlan@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30204a fs/xfs/linux-2.6/xfs_iops.c - 1.271 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.271&r2=text&tr2=1.270&f=h - Use I_NEW in xfs_ichgtime instead of I_SYNC so that new inodes are moved to the dirty list correctly. From owner-xfs@oss.sgi.com Thu Dec 6 08:20:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 08:20:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,J_CHICKENPOX_45, WHOIS_MYPRIVREG autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB6GKZ0a030146 for ; Thu, 6 Dec 2007 08:20:39 -0800 X-ASG-Debug-ID: 1196957422-668403a60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 22D364512BD for ; Thu, 6 Dec 2007 08:10:22 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id caOm7pgk3QeRjrbi for ; Thu, 06 Dec 2007 08:10:22 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1J0JIr-0003kq-GD for xfs@oss.sgi.com; Thu, 06 Dec 2007 08:10:21 -0800 Message-ID: <14194915.post@talk.nabble.com> Date: Thu, 6 Dec 2007 08:10:21 -0800 (PST) From: Kingghost To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS_Repair PRoblem Subject: XFS_Repair PRoblem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: mrlitres@gmail.com X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1196957423 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0204 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.35875 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M BODY: Custom Rule 7568M X-Virus-Scanned: ClamAV 0.91.2/5020/Wed Dec 5 22:21:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13876 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mrlitres@gmail.com Precedence: bulk X-list: xfs Hello, So I was seeing my serial link go up and down so I rebooted and everything was working fine, except my vg0 wouldnt mount. So I tried to xfs_repair it and this is the output I recieved. slutb0x:/# xfs_repair -o assume_xfs /dev/vg0/media Phase 1 - find and verify superblock... sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 128 resetting superblock root inode pointer to 128 sb realtime bitmap inode 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap ino pointer to 129 sb realtime summary inode 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary ino pointer to 130 Phase 2 - using internal log - zero log... missing inbetween rebuilding directory inode 1225702584 bad hash table for directory inode 1342177425 (no data entry): rebuilding rebuilding directory inode 1342177425 bad hash table for directory inode 1344688512 (no data entry): rebuilding rebuilding directory inode 1344688512 bad hash table for directory inode 1344689011 (no data entry): rebuilding rebuilding directory inode 1344689011 bad hash table for directory inode 1347027107 (no data entry): rebuilding rebuilding directory inode 1347027107 bad hash table for directory inode 1347297139 (no data entry): rebuilding rebuilding directory inode 1347297139 bad hash table for directory inode 1348463898 (no data entry): rebuilding rebuilding directory inode 1348463898 bad hash table for directory inode 1386426400 (no data entry): rebuilding rebuilding directory inode 1386426400 bad hash table for directory inode 1407214284 (no data entry): rebuilding rebuilding directory inode 1407214284 rebuilding directory inode 1409980307 bad hash table for directory inode 1476395171 (no data entry): rebuilding rebuilding directory inode 1476395171 bad hash table for directory inode 1482430980 (no data entry): rebuilding rebuilding directory inode 1482430980 bad hash table for directory inode 1483051225 (no data entry): rebuilding rebuilding directory inode 1483051225 bad hash table for directory inode 1485162665 (no data entry): rebuilding rebuilding directory inode 1485162665 bad hash table for directory inode 1490611323 (no data entry): rebuilding rebuilding directory inode 1490611323 rebuilding directory inode 1545482625 bad hash table for directory inode 1546105138 (no data entry): rebuilding rebuilding directory inode 1546105138 bad hash table for directory inode 1546563350 (no data entry): rebuilding rebuilding directory inode 1546563350 bad hash table for directory inode 1576719133 (no data entry): rebuilding rebuilding directory inode 1576719133 bad hash table for directory inode 1610612892 (no data entry): rebuilding rebuilding directory inode 1610612892 bad hash table for directory inode 1618357762 (no data entry): rebuilding rebuilding directory inode 1618357762 bad hash table for directory inode 1619798333 (no data entry): rebuilding rebuilding directory inode 1619798333 bad hash table for directory inode 1669673937 (no data entry): rebuilding rebuilding directory inode 1669673937 bad hash table for directory inode 1754694080 (no data entry): rebuilding rebuilding directory inode 1754694080 bad hash table for directory inode 1756293956 (no data entry): rebuilding rebuilding directory inode 1756293956 bad hash table for directory inode 1793985071 (no data entry): rebuilding rebuilding directory inode 1793985071 bad hash table for directory inode 1879048358 (no data entry): rebuilding rebuilding directory inode 1879048358 bad hash table for directory inode 1879480988 (no data entry): rebuilding rebuilding directory inode 1879480988 bad hash table for directory inode 1884893322 (no data entry): rebuilding rebuilding directory inode 1884893322 bad hash table for directory inode 1885854162 (no data entry): rebuilding rebuilding directory inode 1885854162 bad hash table for directory inode 1888390172 (no data entry): rebuilding rebuilding directory inode 1888390172 bad hash table for directory inode 1892569223 (no data entry): rebuilding rebuilding directory inode 1892569223 bad hash table for directory inode 2015614187 (no data entry): rebuilding rebuilding directory inode 2015614187 bad hash table for directory inode 2019037629 (no data entry): rebuilding rebuilding directory inode 2019037629 bad hash table for directory inode 2027745957 (no data entry): rebuilding rebuilding directory inode 2027745957 bad hash table for directory inode 2027745991 (no data entry): rebuilding rebuilding directory inode 2027745991 bad hash table for directory inode 2041763187 (no data entry): rebuilding rebuilding directory inode 2041763187 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 134217856, moving to lost+found disconnected dir inode 159404583, moving to lost+found disconnected dir inode 188928448, moving to lost+found disconnected dir inode 188935323, moving to lost+found disconnected inode 209057354, moving to lost+found disconnected inode 209057355, moving to lost+found disconnected inode 209057356, moving to lost+found disconnected dir inode 209513188, moving to lost+found disconnected dir inode 209513245, moving to lost+found disconnected dir inode 209513344, moving to lost+found disconnected dir inode 209513395, moving to lost+found disconnected dir inode 209513490, moving to lost+found disconnected dir inode 209513584, moving to lost+found disconnected dir inode 209677569, moving to lost+found disconnected dir inode 213712676, moving to lost+found disconnected inode 262129013, moving to lost+found disconnected inode 262129014, moving to lost+found disconnected inode 262129016, moving to lost+found disconnected dir inode 262132666, moving to lost+found disconnected dir inode 262141188, moving to lost+found disconnected inode 279860753, moving to lost+found disconnected inode 279860754, moving to lost+found disconnected dir inode 279860755, moving to lost+found disconnected inode 279860757, moving to lost+found disconnected inode 279860758, moving to lost+found disconnected inode 279860759, moving to lost+found disconnected inode 279860760, moving to lost+found disconnected inode 279860761, moving to lost+found disconnected inode 279860762, moving to lost+found disconnected inode 279860763, moving to lost+found disconnected inode 279860764, moving to lost+found disconnected inode 279860766, moving to lost+found disconnected inode 279860767, moving to lost+found disconnected inode 279860770, moving to lost+found disconnected inode 279860771, moving to lost+found disconnected inode 279860772, moving to lost+found disconnected inode 279860773, moving to lost+found disconnected inode 279860774, moving to lost+found disconnected inode 279860776, moving to lost+found disconnected dir inode 279874575, moving to lost+found disconnected inode 292512566, moving to lost+found disconnected inode 292512567, moving to lost+found disconnected inode 292512568, moving to lost+found disconnected inode 292512569, moving to lost+found disconnected dir inode 292519637, moving to lost+found disconnected inode 292519660, moving to lost+found disconnected inode 292774410, moving to lost+found disconnected inode 292774412, moving to lost+found disconnected inode 292774413, moving to lost+found disconnected dir inode 307451136, moving to lost+found disconnected inode 342075439, moving to lost+found disconnected dir inode 342357112, moving to lost+found disconnected inode 345352743, moving to lost+found disconnected inode 345352744, moving to lost+found disconnected inode 345352745, moving to lost+found disconnected inode 345352746, moving to lost+found disconnected dir inode 350201220, moving to lost+found disconnected dir inode 404630767, moving to lost+found disconnected inode 404635207, moving to lost+found disconnected dir inode 467834646, moving to lost+found disconnected dir inode 468060626, moving to lost+found disconnected inode 497816685, moving to lost+found disconnected inode 497816686, moving to lost+found disconnected inode 497816687, moving to lost+found disconnected inode 497816688, moving to lost+found disconnected inode 497816689, moving to lost+found disconnected inode 497816690, moving to lost+found disconnected inode 497816691, moving to lost+found disconnected inode 497816692, moving to lost+found disconnected inode 497816702, moving to lost+found disconnected dir inode 500814219, moving to lost+found disconnected dir inode 500815365, moving to lost+found disconnected dir inode 527158122, moving to lost+found disconnected dir inode 536871084, moving to lost+found disconnected dir inode 538001664, moving to lost+found disconnected dir inode 541074254, moving to lost+found disconnected dir inode 541664864, moving to lost+found disconnected dir inode 541770349, moving to lost+found disconnected dir inode 551347552, moving to lost+found disconnected dir inode 677133324, moving to lost+found disconnected dir inode 681949599, moving to lost+found disconnected dir inode 683059743, moving to lost+found disconnected inode 683118797, moving to lost+found disconnected inode 683118798, moving to lost+found disconnected inode 683118799, moving to lost+found disconnected dir inode 683118800, moving to lost+found disconnected inode 730956960, moving to lost+found disconnected inode 730956961, moving to lost+found disconnected inode 730956962, moving to lost+found disconnected inode 730956963, moving to lost+found disconnected inode 730956964, moving to lost+found disconnected inode 730956965, moving to lost+found disconnected inode 730956966, moving to lost+found disconnected inode 730956967, moving to lost+found disconnected inode 730956968, moving to lost+found disconnected inode 730956969, moving to lost+found disconnected inode 730956970, moving to lost+found disconnected inode 730956971, moving to lost+found disconnected inode 730956972, moving to lost+found disconnected inode 730956973, moving to lost+found disconnected inode 730956974, moving to lost+found disconnected inode 730956975, moving to lost+found disconnected inode 730956976, moving to lost+found disconnected inode 730956977, moving to lost+found disconnected inode 730956978, moving to lost+found disconnected inode 730956979, moving to lost+found disconnected inode 730956980, moving to lost+found disconnected inode 730956981, moving to lost+found disconnected inode 730956982, moving to lost+found disconnected inode 730956983, moving to lost+found disconnected inode 730956984, moving to lost+found disconnected inode 730956985, moving to lost+found disconnected inode 730956986, moving to lost+found disconnected inode 730956987, moving to lost+found disconnected inode 730956988, moving to lost+found disconnected inode 730956989, moving to lost+found disconnected inode 730956990, moving to lost+found disconnected inode 730956991, moving to lost+found disconnected inode 730956992, moving to lost+found disconnected inode 730956993, moving to lost+found disconnected inode 730956994, moving to lost+found disconnected inode 730956995, moving to lost+found disconnected inode 730956996, moving to lost+found disconnected inode 730956997, moving to lost+found disconnected inode 730956998, moving to lost+found disconnected inode 730956999, moving to lost+found disconnected inode 730957000, moving to lost+found disconnected inode 730957001, moving to lost+found disconnected inode 730957002, moving to lost+found disconnected inode 730957003, moving to lost+found disconnected inode 730957004, moving to lost+found disconnected inode 730957005, moving to lost+found disconnected inode 730957006, moving to lost+found disconnected inode 730957007, moving to lost+found disconnected inode 730957008, moving to lost+found disconnected inode 730957009, moving to lost+found disconnected inode 730957010, moving to lost+found disconnected inode 730957011, moving to lost+found disconnected inode 730957012, moving to lost+found disconnected inode 730957013, moving to lost+found disconnected inode 730957014, moving to lost+found disconnected inode 730957015, moving to lost+found disconnected inode 730957016, moving to lost+found disconnected inode 730957017, moving to lost+found disconnected inode 730957018, moving to lost+found disconnected inode 730957019, moving to lost+found disconnected inode 730957020, moving to lost+found disconnected inode 730957021, moving to lost+found disconnected inode 730957022, moving to lost+found disconnected dir inode 730957023, moving to lost+found disconnected dir inode 730975064, moving to lost+found disconnected dir inode 731107961, moving to lost+found disconnected dir inode 731173866, moving to lost+found disconnected dir inode 731229206, moving to lost+found disconnected dir inode 731317750, moving to lost+found disconnected dir inode 752117594, moving to lost+found disconnected dir inode 752117670, moving to lost+found disconnected inode 809433019, moving to lost+found disconnected dir inode 823780059, moving to lost+found disconnected dir inode 823780089, moving to lost+found fatal error -- creation of .. entry failed (117), filesystem may be out of space The thing is I have free space, its weird. -- View this message in context: http://www.nabble.com/XFS_Repair-PRoblem-tf4956832.html#a14194915 Sent from the Xfs - General mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Thu Dec 6 08:50:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 08:50:40 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB6GoW5g000647 for ; Thu, 6 Dec 2007 08:50:34 -0800 X-ASG-Debug-ID: 1196959204-793f00880000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hobbit.corpit.ru (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 443A4AED0CC for ; Thu, 6 Dec 2007 08:40:04 -0800 (PST) Received: from hobbit.corpit.ru (hobbit.corpit.ru [81.13.94.6]) by cuda.sgi.com with ESMTP id YZC2orqAp5qZCiMR for ; Thu, 06 Dec 2007 08:40:04 -0800 (PST) Received: from [192.168.1.1] (paltus.tls.msk.ru [192.168.1.1]) by hobbit.corpit.ru (Postfix) with ESMTP id 1D6B32B079; Thu, 6 Dec 2007 19:39:29 +0300 (MSK) (envelope-from mjt@tls.msk.ru) Message-ID: <475825C0.4070605@msgid.tls.msk.ru> Date: Thu, 06 Dec 2007 19:39:28 +0300 From: Michael Tokarev User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Dragos CC: David Greaves , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: assemble vs create an array....... Subject: Re: assemble vs create an array....... References: <474F869D.5040503@mpigani.org> <18255.41044.614676.410107@notabene.brown> <47501D7E.7000804@dgreaves.com> <475552D2.4000802@mpigani.org> <47568DE1.1050108@dgreaves.com> <4758129D.40600@mpigani.org> In-Reply-To: <4758129D.40600@mpigani.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: hobbit.corpit.ru[81.13.94.6] X-Barracuda-Start-Time: 1196959205 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0007 1.0000 -2.0162 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.35878 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5020/Wed Dec 5 22:21:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13877 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mjt@tls.msk.ru Precedence: bulk X-list: xfs [Cc'd to xfs list as it contains something related] Dragos wrote: > Thank you. > I want to make sure I understand. [Some background for XFS list. The talk is about a broken linux software raid (the reason for breakage isn't relevant anymore). The OP seems to lost the order of drives in his array, and now tries to create new array ontop, trying different combinations of drives. The filesystem there WAS XFS. One point is that linux refuses to mount it, saying "structure needs cleaning". This all is mostly md-related, but there are several XFS-related questions and concerns too.] > > 1- Does it matter which permutation of drives I use for xfs_repair (as > long as it tells me that the Structure needs cleaning)? When it comes to > linux I consider myself at intermediate level, but I am a beginner when > it comes to raid and filesystem issues. The permutation DOES MATTER - for all the devices. Linux, when mounting an fs, only looks at the superblock of the filesystem, which is usually located at the beginning of the device. So in each case linux actually recognizes the filesystem (instead of seeing complete garbage), the same device is the first one - I.e, this way you found your first device. The rest may be still out of order. Raid5 data is laid like this (with 3 drives for simplicity, it's similar with more drives): DiskA DiskB DiskC Blk0 Data0 Data1 P0 Blk1 P1 Data2 Data3 Blk2 Data4 P2 Data5 Blk3 Data6 Data7 P3 ... and so on ....................... where your actual data blocks are Data0, Data1, ... DataN, and PX are parity blocks. As long as DiskA remains in this position, the beginning of the array is Data0 block, -- hence linux sees the beginning of the filesystem and recognizes it. But you can switch DiskB and DiskC still, and the rest of the data will be complete garbage, only data blocks on DiskA will be in place. So you still need to find order of the other drives (you found your first drive, DriveA, already). Note also that if Data1 block is all-zeros (a situation which is unlikely for a non-empty filesystem), P0 (first parity block) will be exactly the same as Data0, because XORing anything with zeros gives the same "anything" again (XOR is the operation used to calculate parity blocks in RAID5). So there's still a remote chance you've TWO "first" disks... What to do is to give repairfs a try for each permutation, but again without letting it to actually fix anything. Just run it in read-only mode and see which combination of drives gives less errors, or no fatal errors (there may be several similar combinations, with the same order of drives but with different drive "missing"). It's sad that xfs refuses mount when "structure needs cleaning" - the best way here is to actually mount it and see how it looks like, instead of trying repair tools. Is there some option to force-mount it still (in readonly mode, knowing it may OOPs kernel etc)? I'm not very familiar with xfs yet - it seems to be much faster than ext3 for our workload (mostly databases), and I'm experimenting with it slowly. But this very thread prompted me to think. If I can't force-mount it (or browse it using other ways) as I can almost always do with (somewhat?) broken ext[23] just to examine things, maybe I'm trying it before it's mature enough? ;) Note the smile, but note there's a bit of joke in every joke... :) > 2- After I do it, assuming that it worked, how do I reintegrate the > 'missing' drive while keeping my data? Just add it back -- mdadm --add /dev/mdX /dev/sdYZ. But don't do that till you actually see your data. /mjt From owner-xfs@oss.sgi.com Thu Dec 6 09:30:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 09:30:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB6HUZDY004773 for ; Thu, 6 Dec 2007 09:30:35 -0800 X-ASG-Debug-ID: 1196961128-0a8601c20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B518A4519CF for ; Thu, 6 Dec 2007 09:12:08 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id RIwE1U8KpjEGx6vD for ; Thu, 06 Dec 2007 09:12:08 -0800 (PST) Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 7A1AE1800FF5B; Thu, 6 Dec 2007 11:12:06 -0600 (CST) Message-ID: <47582D65.4000808@sandeen.net> Date: Thu, 06 Dec 2007 11:12:05 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Michael Tokarev CC: Dragos , David Greaves , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: assemble vs create an array....... Subject: Re: assemble vs create an array....... References: <474F869D.5040503@mpigani.org> <18255.41044.614676.410107@notabene.brown> <47501D7E.7000804@dgreaves.com> <475552D2.4000802@mpigani.org> <47568DE1.1050108@dgreaves.com> <4758129D.40600@mpigani.org> <475825C0.4070605@msgid.tls.msk.ru> In-Reply-To: <475825C0.4070605@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1196961129 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.35879 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5021/Thu Dec 6 07:40:41 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13878 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Michael Tokarev wrote: > It's sad that xfs refuses mount when "structure needs > cleaning" - the best way here is to actually mount it > and see how it looks like, instead of trying repair > tools. Is there some option to force-mount it still > (in readonly mode, knowing it may OOPs kernel etc)? depends what went wrong, but in general that error means that metadata corruption was encountered which was sufficient for xfs to abort whatever it was doing. It's not done lightly; it's likely bailing out because it had no other choice. You can't "force mount" something which is sufficiently corrupted that xfs can't understand it anymore... IOW you can't traverse and read corrupted/scrambled metadata, no mount option can help you. :) If the shutdown were encountered during use, you could maybe avoid the bad metadata. If it's during mount that's probably a more fundamental problem. kernel messages when you get the "structure needs cleaning" error would be a clue as to what it actually hit. -Eric From owner-xfs@oss.sgi.com Thu Dec 6 13:06:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 13:06:49 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB6L6YaU030872 for ; Thu, 6 Dec 2007 13:06:41 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA23079; Fri, 7 Dec 2007 08:06:40 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB6L6ddD135190643; Fri, 7 Dec 2007 08:06:39 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB6L6aRc105554571; Fri, 7 Dec 2007 08:06:36 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 7 Dec 2007 08:06:36 +1100 From: David Chinner To: Kingghost Cc: xfs@oss.sgi.com Subject: Re: XFS_Repair PRoblem Message-ID: <20071206210636.GM115527101@sgi.com> References: <14194915.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14194915.post@talk.nabble.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5023/Thu Dec 6 11:37:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13879 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Dec 06, 2007 at 08:10:21AM -0800, Kingghost wrote: > > Hello, > > So I was seeing my serial link go up and down so I rebooted and everything > was working fine, except my vg0 wouldnt mount. So I tried to xfs_repair it > and this is the output I recieved. > > slutb0x:/# xfs_repair -o assume_xfs /dev/vg0/media > Phase 1 - find and verify superblock... > sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with > calculated value 128 NULLFSINO? Something has overwritten your superblock with a bunch of -1 values? > resetting superblock root inode pointer to 128 > sb realtime bitmap inode 18446744073709551615 (NULLFSINO) inconsistent with > calculated value 129 > resetting superblock realtime bitmap ino pointer to 129 > sb realtime summary inode 18446744073709551615 (NULLFSINO) inconsistent with > calculated value 130 > resetting superblock realtime summary ino pointer to 130 > Phase 2 - using internal log > - zero log... Uh-oh - you ran a xfs_repair -L, didn't you? > > missing inbetween > > rebuilding directory inode 1225702584 > bad hash table for directory inode 1342177425 (no data entry): rebuilding And a bunch of trashed directory structures... > disconnected dir inode 752117670, moving to lost+found > disconnected inode 809433019, moving to lost+found > disconnected dir inode 823780059, moving to lost+found > disconnected dir inode 823780089, moving to lost+found > > fatal error -- creation of .. entry failed (117), filesystem may be out of > space 117 = EUCLEAN - corrupted filesystem. Sounds like there's more corruption there than was discovered or the underlying disk is still corruption blocks. What version of repair are you running ? This is a dying disk you're trying to repair right? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 6 13:22:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 13:22:39 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_210 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB6LMSdS000420 for ; Thu, 6 Dec 2007 13:22:30 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA23594; Fri, 7 Dec 2007 08:22:33 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB6LMTdD131164940; Fri, 7 Dec 2007 08:22:31 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB6LMPeI135277070; Fri, 7 Dec 2007 08:22:25 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 7 Dec 2007 08:22:25 +1100 From: David Chinner To: Michael Tokarev Cc: Dragos , David Greaves , linux-raid@vger.kernel.org, xfs@oss.sgi.com Subject: Re: assemble vs create an array....... Message-ID: <20071206212225.GN115527101@sgi.com> References: <474F869D.5040503@mpigani.org> <18255.41044.614676.410107@notabene.brown> <47501D7E.7000804@dgreaves.com> <475552D2.4000802@mpigani.org> <47568DE1.1050108@dgreaves.com> <4758129D.40600@mpigani.org> <475825C0.4070605@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475825C0.4070605@msgid.tls.msk.ru> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5023/Thu Dec 6 11:37:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13880 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Dec 06, 2007 at 07:39:28PM +0300, Michael Tokarev wrote: > What to do is to give repairfs a try for each permutation, > but again without letting it to actually fix anything. > Just run it in read-only mode and see which combination > of drives gives less errors, or no fatal errors (there > may be several similar combinations, with the same order > of drives but with different drive "missing"). Ugggh. > It's sad that xfs refuses mount when "structure needs > cleaning" - the best way here is to actually mount it > and see how it looks like, instead of trying repair > tools. It self protection - if you try to write to a corrupted filesystem, you'll only make the corruption worse. Mounting involves log recovery, which writes to the filesystem.... > Is there some option to force-mount it still > (in readonly mode, knowing it may OOPs kernel etc)? Sure you can: mount -o ro,norecovery But it you hit corruption it will still shut down on you. If the machine oopses then that is a bug. > thread prompted me to think. If I can't force-mount it > (or browse it using other ways) as I can almost always > do with (somewhat?) broken ext[23] just to examine things, > maybe I'm trying it before it's mature enough? ;) Hehe ;) For maximum uber-XFS-guru points, learn to browse your filesystem with xfs_db. :P Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 6 16:29:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 16:29:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB70THWo022155 for ; Thu, 6 Dec 2007 16:29:22 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28520; Fri, 7 Dec 2007 11:29:24 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB70TNdD135206957; Fri, 7 Dec 2007 11:29:23 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB70TMYC135376756; Fri, 7 Dec 2007 11:29:22 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 7 Dec 2007 11:29:22 +1100 From: David Chinner To: Vlad Apostolov Cc: Christoph Hellwig , David Chinner , Mark Goodwin , xfs-dev , xfs-oss Subject: Re: DMAPI problem with the new filldir implementation Message-ID: <20071207002922.GQ115527101@sgi.com> References: <475879DB.40705@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475879DB.40705@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5023/Thu Dec 6 11:37:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13881 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs (cc xfs-dev and xfs@oss) On Fri, Dec 07, 2007 at 09:38:19AM +1100, Vlad Apostolov wrote: > Hi Christoph and Dave, > > It looks like we may have a problem caused by this patch: > > http://oss.sgi.com/archives/xfs/2007-07/msg00338.html > > It makes XFS test 144 to fail if the inode size is 2k. I did > some investigation and I think xfs_readdir() returns incorrect > next location for shortform directories. When the inode size is > 2k, more dir entries fit inline in the inode and test 144 > dm_get_dirattrs() starts using the shortform. > > I think this code here > > if (filldir(dirent, sfep->name, sfep->namelen, > off + xfs_dir2_data_entsize(sfep->namelen), > ino, DT_UNKNOWN)) { > > adds some offset "xfs_dir2_data_entsize(sfep->namelen)" to the > next location pointer, which appears to be incorrect and causes > directory entries to be skipped on the next call of dm_get_dirattrs(). It's supposed to be the offset of the next dirent: On Linux, the dirent structure is defined as follows: struct dirent { ino_t d_ino; /* inode number */ >>>>>> off_t d_off; /* offset to the next dirent */ unsigned short d_reclen; /* length of this record */ unsigned char d_type; /* type of file */ char d_name[256]; /* filename */ }; However, looking at the generic filldir() implementation in fs/readdir.c, I see that it: dirent = buf->previous; if (dirent) { if (__put_user(offset, &dirent->d_off)) goto efault; } Puts the offset in the *previous* dirent, not the current one. That means that the three calls to XFs makes to filldir() are all incorrect; they should be passing the offset of the current object, not the next object as teh filldir code stuffs it in the previous dirent. The reason that dmapi is failing here is that it uses teh offset as the cookie to to indicate the next inode to read. However, getdents uses the filp->f_pos: error = vfs_readdir(file, filldir, &buf); if (error < 0) goto out_putf; error = buf.error; lastdirent = buf.previous; if (lastdirent) { if (put_user(file->f_pos, &lastdirent->d_off)) error = -EFAULT; else error = count - buf.count; } and xfs_file_readdir uses that as teh offset for lookups and keeps it up to date correctly. hence the getdents code is overwritting the incorrect value XFS has been stuffing in there and hence we haven't seen this on normal syscalls. > I tried this simple patch > > --- a/fs/xfs/dmapi/xfs_dm.c 2007-12-03 14:04:10.000000000 +1100 > +++ b/fs/xfs/dmapi/xfs_dm.c 2007-12-03 11:55:12.000000000 +1100 > @@ -1910,7 +1910,6 @@ > goto out_kfree; > } > > - loc = cb->lastoff; Ok, which is using the offset returned by xfs_readdir (the offset of the last dirent successfully read) instead of that used in dm_filldir which is the offset of the next dir. > > error = -EFAULT; > if (cb->lastbuf && put_user(0, &cb->lastbuf->_link)) > > and it seams to fix the problem. > > Because I don't fully understand the new filldir implementation I would > like to ask you if you could have a look at it and see what would be > the best way to fix the problem. Ok, patch attached. passes 144 on all inode sizes, otherwise mostly untested. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/dmapi/xfs_dm.c | 4 ---- fs/xfs/xfs_dir2_block.c | 6 ++---- fs/xfs/xfs_dir2_leaf.c | 2 +- fs/xfs/xfs_dir2_sf.c | 9 +++------ 4 files changed, 6 insertions(+), 15 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_block.c 2007-08-23 23:03:09.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c 2007-12-07 10:23:14.933645761 +1100 @@ -508,7 +508,7 @@ xfs_dir2_block_getdents( continue; cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - ptr - (char *)block); + (char *)dep - (char *)block); ino = be64_to_cpu(dep->inumber); #if XFS_BIG_INUMS ino += mp->m_inoadd; @@ -519,9 +519,7 @@ xfs_dir2_block_getdents( */ if (filldir(dirent, dep->name, dep->namelen, cook, ino, DT_UNKNOWN)) { - *offset = xfs_dir2_db_off_to_dataptr(mp, - mp->m_dirdatablk, - (char *)dep - (char *)block); + *offset = cook; xfs_da_brelse(NULL, bp); return 0; } Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_leaf.c 2007-08-24 22:24:45.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c 2007-12-07 10:18:17.623544813 +1100 @@ -1091,7 +1091,7 @@ xfs_dir2_leaf_getdents( * Won't fit. Return to caller. */ if (filldir(dirent, dep->name, dep->namelen, - xfs_dir2_byte_to_dataptr(mp, curoff + length), + xfs_dir2_byte_to_dataptr(mp, curoff), ino, DT_UNKNOWN)) break; Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_sf.c 2007-08-23 23:03:09.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c 2007-12-07 10:20:57.887115812 +1100 @@ -752,7 +752,7 @@ xfs_dir2_sf_getdents( #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif - if (filldir(dirent, ".", 1, dotdot_offset, ino, DT_DIR)) { + if (filldir(dirent, ".", 1, dot_offset, ino, DT_DIR)) { *offset = dot_offset; return 0; } @@ -762,13 +762,11 @@ xfs_dir2_sf_getdents( * Put .. entry unless we're starting past it. */ if (*offset <= dotdot_offset) { - off = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - XFS_DIR2_DATA_FIRST_OFFSET); ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif - if (filldir(dirent, "..", 2, off, ino, DT_DIR)) { + if (filldir(dirent, "..", 2, dotdot_offset, ino, DT_DIR)) { *offset = dotdot_offset; return 0; } @@ -793,8 +791,7 @@ xfs_dir2_sf_getdents( #endif if (filldir(dirent, sfep->name, sfep->namelen, - off + xfs_dir2_data_entsize(sfep->namelen), - ino, DT_UNKNOWN)) { + off, ino, DT_UNKNOWN)) { *offset = off; return 0; } Index: 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/dmapi/xfs_dm.c 2007-12-03 17:11:46.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c 2007-12-07 11:25:42.678472255 +1100 @@ -1772,7 +1772,6 @@ xfs_dm_get_dioinfo( typedef struct dm_readdir_cb { xfs_mount_t *mp; - xfs_off_t lastoff; char __user *ubuf; dm_stat_t __user *lastbuf; size_t spaceleft; @@ -1834,7 +1833,6 @@ dm_filldir(void *__buf, const char *name cb->spaceleft -= statp->_link; cb->nwritten += statp->_link; cb->ubuf += statp->_link; - cb->lastoff = offset; return 0; @@ -1910,8 +1908,6 @@ xfs_dm_get_dirattrs_rvp( goto out_kfree; } - loc = cb->lastoff; - error = -EFAULT; if (cb->lastbuf && put_user(0, &cb->lastbuf->_link)) goto out_kfree; From owner-xfs@oss.sgi.com Thu Dec 6 16:51:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 16:51:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, WHOIS_MYPRIVREG autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB70pHtx024668 for ; Thu, 6 Dec 2007 16:51:21 -0800 X-ASG-Debug-ID: 1196988685-74ef01930000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3116C4544FC for ; Thu, 6 Dec 2007 16:51:25 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id ah4iGxa3RBnnByQz for ; Thu, 06 Dec 2007 16:51:25 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1J0RR6-0004yc-Ay for xfs@oss.sgi.com; Thu, 06 Dec 2007 16:51:24 -0800 Message-ID: <14204640.post@talk.nabble.com> Date: Thu, 6 Dec 2007 16:51:24 -0800 (PST) From: Kingghost To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS_Repair PRoblem Subject: Re: XFS_Repair PRoblem In-Reply-To: <20071206210636.GM115527101@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: mrlitres@gmail.com References: <14194915.post@talk.nabble.com> <20071206210636.GM115527101@sgi.com> X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1196988688 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.35911 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M BODY: Custom Rule 7568M X-Virus-Scanned: ClamAV 0.91.2/5023/Thu Dec 6 11:37:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13882 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mrlitres@gmail.com Precedence: bulk X-list: xfs Hello, Ya it said if I couldnt mount it to use -L so I did. Apparently this was a mistake. I dd_rescued all the data to a new drive, so drive isnt the issue anymore. David Chinner wrote: > > On Thu, Dec 06, 2007 at 08:10:21AM -0800, Kingghost wrote: >> >> Hello, >> >> So I was seeing my serial link go up and down so I rebooted and >> everything >> was working fine, except my vg0 wouldnt mount. So I tried to xfs_repair >> it >> and this is the output I recieved. >> >> slutb0x:/# xfs_repair -o assume_xfs /dev/vg0/media >> Phase 1 - find and verify superblock... >> sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with >> calculated value 128 > > NULLFSINO? Something has overwritten your superblock with a bunch of -1 > values? > >> resetting superblock root inode pointer to 128 >> sb realtime bitmap inode 18446744073709551615 (NULLFSINO) inconsistent >> with >> calculated value 129 >> resetting superblock realtime bitmap ino pointer to 129 >> sb realtime summary inode 18446744073709551615 (NULLFSINO) inconsistent >> with >> calculated value 130 >> resetting superblock realtime summary ino pointer to 130 >> Phase 2 - using internal log >> - zero log... > > Uh-oh - you ran a xfs_repair -L, didn't you? >> >> missing inbetween >> >> rebuilding directory inode 1225702584 >> bad hash table for directory inode 1342177425 (no data entry): rebuilding > > And a bunch of trashed directory structures... > >> disconnected dir inode 752117670, moving to lost+found >> disconnected inode 809433019, moving to lost+found >> disconnected dir inode 823780059, moving to lost+found >> disconnected dir inode 823780089, moving to lost+found >> >> fatal error -- creation of .. entry failed (117), filesystem may be out >> of >> space > > 117 = EUCLEAN - corrupted filesystem. Sounds like there's more corruption > there than was discovered or the underlying disk is still corruption > blocks. > What version of repair are you running ? > > This is a dying disk you're trying to repair right? > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > > > -- View this message in context: http://www.nabble.com/XFS_Repair-PRoblem-tf4956832.html#a14204640 Sent from the Xfs - General mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Thu Dec 6 17:49:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 17:49:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB71nZ5X030067 for ; Thu, 6 Dec 2007 17:49:41 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA00486; Fri, 7 Dec 2007 12:49:42 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lB71ngdD135262204; Fri, 7 Dec 2007 12:49:42 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB71ne9E135089781; Fri, 7 Dec 2007 12:49:40 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 7 Dec 2007 12:49:40 +1100 From: David Chinner To: David Chinner Cc: Vlad Apostolov , Christoph Hellwig , Mark Goodwin , xfs-dev , xfs-oss Subject: Re: DMAPI problem with the new filldir implementation Message-ID: <20071207014940.GS115527101@sgi.com> References: <475879DB.40705@sgi.com> <20071207002922.GQ115527101@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071207002922.GQ115527101@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5023/Thu Dec 6 11:37:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13883 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Dec 07, 2007 at 11:29:22AM +1100, David Chinner wrote: > (cc xfs-dev and xfs@oss) > > On Fri, Dec 07, 2007 at 09:38:19AM +1100, Vlad Apostolov wrote: > > Hi Christoph and Dave, > > > > It looks like we may have a problem caused by this patch: > > > > http://oss.sgi.com/archives/xfs/2007-07/msg00338.html > > > > It makes XFS test 144 to fail if the inode size is 2k. I did > > some investigation and I think xfs_readdir() returns incorrect > > next location for shortform directories. When the inode size is > > 2k, more dir entries fit inline in the inode and test 144 > > dm_get_dirattrs() starts using the shortform. > > > > I think this code here > > > > if (filldir(dirent, sfep->name, sfep->namelen, > > off + xfs_dir2_data_entsize(sfep->namelen), > > ino, DT_UNKNOWN)) { > > > > adds some offset "xfs_dir2_data_entsize(sfep->namelen)" to the > > next location pointer, which appears to be incorrect and causes > > directory entries to be skipped on the next call of dm_get_dirattrs(). > > It's supposed to be the offset of the next dirent: > > On Linux, the dirent structure is defined as follows: > > struct dirent { > ino_t d_ino; /* inode number */ > >>>>>> off_t d_off; /* offset to the next dirent */ > unsigned short d_reclen; /* length of this record */ > unsigned char d_type; /* type of file */ > char d_name[256]; /* filename */ > }; > > However, looking at the generic filldir() implementation in fs/readdir.c, > I see that it: > > dirent = buf->previous; > if (dirent) { > if (__put_user(offset, &dirent->d_off)) > goto efault; > } > > Puts the offset in the *previous* dirent, not the current one. That > means that the three calls to XFs makes to filldir() are all incorrect; > they should be passing the offset of the current object, not the next > object as teh filldir code stuffs it in the previous dirent. > > The reason that dmapi is failing here is that it uses teh offset as the > cookie to to indicate the next inode to read. However, getdents uses the > filp->f_pos: > > error = vfs_readdir(file, filldir, &buf); > if (error < 0) > goto out_putf; > error = buf.error; > lastdirent = buf.previous; > if (lastdirent) { > if (put_user(file->f_pos, &lastdirent->d_off)) > error = -EFAULT; > else > error = count - buf.count; > } > > and xfs_file_readdir uses that as teh offset for lookups and keeps it up > to date correctly. hence the getdents code is overwritting the incorrect > value XFS has been stuffing in there and hence we haven't seen this > on normal syscalls. Except that the hack to go back to double buffering relies on the filldir offset being pushed off to be the next dirent, and hence with the patch I sent we set filp->f_pos incorrectly in xfs_file_readdir()..... > Ok, patch attached. passes 144 on all inode sizes, otherwise mostly > untested. I did say mostly untested :/ Updated patch below (which passes 006 but is still mostly untested). Cheers, dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/dmapi/xfs_dm.c | 4 ---- fs/xfs/linux-2.6/xfs_file.c | 4 ++-- fs/xfs/xfs_dir2_block.c | 6 ++---- fs/xfs/xfs_dir2_leaf.c | 2 +- fs/xfs/xfs_dir2_sf.c | 9 +++------ 5 files changed, 8 insertions(+), 17 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_block.c 2007-08-23 23:03:09.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c 2007-12-07 10:23:14.933645761 +1100 @@ -508,7 +508,7 @@ xfs_dir2_block_getdents( continue; cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - ptr - (char *)block); + (char *)dep - (char *)block); ino = be64_to_cpu(dep->inumber); #if XFS_BIG_INUMS ino += mp->m_inoadd; @@ -519,9 +519,7 @@ xfs_dir2_block_getdents( */ if (filldir(dirent, dep->name, dep->namelen, cook, ino, DT_UNKNOWN)) { - *offset = xfs_dir2_db_off_to_dataptr(mp, - mp->m_dirdatablk, - (char *)dep - (char *)block); + *offset = cook; xfs_da_brelse(NULL, bp); return 0; } Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_leaf.c 2007-08-24 22:24:45.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c 2007-12-07 10:18:17.623544813 +1100 @@ -1091,7 +1091,7 @@ xfs_dir2_leaf_getdents( * Won't fit. Return to caller. */ if (filldir(dirent, dep->name, dep->namelen, - xfs_dir2_byte_to_dataptr(mp, curoff + length), + xfs_dir2_byte_to_dataptr(mp, curoff), ino, DT_UNKNOWN)) break; Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_sf.c 2007-08-23 23:03:09.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c 2007-12-07 10:20:57.887115812 +1100 @@ -752,7 +752,7 @@ xfs_dir2_sf_getdents( #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif - if (filldir(dirent, ".", 1, dotdot_offset, ino, DT_DIR)) { + if (filldir(dirent, ".", 1, dot_offset, ino, DT_DIR)) { *offset = dot_offset; return 0; } @@ -762,13 +762,11 @@ xfs_dir2_sf_getdents( * Put .. entry unless we're starting past it. */ if (*offset <= dotdot_offset) { - off = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - XFS_DIR2_DATA_FIRST_OFFSET); ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif - if (filldir(dirent, "..", 2, off, ino, DT_DIR)) { + if (filldir(dirent, "..", 2, dotdot_offset, ino, DT_DIR)) { *offset = dotdot_offset; return 0; } @@ -793,8 +791,7 @@ xfs_dir2_sf_getdents( #endif if (filldir(dirent, sfep->name, sfep->namelen, - off + xfs_dir2_data_entsize(sfep->namelen), - ino, DT_UNKNOWN)) { + off, ino, DT_UNKNOWN)) { *offset = off; return 0; } Index: 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/dmapi/xfs_dm.c 2007-12-03 17:11:46.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c 2007-12-07 11:25:42.678472255 +1100 @@ -1772,7 +1772,6 @@ xfs_dm_get_dioinfo( typedef struct dm_readdir_cb { xfs_mount_t *mp; - xfs_off_t lastoff; char __user *ubuf; dm_stat_t __user *lastbuf; size_t spaceleft; @@ -1834,7 +1833,6 @@ dm_filldir(void *__buf, const char *name cb->spaceleft -= statp->_link; cb->nwritten += statp->_link; cb->ubuf += statp->_link; - cb->lastoff = offset; return 0; @@ -1910,8 +1908,6 @@ xfs_dm_get_dirattrs_rvp( goto out_kfree; } - loc = cb->lastoff; - error = -EFAULT; if (cb->lastbuf && put_user(0, &cb->lastbuf->_link)) goto out_kfree; Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2007-12-03 18:41:26.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c 2007-12-07 12:36:52.123061435 +1100 @@ -357,13 +357,13 @@ xfs_file_readdir( reclen = sizeof(struct hack_dirent) + de->namlen; size -= reclen; - curr_offset = de->offset /* & 0x7fffffff */; de = (struct hack_dirent *)((char *)de + reclen); + curr_offset = de->offset /* & 0x7fffffff */; } } done: - if (!error) { + if (!error) { if (size == 0) filp->f_pos = offset & 0x7fffffff; else if (de) From owner-xfs@oss.sgi.com Mon Dec 10 13:54:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 13:55:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lBALsjUY013424 for ; Mon, 10 Dec 2007 13:54:54 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA19975; Mon, 10 Dec 2007 17:19:46 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id C08AD58C4C34; Mon, 10 Dec 2007 17:19:46 +1100 (EST) Date: Mon, 10 Dec 2007 17:19:46 +1100 To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.24-rc5 User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20071210061946.C08AD58C4C34@chook.melbourne.sgi.com> From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13885 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/linux-2.6/xfs_buf.c | 37 +++++------- fs/xfs/linux-2.6/xfs_file.c | 124 ++++++++++++++++++++++++++++++++++++++++ fs/xfs/linux-2.6/xfs_ioctl.c | 20 +++---- fs/xfs/linux-2.6/xfs_ioctl32.c | 3 + fs/xfs/linux-2.6/xfs_iops.c | 4 +- fs/xfs/quota/xfs_qm.c | 3 + fs/xfs/xfs_iget.c | 2 +- fs/xfs/xfs_itable.c | 43 +++++++++----- 8 files changed, 186 insertions(+), 50 deletions(-) through these commits: commit cf10e82bdc0d38d09dfaf46d0daf56136138ef3f Author: David Chinner Date: Fri Dec 7 14:09:11 2007 +1100 [XFS] Fix xfs_ichgtime()s broken usage of I_SYNC The recent I_LOCK->I_SYNC changes mistakenly changed xfs_ichgtime to look at I_SYNC instead of I_LOCK. This was incorrect and prevents newly created inodes from moving to the dirty list. Change this to the correct check which is for I_NEW, not I_LOCK or I_SYNC so that behaviour is correct. SGI-PV: 974225 SGI-Modid: xfs-linux-melb:xfs-kern:30204a Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy commit 978c7b2ff49597ab76ff7529a933bd366941ac25 Author: Rafael J. Wysocki Date: Fri Dec 7 14:09:02 2007 +1100 [XFS] Make xfsbufd threads freezable Fix breakage caused by commit 831441862956fffa17b9801db37e6ea1650b0f69 that did not introduce the necessary call to set_freezable() in xfs/linux-2.6/xfs_buf.c . SGI-PV: 974224 SGI-Modid: xfs-linux-melb:xfs-kern:30203a Signed-off-by: Rafael J. Wysocki Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy commit e89bc612d61edbcefaeb6f2244f86c0f3ec89d23 Author: Christoph Hellwig Date: Fri Dec 7 14:07:53 2007 +1100 [XFS] revert to double-buffering readdir The current readdir implementation deadlocks on a btree buffers locks because nfsd calls back into ->lookup from the filldir callback. The only short-term fix for this is to revert to the old inefficient double-buffering scheme. SGI-PV: 973377 SGI-Modid: xfs-linux-melb:xfs-kern:30201a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy commit a7430847fcb19297d6db833f35b9c9645c4a6395 Author: David Chinner Date: Fri Nov 23 16:30:23 2007 +1100 [XFS] Fix broken inode cluster setup. The radix tree based inode caches did away with the inode cluster hashes, replacing them with a bunch of masking and gang lookups on the radix tree. This masking got broken when moving the code to per-ag radix trees and indexing by agino # rather than straight inode number. The result is clustered inode writeback does not cluster and things can go extremely slowly when there are lots of inodes to write. Fix it up by comparing the agino # of the inode we just looked up to the index of the cluster we are looking for. Tested-by: Torsten Kaiser SGI-PV: 972915 SGI-Modid: xfs-linux-melb:xfs-kern:30033a Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy commit 77be55a5a13d9c7ddf780a93861f2fba33f8be1a Author: Lachlan McIlroy Date: Fri Nov 23 16:31:00 2007 +1100 [XFS] Clear XBF_READ_AHEAD flag on I/O completion. SGI-PV: 972554 SGI-Modid: xfs-linux-melb:xfs-kern:30128a Signed-off-by: Lachlan McIlroy Signed-off-by: Christoph Hellwig commit d1afb678ce77b930334a8a640a05b8e68178a377 Author: Lachlan McIlroy Date: Tue Nov 27 17:01:24 2007 +1100 [XFS] Fixed a few bugs in xfs_buf_associate_memory() - calculation of 'page_count' was incorrect as it did not consider the offset of 'mem' into the first page. The logic to bump 'page_count' didn't work if 'len' was <= PAGE_CACHE_SIZE (ie offset = 3k, len = 2k). - setting b_buffer_length to 'len' is incorrect if 'offset' is > 0. Set it to the total length of the buffer. - I suspect that passing a non-aligned address into mem_to_page() for the first page may have been causing issues - don't know but just tidy up that code anyway. SGI-PV: 971596 SGI-Modid: xfs-linux-melb:xfs-kern:30143a Signed-off-by: Lachlan McIlroy Signed-off-by: Christoph Hellwig commit cd57e594adc624dd9ee4c0ded3949da21ec24b2f Author: Lachlan McIlroy Date: Fri Nov 23 16:30:32 2007 +1100 [XFS] 971064 Various fixups for xfs_bulkstat(). - sanity check for NULL user buffer in xfs_ioc_bulkstat[_compat]() - remove the special case for XFS_IOC_FSBULKSTAT with count == 1. This special case causes bulkstat to fail because the special case uses xfs_bulkstat_single() instead of xfs_bulkstat() and the two functions have different semantics. xfs_bulkstat() will return the next inode after the one supplied while skipping internal inodes (ie quota inodes). xfs_bulkstate_single() will only lookup the inode supplied and return an error if it is an internal inode. - in xfs_bulkstat(), need to initialise 'lastino' to the inode supplied so in cases were we return without examining any inodes the scan wont restart back at zero. - sanity check for valid *ubcountp values. Cannot sanity check for valid ubuffer here because some users of xfs_bulkstat() don't supply a buffer. - checks against 'ubleft' (the space left in the user's buffer) should be against 'statstruct_size' which is the supplied minimum object size. The mixture of checks against statstruct_size and 0 was one of the reasons we were skipping inodes. - if the formatter function returns BULKSTAT_RV_NOTHING and an error and the error is not ENOENT or EINVAL then we need to abort the scan. ENOENT is for inodes that are no longer valid and we just skip them. EINVAL is returned if we try to lookup an internal inode so we skip them too. For a DMF scan if the inode and DMF attribute cannot fit into the space left in the user's buffer it would return ERANGE. We didn't handle this error and skipped the inode. We would continue to skip inodes until one fitted into the user's buffer or we completed the scan. - put back the recalculation of agino (that got removed with the last fix) at the end of the while loop. This is because the code at the start of the loop expects agino to be the last inode examined if it is non-zero. - if we found some inodes but then encountered an error, return success this time and the error next time. If the formatter aborted with ENOMEM we will now return this error but only if we couldn't read any inodes. Previously if we encountered ENOMEM without reading any inodes we returned a zero count and no error which falsely indicated the scan was complete. SGI-PV: 973431 SGI-Modid: xfs-linux-melb:xfs-kern:30089a Signed-off-by: Lachlan McIlroy Signed-off-by: David Chinner commit d757762bf2f6aea954745c76b4d767067b85be9d Author: Donald Douwsma Date: Fri Nov 23 16:27:42 2007 +1100 [XFS] Fix dbflush panic in xfs_qm_sync. The recent behaviour layer removal dropped the check for quotas that have been requested at mount time but have subsequently been turned off. This results in a panic when accessing m_quotainfo which has been freed. This patch adds the check originally made by xfs_qm_syncall() to xfs_qm_sync(). SGI-PV: 969769 SGI-Modid: xfs-linux-melb:xfs-kern:29908a Signed-off-by: Donald Douwsma Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy From owner-xfs@oss.sgi.com Mon Dec 10 13:54:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 13:55:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lBALsjUW013424 for ; Mon, 10 Dec 2007 13:54:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA20648; Mon, 10 Dec 2007 18:05:00 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lBA750IN3262737; Mon, 10 Dec 2007 18:05:00 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBA74wJO3143061; Mon, 10 Dec 2007 18:04:58 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 10 Dec 2007 18:04:58 +1100 From: David Chinner To: David Chinner Cc: Vlad Apostolov , Christoph Hellwig , Mark Goodwin , xfs-dev , xfs-oss Subject: [review please] Re: DMAPI problem with the new filldir implementation Message-ID: <20071210070458.GI4714@sgi.com> References: <475879DB.40705@sgi.com> <20071207002922.GQ115527101@sgi.com> <20071207014940.GS115527101@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071207014940.GS115527101@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13884 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs This passes xfsqa and various other handrolled tests I've thrown at it. Can i get some eyeballs on this, please? Cheers, Dave. On Fri, Dec 07, 2007 at 12:49:40PM +1100, David Chinner wrote: > On Fri, Dec 07, 2007 at 11:29:22AM +1100, David Chinner wrote: > > (cc xfs-dev and xfs@oss) > > > > On Fri, Dec 07, 2007 at 09:38:19AM +1100, Vlad Apostolov wrote: > > > Hi Christoph and Dave, > > > > > > It looks like we may have a problem caused by this patch: > > > > > > http://oss.sgi.com/archives/xfs/2007-07/msg00338.html > > > > > > It makes XFS test 144 to fail if the inode size is 2k. I did > > > some investigation and I think xfs_readdir() returns incorrect > > > next location for shortform directories. When the inode size is > > > 2k, more dir entries fit inline in the inode and test 144 > > > dm_get_dirattrs() starts using the shortform. > > > > > > I think this code here > > > > > > if (filldir(dirent, sfep->name, sfep->namelen, > > > off + xfs_dir2_data_entsize(sfep->namelen), > > > ino, DT_UNKNOWN)) { > > > > > > adds some offset "xfs_dir2_data_entsize(sfep->namelen)" to the > > > next location pointer, which appears to be incorrect and causes > > > directory entries to be skipped on the next call of dm_get_dirattrs(). > > > > It's supposed to be the offset of the next dirent: > > > > On Linux, the dirent structure is defined as follows: > > > > struct dirent { > > ino_t d_ino; /* inode number */ > > >>>>>> off_t d_off; /* offset to the next dirent */ > > unsigned short d_reclen; /* length of this record */ > > unsigned char d_type; /* type of file */ > > char d_name[256]; /* filename */ > > }; > > > > However, looking at the generic filldir() implementation in fs/readdir.c, > > I see that it: > > > > dirent = buf->previous; > > if (dirent) { > > if (__put_user(offset, &dirent->d_off)) > > goto efault; > > } > > > > Puts the offset in the *previous* dirent, not the current one. That > > means that the three calls to XFs makes to filldir() are all incorrect; > > they should be passing the offset of the current object, not the next > > object as teh filldir code stuffs it in the previous dirent. > > > > The reason that dmapi is failing here is that it uses teh offset as the > > cookie to to indicate the next inode to read. However, getdents uses the > > filp->f_pos: > > > > error = vfs_readdir(file, filldir, &buf); > > if (error < 0) > > goto out_putf; > > error = buf.error; > > lastdirent = buf.previous; > > if (lastdirent) { > > if (put_user(file->f_pos, &lastdirent->d_off)) > > error = -EFAULT; > > else > > error = count - buf.count; > > } > > > > and xfs_file_readdir uses that as teh offset for lookups and keeps it up > > to date correctly. hence the getdents code is overwritting the incorrect > > value XFS has been stuffing in there and hence we haven't seen this > > on normal syscalls. > > Except that the hack to go back to double buffering relies on the > filldir offset being pushed off to be the next dirent, and hence > with the patch I sent we set filp->f_pos incorrectly in > xfs_file_readdir()..... > > > > > Ok, patch attached. passes 144 on all inode sizes, otherwise mostly > > untested. > > I did say mostly untested :/ > > Updated patch below (which passes 006 but is still mostly untested). > > Cheers, > > dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > --- > fs/xfs/dmapi/xfs_dm.c | 4 ---- > fs/xfs/linux-2.6/xfs_file.c | 4 ++-- > fs/xfs/xfs_dir2_block.c | 6 ++---- > fs/xfs/xfs_dir2_leaf.c | 2 +- > fs/xfs/xfs_dir2_sf.c | 9 +++------ > 5 files changed, 8 insertions(+), 17 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_block.c 2007-08-23 23:03:09.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c 2007-12-07 10:23:14.933645761 +1100 > @@ -508,7 +508,7 @@ xfs_dir2_block_getdents( > continue; > > cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, > - ptr - (char *)block); > + (char *)dep - (char *)block); > ino = be64_to_cpu(dep->inumber); > #if XFS_BIG_INUMS > ino += mp->m_inoadd; > @@ -519,9 +519,7 @@ xfs_dir2_block_getdents( > */ > if (filldir(dirent, dep->name, dep->namelen, cook, > ino, DT_UNKNOWN)) { > - *offset = xfs_dir2_db_off_to_dataptr(mp, > - mp->m_dirdatablk, > - (char *)dep - (char *)block); > + *offset = cook; > xfs_da_brelse(NULL, bp); > return 0; > } > Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_leaf.c 2007-08-24 22:24:45.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c 2007-12-07 10:18:17.623544813 +1100 > @@ -1091,7 +1091,7 @@ xfs_dir2_leaf_getdents( > * Won't fit. Return to caller. > */ > if (filldir(dirent, dep->name, dep->namelen, > - xfs_dir2_byte_to_dataptr(mp, curoff + length), > + xfs_dir2_byte_to_dataptr(mp, curoff), > ino, DT_UNKNOWN)) > break; > > Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_sf.c 2007-08-23 23:03:09.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c 2007-12-07 10:20:57.887115812 +1100 > @@ -752,7 +752,7 @@ xfs_dir2_sf_getdents( > #if XFS_BIG_INUMS > ino += mp->m_inoadd; > #endif > - if (filldir(dirent, ".", 1, dotdot_offset, ino, DT_DIR)) { > + if (filldir(dirent, ".", 1, dot_offset, ino, DT_DIR)) { > *offset = dot_offset; > return 0; > } > @@ -762,13 +762,11 @@ xfs_dir2_sf_getdents( > * Put .. entry unless we're starting past it. > */ > if (*offset <= dotdot_offset) { > - off = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, > - XFS_DIR2_DATA_FIRST_OFFSET); > ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); > #if XFS_BIG_INUMS > ino += mp->m_inoadd; > #endif > - if (filldir(dirent, "..", 2, off, ino, DT_DIR)) { > + if (filldir(dirent, "..", 2, dotdot_offset, ino, DT_DIR)) { > *offset = dotdot_offset; > return 0; > } > @@ -793,8 +791,7 @@ xfs_dir2_sf_getdents( > #endif > > if (filldir(dirent, sfep->name, sfep->namelen, > - off + xfs_dir2_data_entsize(sfep->namelen), > - ino, DT_UNKNOWN)) { > + off, ino, DT_UNKNOWN)) { > *offset = off; > return 0; > } > Index: 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/dmapi/xfs_dm.c 2007-12-03 17:11:46.000000000 +1100 > +++ 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c 2007-12-07 11:25:42.678472255 +1100 > @@ -1772,7 +1772,6 @@ xfs_dm_get_dioinfo( > > typedef struct dm_readdir_cb { > xfs_mount_t *mp; > - xfs_off_t lastoff; > char __user *ubuf; > dm_stat_t __user *lastbuf; > size_t spaceleft; > @@ -1834,7 +1833,6 @@ dm_filldir(void *__buf, const char *name > cb->spaceleft -= statp->_link; > cb->nwritten += statp->_link; > cb->ubuf += statp->_link; > - cb->lastoff = offset; > > return 0; > > @@ -1910,8 +1908,6 @@ xfs_dm_get_dirattrs_rvp( > goto out_kfree; > } > > - loc = cb->lastoff; > - > error = -EFAULT; > if (cb->lastbuf && put_user(0, &cb->lastbuf->_link)) > goto out_kfree; > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2007-12-03 18:41:26.000000000 +1100 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c 2007-12-07 12:36:52.123061435 +1100 > @@ -357,13 +357,13 @@ xfs_file_readdir( > > reclen = sizeof(struct hack_dirent) + de->namlen; > size -= reclen; > - curr_offset = de->offset /* & 0x7fffffff */; > de = (struct hack_dirent *)((char *)de + reclen); > + curr_offset = de->offset /* & 0x7fffffff */; > } > } > > done: > - if (!error) { > + if (!error) { > if (size == 0) > filp->f_pos = offset & 0x7fffffff; > else if (de) -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 10 13:54:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 13:55:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lBALsjUa013424 for ; Mon, 10 Dec 2007 13:54:57 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19545; Mon, 10 Dec 2007 16:59:55 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 0F96358C4C34; Mon, 10 Dec 2007 16:59:55 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Message-Id: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> Date: Mon, 10 Dec 2007 16:59:55 +1100 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13886 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Don't wait for pending I/Os when purging blocks beyond eof. On last close of a file we purge blocks beyond eof. The same code is used when we truncate the file size down. In this case we need to wait for any pending I/Os for dirty pages beyond the new eof. For the last close case we are not changing the file size and therefore do not need to wait for any I/Os to complete. This fixes a performance bottleneck where writes into the page cache and cache flushes can become mutually exclusive. Date: Mon Dec 10 16:59:09 AEDT 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-vniowait Inspected by: pleckie Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30220a fs/xfs/xfs_inode.c - 1.489 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h - Don't wait for pending I/Os when purging blocks beyond eof. From owner-xfs@oss.sgi.com Mon Dec 10 14:10:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 14:10:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBAMA6cH016919 for ; Mon, 10 Dec 2007 14:10:07 -0800 X-ASG-Debug-ID: 1197323942-602000770000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D997FB24AE1 for ; Mon, 10 Dec 2007 13:59:02 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by cuda.sgi.com with ESMTP id NkbCM7XRFwH2IHg1 for ; Mon, 10 Dec 2007 13:59:02 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so3863136waf for ; Mon, 10 Dec 2007 13:59:01 -0800 (PST) Received: by 10.115.58.1 with SMTP id l1mr4601683wak.1197142954884; Sat, 08 Dec 2007 11:42:34 -0800 (PST) Received: by 10.114.255.19 with HTTP; Sat, 8 Dec 2007 11:42:34 -0800 (PST) Message-ID: <5d96567b0712081142r4ebb4f2dk25c8b00c30afe0b5@mail.gmail.com> Date: Sat, 8 Dec 2007 21:42:34 +0200 From: Raz To: "Chris Wedgwood" X-ASG-Orig-Subj: Re: mounting raid5 with different unit values Subject: Re: mounting raid5 with different unit values Cc: linux-xfs@oss.sgi.com, "Linux RAID Mailing List" In-Reply-To: <20071008004513.GA13543@puku.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> <20071007145213.GA4504@puku.stupidest.org> <20071008004513.GA13543@puku.stupidest.org> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.176] X-Barracuda-Start-Time: 1197323943 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36260 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13887 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs Well... this thing actually works just fine with a newer kernel ( 2.6.18-8-el5 centos5 ). I managed to mount / mkfs.xfs over raid5 with a pseudo raid5 unit size, and with the appropriate raid 5 patches and user space access-pattern, I elimintaed in 99% cases the read penalty . I sincerly hope I won't be getting any crashes with this file system tunnings. so ... first, chris and all you xfs guys, many many thanks. Chris, How "dangerous" these tunnings are ? Am I to expect "weird" behaviour of the file system ? On 10/8/07, Chris Wedgwood wrote: > On Sun, Oct 07, 2007 at 11:48:14AM -0400, Justin Piszcz wrote: > > > man mount :) > > Ah of course. > > But those will be more restrictive that what you can specify when you > make the file-system (because mkfs.xfs can aligned the AGs to suit). > -- Raz From owner-xfs@oss.sgi.com Mon Dec 10 14:20:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 14:20:27 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBAMK5U2018101 for ; Mon, 10 Dec 2007 14:20:08 -0800 X-ASG-Debug-ID: 1197324137-679800540000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 64E5EB24B48 for ; Mon, 10 Dec 2007 14:02:17 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id LwaN1nTpRez42lo4 for ; Mon, 10 Dec 2007 14:02:17 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J1pY4-0007Dv-Dz; Mon, 10 Dec 2007 20:48:20 +0000 Date: Mon, 10 Dec 2007 20:48:20 +0000 From: Christoph Hellwig To: David Chinner Cc: Vlad Apostolov , Christoph Hellwig , Mark Goodwin , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: DMAPI problem with the new filldir implementation Subject: Re: DMAPI problem with the new filldir implementation Message-ID: <20071210204820.GA27456@infradead.org> References: <475879DB.40705@sgi.com> <20071207002922.GQ115527101@sgi.com> <20071207014940.GS115527101@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071207014940.GS115527101@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197324138 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36260 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13888 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Looks good to me. Might be worth to add a test that does a readdir with a small buffer where only "." fits so we don't regress that special case. From owner-xfs@oss.sgi.com Mon Dec 10 14:20:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 14:20:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBAMK7l9018129 for ; Mon, 10 Dec 2007 14:20:08 -0800 X-ASG-Debug-ID: 1197324032-6780004e0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.gmx.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 27D6BB24B0B for ; Mon, 10 Dec 2007 14:00:32 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by cuda.sgi.com with SMTP id uBG2TS0yRDZlXYv2 for ; Mon, 10 Dec 2007 14:00:32 -0800 (PST) Received: (qmail invoked by alias); 10 Dec 2007 21:33:49 -0000 Received: from e182066231.adsl.alicedsl.de (EHLO anheuser) [85.182.66.231] by mail.gmx.net (mp052) with SMTP; 10 Dec 2007 22:33:49 +0100 X-Authenticated: #7882761 X-Provags-ID: V01U2FsdGVkX19V1sxegOlVthzsfD/qVoXG7FVfcEw4FKHEfQQiYU OXnRpMsM4TRX3t From: "Chris" To: X-ASG-Orig-Subj: Unexpected XFS SB number 0x00000000 Subject: Unexpected XFS SB number 0x00000000 Date: Mon, 10 Dec 2007 22:33:35 +0100 Message-ID: <002a01c83b74$52060330$f6120990$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7dFFfjrt8dob8TBqlN3KkO+00lw== Content-Language: de X-Y-GMX-Trusted: 0 X-Barracuda-Connect: mail.gmx.net[213.165.64.20] X-Barracuda-Start-Time: 1197324034 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36260 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13889 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hsvchris@gmx.de Precedence: bulk X-list: xfs Hello! I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller. I used to have 4 750GB HDDs connected and set up as RAID 5 array, single volume, single XFS partition (set up during the installation of Debian). No problems so far. Now I added another 750GB HDD to the array, online capacity/volume expansion by the controller finished just fine. My plan was to add the extra space to the above mentioned XFS partition. So I unmounted the partition, started cfdisk, removed the partition table and wrote a new one that included the new free space. After rebooting the partition wasn't mounted, so I couldn't use xfs_growth to expand the filesystem. xfs_check: unexpected XFS SB magic number 0x00000000 xfs_repair -n: Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock.......[...].............found candidate secondary superblock...unable to verify superblock, continuing..........[...]................ .......Sorry, could not find valid secondary superblock Exciting now. I realize the magic number 0x00000000 is probably not a good thing and maybe using fdisk to write a new table was not the way to do it? Any suggestions on restoring the old partition table / magic number or how to proceed? Is there an easy fix or is this a serious problem? Kind Regards, Chris From owner-xfs@oss.sgi.com Mon Dec 10 15:10:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 15:10:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBANA7mg022230 for ; Mon, 10 Dec 2007 15:10:08 -0800 X-ASG-Debug-ID: 1197327349-742f00f90000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 829F646768D for ; Mon, 10 Dec 2007 14:55:49 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id U5FoYK4DRjlGJqna for ; Mon, 10 Dec 2007 14:55:49 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 790F01C000292; Mon, 10 Dec 2007 17:55:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 75F514019355; Mon, 10 Dec 2007 17:55:17 -0500 (EST) Date: Mon, 10 Dec 2007 17:55:17 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Chris cc: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Unexpected XFS SB number 0x00000000 Subject: Re: Unexpected XFS SB number 0x00000000 In-Reply-To: <002a01c83b74$52060330$f6120990$@de> Message-ID: References: <002a01c83b74$52060330$f6120990$@de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1197327349 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36264 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13890 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Mon, 10 Dec 2007, Chris wrote: > Hello! > > I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch > (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller. > I used to have 4 750GB HDDs connected and set up as RAID 5 array, single > volume, single XFS partition (set up during the installation of Debian). No > problems so far. > > Now I added another 750GB HDD to the array, online capacity/volume expansion > by the controller finished just fine. > My plan was to add the extra space to the above mentioned XFS partition. So > I unmounted the partition, started cfdisk, removed the partition table and > wrote a new one that included the new free space. > After rebooting the partition wasn't mounted, so I couldn't use xfs_growth > to expand the filesystem. > > xfs_check: unexpected XFS SB magic number 0x00000000 > > xfs_repair -n: > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! > attempting to find secondary superblock.......[...].............found > candidate secondary superblock...unable to verify superblock, > continuing..........[...]................ > .......Sorry, could not find valid secondary superblock > Exciting now. > > I realize the magic number 0x00000000 is probably not a good thing and maybe > using fdisk to write a new table was not the way to do it? > Any suggestions on restoring the old partition table / magic number or how > to proceed? Is there an easy fix or is this a serious problem? > > Kind Regards, > Chris > > When I grew mine, I used mdadm/raid5, expanded the array and then you run xfs_growfs on the mounted filesystem and it worked. Wiping out the partition is not the way to do it. Justin. From owner-xfs@oss.sgi.com Mon Dec 10 15:20:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 15:20:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBANK8mU023305 for ; Mon, 10 Dec 2007 15:20:09 -0800 X-ASG-Debug-ID: 1197327669-746d00ea0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 72BE14679D2 for ; Mon, 10 Dec 2007 15:01:09 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id Eb6l5DziQ3rbjaYC for ; Mon, 10 Dec 2007 15:01:09 -0800 (PST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lBAMeNgv007821; Mon, 10 Dec 2007 17:40:23 -0500 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lBAMeNXd029435; Mon, 10 Dec 2007 17:40:23 -0500 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id lBAMeMqp019877; Mon, 10 Dec 2007 17:40:22 -0500 Message-ID: <475DC056.3000502@sandeen.net> Date: Mon, 10 Dec 2007 16:40:22 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Chris CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Unexpected XFS SB number 0x00000000 Subject: Re: Unexpected XFS SB number 0x00000000 References: <002a01c83b74$52060330$f6120990$@de> In-Reply-To: <002a01c83b74$52060330$f6120990$@de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1197327670 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36264 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13891 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Chris wrote: > Hello! > > I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch > (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller. > I used to have 4 750GB HDDs connected and set up as RAID 5 array, single > volume, single XFS partition (set up during the installation of Debian). No > problems so far. > > Now I added another 750GB HDD to the array, online capacity/volume expansion > by the controller finished just fine. > My plan was to add the extra space to the above mentioned XFS partition. So > I unmounted the partition, started cfdisk, removed the partition table and > wrote a new one that included the new free space. > After rebooting the partition wasn't mounted, so I couldn't use xfs_growth > to expand the filesystem. > > xfs_check: unexpected XFS SB magic number 0x00000000 Did your new partition table start in exactly the same place? Can you find the string "XFSB" anywhere near where your old partition started? -Eric From owner-xfs@oss.sgi.com Mon Dec 10 15:30:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 15:30:15 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBANU7tg024291 for ; Mon, 10 Dec 2007 15:30:08 -0800 X-ASG-Debug-ID: 1197328649-6030012a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-out3.libero.it (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6FB9CB26028 for ; Mon, 10 Dec 2007 15:17:29 -0800 (PST) Received: from smtp-out3.libero.it (smtp-out3.libero.it [212.52.84.43]) by cuda.sgi.com with ESMTP id 7IX7T3sqJz2UMKO5 for ; Mon, 10 Dec 2007 15:17:29 -0800 (PST) Received: from mailrelay11.libero.it (192.168.32.128) by smtp-out3.libero.it (7.3.120) id 4688F31B10B7E5FE for xfs@oss.sgi.com; Sun, 9 Dec 2007 18:52:06 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYjAA+6W0dTLLte/2dsb2JhbAAIiXY Received: from unknown (HELO libero.it) ([192.168.17.13]) by outrelay11.libero.it with ESMTP; 09 Dec 2007 18:52:06 +0100 Date: Sun, 9 Dec 2007 18:52:06 +0100 Message-Id: X-ASG-Orig-Subj: Serial number: 6666/05 Subject: Serial number: 6666/05 MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "msperrymichel" X-XaM3-API-Version: 4.3 (R1) (B3pl19) X-SenderIP: 83.44.187.94 X-Barracuda-Connect: smtp-out3.libero.it[212.52.84.43] X-Barracuda-Start-Time: 1197328650 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4679 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.32 X-Barracuda-Spam-Status: No, SCORE=0.32 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=MISSING_HEADERS, TO_CC_NONE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36265 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.19 MISSING_HEADERS Missing To: header 0.13 TO_CC_NONE No To: or Cc: header To: undisclosed-recipients:; X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id lBANU8tg024314 X-archive-position: 13892 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: msperrymichel@libero.it Precedence: bulk X-list: xfs Serial number: 6666/05 Your winning informations for 500,000.00 in category 'A' email lottery are as below. ticket number: 1001-558962-5899. Serial number: 6666/05 Reference number: 7743909/es Contact Mr.Richard Halbert Tel: + 34-635-112-356 Fax: +34-605-196-898 Email:claimdepatminfoes@yahoo.es Yours Sincerely, Mrs. Seville Antonio. From owner-xfs@oss.sgi.com Mon Dec 10 15:49:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 15:49:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBANnmEo025882 for ; Mon, 10 Dec 2007 15:49:52 -0800 X-ASG-Debug-ID: 1197330598-7499016e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2A688467BDE; Mon, 10 Dec 2007 15:49:58 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id 9EoTdWDQIIauOags; Mon, 10 Dec 2007 15:49:58 -0800 (PST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lBAHojHV013965; Mon, 10 Dec 2007 12:50:45 -0500 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lBAHojFo006098; Mon, 10 Dec 2007 12:50:45 -0500 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id lBAHoiOt014580; Mon, 10 Dec 2007 12:50:44 -0500 Message-ID: <475D7C74.6080004@sandeen.net> Date: Mon, 10 Dec 2007 11:50:44 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 972756 - Implement fallocate. Subject: Re: TAKE 972756 - Implement fallocate. References: <20071102024314.9BF3458C38F7@chook.melbourne.sgi.com> In-Reply-To: <20071102024314.9BF3458C38F7@chook.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1197330599 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36268 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13893 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs David Chinner wrote: > Implement fallocate. > > Implement the new generic callout for file preallocation. > Atomically change the file size if requested. > > > Date: Fri Nov 2 13:42:52 AEDT 2007 > Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs > Inspected by: hch@infradead.org > > The following file(s) were checked into: > longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb > > > Modid: xfs-linux-melb:xfs-kern:30009a > fs/xfs/linux-2.6/xfs_iops.c - 1.268 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.268&r2=text&tr2=1.267&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.268&r2=text&tr2=1.267&f=h > - implement ->fallocate() > > > Is this ever going to go upstream...? -eric From owner-xfs@oss.sgi.com Mon Dec 10 16:41:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 16:41:24 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBB0fHWR001623 for ; Mon, 10 Dec 2007 16:41:19 -0800 X-ASG-Debug-ID: 1197333683-677e02120000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.gmx.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 009CBB26F1F for ; Mon, 10 Dec 2007 16:41:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by cuda.sgi.com with SMTP id 4x1upPEhdFTqWUUK for ; Mon, 10 Dec 2007 16:41:24 -0800 (PST) Received: (qmail invoked by alias); 11 Dec 2007 00:41:21 -0000 Received: from e182066231.adsl.alicedsl.de (EHLO anheuser) [85.182.66.231] by mail.gmx.net (mp042) with SMTP; 11 Dec 2007 01:41:21 +0100 X-Authenticated: #7882761 X-Provags-ID: V01U2FsdGVkX1/ggLhhBC3gTL2n4RunhCKoxoRDLFx5W7DwZGsQ7v /3dqPxEdxY8UXt From: "Chris" To: "'Eric Sandeen'" Cc: References: <002a01c83b74$52060330$f6120990$@de> <475DC056.3000502@sandeen.net> In-Reply-To: <475DC056.3000502@sandeen.net> X-ASG-Orig-Subj: AW: Unexpected XFS SB number 0x00000000 Subject: AW: Unexpected XFS SB number 0x00000000 Date: Tue, 11 Dec 2007 01:41:07 +0100 Message-ID: <003401c83b8e$84c1d730$8e458590$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7fajbbY3qepCUTHyavxeML5xisgAC5Avw Content-Language: de X-Y-GMX-Trusted: 0 X-Barracuda-Connect: mail.gmx.net[213.165.64.20] X-Barracuda-Start-Time: 1197333689 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3569 1.0000 -0.1288 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.13 X-Barracuda-Spam-Status: No, SCORE=-0.13 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36271 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13894 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hsvchris@gmx.de Precedence: bulk X-list: xfs > Did your new partition table start in exactly the same place? > I assumed it would be in the same place... I guess there is no way to find out what the old one looked like? > Can you find the string "XFSB" anywhere near where your old partition > started? > I can try to do so...how? :) When I look into the partition with cfdisk, I can see what cylinders/heads/sectors it uses. But I'm sure there are other tools? Interestingly, after a reboot cfdisk shows me a 801575.31 MB partition and 2199023.26 MB free space, although I wrote a single partition of 3000598.57 MB into the table before rebooting. From owner-xfs@oss.sgi.com Mon Dec 10 17:06:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 17:06:57 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBB16qoT003988 for ; Mon, 10 Dec 2007 17:06:53 -0800 X-ASG-Debug-ID: 1197335221-675500070000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.gmx.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id B55D4B26DFD for ; Mon, 10 Dec 2007 17:07:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by cuda.sgi.com with SMTP id sjBUCivXJi2OK1Ne for ; Mon, 10 Dec 2007 17:07:02 -0800 (PST) Received: (qmail invoked by alias); 11 Dec 2007 01:06:59 -0000 Received: from e182066231.adsl.alicedsl.de (EHLO anheuser) [85.182.66.231] by mail.gmx.net (mp018) with SMTP; 11 Dec 2007 02:06:59 +0100 X-Authenticated: #7882761 X-Provags-ID: V01U2FsdGVkX19HDOx3buRHQHF55ZPvdgGEAgyj6muuDdIW/kQCJk l2jFD/skpzBO0T From: "Chris" To: "'Eric Sandeen'" Cc: References: <002a01c83b74$52060330$f6120990$@de> <475DC056.3000502@sandeen.net> In-Reply-To: X-ASG-Orig-Subj: Re: Unexpected XFS SB number 0x00000000 Subject: Re: Unexpected XFS SB number 0x00000000 Date: Tue, 11 Dec 2007 02:06:43 +0100 Message-ID: <000301c83b92$191f6110$4b5e2330$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7fajbbY3qepCUTHyavxeML5xisgAC5AvwAAHnh9A= Content-Language: de X-Y-GMX-Trusted: 0 X-Barracuda-Connect: mail.gmx.net[213.165.64.20] X-Barracuda-Start-Time: 1197335223 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0989 1.0000 -1.3991 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.40 X-Barracuda-Spam-Status: No, SCORE=-1.40 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36273 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13895 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hsvchris@gmx.de Precedence: bulk X-list: xfs > > Did your new partition table start in exactly the same place? > > > > I assumed it would be in the same place... > I guess there is no way to find out what the old one looked like? > > > Can you find the string "XFSB" anywhere near where your old partition > > started? > > > > I can try to do so...how? :) > When I look into the partition with cfdisk, I can see what cylinders/heads/sectors it uses. But I'm > sure there are other tools? > > Interestingly, after a reboot cfdisk shows me a 801575.31 MB partition and 2199023.26 MB free space, > although I wrote a single partition of 3000598.57 MB into the table before rebooting. I just tested some more and using parted found out the following: (parted) print Warning: /dev/sdb contains GPT signatures, indicating that is has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table? Yes/No? y Disk /dev/sdb: 3001GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 22250GB 22250GB xfs So it seems that parted can still "see" the old table. But it doesn't have support for resizing xfs partitions... From owner-xfs@oss.sgi.com Mon Dec 10 17:26:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 17:26:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBB1QrD9005610 for ; Mon, 10 Dec 2007 17:26:55 -0800 X-ASG-Debug-ID: 1197336423-574300860000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4AB45468342 for ; Mon, 10 Dec 2007 17:27:03 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id BRg3RdE14tDwlKJT for ; Mon, 10 Dec 2007 17:27:03 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 2B3DB18234C9E; Mon, 10 Dec 2007 19:26:31 -0600 (CST) Message-ID: <475DE745.9040907@sandeen.net> Date: Mon, 10 Dec 2007 19:26:29 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Chris CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: AW: Unexpected XFS SB number 0x00000000 Subject: Re: AW: Unexpected XFS SB number 0x00000000 References: <002a01c83b74$52060330$f6120990$@de> <475DC056.3000502@sandeen.net> <003401c83b8e$84c1d730$8e458590$@de> In-Reply-To: <003401c83b8e$84c1d730$8e458590$@de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197336424 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36274 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13896 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Chris wrote: >> Did your new partition table start in exactly the same place? >> > > I assumed it would be in the same place... > I guess there is no way to find out what the old one looked like? > >> Can you find the string "XFSB" anywhere near where your old partition >> started? >> > > I can try to do so...how? :) > When I look into the partition with cfdisk, I can see what > cylinders/heads/sectors it uses. But I'm sure there are other tools? > > Interestingly, after a reboot cfdisk shows me a 801575.31 MB partition and > 2199023.26 MB free space, although I wrote a single partition of 3000598.57 > MB into the table before rebooting. fat partitions can't be > 2T -Eric From owner-xfs@oss.sgi.com Mon Dec 10 18:13:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 18:13:26 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBB2DJuF008176 for ; Mon, 10 Dec 2007 18:13:22 -0800 X-ASG-Debug-ID: 1197339209-1c35002c0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 331204687CD for ; Mon, 10 Dec 2007 18:13:29 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id TPazJcRCm8a9fV3E for ; Mon, 10 Dec 2007 18:13:29 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 8D79B18004494; Mon, 10 Dec 2007 20:12:57 -0600 (CST) Message-ID: <475DF228.80306@sandeen.net> Date: Mon, 10 Dec 2007 20:12:56 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Chris CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Unexpected XFS SB number 0x00000000 Subject: Re: Unexpected XFS SB number 0x00000000 References: <002a01c83b74$52060330$f6120990$@de> <475DC056.3000502@sandeen.net> <000301c83b92$191f6110$4b5e2330$@de> In-Reply-To: <000301c83b92$191f6110$4b5e2330$@de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197339210 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0004 1.0000 -2.0186 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36276 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13897 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Chris wrote: > I just tested some more and using parted found out the following: > > (parted) print > Warning: /dev/sdb contains GPT signatures, indicating that is has a GPT > table. However, it does not have a valid fake msdos partition table, as it > should. Perhaps it was corrupted -- possibly by a program that doesn't > understand GPT partition tables. Or perhaps you deleted the GPT table, and > are now using an msdos partition table. Is this a GPT partition table? > Yes/No? y > > Disk /dev/sdb: 3001GB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > > Number Start End Size File system Name > Flags > 1 17.4kB 22250GB 22250GB xfs > > > So it seems that parted can still "see" the old table. But it doesn't have > support for resizing xfs partitions... So, did you originally have a gpt or an msdos partition table? From owner-xfs@oss.sgi.com Mon Dec 10 18:53:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 18:53:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBB2rPCs011039 for ; Mon, 10 Dec 2007 18:53:29 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA18108; Tue, 11 Dec 2007 13:53:24 +1100 Message-ID: <475DFC42.1080300@sgi.com> Date: Tue, 11 Dec 2007 13:56:02 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] xfs: kill last 2.4 ifdef leftover References: <20071130093836.GA2949@lst.de> In-Reply-To: <20071130093836.GA2949@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13898 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs.h 2007-09-29 11:48:48.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs.h 2007-09-29 11:49:03.000000000 +0200 > @@ -41,11 +41,6 @@ > #define XFS_FILESTREAMS_TRACE 1 > #endif > > -#include > -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) > #include > -#else > -#include > -#endif > > #endif /* __XFS_H__ */ > I'll check it in. Ta. --Tim From owner-xfs@oss.sgi.com Mon Dec 10 20:24:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 20:24:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBB4OoiY022127 for ; Mon, 10 Dec 2007 20:24:54 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19873; Tue, 11 Dec 2007 15:24:56 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 7758F58C4C34; Tue, 11 Dec 2007 15:24:56 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 971186 - kill last 2.4 ifdef leftover Message-Id: <20071211042456.7758F58C4C34@chook.melbourne.sgi.com> Date: Tue, 11 Dec 2007 15:24:56 +1100 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13899 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs kill last 2.4 ifdef leftover Signed-off-by: Christoph Hellwig Date: Tue Dec 11 15:24:15 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30226a fs/xfs/xfs.h - 1.51 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs.h.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h - kill last 2.4 ifdef leftover From owner-xfs@oss.sgi.com Tue Dec 11 00:11:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 00:11:17 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBB8B906007037 for ; Tue, 11 Dec 2007 00:11:12 -0800 X-ASG-Debug-ID: 1197360678-154500ae0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 87E9346987C; Tue, 11 Dec 2007 00:11:19 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id r2hXjCKxuChlnRJT; Tue, 11 Dec 2007 00:11:19 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J20Cz-00052n-K4; Tue, 11 Dec 2007 08:11:17 +0000 Date: Tue, 11 Dec 2007 08:11:17 +0000 From: Christoph Hellwig To: Lachlan McIlroy Cc: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Message-ID: <20071211081117.GB19213@infradead.org> References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197360680 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36299 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5083/Mon Dec 10 22:22:03 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13900 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Dec 10, 2007 at 04:59:55PM +1100, Lachlan McIlroy wrote: > Don't wait for pending I/Os when purging blocks beyond eof. > > On last close of a file we purge blocks beyond eof. The same > code is used when we truncate the file size down. In this case > we need to wait for any pending I/Os for dirty pages beyond the > new eof. For the last close case we are not changing the file > size and therefore do not need to wait for any I/Os to complete. > This fixes a performance bottleneck where writes into the page > cache and cache flushes can become mutually exclusive. I think I shortened from of this should be in the comment above the conditional vn_iowait intead of the current /* wait for the completion of any pending DIOs */ which is wrong given that we don't wait for all pending direct I/O requests.. (and vn_iowait doesn't wait for direct I/O anyway) From owner-xfs@oss.sgi.com Tue Dec 11 03:36:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 03:36:36 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBBaVG3028616 for ; Tue, 11 Dec 2007 03:36:32 -0800 X-ASG-Debug-ID: 1197372999-3e8800d00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from puma.mxtelecom.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CB3AE459796 for ; Tue, 11 Dec 2007 03:36:39 -0800 (PST) Received: from puma.mxtelecom.com (mx1.mxtelecom.com [87.86.212.101]) by cuda.sgi.com with ESMTP id Hg8e1QwsQM5EqJEn for ; Tue, 11 Dec 2007 03:36:39 -0800 (PST) Received: from wings.mxtelecom.com ([192.168.2.111] helo=[127.0.0.1]) by puma.mxtelecom.com with esmtp (Exim 4.66) (envelope-from ) id 1J23Pg-0005AI-Lu; Tue, 11 Dec 2007 11:36:36 +0000 Message-ID: <475E76AB.705@mxtelecom.com> Date: Tue, 11 Dec 2007 11:38:19 +0000 From: Matthew Hodgson Organization: MX Telecom Ltd User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Zero-copy Block IO with XFS Subject: Zero-copy Block IO with XFS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.mxtelecom.com[87.86.212.101] X-Barracuda-Start-Time: 1197373002 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36309 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5090/Tue Dec 11 02:08:19 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13901 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@mxtelecom.com Precedence: bulk X-list: xfs Hi all, I'm experimenting with using XFS with a network block device (DST), and have come up against the problem that when writing data to the network, it uses kernel_sendpage to hand the page presented at the BIO layer to the network stack. It then completes the block IO request. The problem arises when XFS proceeds to then reuse that page before the NIC actually sends it. Particularly if TX checksumming or TCP segmentation is being offloaded to the NIC, it seems that the NIC will try to access to page after the BIO request has returned, and so operate on stale data. I assume the same problem might happen in the case of TCP retransmits or similar. The motivation for using sendpage rather than sendmsg (or using sendpage on a copy of the original page) is to try to ensure speed by a zero-copy path through the subsystem. Is there any way at all in which XFS would be able to (theoretically) expose an API to allow an underlying block device to retain ownership of pages until it's done with them, so as to avoid a potentially needless copy? Or is there another way of achieving this? thanks in advance, Matthew. -- Matthew Hodgson Media & Systems Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com From owner-xfs@oss.sgi.com Tue Dec 11 04:47:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 04:47:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBClrKr007559 for ; Tue, 11 Dec 2007 04:47:54 -0800 X-ASG-Debug-ID: 1197377281-22d900830000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.gmx.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 9FD6746A4F1 for ; Tue, 11 Dec 2007 04:48:01 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by cuda.sgi.com with SMTP id m9PnsxGhtKCjVmYK for ; Tue, 11 Dec 2007 04:48:01 -0800 (PST) Received: (qmail invoked by alias); 11 Dec 2007 12:47:59 -0000 Received: from d191156.adsl.hansenet.de (EHLO anheuser) [80.171.191.156] by mail.gmx.net (mp016) with SMTP; 11 Dec 2007 13:47:59 +0100 X-Authenticated: #7882761 X-Provags-ID: V01U2FsdGVkX19/0rgJKt5/8hoIEdkhMrO3o54VYP65aZhg/2TfTl SQMu9otQ7xVX96 From: "Chris" To: "'Chris'" Cc: References: In-Reply-To: X-ASG-Orig-Subj: Re: Unexpected XFS SB number 0x00000000 Subject: Re: Unexpected XFS SB number 0x00000000 Date: Tue, 11 Dec 2007 13:47:44 +0100 Message-ID: <000001c83bf4$06a8bd80$13fa3880$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7dFFfjrt8dob8TBqlN3KkO+00lwAfmlAQ Content-Language: de X-Y-GMX-Trusted: 0 X-Barracuda-Connect: mail.gmx.net[213.165.64.20] X-Barracuda-Start-Time: 1197377284 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4166 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36317 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5090/Tue Dec 11 02:08:19 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13902 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hsvchris@gmx.de Precedence: bulk X-list: xfs Seems like using parted to write a new partition table did the job for me. Used 17.4kB as start and 3000GB as end. Now being able to mount the partition successfully I ran xfs_growfs. Afterwards, I still had to do an xfs_repair though, because there were a lot of (seemingly) random errors when accessing certain files. Everthing normal now... From owner-xfs@oss.sgi.com Tue Dec 11 08:39:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 08:39:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBGd894031048 for ; Tue, 11 Dec 2007 08:39:10 -0800 X-ASG-Debug-ID: 1197391152-21c201b80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nz-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5F83FB30921 for ; Tue, 11 Dec 2007 08:39:12 -0800 (PST) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by cuda.sgi.com with ESMTP id 71Iumilisj8860sl for ; Tue, 11 Dec 2007 08:39:12 -0800 (PST) Received: by nz-out-0506.google.com with SMTP id x3so810090nzd for ; Tue, 11 Dec 2007 08:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=EoQhLH3d07lasgLt0Vbjoy2ne3lzjoRe1JHABrO0rLM=; b=sxv/wdEllur2XekfJdSeNrJU8xDS3qGSAn2U/x8ZPFAkqDGsSmZVduNp5wSwSKw9sBsJM8lhpsfJ/iG9UP7aI7O9u8s1eITWDhJ6Kgq9j/8hPCNEA3LOMY8x/BrMsrimyMu2ym0a+5poz+BZPCQmQHF6NgCVfHKteiYNswXuSF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NGJzMK/4cjvR6/2vSznV6kV9IKLBAg1kms4ZelagjXp2dYgkUUFG/HOEXsAP2vocriYbmxbvL8qp3QmWBuZEpx1ORpFkKh224XwZql8t0Tz2lz9gR782fCf4QvVFunzM6ykEvmsvH2FrM+0/ubMgZYQetAxBNYV294/NpPwPZ9U= Received: by 10.142.102.5 with SMTP id z5mr3711360wfb.1197391145820; Tue, 11 Dec 2007 08:39:05 -0800 (PST) Received: by 10.142.162.19 with HTTP; Tue, 11 Dec 2007 08:39:05 -0800 (PST) Message-ID: Date: Tue, 11 Dec 2007 22:09:05 +0530 From: "Bhagi rathi" To: "Matthew Hodgson" X-ASG-Orig-Subj: Re: Zero-copy Block IO with XFS Subject: Re: Zero-copy Block IO with XFS Cc: xfs@oss.sgi.com In-Reply-To: <475E76AB.705@mxtelecom.com> MIME-Version: 1.0 References: <475E76AB.705@mxtelecom.com> X-Barracuda-Connect: nz-out-0506.google.com[64.233.162.237] X-Barracuda-Start-Time: 1197391159 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36332 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5091/Tue Dec 11 04:41:37 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1878 X-archive-position: 13903 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs On Dec 11, 2007 5:08 PM, Matthew Hodgson wrote: > Hi all, > > I'm experimenting with using XFS with a network block device (DST), and > have come up against the problem that when writing data to the network, > it uses kernel_sendpage to hand the page presented at the BIO layer to > the network stack. It then completes the block IO request. Actually, you can pass a sendpage read actor which takes a reference on the page which ensures valid page exists with you. As long as you have ref on the page and no truncate to the same file, you can safely access the file. Once NIC sends the data over wire, you can do put_page. This should work. By the way, linux sendfile does something similar to the above. Look into read actor of nfs server sendfile usage. -Cheers, Bhagi. > > > The problem arises when XFS proceeds to then reuse that page before the > NIC actually sends it. Particularly if TX checksumming or TCP > segmentation is being offloaded to the NIC, it seems that the NIC will > try to access to page after the BIO request has returned, and so operate > on stale data. I assume the same problem might happen in the case of > TCP retransmits or similar. The motivation for using sendpage rather > than sendmsg (or using sendpage on a copy of the original page) is to > try to ensure speed by a zero-copy path through the subsystem. > > Is there any way at all in which XFS would be able to (theoretically) > expose an API to allow an underlying block device to retain ownership of > pages until it's done with them, so as to avoid a potentially needless > copy? Or is there another way of achieving this? > > thanks in advance, > > Matthew. > > > -- > Matthew Hodgson > Media & Systems Project Manager > Tel: +44 (0) 845 666 7778 > http://www.mxtelecom.com > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Dec 11 08:52:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 08:52:20 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, J_CHICKENPOX_42 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBGqBXF032588 for ; Tue, 11 Dec 2007 08:52:15 -0800 X-ASG-Debug-ID: 1197391937-174200160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nz-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 55D1446BC2E for ; Tue, 11 Dec 2007 08:52:17 -0800 (PST) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.229]) by cuda.sgi.com with ESMTP id f25HHsNt7cPClegT for ; Tue, 11 Dec 2007 08:52:17 -0800 (PST) Received: by nz-out-0506.google.com with SMTP id x3so815140nzd for ; Tue, 11 Dec 2007 08:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=BarU9r+mLohefHrHql1ZEq+PtqPr8gaEahVjFXw+qCM=; b=nI8PlZKMr7I2kSaQAVcdSrEZ8SStn7pOqEcVcVGHkuBJ2ssuA5xQKt7q4oTawnouwnKieoIfatdr/fWEPJQEtEiYUd1X1je54M/uxHfGOJlVJXCBVeiOU4NY1/cDmjUeTx2LhZysMcmDt16ILBXhGE8Hl1t2CqudA4KoQLpXxUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=j6EkM4nN+evwpYTUD+N6Yfwwm11z4wYXNIeMUPjTjlf6P/B2P9VxaChlxFJR+k0h8dFmw+1cxIQetqWD4XY4hwganvnhzdeYogYEg3z5ezP+q+pZYzQ4jXJSS/Z8nZnuYv4EcuHedtGQKSYlLvyRSymoMFpRBudomVJQKe+iOH0= Received: by 10.142.251.9 with SMTP id y9mr3729872wfh.1197391934673; Tue, 11 Dec 2007 08:52:14 -0800 (PST) Received: by 10.142.162.19 with HTTP; Tue, 11 Dec 2007 08:52:14 -0800 (PST) Message-ID: Date: Tue, 11 Dec 2007 22:22:14 +0530 From: "Bhagi rathi" To: "Lachlan McIlroy" X-ASG-Orig-Subj: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Cc: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com In-Reply-To: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> MIME-Version: 1.0 References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> X-Barracuda-Connect: nz-out-0506.google.com[64.233.162.229] X-Barracuda-Start-Time: 1197391941 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36333 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5091/Tue Dec 11 04:41:37 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2098 X-archive-position: 13904 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs On Dec 10, 2007 11:29 AM, Lachlan McIlroy wrote: > Don't wait for pending I/Os when purging blocks beyond eof. > > On last close of a file we purge blocks beyond eof. The same > code is used when we truncate the file size down. In this case > we need to wait for any pending I/Os for dirty pages beyond the > new eof. For the last close case we are not changing the file > size and therefore do not need to wait for any I/Os to complete. > This fixes a performance bottleneck where writes into the page > cache and cache flushes can become mutually exclusive. Lachlan, How the following is addressed if we don't wait for I/O to complete during close of the file and issue truncate: - We didn't waited for the I/O to complete - Truncated blocks beyond EOF. - These blocks are re-used for another transaction as meta-data. - Meta-data flush was induced. However the flush of meta-data reached first before the data I/O because of some issues with under-lying driver. Later the file I/O over-written the meta-data I/O. We have corruption of data. It seems the corruption could be in various ways. Isn't this the reason why truncate has to wait for the I/O to complete? I believe fundamental problem is once the blocks are free'ed, the re-association should not expect some I/O in concurrent to those same block addresses. -Cheers, Bhagi. > > > Date: Mon Dec 10 16:59:09 AEDT 2007 > Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-vniowait > Inspected by: pleckie > Author: lachlan > > The following file(s) were checked into: > longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb > > > Modid: xfs-linux-melb:xfs-kern:30220a > fs/xfs/xfs_inode.c - 1.489 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h > > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h > - Don't wait for pending I/Os when purging blocks beyond eof. > > > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Dec 11 10:27:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 10:28:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBIRtse009039 for ; Tue, 11 Dec 2007 10:27:56 -0800 X-ASG-Debug-ID: 1197397683-4a5200f80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.ukfsn.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C62C3B33EA3 for ; Tue, 11 Dec 2007 10:28:03 -0800 (PST) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by cuda.sgi.com with ESMTP id 4FnMeQq8gQesLcAj for ; Tue, 11 Dec 2007 10:28:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 01D19DF073 for ; Tue, 11 Dec 2007 18:28:47 +0000 (GMT) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (smtp-filter.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwnWAqdnny6l for ; Tue, 11 Dec 2007 18:28:47 +0000 (GMT) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 5B9D3DF3E0 for ; Tue, 11 Dec 2007 18:28:21 +0000 (GMT) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1J29ol-0002Zh-KQ for xfs@oss.sgi.com; Tue, 11 Dec 2007 18:26:55 +0000 Message-ID: <475ED66F.40800@dgreaves.com> Date: Tue, 11 Dec 2007 18:26:55 +0000 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS internal error xfs_btree_check_sblock Subject: XFS internal error xfs_btree_check_sblock X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: s2.ukfsn.org[217.158.120.143] X-Barracuda-Start-Time: 1197397686 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36338 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5092/Tue Dec 11 08:35:26 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13905 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Hi I've been having problems with this filesystem for a while now. I upgraded to 2.6.23 to see if it's improved (no). Once every 2 or 3 cold boots I get this in dmesg as the user logs in and accesses the /scratch filesystem. If the error doesn't occur as the user logs in then it won't happen at all. Filesystem "dm-0": XFS internal error xfs_btree_check_sblock at line 334 of file fs/xfs/xfs_btree.c. Caller 0xc01b7bc1 [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] dump_stack+0x15/0x20 [] xfs_error_report+0x4f/0x60 [] xfs_btree_check_sblock+0x56/0xd0 [] xfs_alloc_lookup+0x181/0x390 [] xfs_alloc_lookup_eq+0x13/0x20 [] xfs_free_ag_extent+0x2f4/0x690 [] xfs_free_extent+0xb4/0xd0 [] xfs_bmap_finish+0x119/0x170 [] xfs_remove+0x247/0x4f0 [] xfs_vn_unlink+0x22/0x50 [] vfs_unlink+0x68/0xa0 [] do_unlinkat+0xb9/0x140 [] sys_unlink+0x10/0x20 [] syscall_call+0x7/0xb ======================= xfs_force_shutdown(dm-0,0x8) called from line 4274 of file fs/xfs/xfs_bmap.c. Return address = 0xc0214dae Filesystem "dm-0": Corruption of in-memory data detected. Shutting down filesystem: dm-0 Please umount the filesystem, and rectify the problem(s) I ssh in as root, umount, mount, umount and run xfs_repair. This is what I got this time: Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... ir_freecount/free mismatch, inode chunk 59/5027968, freecount 27 nfree 26 - found root inode chunk All the rest was clean. It is possible this fs suffered in the 2.6.17 timeframe It is also possible something got broken whilst I was having lots of issues with hibernate (which is still unreliable). I wonder if the fs is borked and xfs_repair isn't fixing it? David PS Please cc on replies. From owner-xfs@oss.sgi.com Tue Dec 11 11:43:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 11:43:21 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_20,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBJhEFs016566 for ; Tue, 11 Dec 2007 11:43:17 -0800 X-ASG-Debug-ID: 1197402205-494d01cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pmx2.sophos.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 026DAB34BF3 for ; Tue, 11 Dec 2007 11:43:25 -0800 (PST) Received: from pmx2.sophos.com (pmx2.sophos.com [213.31.172.17]) by cuda.sgi.com with ESMTP id oJn59MDAsc36LzO5 for ; Tue, 11 Dec 2007 11:43:25 -0800 (PST) Received: from pmx2.sophos.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C38612DA94E for ; Tue, 11 Dec 2007 19:42:52 +0000 (GMT) Received: from smtp22.ca.sophos.com (unknown [192.168.3.163]) by pmx2.sophos.com (Postfix) with ESMTP id 3356C2DA929 for ; Tue, 11 Dec 2007 19:42:52 +0000 (GMT) Received: from ca-exchange.ca.sophos.com (ca-exchange.activestate.ca [192.168.3.140]) by smtp.ca.sophos.com (8.13.1/8.13.1) with ESMTP id lBBJgoHQ009552 for ; Tue, 11 Dec 2007 11:42:50 -0800 X-PMWin-Version: 2.6.1, Antivirus-Engine: 2.52.1 thread-index: Acg8LgZH8fwVgNZmTa+E0x1wdRd4XQ== Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Received: from [192.168.99.209] ([192.168.99.209]) by ca-exchange.ca.sophos.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 11:42:55 -0800 Message-ID: <475EE83A.3060607@ca.sophos.com> Date: Tue, 11 Dec 2007 11:42:50 -0800 From: "David Sparks" Reply-To: "David Sparks" Organization: SophosLabs User-Agent: Thunderbird 2.0.0.9 (X11/20071206) MIME-Version: 1.0 To: X-ASG-Orig-Subj: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? Subject: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 19:42:55.0111 (UTC) FILETIME=[06407970:01C83C2E] X-PMX-Version: 5.3.3.310218, Liza: Liza 1.0 r47, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.11.112626 X-PMX-QueueID: uk-pmx2.brown.sophos:475EE83C_23949_228_1 X-Barracuda-Connect: pmx2.sophos.com[213.31.172.17] X-Barracuda-Start-Time: 1197402206 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36344 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13906 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dave@ca.sophos.com Precedence: bulk X-list: xfs Hi all, Is it expected that filesystems made with lazy-count=1 are not mountable by older kernels? I'm installing a system based with install media based on 2.6.19 and mkfs.xfs 2.8.11 (its Gentoo 2007.0). That mkfs.xfs is old so i copied over a 2.9.4 binary and used that to mkfs the filesystem but its unmountable. Removing the lazy-count=1 option makes it mountable. Is this an expected incompatibility or is mix-n-matching xfsprogs a bad idea? Thanks! From owner-xfs@oss.sgi.com Tue Dec 11 14:16:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 14:16:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBBMFtvx002837 for ; Tue, 11 Dec 2007 14:16:00 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12780; Wed, 12 Dec 2007 09:16:00 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lBBMFxIN5471993; Wed, 12 Dec 2007 09:15:59 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBBMFtOd5470770; Wed, 12 Dec 2007 09:15:55 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 12 Dec 2007 09:15:55 +1100 From: David Chinner To: David Sparks Cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? Message-ID: <20071211221554.GC4612@sgi.com> References: <475EE83A.3060607@ca.sophos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475EE83A.3060607@ca.sophos.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13907 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 11, 2007 at 11:42:50AM -0800, David Sparks wrote: > Hi all, > > Is it expected that filesystems made with lazy-count=1 are not mountable by > older kernels? That is expected. lazy-count is a mkfs option because it changes the on-disk format slightly, and older kernels do not understand that format. Hence mkfs sets a superblock feature bit to prevent the filesystem from being mounted on kernels that don't understand the slightly different disk format. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 11 14:25:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 14:25:50 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBBMPhDU003941 for ; Tue, 11 Dec 2007 14:25:45 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13464; Wed, 12 Dec 2007 09:25:50 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lBBMPmIN5476294; Wed, 12 Dec 2007 09:25:49 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBBMPkTS4562020; Wed, 12 Dec 2007 09:25:46 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 12 Dec 2007 09:25:46 +1100 From: David Chinner To: David Greaves Cc: xfs@oss.sgi.com Subject: Re: XFS internal error xfs_btree_check_sblock Message-ID: <20071211222546.GD4612@sgi.com> References: <475ED66F.40800@dgreaves.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475ED66F.40800@dgreaves.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13908 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 11, 2007 at 06:26:55PM +0000, David Greaves wrote: > Hi > > I've been having problems with this filesystem for a while now. > > I upgraded to 2.6.23 to see if it's improved (no). > > Once every 2 or 3 cold boots I get this in dmesg as the user logs in and > accesses the /scratch filesystem. If the error doesn't occur as the user logs in > then it won't happen at all. > > Filesystem "dm-0": XFS internal error xfs_btree_check_sblock at line 334 of file > fs/xfs/xfs_btree.c. Caller 0xc01b7bc1 > [] show_trace_log_lvl+0x1a/0x30 > [] show_trace+0x12/0x20 > [] dump_stack+0x15/0x20 > [] xfs_error_report+0x4f/0x60 > [] xfs_btree_check_sblock+0x56/0xd0 > [] xfs_alloc_lookup+0x181/0x390 > [] xfs_alloc_lookup_eq+0x13/0x20 > [] xfs_free_ag_extent+0x2f4/0x690 > [] xfs_free_extent+0xb4/0xd0 > [] xfs_bmap_finish+0x119/0x170 > [] xfs_remove+0x247/0x4f0 > [] xfs_vn_unlink+0x22/0x50 > [] vfs_unlink+0x68/0xa0 > [] do_unlinkat+0xb9/0x140 > [] sys_unlink+0x10/0x20 > [] syscall_call+0x7/0xb > ======================= > xfs_force_shutdown(dm-0,0x8) called from line 4274 of file fs/xfs/xfs_bmap.c. > Return address = 0xc0214dae > Filesystem "dm-0": Corruption of in-memory data detected. Shutting down > filesystem: dm-0 > Please umount the filesystem, and rectify the problem(s) So there's a corrupted freespace btree block. > I ssh in as root, umount, mount, umount and run xfs_repair. > > This is what I got this time: > > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > ir_freecount/free mismatch, inode chunk 59/5027968, freecount 27 nfree 26 > - found root inode chunk > > All the rest was clean. repair doesn't check the freespace btrees - it just rebuilds them from scratch. use xfs_check to tell you what is wrong with the filesystem, then use xfs_repair to fix it.... > It is possible this fs suffered in the 2.6.17 timeframe > It is also possible something got broken whilst I was having lots of issues with > hibernate (which is still unreliable). Suspend does not quiesce filesystems safely, so you risk filesystem corruption every time you suspend and resume no matter what filesystem you use. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 11 15:14:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 15:14:17 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBNEAB3007751 for ; Tue, 11 Dec 2007 15:14:12 -0800 X-ASG-Debug-ID: 1197414860-165600130000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3644810FA446 for ; Tue, 11 Dec 2007 15:14:20 -0800 (PST) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id SechnEgai1hzDiZq for ; Tue, 11 Dec 2007 15:14:20 -0800 (PST) Received: from [192.168.1.21] (dslb-084-056-075-184.pools.arcor-ip.net [84.56.75.184]) by mail.lichtvoll.de (Postfix) with ESMTP id 3799A5ADDC for ; Tue, 11 Dec 2007 23:40:41 +0100 (CET) From: Martin Steigerwald To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: write barrier over device mapper supported or not? Subject: write barrier over device mapper supported or not? Date: Tue, 11 Dec 2007 23:42:23 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712112342.24094.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1197414861 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36356 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13909 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Hello! Are write barriers over device mapper supported or not? On LVM2 xfs tells me: Dec 11 23:00:09 shambala kernel: Filesystem "dm-0": Disabling barriers, not supported by the underlying device Dec 11 23:00:09 shambala kernel: XFS mounting filesystem dm-0 Dec 11 23:00:09 shambala kernel: Ending clean XFS mount for filesystem: dm-0 But when I mount ext3 on LVM2 I get: Dec 11 23:05:34 shambala kernel: kjournald starting. Commit interval 5 seconds Dec 11 23:05:34 shambala kernel: EXT3 FS on dm-1, internal journal Dec 11 23:05:34 shambala kernel: EXT3-fs: mounted filesystem with ordered data mode. even when I explicetely specify "-o barrier=1" which should enable barriers on ext3. As far as I understood from the changelogs as I wrote my Linux-Magazin I thought there should be device mapper support in the kernel, but I can not reproduce that finding anymore at the moment. But back then I also looked at the ext3 / jbd sources and found that jbd issues a warning when barrier support is not available. However I do not find that one either. And when I use reisferfs it also seems that write barriers are not available over LVM2: Dec 11 23:34:58 shambala kernel: ReiserFS: dm-2: found reiserfs format "3.6" with standard journal Dec 11 23:34:58 shambala kernel: ReiserFS: dm-2: using ordered data mode Dec 11 23:34:58 shambala kernel: reiserfs: using flush barriers Dec 11 23:34:58 shambala kernel: ReiserFS: dm-2: journal params: device dm-2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Dec 11 23:34:58 shambala kernel: ReiserFS: dm-2: checking transaction log (dm-2) Dec 11 23:35:01 shambala kernel: reiserfs: disabling flush barriers on dm-2 Dec 11 23:35:01 shambala kernel: ReiserFS: dm-2: Using r5 hash to sort names Dec 11 23:35:01 shambala kernel: ReiserFS: dm-2: warning: Created .reiserfs_priv on dm-2 - reserved for xattr storage. Hmmm... too bad... means I will likely not use LVM on my next laptop harddisk. I think I should file a kernel bug report about that. Anyone knows of any plans to support write barriers via device mapper? Well I guess I should ask on dm-devel or so if such a mailinglist exists. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Dec 11 15:25:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 15:25:26 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBBNPDQu009047 for ; Tue, 11 Dec 2007 15:25:22 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15908; Wed, 12 Dec 2007 10:25:21 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lBBNPKIN5496317; Wed, 12 Dec 2007 10:25:20 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBBNPHcc5496140; Wed, 12 Dec 2007 10:25:17 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 12 Dec 2007 10:25:17 +1100 From: David Chinner To: Christoph Hellwig Cc: Lachlan McIlroy , sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Message-ID: <20071211232517.GE4612@sgi.com> References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> <20071211081117.GB19213@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071211081117.GB19213@infradead.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13910 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 11, 2007 at 08:11:17AM +0000, Christoph Hellwig wrote: > On Mon, Dec 10, 2007 at 04:59:55PM +1100, Lachlan McIlroy wrote: > > Don't wait for pending I/Os when purging blocks beyond eof. > > > > On last close of a file we purge blocks beyond eof. The same > > code is used when we truncate the file size down. In this case > > we need to wait for any pending I/Os for dirty pages beyond the > > new eof. For the last close case we are not changing the file > > size and therefore do not need to wait for any I/Os to complete. > > This fixes a performance bottleneck where writes into the page > > cache and cache flushes can become mutually exclusive. > > I think I shortened from of this should be in the comment above > the conditional vn_iowait intead of the current > > /* wait for the completion of any pending DIOs */ > > which is wrong given that we don't wait for all pending direct I/O > requests.. (and vn_iowait doesn't wait for direct I/O anyway) vn_iowait() does wait for direct I/O. That was it's entire purpose - to be able to prevent truncate vs direct I/O write races by tracking direct I/Os. We increment ip->i_iocount in xfs_alloc_ioend() which is called from both the buffered write and direct I/O write path, so vn_iowait() does wait for both buffered and direct writes to complete. FWIW, the freeze code makes use of this functionality (SYNC_IOWAIT) to ensure all pending data writes are complete complete before the freeze is completed.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 11 15:40:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 15:41:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBNetWC011269 for ; Tue, 11 Dec 2007 15:40:57 -0800 X-ASG-Debug-ID: 1197416466-221b00530000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.ukfsn.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BED3546EDBC for ; Tue, 11 Dec 2007 15:41:06 -0800 (PST) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by cuda.sgi.com with ESMTP id ZxpIwBWytpxjcrFv for ; Tue, 11 Dec 2007 15:41:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id C6576DECB3; Tue, 11 Dec 2007 23:42:27 +0000 (GMT) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (smtp-filter.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v22fT3e1c33E; Tue, 11 Dec 2007 23:42:27 +0000 (GMT) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 9E266DEF14; Tue, 11 Dec 2007 23:42:25 +0000 (GMT) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1J2Eie-0005Y5-Ux; Tue, 11 Dec 2007 23:40:57 +0000 Message-ID: <475F2008.5030702@dgreaves.com> Date: Tue, 11 Dec 2007 23:40:56 +0000 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error xfs_btree_check_sblock Subject: Re: XFS internal error xfs_btree_check_sblock References: <475ED66F.40800@dgreaves.com> <20071211222546.GD4612@sgi.com> In-Reply-To: <20071211222546.GD4612@sgi.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: s2.ukfsn.org[217.158.120.143] X-Barracuda-Start-Time: 1197416466 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36359 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13911 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs David Chinner wrote: > On Tue, Dec 11, 2007 at 06:26:55PM +0000, David Greaves wrote: >> Once every 2 or 3 cold boots I get this in dmesg as the user logs in and > So there's a corrupted freespace btree block. OK, ta >> I ssh in as root, umount, mount, umount and run xfs_repair. > repair doesn't check the freespace btrees - it just rebuilds them from > scratch. use xfs_check to tell you what is wrong with the filesystem, then > use xfs_repair to fix it.... OK, having repaired it: haze:~# xfs_check /dev/video_vg/video_lv haze:~# So why do I have to do this on a regular basis (ie run xfs_repair)? I am shutting the machine down cleanly (init 0) >> It is possible this fs suffered in the 2.6.17 timeframe >> It is also possible something got broken whilst I was having lots of issues with >> hibernate (which is still unreliable). > > Suspend does not quiesce filesystems safely, so you risk filesystem > corruption every time you suspend and resume no matter what filesystem > you use. Well, FWIW, I've not hibernated this machine for a *long* time. Also my hibernate script used to run xfs_freeze before hibernating (to be on the safe side). This would regularly hang with an xfs_io process (or some such IIRC) in an unkillable state. I was about to edit my init scripts to do a mount, umount, xfs_repair, mount cycle. But then I thought "this is wrong - I'll report it". So is there anything else I should do? David From owner-xfs@oss.sgi.com Tue Dec 11 16:34:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 16:35:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBC0YrKh021527 for ; Tue, 11 Dec 2007 16:34:56 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA18228; Wed, 12 Dec 2007 11:34:59 +1100 Message-ID: <475F2D54.3090609@sgi.com> Date: Wed, 12 Dec 2007 11:37:40 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: David Sparks CC: xfs@oss.sgi.com Subject: Re: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? References: <475EE83A.3060607@ca.sophos.com> <20071211221554.GC4612@sgi.com> In-Reply-To: <20071211221554.GC4612@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13912 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Tue, Dec 11, 2007 at 11:42:50AM -0800, David Sparks wrote: >> Hi all, >> >> Is it expected that filesystems made with lazy-count=1 are not mountable by >> older kernels? > > That is expected. lazy-count is a mkfs option because it changes the on-disk > format slightly, and older kernels do not understand that format. Hence > mkfs sets a superblock feature bit to prevent the filesystem from being > mounted on kernels that don't understand the slightly different disk format. > > Cheers, > > Dave. And there will be a message in the logs but it probably isn't overly obvious what it is talking about. Looking at code, I presume it will come from: if (!XFS_SB_GOOD_VERSION(sbp)) { xfs_fs_mount_cmn_err(flags, "bad version"); return XFS_ERROR(EWRONGFS); } so there will be a msg about a "bad version". --Tim From owner-xfs@oss.sgi.com Tue Dec 11 17:53:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 17:53:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBC1rGYd025876 for ; Tue, 11 Dec 2007 17:53:18 -0800 X-ASG-Debug-ID: 1197424407-668700f10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from puma.mxtelecom.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E523710FB12D for ; Tue, 11 Dec 2007 17:53:27 -0800 (PST) Received: from puma.mxtelecom.com (mx1.mxtelecom.com [87.86.212.101]) by cuda.sgi.com with ESMTP id bzeFzLUCTkpiLmXU for ; Tue, 11 Dec 2007 17:53:27 -0800 (PST) Received: from localhost ([127.0.0.1]) by puma.mxtelecom.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1J2GmJ-0002au-3z; Wed, 12 Dec 2007 01:52:51 +0000 Date: Wed, 12 Dec 2007 01:52:48 +0000 (GMT) From: Matthew Hodgson To: xfs@oss.sgi.com cc: Bhagi rathi X-ASG-Orig-Subj: Re: Zero-copy Block IO with XFS Subject: Re: Zero-copy Block IO with XFS In-Reply-To: Message-ID: References: <475E76AB.705@mxtelecom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: mx1.mxtelecom.com[87.86.212.101] X-Barracuda-Start-Time: 1197424407 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36368 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13913 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@mxtelecom.com Precedence: bulk X-list: xfs On Tue, 11 Dec 2007, Bhagi rathi wrote: > On Dec 11, 2007 5:08 PM, Matthew Hodgson wrote: > >> Hi all, >> >> I'm experimenting with using XFS with a network block device (DST), and >> have come up against the problem that when writing data to the network, >> it uses kernel_sendpage to hand the page presented at the BIO layer to >> the network stack. It then completes the block IO request. > > Actually, you can pass a sendpage read actor which takes a reference on > the page which ensures valid page exists with you. Hmm, i'm a little confused as to how one would do that - I can see that sendfile can be passed a read actor for use in the underlying read, but I can't see anywhere where sendpage can be used with a read actor. I see that nfsd/vfs.c:nfsd_read_actor() adjusts the page refcounting to stop them being freed before they are sent - but that only seems to be usable when sending with sendfile. > As long as you have > ref on the page and no truncate to the same file, you can safely access > the file. Once NIC sends the data over wire, you can do put_page. This > should work. I'm not sure that it will help, though. The problem seems to be that XFS itself overwrites the page with new data (rather than the page being freed and reused) whilst the page is waiting to be sent in the TCP stack. Is there any way to prevent XFS from doing this - or have I misunderstood the problem? Along similar lines, is there any way to stop XFS from passing slab pages to the block IO layer? Attempts to pass slab pages over to the TCP stack fail too. thanks, Matthew. From owner-xfs@oss.sgi.com Tue Dec 11 19:36:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 19:36:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBC3aYA3004415 for ; Tue, 11 Dec 2007 19:36:38 -0800 X-ASG-Debug-ID: 1197430601-668501cf0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CA0E9B39CC9 for ; Tue, 11 Dec 2007 19:36:41 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 3Gaevk9r1X3CyR8A for ; Tue, 11 Dec 2007 19:36:41 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 2D61018004494; Tue, 11 Dec 2007 21:36:39 -0600 (CST) Message-ID: <475F5746.8080405@sandeen.net> Date: Tue, 11 Dec 2007 21:36:38 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Martin Steigerwald CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: write barrier over device mapper supported or not? Subject: Re: write barrier over device mapper supported or not? References: <200712112342.24094.Martin@lichtvoll.de> In-Reply-To: <200712112342.24094.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197430605 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36376 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5094/Tue Dec 11 18:55:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13914 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Martin Steigerwald wrote: > Hello! > > Are write barriers over device mapper supported or not? Nope. see dm_request(): /* * There is no use in forwarding any barrier request since we can't * guarantee it is (or can be) handled by the targets correctly. */ if (unlikely(bio_barrier(bio))) { bio_endio(bio, -EOPNOTSUPP); return 0; } > On LVM2 xfs tells me: > > Dec 11 23:00:09 shambala kernel: Filesystem "dm-0": Disabling barriers, > not supported by the underlying device > Dec 11 23:00:09 shambala kernel: XFS mounting filesystem dm-0 > Dec 11 23:00:09 shambala kernel: Ending clean XFS mount for filesystem: > dm-0 > > But when I mount ext3 on LVM2 I get: > > Dec 11 23:05:34 shambala kernel: kjournald starting. Commit interval 5 > seconds > Dec 11 23:05:34 shambala kernel: EXT3 FS on dm-1, internal journal > Dec 11 23:05:34 shambala kernel: EXT3-fs: mounted filesystem with ordered > data mode. > > even when I explicetely specify "-o barrier=1" which should enable > barriers on ext3. > > As far as I understood from the changelogs as I wrote my Linux-Magazin I > thought there should be device mapper support in the kernel, but I can > not reproduce that finding anymore at the moment. > > But back then I also looked at the ext3 / jbd sources and found that jbd > issues a warning when barrier support is not available. However I do not > find that one either. in journal_write_commit_record() there is such a warning, but not in the mount path: printk(KERN_WARNING "JBD: barrier-based sync failed on %s - " "disabling barriers\n", bdevname(journal->j_dev, b)); and if I set barrier=1 on an lvm-root test box, I do get: JBD: barrier-based sync failed on dm-0 - disabling barriers -Eric From owner-xfs@oss.sgi.com Tue Dec 11 20:03:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 20:03:27 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBC43LaN007217 for ; Tue, 11 Dec 2007 20:03:24 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23564; Wed, 12 Dec 2007 15:03:23 +1100 Message-ID: <475F5DC3.6070203@sgi.com> Date: Wed, 12 Dec 2007 15:04:19 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Bhagi rathi CC: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5094/Tue Dec 11 18:55:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13915 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Bhagi rathi wrote: > On Dec 10, 2007 11:29 AM, Lachlan McIlroy wrote: > >> Don't wait for pending I/Os when purging blocks beyond eof. >> >> On last close of a file we purge blocks beyond eof. The same >> code is used when we truncate the file size down. In this case >> we need to wait for any pending I/Os for dirty pages beyond the >> new eof. For the last close case we are not changing the file >> size and therefore do not need to wait for any I/Os to complete. >> This fixes a performance bottleneck where writes into the page >> cache and cache flushes can become mutually exclusive. > > > Lachlan, > > How the following is addressed if we don't wait for I/O to complete during > close of the file and > issue truncate: > > - We didn't waited for the I/O to complete > - Truncated blocks beyond EOF. > - These blocks are re-used for another transaction as meta-data. > - Meta-data flush was induced. However the flush of meta-data > reached first before the data I/O > because of some issues with under-lying driver. Later the file I/O > over-written the meta-data I/O. > We have corruption of data. This case will not happen. For a truncate down we may have dirty pages beyond eof that are in the process of being written to disk while we are trying to shrink the file - we need to wait for those. In the case of truncating blocks beyond eof on last close we are not changing the file size and so there cannot be pages beyond eof. Any I/O that may be in progress will be within the file size and not to any of the blocks we are trying to free. > > It seems the corruption could be in various ways. Isn't this the reason why > truncate has to wait > for the I/O to complete? Corruption could certainly occur if we don't wait for I/O. I think the reason this code was added was to synchronize with direct I/O unwritten extent conversions which could occur after the direct writer thread has released the iolock and so we can't use the iolock alone as an I/O barrier. > I believe fundamental problem is once the blocks > are free'ed, the re-association should > not expect some I/O in concurrent to those same block addresses. > > -Cheers, > Bhagi. > > >> >> Date: Mon Dec 10 16:59:09 AEDT 2007 >> Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-vniowait >> Inspected by: pleckie >> Author: lachlan >> >> The following file(s) were checked into: >> longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb >> >> >> Modid: xfs-linux-melb:xfs-kern:30220a >> fs/xfs/xfs_inode.c - 1.489 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/>> xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h >> http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h >> - Don't wait for pending I/Os when purging blocks beyond eof. >> >> >> >> >> > > > [[HTML alternate version deleted]] > > > From owner-xfs@oss.sgi.com Tue Dec 11 21:14:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 21:14:21 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBC5DuYQ019860 for ; Tue, 11 Dec 2007 21:14:00 -0800 X-ASG-Debug-ID: 1197436434-6070004e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2E8D0470260; Tue, 11 Dec 2007 21:13:54 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id cgmDbOPWSgCwMcYR; Tue, 11 Dec 2007 21:13:54 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J2Juq-0001uz-2h; Wed, 12 Dec 2007 05:13:52 +0000 Date: Wed, 12 Dec 2007 05:13:51 +0000 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , Lachlan McIlroy , sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Message-ID: <20071212051351.GA7291@infradead.org> References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> <20071211081117.GB19213@infradead.org> <20071211232517.GE4612@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071211232517.GE4612@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197436448 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0003 1.0000 -2.0188 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5095/Tue Dec 11 19:50:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13916 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Dec 12, 2007 at 10:25:17AM +1100, David Chinner wrote: > > which is wrong given that we don't wait for all pending direct I/O > > requests.. (and vn_iowait doesn't wait for direct I/O anyway) > > vn_iowait() does wait for direct I/O. That was it's entire purpose - to be > able to prevent truncate vs direct I/O write races by tracking direct I/Os. > We increment ip->i_iocount in xfs_alloc_ioend() which is called from both the > buffered write and direct I/O write path, so vn_iowait() does wait for both > buffered and direct writes to complete. Sorry, forgot a little important word above - it should read 'and vn_iowait doesn't wait _just_ for direct I/O anyway), because it waits for completion of regular I/O aswell. Not that it should actually matter in that caller.forgot a little important word above - it should read 'and vn_iowait doesn't wait _just_ for direct I/O anyway), because it waits for completion of regular I/O aswell. Not that it should actually matter in that caller. From owner-xfs@oss.sgi.com Tue Dec 11 23:01:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 23:02:03 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBC71X9t029332 for ; Tue, 11 Dec 2007 23:01:39 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA27583; Wed, 12 Dec 2007 18:01:41 +1100 Message-ID: <475F878D.6090407@sgi.com> Date: Wed, 12 Dec 2007 18:02:37 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] make inode reclaim synchronise with xfs_iflush_done() Content-Type: multipart/mixed; boundary="------------090009090006020202070505" X-Virus-Scanned: ClamAV 0.91.2/5095/Tue Dec 11 19:50:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13917 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------090009090006020202070505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On a forced shutdown, xfs_finish_reclaim() will skip flushing the inode. If the inode flush lock is not already held and there is an outstanding xfs_iflush_done() then we might free the inode prematurely. By acquiring and releasing the flush lock we will synchronise with xfs_iflush_done(). Alternatively we could take a hold on the inode when when issuing I/Os with xfs_iflush_done() and release it in xfs_iflush_done(). Would this be a better approach? Lachlan --------------090009090006020202070505 Content-Type: text/x-patch; name="xfs_finish_reclaim.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_finish_reclaim.diff" --- fs/xfs/xfs_vnodeops.c_1.726 2007-12-12 17:14:59.000000000 +1100 +++ fs/xfs/xfs_vnodeops.c 2007-12-12 17:15:42.000000000 +1100 @@ -3762,20 +3762,29 @@ xfs_finish_reclaim( goto reclaim; } xfs_iflock(ip); /* synchronize with xfs_iflush_done */ + xfs_ifunlock(ip); } ASSERT(ip->i_update_core == 0); ASSERT(ip->i_itemp == NULL || ip->i_itemp->ili_format.ilf_fields == 0); xfs_iunlock(ip, XFS_ILOCK_EXCL); - } else if (locked) { + } else { /* * We are not interested in doing an iflush if we're * in the process of shutting down the filesystem forcibly. * So, just reclaim the inode. - */ - xfs_ifunlock(ip); - xfs_iunlock(ip, XFS_ILOCK_EXCL); + * + * If the flush lock is not already held then temporarily + * acquire it to synchronize with xfs_iflush_done. + */ + if (locked) { + xfs_ifunlock(ip); + xfs_iunlock(ip, XFS_ILOCK_EXCL); + } else { + xfs_iflock(ip); + xfs_ifunlock(ip); + } } reclaim: --------------090009090006020202070505-- From owner-xfs@oss.sgi.com Tue Dec 11 23:06:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 23:07:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62, T_STOX_BOUND_090909_B autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBC76io0029881 for ; Tue, 11 Dec 2007 23:06:50 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA27648; Wed, 12 Dec 2007 18:06:50 +1100 Message-ID: <475F88C3.709@sgi.com> Date: Wed, 12 Dec 2007 18:07:47 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] prevent panic during log recovery due to bogus operation header length Content-Type: multipart/mixed; boundary="------------070900080804020003090805" X-Virus-Scanned: ClamAV 0.91.2/5098/Tue Dec 11 21:46:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13918 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------070900080804020003090805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A problem was reported where a system panicked in log recovery due to a corrupt log record. The cause of the corruption is not known but this change will at least prevent a crash for this specific scenario. Log recovery definitely needs some more work in this area. Lachlan --------------070900080804020003090805 Content-Type: text/x-patch; name="xfs_log_recover.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_log_recover.diff" --- fs/xfs/xfs_log_recover.c_1.332 2007-12-12 17:14:57.000000000 +1100 +++ fs/xfs/xfs_log_recover.c 2007-12-12 17:15:42.000000000 +1100 @@ -2912,7 +2912,12 @@ xlog_recover_process_data( xlog_recover_new_tid(&rhash[hash], tid, be64_to_cpu(rhead->h_lsn)); } else { - ASSERT(dp + be32_to_cpu(ohead->oh_len) <= lp); + if (dp + be32_to_cpu(ohead->oh_len) > lp) { + xlog_warn( + "XFS: xlog_recover_process_data: bad length"); + ASSERT(0); + return (XFS_ERROR(EIO)); + } flags = ohead->oh_flags & ~XLOG_END_TRANS; if (flags & XLOG_WAS_CONT_TRANS) flags &= ~XLOG_CONTINUE_TRANS; --------------070900080804020003090805-- From owner-xfs@oss.sgi.com Tue Dec 11 23:19:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 23:19:47 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBC7JV6S031342 for ; Tue, 11 Dec 2007 23:19:36 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA27919; Wed, 12 Dec 2007 18:19:38 +1100 Message-ID: <475F8BC3.8020804@sgi.com> Date: Wed, 12 Dec 2007 18:20:35 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] make xfs_idestroy() wait for log I/O to complete Content-Type: multipart/mixed; boundary="------------030001020001050703050701" X-Virus-Scanned: ClamAV 0.91.2/5098/Tue Dec 11 21:46:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13919 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------030001020001050703050701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit An xfs inode can be destroyed before log I/O involving that inode is complete. We need to wait for the inode to be unpinned before tearing it down. The patch looks big but the only real change is adding a call to xfs_iunpin_wait() to the start of xfs_idestroy(). The rest of the patch is moving xfs_idestroy() after the pinning routines. Lachlan --------------030001020001050703050701 Content-Type: text/x-patch; name="xfs_idestroy.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_idestroy.diff" --- fs/xfs/xfs_inode.c_1.489 2007-12-12 17:14:54.000000000 +1100 +++ fs/xfs/xfs_inode.c 2007-12-12 17:15:42.000000000 +1100 @@ -2733,71 +2733,6 @@ xfs_idestroy_fork( } /* - * This is called free all the memory associated with an inode. - * It must free the inode itself and any buffers allocated for - * if_extents/if_data and if_broot. It must also free the lock - * associated with the inode. - */ -void -xfs_idestroy( - xfs_inode_t *ip) -{ - switch (ip->i_d.di_mode & S_IFMT) { - case S_IFREG: - case S_IFDIR: - case S_IFLNK: - xfs_idestroy_fork(ip, XFS_DATA_FORK); - break; - } - if (ip->i_afp) - xfs_idestroy_fork(ip, XFS_ATTR_FORK); - mrfree(&ip->i_lock); - mrfree(&ip->i_iolock); - freesema(&ip->i_flock); - -#ifdef XFS_INODE_TRACE - ktrace_free(ip->i_trace); -#endif -#ifdef XFS_BMAP_TRACE - ktrace_free(ip->i_xtrace); -#endif -#ifdef XFS_BMBT_TRACE - ktrace_free(ip->i_btrace); -#endif -#ifdef XFS_RW_TRACE - ktrace_free(ip->i_rwtrace); -#endif -#ifdef XFS_ILOCK_TRACE - ktrace_free(ip->i_lock_trace); -#endif -#ifdef XFS_DIR2_TRACE - ktrace_free(ip->i_dir_trace); -#endif - if (ip->i_itemp) { - /* - * Only if we are shutting down the fs will we see an - * inode still in the AIL. If it is there, we should remove - * it to prevent a use-after-free from occurring. - */ - xfs_mount_t *mp = ip->i_mount; - xfs_log_item_t *lip = &ip->i_itemp->ili_item; - - ASSERT(((lip->li_flags & XFS_LI_IN_AIL) == 0) || - XFS_FORCED_SHUTDOWN(ip->i_mount)); - if (lip->li_flags & XFS_LI_IN_AIL) { - spin_lock(&mp->m_ail_lock); - if (lip->li_flags & XFS_LI_IN_AIL) - xfs_trans_delete_ail(mp, lip); - else - spin_unlock(&mp->m_ail_lock); - } - xfs_inode_item_destroy(ip); - } - kmem_zone_free(xfs_inode_zone, ip); -} - - -/* * Increment the pin count of the given buffer. * This value is protected by ipinlock spinlock in the mount structure. */ @@ -2860,6 +2795,74 @@ xfs_iunpin_wait( wait_event(ip->i_ipin_wait, (atomic_read(&ip->i_pincount) == 0)); } +/* + * This is called free all the memory associated with an inode. + * It must free the inode itself and any buffers allocated for + * if_extents/if_data and if_broot. It must also free the lock + * associated with the inode. + */ +void +xfs_idestroy( + xfs_inode_t *ip) +{ + /* + * Wait for any log writes referencing this inode to complete. + */ + xfs_iunpin_wait(ip); + + switch (ip->i_d.di_mode & S_IFMT) { + case S_IFREG: + case S_IFDIR: + case S_IFLNK: + xfs_idestroy_fork(ip, XFS_DATA_FORK); + break; + } + if (ip->i_afp) + xfs_idestroy_fork(ip, XFS_ATTR_FORK); + mrfree(&ip->i_lock); + mrfree(&ip->i_iolock); + freesema(&ip->i_flock); + +#ifdef XFS_INODE_TRACE + ktrace_free(ip->i_trace); +#endif +#ifdef XFS_BMAP_TRACE + ktrace_free(ip->i_xtrace); +#endif +#ifdef XFS_BMBT_TRACE + ktrace_free(ip->i_btrace); +#endif +#ifdef XFS_RW_TRACE + ktrace_free(ip->i_rwtrace); +#endif +#ifdef XFS_ILOCK_TRACE + ktrace_free(ip->i_lock_trace); +#endif +#ifdef XFS_DIR2_TRACE + ktrace_free(ip->i_dir_trace); +#endif + if (ip->i_itemp) { + /* + * Only if we are shutting down the fs will we see an + * inode still in the AIL. If it is there, we should remove + * it to prevent a use-after-free from occurring. + */ + xfs_mount_t *mp = ip->i_mount; + xfs_log_item_t *lip = &ip->i_itemp->ili_item; + + ASSERT(((lip->li_flags & XFS_LI_IN_AIL) == 0) || + XFS_FORCED_SHUTDOWN(ip->i_mount)); + if (lip->li_flags & XFS_LI_IN_AIL) { + spin_lock(&mp->m_ail_lock); + if (lip->li_flags & XFS_LI_IN_AIL) + xfs_trans_delete_ail(mp, lip); + else + spin_unlock(&mp->m_ail_lock); + } + xfs_inode_item_destroy(ip); + } + kmem_zone_free(xfs_inode_zone, ip); +} /* * xfs_iextents_copy() --------------030001020001050703050701-- From owner-xfs@oss.sgi.com Wed Dec 12 00:26:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 00:27:50 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBC8Qo8K010994 for ; Wed, 12 Dec 2007 00:26:52 -0800 X-ASG-Debug-ID: 1197448017-0380004a0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6F57AB3A547 for ; Wed, 12 Dec 2007 00:26:57 -0800 (PST) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id Icn909HDWTib4r6v for ; Wed, 12 Dec 2007 00:26:57 -0800 (PST) Received: from shambala.of.teamix.net (blackhole.teamix.net [194.150.191.251]) by mail.lichtvoll.de (Postfix) with ESMTP id 501585ADDC for ; Wed, 12 Dec 2007 09:25:09 +0100 (CET) From: Martin Steigerwald To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: write barrier over device mapper supported or not? Subject: Re: write barrier over device mapper supported or not? Date: Wed, 12 Dec 2007 09:26:52 +0100 User-Agent: KMail/1.9.7 References: <200712112342.24094.Martin@lichtvoll.de> <475F5746.8080405@sandeen.net> (sfid-20071212_092001_588630_42C71ACD) In-Reply-To: <475F5746.8080405@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712120926.53348.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1197448021 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3501 1.0000 -0.1525 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.15 X-Barracuda-Spam-Status: No, SCORE=-0.15 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36394 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5098/Tue Dec 11 21:46:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13920 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Am Mittwoch 12 Dezember 2007 schrieb Eric Sandeen: > Martin Steigerwald wrote: > > Hello! > > > > Are write barriers over device mapper supported or not? > > Nope. > > see dm_request(): > > /* > * There is no use in forwarding any barrier request since we > can't * guarantee it is (or can be) handled by the targets correctly. > */ > if (unlikely(bio_barrier(bio))) { > bio_endio(bio, -EOPNOTSUPP); > return 0; > } Thanks for your definitive answer. What does that mean? What is the target in that case? If it is the libata PATA internal notebook drive it actually should support barriers and then I actually would like device mapper to support them too. Or is LVM2 the target and device mapper can't tell that LVM2 supports it? I ask myself the question why write barrier if half the kernel does not handle it correctly and I am limited to plain partitions if I want to use it? Well I think I will just file a bug report at kernel.bugzilla.org about it. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Wed Dec 12 01:19:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 01:21:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBC9JXjI015357 for ; Wed, 12 Dec 2007 01:19:35 -0800 X-ASG-Debug-ID: 1197451183-794500cd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from astra.telenet-ops.be (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E1907470D7A for ; Wed, 12 Dec 2007 01:19:44 -0800 (PST) Received: from astra.telenet-ops.be (astra.telenet-ops.be [195.130.132.58]) by cuda.sgi.com with ESMTP id ysjyJYdtdqZrBFAL for ; Wed, 12 Dec 2007 01:19:44 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id 222F83810F for ; Wed, 12 Dec 2007 10:19:42 +0100 (CET) Received: from [84.195.46.72] (d54C32E48.access.telenet.be [84.195.46.72]) by astra.telenet-ops.be (Postfix) with ESMTP id 0E2AC3810B for ; Wed, 12 Dec 2007 10:19:41 +0100 (CET) Message-ID: <475FA7B1.6070706@pandora.be> Date: Wed, 12 Dec 2007 10:19:45 +0100 From: Denis Wegge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS unable to mount, recover data Subject: Re: XFS unable to mount, recover data References: <475696D3.60007@pandora.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: astra.telenet-ops.be[195.130.132.58] X-Barracuda-Start-Time: 1197451184 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0012 1.0000 -2.0132 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36398 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13921 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: denis_wegge@pandora.be Precedence: bulk X-list: xfs I tried putting it in the freezer, but that didn't help. Tests on another computer also show that the hard drive cannot be accessed. It seems like the data on the disk is definitely lost. The disk, however, has a 3 year warranty, so I'm going to return it. Thanks for your help. Denis Justin Piszcz wrote: > > > On Wed, 5 Dec 2007, Denis Wegge wrote: > >> Hello >> >> I am having trouble with the XFS filesystem on a 320GB Western Digital >> SATA harddisk. For no obvious reason the partition can no longer be >> mounted. The following error occurs: >> >> knoppix@Knoppix:~$ sudo mount /dev/sda1 /mnt/sda1 >> mount: /dev/sda1: can't read superblock > > Looks like your disk is dying or dead from your logs. You can try > putting it > in a plastic airtight bag then put it in the freezer and try again but > otherwise if that does not work, its time for the trash bin (after you try) > a dd and overwrite the disk but with that many bad sectors it looks like > it has really gone south. > > Insert new disk, restore from backup. > > Justin. > > > From owner-xfs@oss.sgi.com Wed Dec 12 03:07:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 03:08:03 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBCB7W08023873 for ; Wed, 12 Dec 2007 03:07:34 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA02609; Wed, 12 Dec 2007 22:07:39 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lBCB7bIN5770421; Wed, 12 Dec 2007 22:07:38 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBCB7ZVG5770781; Wed, 12 Dec 2007 22:07:35 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 12 Dec 2007 22:07:35 +1100 From: David Chinner To: Matthew Hodgson Cc: xfs@oss.sgi.com Subject: Re: Zero-copy Block IO with XFS Message-ID: <20071212110735.GH4612@sgi.com> References: <475E76AB.705@mxtelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475E76AB.705@mxtelecom.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13922 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 11, 2007 at 11:38:19AM +0000, Matthew Hodgson wrote: > Hi all, > > I'm experimenting with using XFS with a network block device (DST), and > have come up against the problem that when writing data to the network, > it uses kernel_sendpage to hand the page presented at the BIO layer to > the network stack. It then completes the block IO request. > > The problem arises when XFS proceeds to then reuse that page before the > NIC actually sends it. Where does XFS overwrite a page while I/O is still in progress? Stack trace please. > Particularly if TX checksumming or TCP > segmentation is being offloaded to the NIC, it seems that the NIC will > try to access to page after the BIO request has returned, and so operate > on stale data. That sounds like you are completing the bio before the I/O has really been completed. Basically, the bio can't be completed until the data has been sent and that will prevent any use after free or overwrite of the data while it is being sent... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 12 03:12:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 03:12:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBCBC2fS024393 for ; Wed, 12 Dec 2007 03:12:07 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA02676; Wed, 12 Dec 2007 22:12:05 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lBCBC4IN5770904; Wed, 12 Dec 2007 22:12:04 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBCBC2aA5770590; Wed, 12 Dec 2007 22:12:02 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 12 Dec 2007 22:12:02 +1100 From: David Chinner To: David Greaves Cc: David Chinner , xfs@oss.sgi.com Subject: Re: XFS internal error xfs_btree_check_sblock Message-ID: <20071212111202.GI4612@sgi.com> References: <475ED66F.40800@dgreaves.com> <20071211222546.GD4612@sgi.com> <475F2008.5030702@dgreaves.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F2008.5030702@dgreaves.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13923 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 11, 2007 at 11:40:56PM +0000, David Greaves wrote: > David Chinner wrote: > > On Tue, Dec 11, 2007 at 06:26:55PM +0000, David Greaves wrote: > >> Once every 2 or 3 cold boots I get this in dmesg as the user logs in and > > So there's a corrupted freespace btree block. > OK, ta > > >> I ssh in as root, umount, mount, umount and run xfs_repair. > > repair doesn't check the freespace btrees - it just rebuilds them from > > scratch. use xfs_check to tell you what is wrong with the filesystem, then > > use xfs_repair to fix it.... > > OK, having repaired it: > haze:~# xfs_check /dev/video_vg/video_lv > haze:~# Of course there's no errors - you just repaired them ;) Run xfs_check before you run xfs-repair when a corruption occurs. > So why do I have to do this on a regular basis (ie run xfs_repair)? Don't know yet. > I am shutting the machine down cleanly (init 0) That doesn't mean everything shuts down cleanly.... > >> It is possible this fs suffered in the 2.6.17 timeframe > >> It is also possible something got broken whilst I was having lots of issues with > >> hibernate (which is still unreliable). > > > > Suspend does not quiesce filesystems safely, so you risk filesystem > > corruption every time you suspend and resume no matter what filesystem > > you use. > > Well, FWIW, I've not hibernated this machine for a *long* time. Ok, so ignore that. > Also my hibernate script used to run xfs_freeze before hibernating (to be on the > safe side). This would regularly hang with an xfs_io process (or some such IIRC) > in an unkillable state. Well, 2.6.23 completely broke this, along with freezing XFS filesystems. > I was about to edit my init scripts to do a mount, umount, xfs_repair, mount > cycle. But then I thought "this is wrong - I'll report it". > So is there anything else I should do? Check the filesystem before repairing it. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 12 03:18:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 03:19:38 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCBInT1025470 for ; Wed, 12 Dec 2007 03:18:52 -0800 X-ASG-Debug-ID: 1197458340-049b021e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from puma.mxtelecom.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0777BB3CA01; Wed, 12 Dec 2007 03:19:00 -0800 (PST) Received: from puma.mxtelecom.com (mx1.mxtelecom.com [87.86.212.101]) by cuda.sgi.com with ESMTP id O6UzT9mDAMDwuZsL; Wed, 12 Dec 2007 03:19:00 -0800 (PST) Received: from wings.mxtelecom.com ([192.168.2.111] helo=[127.0.0.1]) by puma.mxtelecom.com with esmtp (Exim 4.66) (envelope-from ) id 1J2PcA-0000xR-Pm; Wed, 12 Dec 2007 11:18:58 +0000 Message-ID: <475FC40C.3030102@mxtelecom.com> Date: Wed, 12 Dec 2007 11:20:44 +0000 From: Matthew Hodgson Organization: MX Telecom Ltd User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Zero-copy Block IO with XFS Subject: Re: Zero-copy Block IO with XFS References: <475E76AB.705@mxtelecom.com> <20071212110735.GH4612@sgi.com> In-Reply-To: <20071212110735.GH4612@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.mxtelecom.com[87.86.212.101] X-Barracuda-Start-Time: 1197458341 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36406 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13924 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@mxtelecom.com Precedence: bulk X-list: xfs Hi Dave, Thanks for the response :) David Chinner wrote: > On Tue, Dec 11, 2007 at 11:38:19AM +0000, Matthew Hodgson wrote: >> I'm experimenting with using XFS with a network block device (DST), and >> have come up against the problem that when writing data to the network, >> it uses kernel_sendpage to hand the page presented at the BIO layer to >> the network stack. It then completes the block IO request. >> >> The problem arises when XFS proceeds to then reuse that page before the >> NIC actually sends it. > > Where does XFS overwrite a page while I/O is still in progress? > Stack trace please. It doesn't. The problem is that after the block device has completed the IO request with bio_endio(), there's a risk that it may still need access to the page in order to retransmit it, perform offloaded checksumming, etc. >> Particularly if TX checksumming or TCP >> segmentation is being offloaded to the NIC, it seems that the NIC will >> try to access to page after the BIO request has returned, and so operate >> on stale data. > > That sounds like you are completing the bio before the I/O has > really been completed. Basically, the bio can't be completed until > the data has been sent and that will prevent any use after free or > overwrite of the data while it is being sent... Agreed. In general that will cause a fairly major performance hit, however (you'd have to at least wait for the ACK from the TCP peer before completing the BIO). Or make a copy of the page. Is there no scope (however theoretical - I guess this is starting to become an academic question) for providing XFS with hints that particular pages are in use elsewhere and should not be overwritten? Could XFS mandate only overwriting pages in its cache with a ->count of 1? In other news, does XFS still provide the block layer with slab-allocated pages for metadata operations? thanks, Matthew. -- Matthew Hodgson Media & Systems Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com From owner-xfs@oss.sgi.com Wed Dec 12 03:39:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 03:40:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCBdXC5027549 for ; Wed, 12 Dec 2007 03:39:34 -0800 X-ASG-Debug-ID: 1197459579-14b300830000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.ukfsn.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8ACAC4717C3 for ; Wed, 12 Dec 2007 03:39:40 -0800 (PST) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by cuda.sgi.com with ESMTP id BIxELAARiZ5ljzKi for ; Wed, 12 Dec 2007 03:39:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 81CB8DECB9; Wed, 12 Dec 2007 11:41:04 +0000 (GMT) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (smtp-filter.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW9iqUbsrjM4; Wed, 12 Dec 2007 11:41:04 +0000 (GMT) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 3CB68DECB3; Wed, 12 Dec 2007 11:41:04 +0000 (GMT) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1J2Pw9-00040E-BZ; Wed, 12 Dec 2007 11:39:37 +0000 Message-ID: <475FC878.4000709@dgreaves.com> Date: Wed, 12 Dec 2007 11:39:36 +0000 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error xfs_btree_check_sblock Subject: Re: XFS internal error xfs_btree_check_sblock References: <475ED66F.40800@dgreaves.com> <20071211222546.GD4612@sgi.com> <475F2008.5030702@dgreaves.com> <20071212111202.GI4612@sgi.com> In-Reply-To: <20071212111202.GI4612@sgi.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: s2.ukfsn.org[217.158.120.143] X-Barracuda-Start-Time: 1197459584 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36402 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13925 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs David Chinner wrote: > On Tue, Dec 11, 2007 at 11:40:56PM +0000, David Greaves wrote: >> So is there anything else I should do? > > Check the filesystem before repairing it. yeah, OK :) Well, it happened next boot. So: haze:~# umount /scratch haze:~# xfs_check /dev/video_vg/video_lv ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. haze:~# mount /scratch haze:~# umount /scratch haze:~# xfs_check /dev/video_vg/video_lv bad format 2 for inode 1435146910 type 0 ir_freecount/free mismatch, inode chunk 42/25860704, freecount 64 nfree 63 bad format 2 for inode 1435150526 type 0 ir_freecount/free mismatch, inode chunk 42/25864320, freecount 64 nfree 63 bad format 2 for inode 1435173822 type 0 ir_freecount/free mismatch, inode chunk 42/25887616, freecount 64 nfree 63 bad format 2 for inode 1984739518 type 0 ir_freecount/free mismatch, inode chunk 59/5027968, freecount 27 nfree 26 allocated inode 1435146910 has 0 link count allocated inode 1435173822 has 0 link count allocated inode 1435150526 has 0 link count allocated inode 1984739518 has 0 link count haze:~# Filesystem "dm-0": XFS internal error xfs_btree_check_sblock at line 334 of file fs/xfs/xfs_btree.c. Caller 0xc01b7bc1 [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] dump_stack+0x15/0x20 [] xfs_error_report+0x4f/0x60 [] xfs_btree_check_sblock+0x56/0xd0 [] xfs_alloc_lookup+0x181/0x390 [] xfs_alloc_lookup_ge+0x16/0x20 [] xfs_alloc_ag_vextent_size+0x52/0x410 [] xfs_alloc_ag_vextent+0x107/0x110 [] xfs_alloc_fix_freelist+0x1f8/0x450 [] xfs_free_extent+0x8c/0xd0 [] xfs_bmap_finish+0x119/0x170 [] xfs_itruncate_finish+0x23a/0x3a0 [] xfs_free_eofblocks+0x26d/0x2b0 [] xfs_release+0x171/0x270 [] xfs_file_release+0x16/0x20 [] __fput+0x9b/0x190 [] fput+0x18/0x20 [] filp_close+0x47/0x80 [] sys_close+0x87/0x110 [] syscall_call+0x7/0xb ======================= xfs_force_shutdown(dm-0,0x8) called from line 4274 of file fs/xfs/xfs_bmap.c. Return address = 0xc0214dae Filesystem "dm-0": Corruption of in-memory data detected. Shutting down filesystem: dm-0 I've not yet run a repair... David From owner-xfs@oss.sgi.com Wed Dec 12 05:19:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 05:20:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCDJYQj007484 for ; Wed, 12 Dec 2007 05:19:36 -0800 X-ASG-Debug-ID: 1197465585-727501780000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 27B57471BF6 for ; Wed, 12 Dec 2007 05:19:45 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id IjvV5vP05gumEUe8 for ; Wed, 12 Dec 2007 05:19:45 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 124FE1C001985; Wed, 12 Dec 2007 08:19:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 0DD5E4019355; Wed, 12 Dec 2007 08:19:14 -0500 (EST) Date: Wed, 12 Dec 2007 08:19:14 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Timothy Shimmin cc: David Sparks , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? Subject: Re: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? In-Reply-To: <475F2D54.3090609@sgi.com> Message-ID: References: <475EE83A.3060607@ca.sophos.com> <20071211221554.GC4612@sgi.com> <475F2D54.3090609@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1197465586 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36415 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13926 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Wed, 12 Dec 2007, Timothy Shimmin wrote: > David Chinner wrote: >> On Tue, Dec 11, 2007 at 11:42:50AM -0800, David Sparks wrote: >>> Hi all, >>> >>> Is it expected that filesystems made with lazy-count=1 are not mountable >>> by >>> older kernels? >> >> That is expected. lazy-count is a mkfs option because it changes the >> on-disk >> format slightly, and older kernels do not understand that format. Hence >> mkfs sets a superblock feature bit to prevent the filesystem from being >> mounted on kernels that don't understand the slightly different disk >> format. >> >> Cheers, >> >> Dave. > > And there will be a message in the logs but it probably isn't > overly obvious what it is talking about. > > Looking at code, I presume it will come from: > if (!XFS_SB_GOOD_VERSION(sbp)) { > xfs_fs_mount_cmn_err(flags, "bad version"); > return XFS_ERROR(EWRONGFS); > } > so there will be a msg about a "bad version". > > --Tim > > Has anyone done any benchmarks with Dave Chinner's recommendations for mkfs.xfs/optmizations? Justin. From owner-xfs@oss.sgi.com Wed Dec 12 05:26:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 05:26:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCDQMs9008258 for ; Wed, 12 Dec 2007 05:26:26 -0800 X-ASG-Debug-ID: 1197465993-567e00080000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 442CA10FBA2B for ; Wed, 12 Dec 2007 05:26:33 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id sPqqG5pa4TsGQPvi for ; Wed, 12 Dec 2007 05:26:33 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 67E751C001985; Wed, 12 Dec 2007 08:26:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 63F754019355; Wed, 12 Dec 2007 08:26:01 -0500 (EST) Date: Wed, 12 Dec 2007 08:26:01 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Denis Wegge cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS unable to mount, recover data Subject: Re: XFS unable to mount, recover data In-Reply-To: <475FA7B1.6070706@pandora.be> Message-ID: References: <475696D3.60007@pandora.be> <475FA7B1.6070706@pandora.be> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1197465994 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36414 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13927 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Just curious what brand/make/model was it that failed? On Wed, 12 Dec 2007, Denis Wegge wrote: > I tried putting it in the freezer, but that didn't help. Tests on > another computer also show that the hard drive cannot be accessed. > > It seems like the data on the disk is definitely lost. The disk, > however, has a 3 year warranty, so I'm going to return it. > > Thanks for your help. > > Denis > > Justin Piszcz wrote: >> >> >> On Wed, 5 Dec 2007, Denis Wegge wrote: >> >>> Hello >>> >>> I am having trouble with the XFS filesystem on a 320GB Western Digital >>> SATA harddisk. For no obvious reason the partition can no longer be >>> mounted. The following error occurs: >>> >>> knoppix@Knoppix:~$ sudo mount /dev/sda1 /mnt/sda1 >>> mount: /dev/sda1: can't read superblock >> >> Looks like your disk is dying or dead from your logs. You can try putting >> it >> in a plastic airtight bag then put it in the freezer and try again but >> otherwise if that does not work, its time for the trash bin (after you try) >> a dd and overwrite the disk but with that many bad sectors it looks like >> it has really gone south. >> >> Insert new disk, restore from backup. >> >> Justin. >> >> >> > > From owner-xfs@oss.sgi.com Wed Dec 12 12:06:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 12:09:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCK6JQx014720 for ; Wed, 12 Dec 2007 12:06:23 -0800 X-ASG-Debug-ID: 1197489979-79d4000a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from astra.telenet-ops.be (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D2465B60151 for ; Wed, 12 Dec 2007 12:06:19 -0800 (PST) Received: from astra.telenet-ops.be (astra.telenet-ops.be [195.130.132.58]) by cuda.sgi.com with ESMTP id N8TAutOvpcOPuTWk for ; Wed, 12 Dec 2007 12:06:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id F0E1938154; Wed, 12 Dec 2007 21:05:44 +0100 (CET) Received: from [84.195.42.103] (d54C32A67.access.telenet.be [84.195.42.103]) by astra.telenet-ops.be (Postfix) with ESMTP id B8CFC38141; Wed, 12 Dec 2007 21:05:44 +0100 (CET) Message-ID: <47603F1E.1090901@pandora.be> Date: Wed, 12 Dec 2007 21:05:50 +0100 From: Denis Wegge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Justin Piszcz Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS unable to mount, recover data Subject: Re: XFS unable to mount, recover data References: <475696D3.60007@pandora.be> <475FA7B1.6070706@pandora.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: astra.telenet-ops.be[195.130.132.58] X-Barracuda-Start-Time: 1197489990 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36442 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5105/Wed Dec 12 10:28:14 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13928 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: denis_wegge@pandora.be Precedence: bulk X-list: xfs It was a Western Digital 320GB SATAII 16MB, WD3200KS-00PFB0 (don't remember the name of the model). Justin Piszcz wrote: > Just curious what brand/make/model was it that failed? > > On Wed, 12 Dec 2007, Denis Wegge wrote: > >> I tried putting it in the freezer, but that didn't help. Tests on >> another computer also show that the hard drive cannot be accessed. >> >> It seems like the data on the disk is definitely lost. The disk, >> however, has a 3 year warranty, so I'm going to return it. >> >> Thanks for your help. >> >> Denis >> >> Justin Piszcz wrote: >>> >>> >>> On Wed, 5 Dec 2007, Denis Wegge wrote: >>> >>>> Hello >>>> >>>> I am having trouble with the XFS filesystem on a 320GB Western Digital >>>> SATA harddisk. For no obvious reason the partition can no longer be >>>> mounted. The following error occurs: >>>> >>>> knoppix@Knoppix:~$ sudo mount /dev/sda1 /mnt/sda1 >>>> mount: /dev/sda1: can't read superblock >>> >>> Looks like your disk is dying or dead from your logs. You can try >>> putting it >>> in a plastic airtight bag then put it in the freezer and try again but >>> otherwise if that does not work, its time for the trash bin (after >>> you try) >>> a dd and overwrite the disk but with that many bad sectors it looks like >>> it has really gone south. >>> >>> Insert new disk, restore from backup. >>> >>> Justin. >>> >>> >>> >> >> > > From owner-xfs@oss.sgi.com Wed Dec 12 12:27:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 12:28:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,URIBL_GREY autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCKRDl5020864 for ; Wed, 12 Dec 2007 12:27:16 -0800 X-ASG-Debug-ID: 1197491243-31ce003a0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from umail.ru (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B4EF6475526 for ; Wed, 12 Dec 2007 12:27:24 -0800 (PST) Received: from umail.ru (fe01-umail.mtu.ru [62.5.255.15]) by cuda.sgi.com with ESMTP id lUONC8J4eKF7leQf for ; Wed, 12 Dec 2007 12:27:24 -0800 (PST) X-ASG-Orig-Subj: Undeliverable mail: Delivery reports about your e-mail Subject: Undeliverable mail: Delivery reports about your e-mail From: To: Date: Wed, 12 Dec 2007 23:11:50 +0300 Message-ID: X-MAPI-Message-Class: REPORT.IPM.Note.NDR MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===304745768====fe01-umail.umail.ru===_" X-Barracuda-Connect: fe01-umail.mtu.ru[62.5.255.15] X-Barracuda-Start-Time: 1197491244 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6314 1.0000 0.9100 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.46 X-Barracuda-Spam-Status: No, SCORE=1.46 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36443 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV 0.91.2/5105/Wed Dec 12 10:28:14 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13929 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@umail.ru Precedence: bulk X-list: xfs --_===304745768====fe01-umail.umail.ru===_ Content-Type: text/plain; charset="utf-8" Failed to deliver to 'olgaefimova@mtu-net.ru' LOCAL module(account olgaefimova@mtu-net.ru) reports: account is full (quota exceeded) --_===304745768====fe01-umail.umail.ru===_ Content-Type: message/delivery-status Reporting-MTA: dns; fe01-umail.umail.ru Original-Recipient: rfc822; Final-Recipient: LOCAL; Action: failed Status: 4.0.0 --_===304745768====fe01-umail.umail.ru===_ Content-Type: text/rfc822-headers Received: from [195.34.34.242] (HELO so01.mtu.ru) by fe01-umail.umail.ru (CommuniGate Pro SMTP 5.1.10) with ESMTP id 304745757 for olgaefimova@mtu-net.ru; Wed, 12 Dec 2007 23:11:49 +0300 Received: from so01.mtu.ru (localhost.mtu.ru [127.0.0.1]) by so01.mtu.ru (Postfix) with ESMTP id 072DCBA8620 for ; Wed, 12 Dec 2007 23:11:48 +0300 (MSK) Received: from localhost (localhost.mtu.ru [127.0.0.1]) by so01.mtu.ru (Postfix) with ESMTP id E0471BA8604 for ; Wed, 12 Dec 2007 23:11:47 +0300 (MSK) X-Spam-Flag: YES X-Spam-Yversion: Spamooborona 1.7.0-isp Received: from smtp04.mtu.ru (alt-proxy-1.mtu.ru [62.5.255.74]) by so01.mtu.ru (Postfix) with ESMTP id DC3C8BABBF5 for ; Wed, 12 Dec 2007 22:59:08 +0300 (MSK) Received: from smtp04.mtu.ru (localhost [127.0.0.1]) by smtp04.mtu.ru (Postfix) with ESMTP id A5F13819944 for ; Wed, 12 Dec 2007 22:46:06 +0300 (MSK) Received: from oss.sgi.com (ppp128-96.dialup.mtu-net.ru [62.118.128.96]) by smtp04.mtu.ru (Postfix) with ESMTP id A43F2820AC7 for ; Wed, 12 Dec 2007 22:21:00 +0300 (MSK) From: linux-xfs@oss.sgi.com To: olgaefimova@mtu-net.ru Subject: Delivery reports about your e-mail Date: Thu, 7 Sep 2006 12:46:40 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_54D0AF69.C774F603" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20071212192102.A43F2820AC7@smtp04.mtu.ru> X-DCC-STREAM-Metrics: so01.mtu.ru 10002; Body=1 Fuz1=1 --_===304745768====fe01-umail.umail.ru===_-- From owner-xfs@oss.sgi.com Wed Dec 12 19:44:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 19:45:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBD3ihGq027747 for ; Wed, 12 Dec 2007 19:44:46 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA29657; Thu, 13 Dec 2007 14:44:45 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 2DEBC58C4C35; Thu, 13 Dec 2007 14:44:45 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 973746 - Put the correct offset in dirent d_off Message-Id: <20071213034445.2DEBC58C4C35@chook.melbourne.sgi.com> Date: Thu, 13 Dec 2007 14:44:45 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5106/Wed Dec 12 11:34:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13935 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Put the correct offset in dirent d_off The recent filldir regression fix was not putting the correct d_off in each dirent. This was resulting in incorrect cookies being passed to dmapi ioctls and the wrong offset appearing in the dirents. readdir was unaffected as the filp->f_pos was being updated with the correct offset and this was being written into the last dirent in each buffer. Fix the XFS code to do the right thing. Date: Thu Dec 13 14:44:12 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30240a fs/xfs/xfs_dir2_block.c - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_block.c.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h - pass the current offset to the filldir method rather than the offset of the next object. filldir expects the current offset, not the next one. fs/xfs/xfs_dir2_sf.c - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h - pass the current offset to the filldir method rather than the offset of the next object. filldir expects the current offset, not the next one. fs/xfs/xfs_dir2_leaf.c - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h - pass the current offset to the filldir method rather than the offset of the next object. filldir expects the current offset, not the next one. fs/xfs/linux-2.6/xfs_file.c - 1.160 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.160&r2=text&tr2=1.159&f=h - Update filp->f_pos correctly now that we pass the current offset with each dirent to filldir. fs/xfs/dmapi/xfs_dm.c - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h - Remove special handling of dirent offsets for the cookie betwen ioctl calls. From owner-xfs@oss.sgi.com Thu Dec 13 02:42:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 02:43:08 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBDAgRPx003652 for ; Thu, 13 Dec 2007 02:42:29 -0800 X-ASG-Debug-ID: 1197542556-59ad005c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.ukfsn.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7DF00112B893 for ; Thu, 13 Dec 2007 02:42:36 -0800 (PST) Received: from mail.ukfsn.org (mx1.ukfsn.org [77.75.108.10]) by cuda.sgi.com with ESMTP id aXthujiwyWDAMO8p for ; Thu, 13 Dec 2007 02:42:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id CA551DECFF; Thu, 13 Dec 2007 10:44:07 +0000 (GMT) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (smtp-filter.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29J-dWkaBx70; Thu, 13 Dec 2007 10:44:07 +0000 (GMT) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 96E15DF316; Thu, 13 Dec 2007 10:44:07 +0000 (GMT) Received: from [10.0.0.90] by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1J2lWU-0008QE-Rm; Thu, 13 Dec 2007 10:42:34 +0000 Message-ID: <47610C9A.3070406@dgreaves.com> Date: Thu, 13 Dec 2007 10:42:34 +0000 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error xfs_btree_check_sblock Subject: Re: XFS internal error xfs_btree_check_sblock References: <475ED66F.40800@dgreaves.com> <20071211222546.GD4612@sgi.com> <475F2008.5030702@dgreaves.com> <20071212111202.GI4612@sgi.com> <475FC878.4000709@dgreaves.com> <20071212220032.GJ4612@sgi.com> In-Reply-To: <20071212220032.GJ4612@sgi.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.ukfsn.org[77.75.108.10] X-Barracuda-Start-Time: 1197542559 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36498 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5106/Wed Dec 12 11:34:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13936 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs David Chinner wrote: > Can you hol doff for a while longer? I'm afraid SWMBO came home and "did the usual fix" whilst I was making coffee.. (she's almost as well trained as I am!) I'll wait for a recurrence and do as you suggested... David From owner-xfs@oss.sgi.com Thu Dec 13 07:52:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 07:52:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBDFqXUI031052 for ; Thu, 13 Dec 2007 07:52:35 -0800 X-ASG-Debug-ID: 1197561163-6c37021b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 943D2111EE1C for ; Thu, 13 Dec 2007 07:52:43 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by cuda.sgi.com with ESMTP id tk2hrlB9z1rreV3J for ; Thu, 13 Dec 2007 07:52:43 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so1243306waf.18 for ; Thu, 13 Dec 2007 07:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=scQhA7U359Zb7w5pm/uovKgNtfGrk6E7J3HBgfKeaAY=; b=gSeQM5pInlmbGrnE8ALbyE+bVuMSCEcMevku+2QN9ufEOtE7pe/91U8AE9n1/uP1nN5fc9EWVHDjqeZ2Dr0qqtSYyVsNNReYfAUEvOqwWOSpmep8IswoWJhrCoOEl1QAHMNDbRKWiVF/8HS2KHzZBA7TSOp4bLLh196oQTlkVro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=M6TsuLC2gkXLZWqCAnj69oiYVMGyFADhF6qcveTsz5pSdsC6OphXoFsXc0qcpIfZwbGDJyR2PGIwSo12E28N5lOIwbG4uTmafMov+QF59uTvje51liEYJifANfwLC+6xKQIHVgHAMn+A4ofeWhcCRhiGA2sLjnRsnQ6Ga9p03xI= Received: by 10.114.94.1 with SMTP id r1mr2420032wab.32.1197560778970; Thu, 13 Dec 2007 07:46:18 -0800 (PST) Received: by 10.115.74.17 with HTTP; Thu, 13 Dec 2007 07:46:18 -0800 (PST) Message-ID: Date: Thu, 13 Dec 2007 16:46:18 +0100 From: "KE Liew" To: xfs@oss.sgi.com X-ASG-Orig-Subj: mount: Function not implemented Subject: mount: Function not implemented MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_35143_13710901.1197560778960" X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.176] X-Barracuda-Start-Time: 1197561164 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.08 X-Barracuda-Spam-Status: No, SCORE=-1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_10_20, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36518 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.94 HTML_10_20 BODY: Message is 10% to 20% HTML X-Virus-Scanned: ClamAV 0.91.2/5112/Thu Dec 13 03:09:13 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13937 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ke.liew@gmail.com Precedence: bulk X-list: xfs ------=_Part_35143_13710901.1197560778960 Content-Type: multipart/alternative; boundary="----=_Part_35144_16749570.1197560778960" ------=_Part_35144_16749570.1197560778960 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I was in #xfs with sandeen in discussing on the above issue. In the nutshell, I can't mount /dev/hdb due to the above error: mount -t xfs /dev/hdb /path/to It all started after I did a sequence of things to the new hdd I purchased. First, I created an msdos disklabel on a new xfs partition /dev/hdb1. It uses the full capacity of the hdd. Then I transferred files from one hdd to another using mv -v /stuff-to-transfer /hdb-mount-point Upon completion, I umount both devices and rebooted. On boot, I was not able to mount neither /dev/hdb1 nor /dev/hdb. /dev/hdb1 returns mount: special device /dev/hdb1 does not exist and /dev/hdb returns the above error message, no relevant messages are present in dmesg | tail The hexdump: =================== # dd if=/dev/hdb bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 |XFSB.........:8.| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 82 fd 56 0c 80 92 4f 4a 87 8b 5e 5d 5e 55 89 aa |..V...OJ..^]^U..| 00000030 00 00 00 00 00 20 00 05 00 00 00 00 00 00 09 00 |..... ..........| 00000040 00 00 00 00 00 00 09 01 00 00 00 00 00 00 09 02 |................| 00000050 00 00 00 01 00 03 a3 8b 00 00 00 10 00 00 00 00 |................| 00000060 00 00 07 47 3c 04 80 00 01 00 01 00 00 00 00 00 |...G<...........| 00000070 00 00 00 00 00 00 00 00 10 0f 08 08 12 00 00 19 |................| 00000080 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 fd |................| 00000090 00 00 00 00 00 3a 31 18 00 00 00 00 00 00 00 00 |.....:1.........| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000000c0 00 0f 80 00 00 01 00 00 00 00 00 00 00 00 00 00 |................| 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 512 bytes (512 B) copied, 0.00695137 seconds, 73.7 kB/s =================== The xfs_db: =================== # xfs_db -r -c "sb 0" -c p /dev/hdb cache_node_purge: refcount was 1, not zero (node=0x80ca410) xfs_db: cannot read root inode (22) cache_node_purge: refcount was 1, not zero (node=0x80da608) xfs_db: cannot read realtime bitmap inode (22) Segmentation fault =================== Distro: Debian etch uname -a : 2.6.18-5-686 xfsprogs version 2.9.4-2 (from Sid) You will find the chatlog attached. I just hope that it's recoverable even though I have backups that aren't exactly up to date. Thanks! Best regards, KwangErn ------=_Part_35144_16749570.1197560778960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

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

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

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

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

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

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

Thanks!


Best regards,

KwangErn
------=_Part_35144_16749570.1197560778960-- ------=_Part_35143_13710901.1197560778960 Content-Type: text/plain; name=XFS-SGI.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fa5gpacd0 Content-Disposition: attachment; filename=XFS-SGI.txt PGt0d2lsaWdodD4gaSd2ZSBnb3QgYW4gWEZTIHBhcnRpdGlvbiwgaXQgZG9l c24ndCBtb3VudCAnY3V6IHRoZSBzdXBlcmJsb2NrIGNhbid0IGJlIGZvdW5k LCB3aGljaCB3YXMgd2VpcmQuIGkgdHJpZWQgeGZzX3JlcGFpciBidXQgaXQg ZGlkbid0IGdpdmUgbWUgYW55IGdvb2QgcmVzdWx0cy4gaSB0cmllZCB3aXRo IHhmc19yZXBhaXIgLW8gYXNzdW1lX3hmcyAvZGV2L3NkYSBhbmQgaXQgc3Rp bGwgZG9lc24ndCBzZWVtIHRvIHdvcmsuIHNvIGhvdyBjYW4gaSBtb3VudCB0 aGlzIHBhcnRpdGlvbiB3aGVuIGl0IGNhbid0IGZpbmQgdGhlIHN1cGVyYmxv Y2s/IGkga25vdyB0aGVyZSBhcmUgY29udGVudHMgJ2N1eiBpIHRyYW5zZmVy ZWQgZmlsZXMgdG8gaXQgYW5kIHVtb3VudCBpdCBiZWZvcmUgcmVib290aW5n Lgo8c2FuZGVlbj4gd2hhdCBoYXBwZW5lZCBiZXR3ZWVuIHdvcmtpbmcgYW5k IG5vdCB3b3JraW5nPwo8a3R3aWxpZ2h0PiBzYW5kZWVuLCBpIHRyYW5zZmVy ZWQgZmlsZXMgdG8gaXQsIHVtb3VudCBpdCwgdGhlbiByZWJvb3QKPHNhbmRl ZW4+IGt0d2lsaWdodCwgaG93IGJpZyBpcyB0aGUgcGFydGl0aW9uCjxzYW5k ZWVuPiBrdHdpbGlnaHQsIHdoYXQga2VybmVsLCB3aGljaCBwYXJ0aXRpb24s IHdoYXQgdHlwZSBvZiBibG9jayBkZXZpY2UsIGV0Ywo8a3R3aWxpZ2h0PiAy LjYuMTgtNSwgaXQncyB0aGUgZW50aXJlIGhkZCwgL2Rldi9oZGIKPGt0d2ls aWdodD4gd2hhdCBkbyB5b3UgbWVhbiBieSBibG9jayBkZXZpY2U/CjxzYW5k ZWVuPiB0aGF0J3MgZW5vdWdoCjxzYW5kZWVuPiB3aGF0IGRvZXMgZmlsZSAt cyAvZGV2L3NkYiBzYXkKPHNhbmRlZW4+IGVyCjxzYW5kZWVuPiBoZGIgOikK PGt0d2lsaWdodD4gL2Rldi9oZGI6IFNHSSBYRlMgZmlsZXN5c3RlbSBkYXRh IChibGtzeiA2NTUzNiwgaW5vc3ogMjU2LCB2MiBkaXJzKQo8a3R3aWxpZ2h0 PiBpdCBzaG91bGQgaGF2ZSBhIC9kZXYvaGRiMQo8c2FuZGVlbj4gaHVoLCBv aywgSSB0aG91Z2h0IG1heWJlIHNvbWV0aGluZyBvdmVyd3JvdGUgaXQKPGt0 d2lsaWdodD4gaXQncyB1bW91bnQsIGFuZCBpIHRyeSBteSBiZXN0IG5vdCB0 byBkbyBhbnl0aGluZyB0byBkbyA6KQo8c2FuZGVlbj4gbm90aGluZyB3cm9u ZyB3aXRoIHVzaW5nIHRoZSB3aG9sZSBiZGV2CjxrdHdpbGlnaHQ+IGhtLCBi dXQgaSBjYW4ndCBtb3VudCBlaXRoZXIgaGRiIG9yIGhkYjEKPHNhbmRlZW4+ IHdoaWNoIG9uZSAqc2hvdWxkKiBpdCBiZQo8c2FuZGVlbj4gd2hhdCB1c2Vk IHRvIG1vdW50IDopCjxzYW5kZWVuPiBpLmUgLndoYXQncyBpbiBmc3RhYgo8 a3R3aWxpZ2h0PiBub3RoaW5nIGluIGZzdGFiCjxrdHdpbGlnaHQ+IGJ1dCBp IHVzZWQgaGRiMSB0byBtb3VudCBwcmV2aW91c2x5CjxzYW5kZWVuPiB3aGF0 IGRvZXMgZmlsZSAtcyAvZGV2L2hkYjEgc2F5IHRoZW4/CjxzYW5kZWVuPiBv ciBmZGlzayAtbCAvZGV2L3NkYj8KPGt0d2lsaWdodD4gL2Rldi9oZGIxOiBF UlJPUjogY2Fubm90IG9wZW4gYC9kZXYvaGRiMScgKE5vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnkpCjxrdHdpbGlnaHQ+IERpc2sgL2Rldi9oZGI6IDI1MC4w IEdCLCAyNTAwNTkzNTAwMTYgYnl0ZXMKPGt0d2lsaWdodD4gMjU1IGhlYWRz LCA2MyBzZWN0b3JzL3RyYWNrLCAzMDQwMSBjeWxpbmRlcnMKPGt0d2lsaWdo dD4gVW5pdHMgPSBjeWxpbmRlcnMgb2YgMTYwNjUgKiA1MTIgPSA4MjI1Mjgw IGJ5dGVzCjxrdHdpbGlnaHQ+IERpc2sgL2Rldi9oZGIgZG9lc24ndCBjb250 YWluIGEgdmFsaWQgcGFydGl0aW9uIHRhYmxlCjxrdHdpbGlnaHQ+IHRoZSBs YXN0IHNlbnRlbmNlIGlzIHF1aXRlLi4uIDovCjxzYW5kZWVuPiBlciwgc28s IHlvdSBubyBsb25nZXIgaGF2ZSBhIHBhcnRpdGlvbiB0YWJsZSwgYnV0IHJh dGhlciBpdCBpcyBhbiB4ZnMgZmlsZXN5c3RlbSBvbiB0aGUgd2hvbGUgL2Rl di9oZGIuLi4gd2hpY2ggaXMgZmluZSwgYnV0IG9uIHRoZSBsYXN0IGJvb3Qg eW91IG1vdW50ZWQgaGRiMT8KPHNhbmRlZW4+IEknbSBoYXZpbmcgYSBoYXJk IHRpbWUgYmVsaWV2aW5nIHRoYXQgbm90aGluZyBoYXBwZW5lZCBleGNlcHQg ZmlsZSBjb3BpZXMgYW5kIGEgcmVib290IDopCjxzYW5kZWVuPiBsb29rcyB0 byBtZSBsaWtlIHlvdSBta2ZzJ2QgL2Rldi9oZGIKPHNhbmRlZW4+IGNhbiB5 b3UgbW91bnQgL2Rldi9oZGI/CjxrdHdpbGlnaHQ+IGNhbid0IGJlLi4uCjxr dHdpbGlnaHQ+IG5vcGUsIGkgY2FuJ3QgbW91bnQgaXQKPHNhbmRlZW4+IHdo YXQgZG9lcyBkbWVzZyBzYXkgd2hlbiB5b3UgdHJ5Pwo8eG9yQXhBeD4ga3R3 aWxpZ2h0OiBoZXhkdW1wIC1DIHRoZSBmaXJzdCA1MTIgYnl0ZXMgZm9yIHVz Cjx4b3JBeEF4PiBhbmQgdXNlIHBhc3RlLnBvY29vLm9yZwo8c2FuZGVlbj4g YSkgeW91IGhhdmUgbm8gcGFydGl0aW9uIHRhYmxlLCB0aHVzIG5vIC9kZXYv aGRiMSwgYW5kIGIpICJmaWxlIiBmaW5kcyBhbiBYRlMgc3VwZXJibG9jayBk aXJlY3RseSBvbiBoZGIsIHNvLi4uCjxrdHdpbGlnaHQ+IGRtZXNnIGRvZXNu J3Qgc2F5IGFueXRoaW5nLCBidXQgbW91bnRpbmcgZ2l2ZXMgbWUgIm1vdW50 OiBGdW5jdGlvbiBub3QgaW1wbGVtZW50ZWQiCiogc2FuZGVlbiB0aGlua3Mg eGZzIHNob3VsZCBzdG9yZSBta2ZzIHRpbWUgZm9yIGNhc2VzIGxpa2UgdGhp cyA6KQo8eG9yQXhBeD4gc2FuZGVlbjogaGVoZQo8c2FuZGVlbj4gbHNtb2Qg fCBncmVwIHhmcyA/IDopCjxrdHdpbGlnaHQ+IHVtLCBzbyBoZXhkdW1wIC1D IC9kZXYvaGRiPwo8eG9yQXhBeD4ga3R3aWxpZ2h0OiBkZCAuLi4gY291bnQ9 MQo8c2FuZGVlbj4gZGQgaWY9L2Rldi9oZGIgYnM9NTEyIGNvdW50PTEgfCBo ZXhkdW1wIC1DCjxrdHdpbGlnaHQ+IHhmcyBpcyBsb2FkZWQsIGkgYXZlIG90 aGVyIHhmcyBwYXJ0aXRpb25zIG1vdW50ZWQKPGt0d2lsaWdodD4gaHR0cDov L3JhZmIubmV0L3AvV0x4SnpkOTAuaHRtbAo8c2FuZGVlbj4gSSBoYXZlIGEg aGFyZCB0aW1lIGJlbGlldmluZyB0aGF0IG1vdW50IC9kZXYvaGRiIC9zb21l L3doZXJlIGZhaWxzIGJ1dCBnZW5lcmF0ZXMgbm8ga2VybmVsIG1lc3NhZ2Vz CjxzYW5kZWVuPiB0cnkgbW91bnQgLXQgeGZzPwo8a3R3aWxpZ2h0PiBodHRw Oi8vcmFmYi5uZXQvcC9naEtDZ0kzNi5odG1sCjxzYW5kZWVuPiB4ZnNfZGIg LXIgLWMgInNiIDAiIC1jIHAgL2Rldi9zZGIgCjxzYW5kZWVuPiBhbmQgbW91 bnQgLXQgeGZzIC9kZXYvaGRiIC9zb21lL3doZXJlOyBkbWVzZyB8IHRhaWwg LW4gMTAKPGt0d2lsaWdodD4gaHR0cDovL3JhZmIubmV0L3AvR0w5NWJlNDgu aHRtbAo8c2FuZGVlbj4gc29ycnkgcy9zZGIvaGRiLyA6KQo8a3R3aWxpZ2h0 PiBucCA7KQo8c2FuZGVlbj4gZXcKPGt0d2lsaWdodD4gaHR0cDovL3JhZmIu bmV0L3AvQWNpbEx6MzAuaHRtbAo8a3R3aWxpZ2h0PiBub3QgYSBnb29kIGV3 IGkgZ3Vlc3MKPGt0d2lsaWdodD4gdGhhdCBzZWdmYXVsdCBpc24ndCBuaWNl CjxzYW5kZWVuPiBlcnJyCjxzYW5kZWVuPiBYRlMgbW91bnRpbmcgZmlsZXN5 c3RlbSBzZGIxCjxzYW5kZWVuPiBFbmRpbmcgY2xlYW4gWEZTIG1vdW50IGZv ciBmaWxlc3lzdGVtOiBzZGIxCjxzYW5kZWVuPiBvaCBzZGIKPHNhbmRlZW4+ IGdlZXNoCjxrdHdpbGlnaHQ+IGRpZmZlcmVudCA7KQo8c2FuZGVlbj4geW91 J2QgdGhpbmsgSSdkIGhhdmUgdGhpcyBzdHJhaWdodCBieSBub3cgOikKPHNh bmRlZW4+ICpzaWdoKgo8a3R3aWxpZ2h0PiBpdCdzIGhkYiwgTk9UIHNkYgo8 a3R3aWxpZ2h0PiB0aG91Z2ggaSBoYXZlIGFuIHNkYiBhbmQgaXQncyB3b3Jr aW5nIHBlcmZlY3RseS4KPGt0d2lsaWdodD4gbGV0J3Mgbm90IHRvdWNoIGl0 IDopCjxrdHdpbGlnaHQ+IHNvIGRtZXNnIGRvZXNuJ3Qgc2F5IGFueXRoaW5n IHdoZW4gdHJ5aW5nIHRvIG1vdW50IGhkYgo8c2FuZGVlbj4gd2VpcmQgdGhh dCB4ZnNfZGIgc2VnZmF1bHRzCjxzYW5kZWVuPiBpcyB0aGlzIGxhdGVzdCB4 ZnNwcm9ncz8KPGt0d2lsaWdodD4gMi44LjExLTEgCjxrdHdpbGlnaHQ+IGRl YmlhbiBldGNoLgo8a3R3aWxpZ2h0PiBpdCdzICJzdGFibGUiIDopCjxzYW5k ZWVuPiBtaWdodCB0cnkgdmVyeSBsYXRlc3QgeGZzcHJvZ3MgZm9yIGZ1bgo8 a3R3aWxpZ2h0PiAuLi4KPHNhbmRlZW4+IGp1c3QgdG8gc2VlIGlmIHdlIGNh biBleGFtaW5lIGl0IG1vcmUKPGt0d2lsaWdodD4gc28gaSBzaG91bGQgZ3Jh YiBpdCBvZmYgc2lkPwo8a3R3aWxpZ2h0PiB0ZWxsIG1lIHdoYXQgeW91IGtu b3cgc28gZmFyIG9yIGl0cyBhc3N1bXB0aW9ucwo8c2FuZGVlbj4gb3IgdXNl IHhmc19tZXRhZHVtcCB0byBnZXQgYW4gZnMgaW1hZ2UsIGFuZCBwcm92aWRl IGl0IHRvIHRoZSBzZ2kgZ3V5cwo8c2FuZGVlbj4gYXQgYSBtaW5pbXVtIHhm c19kYiBzaG91bGQgbm90IHNlZ2ZhdWx0CjxrdHdpbGlnaHQ+IGhtCjxzYW5k ZWVuPiB3ZWxsLCBzbyBmYXIsIGJhcmUgaGRiIGhhcyBhdCBsZWFzdCB0aGUg YmVnaW5uaW5nIG9mIGFuIHhmcyBmaWxlc3lzdGVtIHNpZ25hdHVyZSwgWEZT QiBpcyBzdXBlIGJsb2NrIG1hZ2ljCjxzYW5kZWVuPiBhbmQsIHlvdSBoYXZl IG5vIHBhcnRpdGlvbiB0YWJsZSBvbiBoZGIKPGt0d2lsaWdodD4gc28gYmFz aWNhbGx5IGkgaGF2ZSBubyBmaWxlcyBvbiBoZGI/CjxrdHdpbGlnaHQ+IG5v IHdheSBvZiByZWNvdmVyaW5nPwo8c2FuZGVlbj4gbm90IHN1cmUgeWV0Cjxr dHdpbGlnaHQ+IGdyZWF0IDopCjxzYW5kZWVuPiBidXQsIEkgZG9uJ3QgcXVp dGUgYmVsaWV2ZSB0aGF0IHlvdSBoYWQgL2Rldi9oZGIxIG1vdW50ZWQsIGNv cGllZCBmaWxlcywgdW1vdW50ZWQsIGFuZCBzdWRkZW5seSB5b3UgaGFkIG5v IG1vcmUgcGFydGl0aW9uIHRhYmxlCjxzYW5kZWVuPiBzb21ldGhpbmcgZWxz ZSBoYXBwZW5lZCBpbiBiZXR3ZWVuIHdoZXRoZXIgeW91IGRpZCBpdCB5b3Vy c2VsZiBvciBzb21ldGhpbmcgZGlkIGl0IHRvIHlvdSBJIHRoaW5rIDopCjxr dHdpbGlnaHQ+IGkgZG9uJ3QgYmVsaWV2ZSBpdCBlaXRoZXIsIGJ1dCB0aGF0 J3MgdGhlIHRydXRoLgo8a3R3aWxpZ2h0PiB3ZWxsLCByYXRoZXIgdGhhbiBj b3B5LCBpdCB3YXMgYSBtb3ZlLiBkb2VzIHRoYXQgbWFrZSBhbnkgZGlmZmVy ZW5jZT8gOlAKPHNhbmRlZW4+IHdoYXQga2luZCBvZiBwYXJ0aXRpb24gdGFi bGUgZGlkIHlvdSBoYXZlPwo8c2FuZGVlbj4gZG9zIG9yIGdwdD8KPGt0d2ls aWdodD4gZG9zCjxzYW5kZWVuPiB5b3VyIHJvb3QgaW5vZGUgbnIgZnJvbSB0 aGUgaGV4ZHVtcCBpcyBhIGxpdHRsZSBmdW5reQo8a3R3aWxpZ2h0PiBiYWQg ZnVua3k/CjxrdHdpbGlnaHQ+IGssIGZpbmFsbHkgZ2V0dGluJyBzaWQncyB4 ZnNwcm9ncwo8a3R3aWxpZ2h0PiBncmVhdCwgeGZzX2RiIHNlZ2ZhdWx0cyB0 b28gOikKPGt0d2lsaWdodD4geGZzcHJvZ3MgMi45LjQtMgo8c2FuZGVlbj4g aG1tCjxzYW5kZWVuPiBvdGhlciBzYW1lIG1lc3NhZ2VzPwo8c2FuZGVlbj4g Y2FjaGVfbm9kZSBzdHVmZiBvciBubwo8a3R3aWxpZ2h0PiBub3QgcmVhbGx5 CjxrdHdpbGlnaHQ+IGh0dHA6Ly9yYWZiLm5ldC9wL2U0dVlOQzU4Lmh0bWwK PHNhbmRlZW4+IHNhbWUgc3R1ZmYKPGt0d2lsaWdodD4gbyBvayA6fAo8a3R3 aWxpZ2h0PiBub2RlIGlzIGRpZmZlcmVudC4gdGhhdCBoZWxwcz8KPGt0d2ls aWdodD4gaGFoYQo8a3R3aWxpZ2h0PiBzYW5kZWVuLCB3b3VsZCB4ZnNfZnNy IGhlbHA/CjxzYW5kZWVuPiBubwo8c2FuZGVlbj4geW91IGhhdmUgdG8gbW91 bnQgaXQgZmlyc3QgOikKPGt0d2lsaWdodD4gOigKPGt0d2lsaWdodD4gaG93 ICdib3V0IHhmc19jaGVjayBvciB4ZnNfYWRtaW4/CjxzYW5kZWVuPiBub3Qg dGhhdCBpdCdkIGhlbHAgYW55d2F5CjxrdHdpbGlnaHQ+IGhtCjxrdHdpbGln aHQ+IHNvIHdoYXQgYXJlIG15IG9wdGlvbnM/CjxzYW5kZWVuPiBpZiB4ZnNf ZGIgY2FuJ3QgZXZlbiByZWNvZ25pemUgdGhlIGZpbGVzeXN0ZW0gdGhpbmdz IGFyZW4ndCBzbyBnb29kCjxrdHdpbGlnaHQ+IHdvdWxkIGRkIGhlbHA/IGxl dCdzIHNheSBpIHNraXAgdGhlIGZpcnN0IGZldyBieXRlcwo8a3R3aWxpZ2h0 PiB0aGVuIG1vdW50IGl0IGFzIGFuIGlzby4KPGhhbm5lc2Q+IG5vIGJhY2t1 cD8KPGt0d2lsaWdodD4gaGFubmVzZCwgeWVzLCBidXQgbm90IHRoYXQgdXAg dG8gZGF0ZSA6Lwo8a3R3aWxpZ2h0PiBpZiBpIGNhbiByZWNvdmVyLCBpdCdk IGJlIGJldHRlci4KPHNhbmRlZW4+IGp1c3QgZm9yIGZ1biwgZG9lcyBkZCBp Zj0vZGV2L2hkYiBicz01MTIgY291bnQ9MzIgfCBoZXhkdW1wIC1DIHwgZ3Jl cCBYRlNCIHR1cm4gdXAgbW9yZSB0aGFuIDEgWEZTQj8KKiBzYW5kZWVuIGd1 ZXNzZXMgYXQgdGhlIGNvdW50PTMyLCBidXQgaGRiMSBwcm9iYWJseSBzdGFy dGVkIGJlZm9yZSAxNmsKPGt0d2lsaWdodD4gaHR0cDovL3JhZmIubmV0L3Av dEhxV3liODguaHRtbAo8a3R3aWxpZ2h0PiBpIG9ubHkgc2VlIG9uZS4KPHNh bmRlZW4+IG5vcGUKPGt0d2lsaWdodD4gaG0sIHNvIGl0J3Mgbm90IGdvb2Qu CjxrdHdpbGlnaHQ+IHNvIHNob3VsZCBpIGp1c3QgZm9yZ2V0IGFib3V0IGl0 PyBvciBpcyB0aGVyZSBhIGdsaW1wc2Ugb2YgaG9wZSBzb21ld2hlcmU/IDop CjxzYW5kZWVuPiB3YXMgZ29ubmEgbG9vayBvdmVyIHRoZSBmaXJzdCBoZXhk dW1wIGEgYml0CjxrdHdpbGlnaHQ+IG9rCjxzYW5kZWVuPiAwMCAwMCAwMCAw MCAwMCAwMCAwOSAwMCBzaG91bGQgYmUgeW91ciByb290IGlub2RlLCB3aGlj aCBpcyBub3QgMjIsIHNvIGEgbGl0dGxlIGNvbmZ1c2VkIGFib3V0IHdoeSBp dCBpcyBzc2F5aW5nIHJvb3Rpbm8gMjIgd2hlbiB5b3UgdHJ5IHhmc19kYgo8 c2FuZGVlbj4gdW5sZXNzIHRoYXQncyBFSU5WQUwgdGhhdCBnb3QgbG9zdAo8 c2FuZGVlbj4gY2FuIHlvdSB1c2UgeGZzX21ldGFkdW1wIHRvIG1ha2UgYW4g ZnMgaW1hZ2U/ICAgbWF5YmUgdGhlIHNnaSBndXlzIGNhbiBoZWxwIGZ1cnRo ZXIKPGt0d2lsaWdodD4gc29tZSBtb25zdGVyIGF0ZSBpdCBpIHNlZS4KPGt0 d2lsaWdodD4gaG93IGJpZyB3b3VsZCB0aGUgZnMgaW1hZ2UgYmU/IGFzIGJp ZyBhcyB0aGUgcGFydGl0aW9uPwo8c2FuZGVlbj4gYXQgbGVhc3QgYm5hdWpv ayB3b3VsZCBwcm9iYWJseSBsaWtlIHRvIHNlZSB3aGF0J3MgZ29pbmcgb24g d2l0aCB4ZnNfZGIKPHNhbmRlZW4+IG5vIGl0IG9ubHkgZHVtcHMgbWV0YWRh dGEgbm8gZGF0YQo8c2FuZGVlbj4gc28gaXQgc2hvdWxkIGJlIHNpZ25pZmlj YW50bHkgc21hbGxlcgo8a3R3aWxpZ2h0PiBobQo8c2FuZGVlbj4gYnV0IGlm IGRiIGNhbid0IHJlYWQgaXQsIG1ldGFkdW1wIG1pZ2h0IG5vdCBlaXRoZXIK PGt0d2lsaWdodD4geWEgZ290dGEgc2VlIHRoaXMKPGt0d2lsaWdodD4gaHR0 cDovL3JhZmIubmV0L3Avb2pWQU55NzMuaHRtbAo8c2FuZGVlbj4geWVhaCwg bGlieGZzIHByb2JsZW0sIEkgd2FzIHNvcnRhIGFmcmFpZCBvZiB0aGF0Cjxz YW5kZWVuPiB3ZWxsLiAgdW5kZXJseWluZyBwcm9ibGVtIGlzIHdoYXQncyBv biB5b3VyIGRpc2ssIGJ1dCB0aGVuIGxpYnhmcyBpc24ndCBjb3Bpbmcgd2Vs bCBlaXRoZXIKPHNhbmRlZW4+IG1heWJlIHRoZSBmaXJzdCBmZXcgSyBvZiB0 aGUgZnMgd291bGQgYmUgZW5vdWdoIGZvciB0aGVtIHRvIGRpZyBpbiBmdXJ0 aGVyCjxrdHdpbGlnaHQ+IGhtCjxzYW5kZWVuPiBJIHNob3VsZCBiZSB3b3Jr aW5nIG9uIGFub3RoZXIgZnMgcmlnaHQgbm93IDstKQo8a3R3aWxpZ2h0PiA6 KQo8a3R3aWxpZ2h0PiBrLCBzbyBpIHdpbGwgc2VuZCB4ZnNfbWV0YWR1bXAs IGFuZCB4ZnNfZGIgdG8gc2dpPwo8a3R3aWxpZ2h0PiB3aGF0IGVsc2Ugc2hv dWxkIGkgaW5jbHVkZSBpbiB0aGUgZW1haWw/CjxoYW5uZXNkPiB0aGUgY2hh dCBsb2cgbWF5YmUgOikKPGt0d2lsaWdodD4gOikKPGt0d2lsaWdodD4gYSBo ZWNrIGxvYWQgb2Ygc3R1ZmYgdGhlbgo8a3R3aWxpZ2h0PiBlbWFpbD8gc3Vw cG9ydEBzZ2kuY29tPwo8c2FuZGVlbj4geGZzQHNnaS5jb20KPHNhbmRlZW4+ IG9wZW4gc291cmNlIHhmcyBsaXN0CjxzYW5kZWVuPiBoZXhkdW1wIG9mIGhk YiB3b3VsZCBiZSBhIHBsYWNlIHRvIHN0YXJ0LCBhbG9uZyB3LyB4ZnNfZGIg cmVzdWx0cwo8a3R3aWxpZ2h0PiBubSwgZm91bmQuIHhmc0Bvc3Muc2dpLmNv bQo8c2FuZGVlbj4gYW5kIGEgc3dvcm4gc3RhdGVtZW50IHRoYXQgb2ggcmVh bGx5IHRoaXMgdXNlZCB0byBiZSBoZGIxIGJ1dCBpdCBtYWdpY2FsbHkgbW92 ZWQgOikK ------=_Part_35143_13710901.1197560778960-- From owner-xfs@oss.sgi.com Thu Dec 13 14:24:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 14:24:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBDMOAMG030556 for ; Thu, 13 Dec 2007 14:24:13 -0800 X-ASG-Debug-ID: 1197584656-79bf015b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pro14.sgizmo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E8A04113767A for ; Thu, 13 Dec 2007 14:24:16 -0800 (PST) Received: from pro14.sgizmo.com (pro14.sgizmo.com [66.135.42.16]) by cuda.sgi.com with ESMTP id PAXYsGTUJ5yYQBRp for ; Thu, 13 Dec 2007 14:24:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by pro14.sgizmo.com (8.13.1/8.13.1) with ESMTP id lBDMOGjU026898 for ; Thu, 13 Dec 2007 16:24:16 -0600 Date: Thu, 13 Dec 2007 16:24:16 -0600 Message-Id: <200712132224.lBDMOGjU026898@pro14.sgizmo.com> content-type: text/plain; charset=UTF-8 From: "Dr. Ed Halteman" To: "David Chinner " X-ASG-Orig-Subj: Request for Help with National Study on RFID and Wireless Technology Subject: Request for Help with National Study on RFID and Wireless Technology X-Barracuda-Connect: pro14.sgizmo.com[66.135.42.16] X-Barracuda-Start-Time: 1197584660 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4992 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36542 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13938 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ed@survey-design-and-analysis.com Precedence: bulk X-list: xfs Dear David, As an engineering, technology, or business professional, we need your input. Survey Design and Analysis is conducting a study on the market requirements for future applications of RFID technology, particularly as it is used in conjunction with other wireless technologies to track asset movement / usage, improve sales productivity, enhance the customer experience, and manage inventory. The results of this study will be used to guide the development of new products and services. The first 300 qualified respondents that complete the survey will be entered in a drawing for Amazon gift certificates each worth $100. One out of every 10 respondents will win. Please take approximately 15 minutes now to provide your input at the following link. http://s-3d4cr-25491.sgizmo.com/i/9jkvg/2508/516511/ If you have any questions, please do not hesitate to contact me. I know your time is valuable and I appreciate your assistance. Thank you. Ed Halteman Edward Halteman, PhD Wireless Technology Study Manager Survey Design and Analysis 1331 Cedar Ave Boulder, CO 80304 ed@survey-design-and-analysis.com 303-818-3679 SurveyDNA.com ------------------- This invitation was sent by Survey Design and Analysis - 1331 Cedar Ave Boulder, CO 80304 United States. Phone: 303-818-3679 From owner-xfs@oss.sgi.com Thu Dec 13 14:47:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 14:48:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBDMlkAj032091 for ; Thu, 13 Dec 2007 14:47:48 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA01507; Fri, 14 Dec 2007 09:47:53 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lBDMlqIN7830007; Fri, 14 Dec 2007 09:47:52 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBDMln3D7832602; Fri, 14 Dec 2007 09:47:49 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 14 Dec 2007 09:47:49 +1100 From: David Chinner To: KE Liew Cc: xfs@oss.sgi.com Subject: Re: mount: Function not implemented Message-ID: <20071213224749.GJ4396912@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13939 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Dec 13, 2007 at 04:46:18PM +0100, KE Liew wrote: > Hi all, > > I was in #xfs with sandeen in discussing on the above issue. In the > nutshell, I can't mount /dev/hdb due to the above error: mount -t xfs > /dev/hdb /path/to #define ENOSYS 38 /* Function not implemented */ Exactly what is mount being told there is not system call support? What kernel are you running? Can you strace the mount process and find out where the error is coming from? > It all started after I did a sequence of things to the new hdd I purchased. > First, I created an msdos disklabel on a new xfs partition /dev/hdb1. It > uses the full capacity of the hdd. Did you then write out the partition table? Did the kernel warn you that it couldn't reread the partition table and so you should reboot before doing anything else? Did you make the xfs filesystem on /dev/hdb or hdb1? > Then I transferred files from one hdd to > another using mv -v /stuff-to-transfer /hdb-mount-point Upon completion, I > umount both devices and rebooted. On boot, I was not able to mount neither > /dev/hdb1 nor /dev/hdb. /dev/hdb1 returns mount: special device /dev/hdb1 > does not exist and /dev/hdb returns the above error message, no relevant > messages are present in dmesg | tail > > The hexdump: > =================== > # dd if=/dev/hdb bs=512 count=1 | hexdump -C > 1+0 records in > 1+0 records out > 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 > |XFSB.........:8.| This kind of indicates that you did a 'mkfs.xfs /dev/hdb' not the partition you created. If that is the case, then rebooting may have written who-knows-what to disk. > The xfs_db: > =================== > # xfs_db -r -c "sb 0" -c p /dev/hdb > cache_node_purge: refcount was 1, not zero (node=0x80ca410) > xfs_db: cannot read root inode (22) EINVAL. > cache_node_purge: refcount was 1, not zero (node=0x80da608) > xfs_db: cannot read realtime bitmap inode (22) > Segmentation fault > =================== That tends to indicate that the filesystem superblock is ok but the contents are not. Without knowing exactly what you did and what errors came up, it's going to be hard reconstructing what went wrong. Perhaps a metadump of the filesysetm woul dbe useful in working out how it is broken.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 13 20:07:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 20:07:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBE46vOS024185 for ; Thu, 13 Dec 2007 20:07:00 -0800 X-ASG-Debug-ID: 1197605226-5dd8001f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B4D8347F655 for ; Thu, 13 Dec 2007 20:07:06 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id fRq24CegEShWHJ1Y for ; Thu, 13 Dec 2007 20:07:06 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E50D3182DD13F; Thu, 13 Dec 2007 22:06:33 -0600 (CST) Message-ID: <47620148.2060401@sandeen.net> Date: Thu, 13 Dec 2007 22:06:32 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: David Chinner CC: KE Liew , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount: Function not implemented Subject: Re: mount: Function not implemented References: <20071213224749.GJ4396912@sgi.com> In-Reply-To: <20071213224749.GJ4396912@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197605228 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36555 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13940 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs David Chinner wrote: > On Thu, Dec 13, 2007 at 04:46:18PM +0100, KE Liew wrote: >> The hexdump: >> =================== >> # dd if=/dev/hdb bs=512 count=1 | hexdump -C >> 1+0 records in >> 1+0 records out >> 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 >> |XFSB.........:8.| > > This kind of indicates that you did a 'mkfs.xfs /dev/hdb' not > the partition you created. If that is the case, then rebooting > may have written who-knows-what to disk. although if it was a) new and b) he made a whole-disk partition, it was probably not a busy disk and I wouldn't expect a reboot was necessary. >> The xfs_db: >> =================== >> # xfs_db -r -c "sb 0" -c p /dev/hdb >> cache_node_purge: refcount was 1, not zero (node=0x80ca410) >> xfs_db: cannot read root inode (22) > > EINVAL. Hm, that should probably use perror or something, silly me read that as the inode *number* and then thought "hmm I bet something stuck EINVAL into the inode number, oops!" :) >> cache_node_purge: refcount was 1, not zero (node=0x80da608) >> xfs_db: cannot read realtime bitmap inode (22) >> Segmentation fault >> =================== > > That tends to indicate that the filesystem superblock is ok but > the contents are not. > > Without knowing exactly what you did and what errors came up, it's > going to be hard reconstructing what went wrong. Perhaps a metadump > of the filesysetm woul dbe useful in working out how it is broken.... Metadump failed with the same errors as xfs_db -Eric From owner-xfs@oss.sgi.com Thu Dec 13 21:28:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 21:28:42 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBE5SU4r032593 for ; Thu, 13 Dec 2007 21:28:37 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA12779; Fri, 14 Dec 2007 16:28:39 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lBE5SbIN7979050; Fri, 14 Dec 2007 16:28:37 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBE5SXqc7971999; Fri, 14 Dec 2007 16:28:33 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 14 Dec 2007 16:28:33 +1100 From: David Chinner To: Eric Sandeen Cc: David Chinner , KE Liew , xfs@oss.sgi.com Subject: Re: mount: Function not implemented Message-ID: <20071214052833.GM4396912@sgi.com> References: <20071213224749.GJ4396912@sgi.com> <47620148.2060401@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47620148.2060401@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13941 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Dec 13, 2007 at 10:06:32PM -0600, Eric Sandeen wrote: > David Chinner wrote: > > On Thu, Dec 13, 2007 at 04:46:18PM +0100, KE Liew wrote: > > >> The hexdump: > >> =================== > >> # dd if=/dev/hdb bs=512 count=1 | hexdump -C > >> 1+0 records in > >> 1+0 records out > >> 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 > >> |XFSB.........:8.| > > > > This kind of indicates that you did a 'mkfs.xfs /dev/hdb' not > > the partition you created. If that is the case, then rebooting > > may have written who-knows-what to disk. > > although if it was a) new and b) he made a whole-disk partition, it was > probably not a busy disk and I wouldn't expect a reboot was necessary. Agreed. But something went wrong so best to ask.... > >> The xfs_db: > >> =================== > >> # xfs_db -r -c "sb 0" -c p /dev/hdb > >> cache_node_purge: refcount was 1, not zero (node=0x80ca410) > >> xfs_db: cannot read root inode (22) > > > > EINVAL. > > Hm, that should probably use perror or something, silly me read that as > the inode *number* and then thought "hmm I bet something stuck EINVAL > into the inode number, oops!" :) Yeah, it probably should perror then tell you the root inode number it failed to read.... Looking at it a bit deeper, libxfs_iget() returned EINVAL and that is most likely from: ip->i_ino = ino; ip->i_mount = mp; if ((error = xfs_itobp(mp, tp, ip, &dip, &bp, bno))) return error; if (INT_GET(dip->di_core.di_magic, ARCH_CONVERT) != XFS_DINODE_MAGIC) { xfs_trans_brelse(tp, bp); >>>>>> return EINVAL; } The inode number being toast. Looking back at superblock dump, the root inode number is 0x900, which is extremely strange. Normal root inode number is 0x80 which indicates a block number of 0x40 (512 byte blocks), whereas 0x900 indicates a block number of 0x480 (1152) which is a long way away from where it should be. 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 |XFSB.........:8.| Hmmmm. Filesystem block size = 0x10000 = 64k and data blocks = 0x3a38b0 which gives a filesystem size of 232GB. Disk /dev/hdb: 250.0 GB, 250059350016 bytes Still the root inode is in the wrong place. They should be at 0x800 for 64k block size. (yes, I just checked this out by making a 64k block size filesystem). So, key questions: 1. What platform is this? 2. What page size is being used? 3. what kernel is being run? 4. What was the mkfs command used to make the filesystem? 5. how did you mount this filesystem in the first place? > > Without knowing exactly what you did and what errors came up, it's > > going to be hard reconstructing what went wrong. Perhaps a metadump > > of the filesysetm woul dbe useful in working out how it is broken.... > > Metadump failed with the same errors as xfs_db Oh, I didn't notice that. But seeing as the above error is in libxfs it's not surprising that they both fail there.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 13 21:43:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 21:43:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBE5hcOe001237 for ; Thu, 13 Dec 2007 21:43:43 -0800 X-ASG-Debug-ID: 1197611029-439500170000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8529A11422CF for ; Thu, 13 Dec 2007 21:43:49 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by cuda.sgi.com with ESMTP id Xc9uu0DJANtjG1B7 for ; Thu, 13 Dec 2007 21:43:49 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so1654630waf.18 for ; Thu, 13 Dec 2007 21:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=DOQAEKDf2A35z/7jhTMlSfD0YpOe2DCztZyLkpEu3Oo=; b=epTVMkqZhAZk53kOyCzioNdugSUDqlzWBg7+iqZ/xK44CSiE+Ok9i/t+bEs/t3hEY3ZZICOe0P4ZU2heSL7l8Eg8Fjzce8VS9VcDWmKiqR1nA/+Robt4+cLX+g9+H883DSKbwoRn+ig7JyDGcWD5nuIvShQDsv5scn3hZEwoI3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=h8SYhQYLEgoY9evokuiVDmrxZ9P9V/39VU4d5E3uWeXF0yN7dh0ix5DEFepdyn8m+zk183ifXsP8NYtp7j1CyTPn7eopgff0qu8aUaCheVSSy0kcLM0JHHda06sVDk3ioxz+1lS29tG5P24UjcFxZUZuLUysvqGJlMQRV07rWXA= Received: by 10.114.53.1 with SMTP id b1mr3253745waa.134.1197610644042; Thu, 13 Dec 2007 21:37:24 -0800 (PST) Received: by 10.115.74.17 with HTTP; Thu, 13 Dec 2007 21:37:23 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 06:37:23 +0100 From: "KE Liew" To: "David Chinner" X-ASG-Orig-Subj: Re: mount: Function not implemented Subject: Re: mount: Function not implemented Cc: "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <20071214052833.GM4396912@sgi.com> MIME-Version: 1.0 References: <20071213224749.GJ4396912@sgi.com> <47620148.2060401@sandeen.net> <20071214052833.GM4396912@sgi.com> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.183] X-Barracuda-Start-Time: 1197611030 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36562 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 677 X-archive-position: 13942 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ke.liew@gmail.com Precedence: bulk X-list: xfs On Dec 14, 2007 6:28 AM, David Chinner wrote: > So, key questions: > > 1. What platform is this? Debian Etch. > > 2. What page size is being used? Pardon my lack of knowledge, but what do you mean by page size? > > 3. what kernel is being run? Stock kernel 2.6.18-5-686 > > 4. What was the mkfs command used to make the filesystem? from .bash_history - mkfs.xfs -f /dev/hdb1 > > 5. how did you mount this filesystem in the first place? As mentioned, the usual mount -t xfs /dev/hdb1 /path/to Tried both /dev/hdb and /dev/hdb1, where hdb1 was the first I tried. KwangErn [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Dec 13 22:26:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 22:26:10 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=AWL,BAYES_20,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBE6Q1ZI003375 for ; Thu, 13 Dec 2007 22:26:08 -0800 X-ASG-Debug-ID: 1197613573-29db021a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4941D1142820 for ; Thu, 13 Dec 2007 22:26:13 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by cuda.sgi.com with ESMTP id m6P67k5DtPHCAkhQ for ; Thu, 13 Dec 2007 22:26:13 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so1679582waf.18 for ; Thu, 13 Dec 2007 22:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=q9EsHIaE3eTioLbhWVwV/QqKmZgpmixIfvvBPZL+zzc=; b=LM6jmOQa1rxblqvwRjmYOQkK0wqCuciPVGQ/EbTfH0YWpnJJUbQZ2ingICY+hNzCePf18EvAnk76u23KHD/NAa+qVSd2tiEszPS2MhvkPcWIWm7FzMrP/r5LW1NZVEaXlLamxxLxlcN19HbMCzoy+oGWC9HYNwP1PjvZvj++Ajg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PkDU977/Pnu+MXCtbXqNXOwAbHmtjpVfJvSgBoHz6sZ4V8nIsbBoKWNd5lohxWJ8f+SgjbwY8va9HeyRzarindOZUStoHC0g5BiOUEEKUKdPptbvFlAdcDvlMFAtlMvYP8KVEgx96Q46TpSKUgPx7nfYlYyeCDLBouLXBHhvOpM= Received: by 10.114.59.1 with SMTP id h1mr1788694waa.39.1197613198966; Thu, 13 Dec 2007 22:19:58 -0800 (PST) Received: by 10.115.74.17 with HTTP; Thu, 13 Dec 2007 22:19:58 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 07:19:58 +0100 From: "KE Liew" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount: Function not implemented Subject: Re: mount: Function not implemented In-Reply-To: MIME-Version: 1.0 References: <20071213224749.GJ4396912@sgi.com> <47620148.2060401@sandeen.net> <20071214052833.GM4396912@sgi.com> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.183] X-Barracuda-Start-Time: 1197613573 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.08 X-Barracuda-Spam-Status: No, SCORE=-1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_10_20, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36564 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.94 HTML_10_20 BODY: Message is 10% to 20% HTML X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 922 X-archive-position: 13943 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ke.liew@gmail.com Precedence: bulk X-list: xfs Just for document purposes... sandeen mentioned to do, dd if=/dev/hdb bs=512 count=128 | hexdump -C | grep XFSB 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 |XFSB.........:8.| 00007e00 58 46 53 42 00 00 10 00 00 00 00 00 03 a3 88 a0 |XFSB............| 128+0 records in 128+0 records out 65536 bytes (66 kB) copied, 0.0283236 seconds, 2.3 MB/s So recreating the partition should work. First we backup the sectors. dd if=/dev/hdb bs=512 count=256 of=backup_sectors Then the partition is recreated using fdisk /dev/hdb, option n -> p (primary -> 1 for partition 1 -> default first cylinder 1 -> default last cylinder 30401 -> (w)rite table to disk and exit. :) Running xfs_check /dev/hdb1 returns no errors, which was hoped. Mounting the partition shows ALL files present! So everything is working back to normal. Thanks to XFS team and sandeen! :) KwangErn [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Dec 14 03:54:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 03:55:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEBskmh025737 for ; Fri, 14 Dec 2007 03:54:50 -0800 X-ASG-Debug-ID: 1197633296-58cc03900000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from iate.obninsk.ru (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C3F1A1144D5C for ; Fri, 14 Dec 2007 03:54:57 -0800 (PST) Received: from iate.obninsk.ru (iate.obninsk.ru [195.112.102.46]) by cuda.sgi.com with ESMTP id 2BG8d4KfnGEDUD4H for ; Fri, 14 Dec 2007 03:54:57 -0800 (PST) X-ASG-Orig-Subj: Undeliverable mail: Subject: Undeliverable mail: From: To: Date: Fri, 14 Dec 2007 14:54:56 +0300 Message-ID: X-MAPI-Message-Class: REPORT.IPM.Note.NDR MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===4480892====iate.obninsk.ru===_" X-Barracuda-Connect: iate.obninsk.ru[195.112.102.46] X-Barracuda-Start-Time: 1197633297 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2852 1.0000 -0.4126 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.14 X-Barracuda-Spam-Status: No, SCORE=0.14 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36586 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV 0.91.2/5116/Thu Dec 13 23:14:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13944 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@iate.obninsk.ru Precedence: bulk X-list: xfs --_===4480892====iate.obninsk.ru===_ Content-Type: text/plain; charset="utf-8" Failed to deliver to '' WARNING! Your message was infected by VIRUSES: Worm.Mytob.Crypt.Gen, Suspicious File: text.pif It was rejected for delivery. Antiviral program output: ================================================== infected: Worm.Mytob.Crypt.Gen text.pif Suspicious File: text.pif ================================================== --_===4480892====iate.obninsk.ru===_ Content-Type: message/delivery-status Reporting-MTA: dns; iate.obninsk.ru Original-Recipient: rfc822; Final-Recipient: system; Action: failed Status: 5.0.0 --_===4480892====iate.obninsk.ru===_ Content-Type: text/rfc822-headers Received: from [213.148.186.44] (HELO oss.sgi.com) by iate.obninsk.ru (CommuniGate Pro SMTP 5.1.5) with ESMTP id 4480897 for korovin@iate.obninsk.ru; Fri, 14 Dec 2007 14:54:56 +0300 Received-SPF: none receiver=iate.obninsk.ru; client-ip=213.148.186.44; envelope-from=xfs@oss.sgi.com From: xfs@oss.sgi.com To: korovin@iate.obninsk.ru Subject: Date: Fri, 14 Dec 2007 14:57:01 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_16DB97CC.C435AE51" X-Priority: 3 X-MSMail-Priority: Normal Message-ID: --_===4480892====iate.obninsk.ru===_-- From owner-xfs@oss.sgi.com Fri Dec 14 09:38:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 09:38:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEHcahJ018815 for ; Fri, 14 Dec 2007 09:38:38 -0800 X-ASG-Debug-ID: 1197653928-7f3200260000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from out3.smtp.messagingengine.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BE204114901F for ; Fri, 14 Dec 2007 09:38:48 -0800 (PST) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by cuda.sgi.com with ESMTP id 3w5m4Q66SRc2u0ow for ; Fri, 14 Dec 2007 09:38:48 -0800 (PST) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 4694D7B6F2 for ; Fri, 14 Dec 2007 12:38:47 -0500 (EST) Received: from web8.messagingengine.com ([10.202.2.217]) by compute1.internal (MEProxy); Fri, 14 Dec 2007 12:38:47 -0500 Received: by web8.messagingengine.com (Postfix, from userid 99) id 28033552FC; Fri, 14 Dec 2007 12:38:47 -0500 (EST) Message-Id: <1197653927.3841.1226620089@webmail.messagingengine.com> X-Sasl-Enc: sDK6qeod+JpoSKpNnKDr40O/NAuFXR/64HmDCaRvtHxe 1197653927 From: "Alex Madarasz" To: xfs@oss.sgi.com Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface X-ASG-Orig-Subj: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Subject: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Date: Fri, 14 Dec 2007 12:38:47 -0500 X-Barracuda-Connect: out3.smtp.messagingengine.com[66.111.4.27] X-Barracuda-Start-Time: 1197653928 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36610 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5120/Fri Dec 14 08:10:00 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13945 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: List.XFS@madalexlists.nospammail.net Precedence: bulk X-list: xfs We're building a new Fedora 8.0.1 Linux system to stream data from a 250Msps ADC to disk, and want to start tuning the system configuration for maximum XFS write performance. To date, without any significant effort at tuning our Fedora 7 dev system, we're seeing 250MBps write with 8-bit samples and ~ 300MBps write with 16-bit samples. We want to push the tuning as far as we can go with this architecture before we start looking at other hardware options. Looking at various other tuning pages on the Web finds few that are interested in maxing out sequential writes to very large arrays while using SAS HW RAID with big fast SAS drives too. HW: HP ML350 G5 - 2 x Dual-Core Intel 5160 Xeon (3GHz, 1333 FSB) CPUs - 8GB dual-interleaved memory - HP Smart Array E200i (cciss) embedded PCI-E RAID ctrlr - 128MB cache - 2 x WD RE2 500GB 7200RPM SATA drives - HW RAID 1 - ext3 root LVM and Linux system partitions - HP Smart Array P400 (cciss) PCI-E x8 RAID ctrlr - 512MB cache - 8 x HP/Seagate 300GB 15000RPM SAS drives - HW RAID 0 logical disk - Dedicated xfs data partition - 250Msps ADC on 64-bit/100MHz PCI-X XFS Tuning Options? - HW RAID0: - Array/logical disk HW RAID stripe size? - Cache enabled (some reports that cache s/b turned off?)? - xfs mkfs / mount options? - External Log? - How big a partition on the E200i? - mkfs / mount options? ...? Thanks for any tips, -- Alex From owner-xfs@oss.sgi.com Fri Dec 14 12:25:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 12:25:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_65, J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEKP8QA032214 for ; Fri, 14 Dec 2007 12:25:10 -0800 X-ASG-Debug-ID: 1197663917-09e600af0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8DB62113A87A for ; Fri, 14 Dec 2007 12:25:18 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id g1lqOmXOd5brmBak for ; Fri, 14 Dec 2007 12:25:18 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBEKPBF3023508 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Dec 2007 21:25:11 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBEKPBPT023504 for xfs@oss.sgi.com; Fri, 14 Dec 2007 21:25:11 +0100 Date: Fri, 14 Dec 2007 21:25:11 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/2] cleanup fix handling Subject: [PATCH 1/2] cleanup fix handling Message-ID: <20071214202511.GA23248@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1197663919 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36620 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5122/Fri Dec 14 10:51:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13946 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Cleanup various fid related bits: - merge xfs_fid2 into it's only caller xfs_dm_inode_to_fh. - remove xfs_vget and opencode it in the two callers, simplifying both of them by avoiding the awkward calling convetion. - assign directly to the dm_fid_t members in various places in the dmapi code instead of casting them to xfs_fid_t first (which is identical to dm_fid_t) Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-12-13 19:14:47.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-12-13 20:10:04.000000000 +0100 @@ -586,14 +586,12 @@ dm_dip_to_handle( dm_handle_t *handlep) { dm_fid_t fid; - struct xfs_fid *xfid; int hsize; - xfid = (struct xfs_fid *)&fid; - xfid->fid_len = sizeof(struct xfs_fid) - sizeof(xfid->fid_len); - xfid->fid_pad = 0; - xfid->fid_ino = ino; - xfid->fid_gen = be32_to_cpu(dip->di_core.di_gen); + fid.dm_fid_len = sizeof(struct dm_fid) - sizeof(fid.dm_fid_len); + fid.dm_fid_pad = 0; + fid.dm_fid_ino = ino; + fid.dm_fid_gen = be32_to_cpu(dip->di_core.di_gen); memcpy(&handlep->ha_fsid, fsid, sizeof(*fsid)); memcpy(&handlep->ha_fid, &fid, fid.dm_fid_len + sizeof(fid.dm_fid_len)); @@ -3273,27 +3271,49 @@ xfs_dm_get_invis_ops( STATIC int xfs_dm_fh_to_inode( struct super_block *sb, - struct inode **ip, + struct inode **inode, dm_fid_t *dmfid) { - bhv_vnode_t *vp = NULL; - xfs_mount_t *mp = XFS_M(sb); - int error; - struct xfs_fid xfid; + xfs_mount_t *mp = XFS_M(sb); + xfs_inode_t *ip; + xfs_ino_t ino; + unsigned int igen; + int error; - /* Returns negative errors to DMAPI */ + *inode = NULL; - *ip = NULL; - memcpy(&xfid, dmfid, sizeof(*dmfid)); - if (xfid.fid_len) { /* file object handle */ - error = xfs_vget(mp, &vp, &xfid); + if (!dmfid->dm_fid_len) { + /* filesystem handle */ + *inode = igrab(mp->m_rootip->i_vnode); + if (!*inode) + return -ENOENT; + return 0; } - else { /* filesystem handle */ - error = xfs_root(mp, &vp); + + if (dmfid->dm_fid_len != sizeof(*dmfid) - sizeof(dmfid->dm_fid_len)) + return -EINVAL; + + ino = dmfid->dm_fid_ino; + igen = dmfid->dm_fid_gen; + + /* fail requests for ino 0 gracefully. */ + if (ino == 0) + return -ESTALE; + + error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, 0); + if (error) + return -error; + if (!ip) + return -EIO; + + if (!ip->i_d.di_mode || ip->i_d.di_gen != igen) { + xfs_iput_new(ip, XFS_ILOCK_SHARED); + return -ENOENT; } - if (vp && (error == 0)) - *ip = vn_to_inode(vp); - return -error; /* Return negative error to DMAPI */ + + *inode = ip->i_vnode; + xfs_iunlock(ip, XFS_ILOCK_SHARED); + return 0; } STATIC int @@ -3303,18 +3323,21 @@ xfs_dm_inode_to_fh( dm_fsid_t *dmfsid) { xfs_inode_t *ip = XFS_I(inode); - int error; - struct xfs_fid xfid; /* Returns negative errors to DMAPI */ if (ip->i_mount->m_fixedfsid == NULL) return -EINVAL; - error = xfs_fid2(ip, &xfid); - if (error) - return -error; /* Return negative error to DMAPI */ - memcpy(dmfid, &xfid, sizeof(*dmfid)); + dmfid->dm_fid_len = sizeof(dm_fid_t) - sizeof(dmfid->dm_fid_len); + dmfid->dm_fid_pad = 0; + /* + * use memcpy because the inode is a long long and there's no + * assurance that dmfid->dm_fid_ino is properly aligned. + */ + memcpy(&dmfid->dm_fid_ino, &ip->i_ino, sizeof(dmfid->dm_fid_ino)); + dmfid->dm_fid_gen = ip->i_d.di_gen; + memcpy(dmfsid, ip->i_mount->m_fixedfsid, sizeof(*dmfsid)); return 0; } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_export.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_export.c 2007-12-13 19:14:47.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_export.c 2007-12-13 19:18:49.000000000 +0100 @@ -118,20 +118,29 @@ xfs_nfs_get_inode( u64 ino, u32 generation) { - xfs_fid_t xfid; - bhv_vnode_t *vp; + xfs_mount_t *mp = XFS_M(sb); + xfs_inode_t *ip; int error; - xfid.fid_len = sizeof(xfs_fid_t) - sizeof(xfid.fid_len); - xfid.fid_pad = 0; - xfid.fid_ino = ino; - xfid.fid_gen = generation; + /* + * NFS can sometimes send requests for ino 0. Fail them gracefully. + */ + if (ino == 0) + return ERR_PTR(-ESTALE); - error = xfs_vget(XFS_M(sb), &vp, &xfid); + error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, 0); if (error) return ERR_PTR(-error); + if (!ip) + return ERR_PTR(-EIO); - return vp ? vn_to_inode(vp) : NULL; + if (!ip->i_d.di_mode || ip->i_d.di_gen != generation) { + xfs_iput_new(ip, XFS_ILOCK_SHARED); + return ERR_PTR(-ENOENT); + } + + xfs_iunlock(ip, XFS_ILOCK_SHARED); + return ip->i_vnode; } STATIC struct dentry * Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-13 19:19:52.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-13 19:22:10.000000000 +0100 @@ -267,7 +267,6 @@ EXPORT_SYMBOL(xfs_read_buf); EXPORT_SYMBOL(xfs_rwlock); EXPORT_SYMBOL(xfs_rwunlock); EXPORT_SYMBOL(xfs_setattr); -EXPORT_SYMBOL(xfs_fid2); EXPORT_SYMBOL(xfs_attr_get); EXPORT_SYMBOL(xfs_attr_set); EXPORT_SYMBOL(xfs_fsync); @@ -310,5 +309,4 @@ EXPORT_SYMBOL(xfs_ichgtime_fast); EXPORT_SYMBOL(xfs_free_eofblocks); EXPORT_SYMBOL(xfs_do_force_shutdown); -EXPORT_SYMBOL(xfs_vget); EXPORT_SYMBOL(xfs_root); Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-12-13 19:14:47.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-12-13 19:19:37.000000000 +0100 @@ -1408,56 +1408,3 @@ xfs_syncsub( return XFS_ERROR(last_error); } - -/* - * xfs_vget - called by DMAPI and NFSD to get vnode from file handle - */ -int -xfs_vget( - xfs_mount_t *mp, - bhv_vnode_t **vpp, - xfs_fid_t *xfid) -{ - xfs_inode_t *ip; - int error; - xfs_ino_t ino; - unsigned int igen; - - /* - * Invalid. Since handles can be created in user space and passed in - * via gethandle(), this is not cause for a panic. - */ - if (xfid->fid_len != sizeof(*xfid) - sizeof(xfid->fid_len)) - return XFS_ERROR(EINVAL); - - ino = xfid->fid_ino; - igen = xfid->fid_gen; - - /* - * NFS can sometimes send requests for ino 0. Fail them gracefully. - */ - if (ino == 0) - return XFS_ERROR(ESTALE); - - error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, 0); - if (error) { - *vpp = NULL; - return error; - } - - if (ip == NULL) { - *vpp = NULL; - return XFS_ERROR(EIO); - } - - if (ip->i_d.di_mode == 0 || ip->i_d.di_gen != igen) { - xfs_iput_new(ip, XFS_ILOCK_SHARED); - *vpp = NULL; - return XFS_ERROR(ENOENT); - } - - *vpp = XFS_ITOV(ip); - xfs_iunlock(ip, XFS_ILOCK_SHARED); - return 0; -} - Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.h 2007-12-13 19:19:40.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.h 2007-12-13 19:19:45.000000000 +0100 @@ -15,7 +15,6 @@ int xfs_mntupdate(struct xfs_mount *mp, struct xfs_mount_args *args); int xfs_root(struct xfs_mount *mp, bhv_vnode_t **vpp); int xfs_sync(struct xfs_mount *mp, int flags); -int xfs_vget(struct xfs_mount *mp, bhv_vnode_t **vpp, struct xfs_fid *xfid); void xfs_do_force_shutdown(struct xfs_mount *mp, int flags, char *fname, int lnnum); void xfs_attr_quiesce(struct xfs_mount *mp); Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-12-13 19:20:41.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-12-13 19:20:53.000000000 +0100 @@ -3457,27 +3457,6 @@ std_return: goto std_return; } - -int -xfs_fid2( - xfs_inode_t *ip, - xfs_fid_t *xfid) -{ - xfs_itrace_entry(ip); - - xfid->fid_len = sizeof(xfs_fid_t) - sizeof(xfid->fid_len); - xfid->fid_pad = 0; - /* - * use memcpy because the inode is a long long and there's no - * assurance that xfid->fid_ino is properly aligned. - */ - memcpy(&xfid->fid_ino, &ip->i_ino, sizeof(xfid->fid_ino)); - xfid->fid_gen = ip->i_d.di_gen; - - return 0; -} - - int xfs_rwlock( xfs_inode_t *ip, Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.h 2007-12-13 19:20:04.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.h 2007-12-13 19:22:04.000000000 +0100 @@ -39,7 +39,6 @@ int xfs_readdir(struct xfs_inode *dp, vo int xfs_symlink(struct xfs_inode *dp, bhv_vname_t *dentry, char *target_path, mode_t mode, bhv_vnode_t **vpp, struct cred *credp); -int xfs_fid2(struct xfs_inode *ip, struct xfs_fid *xfid); int xfs_rwlock(struct xfs_inode *ip, bhv_vrwlock_t locktype); void xfs_rwunlock(struct xfs_inode *ip, bhv_vrwlock_t locktype); int xfs_inode_flush(struct xfs_inode *ip, int flags); From owner-xfs@oss.sgi.com Fri Dec 14 12:29:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 12:29:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEKT34H000317 for ; Fri, 14 Dec 2007 12:29:06 -0800 X-ASG-Debug-ID: 1197664153-61f900990000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EAF3A484C23 for ; Fri, 14 Dec 2007 12:29:14 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id GubRwYi5tNia3NA2 for ; Fri, 14 Dec 2007 12:29:14 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBEKQWF3023598 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Dec 2007 21:26:32 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBEKQWTw023596 for xfs@oss.sgi.com; Fri, 14 Dec 2007 21:26:32 +0100 Date: Fri, 14 Dec 2007 21:26:31 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/2] kill xfs_root Subject: [PATCH 2/2] kill xfs_root Message-ID: <20071214202631.GB23248@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1197664154 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36621 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5122/Fri Dec 14 10:51:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13947 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs The only caller (xfs_fs_fill_super) can simplify call igrab on the root inode. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-13 20:12:18.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-13 20:12:23.000000000 +0100 @@ -309,4 +309,3 @@ EXPORT_SYMBOL(xfs_ichgtime_fast); EXPORT_SYMBOL(xfs_free_eofblocks); EXPORT_SYMBOL(xfs_do_force_shutdown); -EXPORT_SYMBOL(xfs_root); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2007-12-13 20:11:13.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2007-12-13 20:11:56.000000000 +0100 @@ -1287,9 +1287,11 @@ xfs_fs_fill_super( sb->s_time_gran = 1; set_posix_acl_flag(sb); - error = xfs_root(mp, &rootvp); - if (error) + rootvp = igrab(mp->m_rootip->i_vnode); + if (!rootvp) { + error = ENOENT; goto fail_unmount; + } sb->s_root = d_alloc_root(vn_to_inode(rootvp)); if (!sb->s_root) { Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-12-13 20:11:13.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-12-13 20:12:03.000000000 +0100 @@ -808,26 +808,6 @@ fscorrupt_out2: } /* - * xfs_root extracts the root vnode from a vfs. - * - * vfsp -- the vfs struct for the desired file system - * vpp -- address of the caller's vnode pointer which should be - * set to the desired fs root vnode - */ -int -xfs_root( - xfs_mount_t *mp, - bhv_vnode_t **vpp) -{ - bhv_vnode_t *vp; - - vp = XFS_ITOV(mp->m_rootip); - VN_HOLD(vp); - *vpp = vp; - return 0; -} - -/* * xfs_sync flushes any pending I/O to file system vfsp. * * This routine is called by vfs_sync() to make sure that things make it Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.h 2007-12-13 20:12:05.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.h 2007-12-13 20:12:07.000000000 +0100 @@ -13,7 +13,6 @@ int xfs_mount(struct xfs_mount *mp, stru int xfs_unmount(struct xfs_mount *mp, int flags, struct cred *credp); int xfs_mntupdate(struct xfs_mount *mp, int *flags, struct xfs_mount_args *args); -int xfs_root(struct xfs_mount *mp, bhv_vnode_t **vpp); int xfs_sync(struct xfs_mount *mp, int flags); void xfs_do_force_shutdown(struct xfs_mount *mp, int flags, char *fname, int lnnum); From owner-xfs@oss.sgi.com Fri Dec 14 12:30:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 12:30:22 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEKU9x4000576 for ; Fri, 14 Dec 2007 12:30:13 -0800 X-ASG-Debug-ID: 1197664215-7f3402480000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 55074113AC4E for ; Fri, 14 Dec 2007 12:30:15 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id P44zOBFrCWvo8EUq for ; Fri, 14 Dec 2007 12:30:15 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J3HAC-0006BU-EH; Fri, 14 Dec 2007 20:29:40 +0000 Date: Fri, 14 Dec 2007 20:29:40 +0000 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] make inode reclaim synchronise with xfs_iflush_done() Subject: Re: [PATCH] make inode reclaim synchronise with xfs_iflush_done() Message-ID: <20071214202940.GA23564@infradead.org> References: <475F878D.6090407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F878D.6090407@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197664221 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36620 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5122/Fri Dec 14 10:51:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13948 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Dec 12, 2007 at 06:02:37PM +1100, Lachlan McIlroy wrote: > On a forced shutdown, xfs_finish_reclaim() will skip flushing the inode. > If the inode flush lock is not already held and there is an outstanding > xfs_iflush_done() then we might free the inode prematurely. By acquiring > and releasing the flush lock we will synchronise with xfs_iflush_done(). Sound fine, but I think it would be nicer if we could keep the else if formatting, ala: /* * We are not interested in doing an iflush if we're * in the process of shutting down the filesystem forcibly. * So, just reclaim the inode. */ } else if (locked) { xfs_ifunlock(ip); xfs_iunlock(ip, XFS_ILOCK_EXCL); } else { /* * If the flush lock is not already held then temporarily * acquire it to synchronize with xfs_iflush_done. */ xfs_iflock(ip); xfs_ifunlock(ip); } From owner-xfs@oss.sgi.com Fri Dec 14 12:31:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 12:31:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEKV2nU000873 for ; Fri, 14 Dec 2007 12:31:05 -0800 X-ASG-Debug-ID: 1197664273-61f9009e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A3CD3484C49 for ; Fri, 14 Dec 2007 12:31:14 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id ihk6y9VIWmsR6qXv for ; Fri, 14 Dec 2007 12:31:14 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J3HBB-0006CP-Nr; Fri, 14 Dec 2007 20:30:41 +0000 Date: Fri, 14 Dec 2007 20:30:41 +0000 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] prevent panic during log recovery due to bogus operation header length Subject: Re: [PATCH] prevent panic during log recovery due to bogus operation header length Message-ID: <20071214203041.GB23564@infradead.org> References: <475F88C3.709@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F88C3.709@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197664274 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36621 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5122/Fri Dec 14 10:51:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13949 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Dec 12, 2007 at 06:07:47PM +1100, Lachlan McIlroy wrote: > A problem was reported where a system panicked in log recovery due > to a corrupt log record. The cause of the corruption is not known > but this change will at least prevent a crash for this specific > scenario. Log recovery definitely needs some more work in this area. > > Lachlan > --- fs/xfs/xfs_log_recover.c_1.332 2007-12-12 17:14:57.000000000 +1100 > +++ fs/xfs/xfs_log_recover.c 2007-12-12 17:15:42.000000000 +1100 > @@ -2912,7 +2912,12 @@ xlog_recover_process_data( > xlog_recover_new_tid(&rhash[hash], tid, > be64_to_cpu(rhead->h_lsn)); > } else { > - ASSERT(dp + be32_to_cpu(ohead->oh_len) <= lp); > + if (dp + be32_to_cpu(ohead->oh_len) > lp) { > + xlog_warn( > + "XFS: xlog_recover_process_data: bad length"); > + ASSERT(0); > + return (XFS_ERROR(EIO)); > + } this still gives a panic for debug builds.. Maybe this should become a WARN_ON(1) instead? From owner-xfs@oss.sgi.com Fri Dec 14 12:33:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 12:33:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEKXFOQ001591 for ; Fri, 14 Dec 2007 12:33:17 -0800 X-ASG-Debug-ID: 1197664405-4eab01b90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3AE90484C7D; Fri, 14 Dec 2007 12:33:25 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id 2jrOM6a6CsaDvRg7; Fri, 14 Dec 2007 12:33:25 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J3HDn-0006E8-GB; Fri, 14 Dec 2007 20:33:23 +0000 Date: Fri, 14 Dec 2007 20:33:23 +0000 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] make xfs_idestroy() wait for log I/O to complete Subject: Re: [PATCH] make xfs_idestroy() wait for log I/O to complete Message-ID: <20071214203323.GC23564@infradead.org> References: <475F8BC3.8020804@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F8BC3.8020804@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197664407 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36621 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5122/Fri Dec 14 10:51:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13950 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Dec 12, 2007 at 06:20:35PM +1100, Lachlan McIlroy wrote: > An xfs inode can be destroyed before log I/O involving that inode > is complete. We need to wait for the inode to be unpinned before > tearing it down. The patch looks big but the only real change is > adding a call to xfs_iunpin_wait() to the start of xfs_idestroy(). > The rest of the patch is moving xfs_idestroy() after the pinning > routines. Making sure the inode is unpinned before it's destroyed definitvely sounds useful. I can't think of any harm this might cause either. I'd prefer to have to commits, one to move the function around and one to add the call to xfs_iunpin_wait, though. From owner-xfs@oss.sgi.com Sat Dec 15 20:35:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 15 Dec 2007 20:35:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBG4ZmBF018656 for ; Sat, 15 Dec 2007 20:35:51 -0800 X-ASG-Debug-ID: 1197779757-34a600eb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5865A115D7F2 for ; Sat, 15 Dec 2007 20:35:58 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id m3WCXpqWdN0sm5Kj for ; Sat, 15 Dec 2007 20:35:58 -0800 (PST) Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A516B182DD1D9; Sat, 15 Dec 2007 22:35:20 -0600 (CST) Message-ID: <4764AB08.7040608@sandeen.net> Date: Sat, 15 Dec 2007 22:35:20 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alex Madarasz CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Subject: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? References: <1197653927.3841.1226620089@webmail.messagingengine.com> In-Reply-To: <1197653927.3841.1226620089@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197779760 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36749 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5140/Sat Dec 15 13:09:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13951 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Alex Madarasz wrote: > We're building a new Fedora 8.0.1 Linux system to stream data from a > 250Msps ADC to disk, and want to start tuning the system configuration > for maximum XFS write performance. To date, without any significant > effort at tuning our Fedora 7 dev system, we're seeing 250MBps write > with 8-bit samples and ~ 300MBps write with 16-bit samples. We want to > push the tuning as far as we can go with this architecture before we > start looking at other hardware options. Looking at various other > tuning pages on the Web finds few that are interested in maxing out > sequential writes to very large arrays while using SAS HW RAID with big > fast SAS drives too. ... > XFS Tuning Options? > > - HW RAID0: > - Array/logical disk HW RAID stripe size? At any rate you'll want to match xfs's geometry with the raid geometry. > - Cache enabled (some reports that cache s/b turned off?)? If it's battery-backed cache, leave it on, and disable barriers in xfs (it's a mount option) > - xfs mkfs / mount options? David mentioned these before as a generic place to start: # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 # mount -o logbsize=256k and that those would be upcoming new defaults for mkfs. 4 ags may not be what you want for a ~2T filesystem. > - External Log? > - How big a partition on the E200i? > - mkfs / mount options? not sure if an external log would be beneficial or not. I'm sure others will have more concrete suggestions. It might be interesting to post any performance you're getting which does not meet your expectations... -Eric > > ...? > > Thanks for any tips, > From owner-xfs@oss.sgi.com Sun Dec 16 01:07:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 01:07:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBG97Ppe012341 for ; Sun, 16 Dec 2007 01:07:27 -0800 X-ASG-Debug-ID: 1197796054-700500240000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8AA6C48A24E for ; Sun, 16 Dec 2007 01:07:35 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id ZvV3khJOGUkupChM for ; Sun, 16 Dec 2007 01:07:35 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 722FC1C000267; Sun, 16 Dec 2007 04:07:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 700E340195BB; Sun, 16 Dec 2007 04:07:03 -0500 (EST) Date: Sun, 16 Dec 2007 04:07:03 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Eric Sandeen cc: Alex Madarasz , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Subject: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? In-Reply-To: <4764AB08.7040608@sandeen.net> Message-ID: References: <1197653927.3841.1226620089@webmail.messagingengine.com> <4764AB08.7040608@sandeen.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1197796057 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36766 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5140/Sat Dec 15 13:09:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13952 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sat, 15 Dec 2007, Eric Sandeen wrote: > Alex Madarasz wrote: >> We're building a new Fedora 8.0.1 Linux system to stream data from a >> 250Msps ADC to disk, and want to start tuning the system configuration >> for maximum XFS write performance. To date, without any significant >> effort at tuning our Fedora 7 dev system, we're seeing 250MBps write >> with 8-bit samples and ~ 300MBps write with 16-bit samples. We want to >> push the tuning as far as we can go with this architecture before we >> start looking at other hardware options. Looking at various other >> tuning pages on the Web finds few that are interested in maxing out >> sequential writes to very large arrays while using SAS HW RAID with big >> fast SAS drives too. > > ... > >> XFS Tuning Options? >> >> - HW RAID0: >> - Array/logical disk HW RAID stripe size? > > At any rate you'll want to match xfs's geometry with the raid geometry. > >> - Cache enabled (some reports that cache s/b turned off?)? > > If it's battery-backed cache, leave it on, and disable barriers in xfs > (it's a mount option) > >> - xfs mkfs / mount options? > > David mentioned these before as a generic place to start: > > # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 > > # mount -o logbsize=256k > > and that those would be upcoming new defaults for mkfs. > > 4 ags may not be what you want for a ~2T filesystem. > >> - External Log? >> - How big a partition on the E200i? >> - mkfs / mount options? > > not sure if an external log would be beneficial or not. > > I'm sure others will have more concrete suggestions. It might be > interesting to post any performance you're getting which does not meet > your expectations... > > -Eric > >> >> ...? >> >> Thanks for any tips, >> > > I have a question, if he exported all of the HDD as JBOD and then made a software raid, took those software raid creation parameters and then re-made the HW raid, would they still apply to the HW raid? Justin. From owner-xfs@oss.sgi.com Sun Dec 16 08:33:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 08:34:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBGGXli1025633 for ; Sun, 16 Dec 2007 08:33:48 -0800 X-ASG-Debug-ID: 1197822836-6318026c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 16D56116635C for ; Sun, 16 Dec 2007 08:33:56 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id G5hPHLoEZL1m4sf1 for ; Sun, 16 Dec 2007 08:33:56 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBGGXnF3002356 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 16 Dec 2007 17:33:49 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBGGXndK002354 for xfs@oss.sgi.com; Sun, 16 Dec 2007 17:33:49 +0100 Date: Sun, 16 Dec 2007 17:33:49 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/2] keep i_nlink updated and use proper accessors Subject: [PATCH 2/2] keep i_nlink updated and use proper accessors Message-ID: <20071216163349.GA2107@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1197822840 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36795 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5145/Sun Dec 16 03:23:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13953 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs To get the read-only bind mounts in -mm to work correctly with XFS we need to call the drop_nlink and inc_nlink helpers to monitor the link count. Add calls to these to xfs_bumplink and xfs_droplink and stop copying over di_nlink to i_nlink in xfs_validate_fields and vn_revalidate. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-09-30 20:09:32.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-09-30 20:16:43.000000000 +0200 @@ -184,7 +184,6 @@ xfs_validate_fields( struct xfs_inode *ip = XFS_I(inode); loff_t size; - inode->i_nlink = ip->i_d.di_nlink; /* we're under i_sem so i_size can't change under us */ size = XFS_ISIZE(ip); if (i_size_read(inode) != size) Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2007-09-30 20:09:32.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2007-09-30 20:16:31.000000000 +0200 @@ -117,7 +117,6 @@ vn_revalidate( xfs_ilock(ip, XFS_ILOCK_SHARED); inode->i_mode = ip->i_d.di_mode; - inode->i_nlink = ip->i_d.di_nlink; inode->i_uid = ip->i_d.di_uid; inode->i_gid = ip->i_d.di_gid; inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; Index: linux-2.6-xfs/fs/xfs/xfs_utils.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_utils.c 2007-09-30 20:09:32.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_utils.c 2007-09-30 20:16:06.000000000 +0200 @@ -302,6 +302,7 @@ xfs_droplink( ASSERT (ip->i_d.di_nlink > 0); ip->i_d.di_nlink--; + drop_nlink(ip->i_vnode); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); error = 0; @@ -365,6 +366,7 @@ xfs_bumplink( ASSERT(ip->i_d.di_nlink > 0); ip->i_d.di_nlink++; + inc_nlink(ip->i_vnode); if ((ip->i_d.di_version == XFS_DINODE_VERSION_1) && (ip->i_d.di_nlink > XFS_MAXLINK_1)) { /* From owner-xfs@oss.sgi.com Sun Dec 16 08:33:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 08:34:02 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBGGXpoE025647 for ; Sun, 16 Dec 2007 08:33:51 -0800 X-ASG-Debug-ID: 1197822838-4ff601c70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E829848B6D2 for ; Sun, 16 Dec 2007 08:33:59 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id ZbqSSKWGrjgHMAbc for ; Sun, 16 Dec 2007 08:33:59 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBGGXrF3002372 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 16 Dec 2007 17:33:53 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBGGXq1b002370 for xfs@oss.sgi.com; Sun, 16 Dec 2007 17:33:52 +0100 Date: Sun, 16 Dec 2007 17:33:52 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/2] stop updating inode->i_blocks Subject: [PATCH 1/2] stop updating inode->i_blocks Message-ID: <20071216163352.GB2107@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1197822842 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36796 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5145/Sun Dec 16 03:23:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13954 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs The VFS doesn't use i_blocks, it's only used by generic_fillattr and the generic quota code which XFS doesn't use. In XFS there is one use to check whether we have an inline or out of line sumlink, but we can replace that with a check of the XFS_IFINLINE inode flag. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-11-30 10:14:10.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-11-30 10:18:38.000000000 +0100 @@ -2503,11 +2503,6 @@ xfs_dm_punch_hole( */ if (!error && (len == 0)) { error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_NOLOCK); - if (!error) { - /* Update linux inode block count after free above */ - inode->i_blocks = XFS_FSB_TO_BB(mp, - ip->i_d.di_nblocks + ip->i_delayed_blks); - } } /* Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-11-30 10:15:48.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-11-30 10:18:38.000000000 +0100 @@ -202,9 +202,6 @@ xfs_validate_fields( loff_t size; inode->i_nlink = ip->i_d.di_nlink; - inode->i_blocks = - XFS_FSB_TO_BB(ip->i_mount, ip->i_d.di_nblocks + - ip->i_delayed_blks); /* we're under i_sem so i_size can't change under us */ size = XFS_ISIZE(ip); if (i_size_read(inode) != size) Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2007-11-30 10:15:48.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2007-11-30 10:18:38.000000000 +0100 @@ -568,7 +568,7 @@ xfs_set_inodeops( break; case S_IFLNK: inode->i_op = &xfs_symlink_inode_operations; - if (inode->i_blocks) + if (!(XFS_I(inode)->i_df.if_flags & XFS_IFINLINE)) inode->i_mapping->a_ops = &xfs_address_space_operations; break; default: @@ -605,8 +605,6 @@ xfs_revalidate_inode( inode->i_generation = ip->i_d.di_gen; i_size_write(inode, ip->i_d.di_size); - inode->i_blocks = - XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); inode->i_atime.tv_sec = ip->i_d.di_atime.t_sec; inode->i_atime.tv_nsec = ip->i_d.di_atime.t_nsec; inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2007-11-30 10:14:10.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2007-11-30 10:18:38.000000000 +0100 @@ -106,8 +106,6 @@ vn_revalidate( inode->i_nlink = ip->i_d.di_nlink; inode->i_uid = ip->i_d.di_uid; inode->i_gid = ip->i_d.di_gid; - inode->i_blocks = - XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; inode->i_mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; inode->i_ctime.tv_sec = ip->i_d.di_ctime.t_sec; Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-11-30 10:14:10.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-11-30 10:18:38.000000000 +0100 @@ -1557,9 +1557,6 @@ xfs_release( error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); if (error) return error; - /* Update linux inode block count after free above */ - vn_to_inode(vp)->i_blocks = XFS_FSB_TO_BB(mp, - ip->i_d.di_nblocks + ip->i_delayed_blks); } } @@ -1633,9 +1630,6 @@ xfs_inactive( error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); if (error) return VN_INACTIVE_CACHE; - /* Update linux inode block count after free above */ - vn_to_inode(vp)->i_blocks = XFS_FSB_TO_BB(mp, - ip->i_d.di_nblocks + ip->i_delayed_blks); } goto out; } From owner-xfs@oss.sgi.com Sun Dec 16 13:41:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 13:41:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBGLfmGR018169 for ; Sun, 16 Dec 2007 13:41:50 -0800 X-ASG-Debug-ID: 1197841317-0c1301110000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 888C648C56D for ; Sun, 16 Dec 2007 13:41:58 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 74VXG5ZUmDrXdoCZ for ; Sun, 16 Dec 2007 13:41:58 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id B2119182DD1D9; Sun, 16 Dec 2007 15:41:25 -0600 (CST) Message-ID: <47659B84.6050203@sandeen.net> Date: Sun, 16 Dec 2007 15:41:24 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] stop updating inode->i_blocks Subject: Re: [PATCH 1/2] stop updating inode->i_blocks References: <20071216163352.GB2107@lst.de> In-Reply-To: <20071216163352.GB2107@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197841320 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36816 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5147/Sun Dec 16 12:56:32 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13955 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Christoph Hellwig wrote: > The VFS doesn't use i_blocks, it's only used by generic_fillattr and > the generic quota code which XFS doesn't use. In XFS there is one use > to check whether we have an inline or out of line sumlink, but we can > replace that with a check of the XFS_IFINLINE inode flag. > > > Signed-off-by: Christoph Hellwig Looks reasonable to me. Acked-by: Eric Sandeen > Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-11-30 10:14:10.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-11-30 10:18:38.000000000 +0100 > @@ -2503,11 +2503,6 @@ xfs_dm_punch_hole( > */ > if (!error && (len == 0)) { > error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_NOLOCK); > - if (!error) { > - /* Update linux inode block count after free above */ > - inode->i_blocks = XFS_FSB_TO_BB(mp, > - ip->i_d.di_nblocks + ip->i_delayed_blks); > - } > } > > /* > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-11-30 10:15:48.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-11-30 10:18:38.000000000 +0100 > @@ -202,9 +202,6 @@ xfs_validate_fields( > loff_t size; > > inode->i_nlink = ip->i_d.di_nlink; > - inode->i_blocks = > - XFS_FSB_TO_BB(ip->i_mount, ip->i_d.di_nblocks + > - ip->i_delayed_blks); > /* we're under i_sem so i_size can't change under us */ > size = XFS_ISIZE(ip); > if (i_size_read(inode) != size) > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2007-11-30 10:15:48.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2007-11-30 10:18:38.000000000 +0100 > @@ -568,7 +568,7 @@ xfs_set_inodeops( > break; > case S_IFLNK: > inode->i_op = &xfs_symlink_inode_operations; > - if (inode->i_blocks) > + if (!(XFS_I(inode)->i_df.if_flags & XFS_IFINLINE)) > inode->i_mapping->a_ops = &xfs_address_space_operations; > break; > default: > @@ -605,8 +605,6 @@ xfs_revalidate_inode( > > inode->i_generation = ip->i_d.di_gen; > i_size_write(inode, ip->i_d.di_size); > - inode->i_blocks = > - XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); > inode->i_atime.tv_sec = ip->i_d.di_atime.t_sec; > inode->i_atime.tv_nsec = ip->i_d.di_atime.t_nsec; > inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2007-11-30 10:14:10.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2007-11-30 10:18:38.000000000 +0100 > @@ -106,8 +106,6 @@ vn_revalidate( > inode->i_nlink = ip->i_d.di_nlink; > inode->i_uid = ip->i_d.di_uid; > inode->i_gid = ip->i_d.di_gid; > - inode->i_blocks = > - XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); > inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; > inode->i_mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; > inode->i_ctime.tv_sec = ip->i_d.di_ctime.t_sec; > Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-11-30 10:14:10.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-11-30 10:18:38.000000000 +0100 > @@ -1557,9 +1557,6 @@ xfs_release( > error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); > if (error) > return error; > - /* Update linux inode block count after free above */ > - vn_to_inode(vp)->i_blocks = XFS_FSB_TO_BB(mp, > - ip->i_d.di_nblocks + ip->i_delayed_blks); > } > } > > @@ -1633,9 +1630,6 @@ xfs_inactive( > error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); > if (error) > return VN_INACTIVE_CACHE; > - /* Update linux inode block count after free above */ > - vn_to_inode(vp)->i_blocks = XFS_FSB_TO_BB(mp, > - ip->i_d.di_nblocks + ip->i_delayed_blks); > } > goto out; > } > > From owner-xfs@oss.sgi.com Sun Dec 16 15:31:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 15:31:43 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBGNVUbr026681 for ; Sun, 16 Dec 2007 15:31:34 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA24012; Mon, 17 Dec 2007 10:31:34 +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 lBGNVWIN11022838; Mon, 17 Dec 2007 10:31:33 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBGNVSxK10994059; Mon, 17 Dec 2007 10:31:28 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 17 Dec 2007 10:31:27 +1100 From: David Chinner To: Eric Sandeen Cc: Alex Madarasz , xfs@oss.sgi.com Subject: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Message-ID: <20071216233127.GY4612@sgi.com> References: <1197653927.3841.1226620089@webmail.messagingengine.com> <4764AB08.7040608@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4764AB08.7040608@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5147/Sun Dec 16 12:56:32 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13956 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 Sat, Dec 15, 2007 at 10:35:20PM -0600, Eric Sandeen wrote: > Alex Madarasz wrote: > > We're building a new Fedora 8.0.1 Linux system to stream data from a > > 250Msps ADC to disk, and want to start tuning the system configuration > > for maximum XFS write performance. To date, without any significant > > effort at tuning our Fedora 7 dev system, we're seeing 250MBps write > > with 8-bit samples and ~ 300MBps write with 16-bit samples. We want to > > push the tuning as far as we can go with this architecture before we > > start looking at other hardware options. Looking at various other > > tuning pages on the Web finds few that are interested in maxing out > > sequential writes to very large arrays while using SAS HW RAID with big > > fast SAS drives too. > > ... > > > XFS Tuning Options? > > > > - HW RAID0: > > - Array/logical disk HW RAID stripe size? > > At any rate you'll want to match xfs's geometry with the raid geometry. > > > - Cache enabled (some reports that cache s/b turned off?)? > > If it's battery-backed cache, leave it on, and disable barriers in xfs > (it's a mount option) > > > - xfs mkfs / mount options? > > David mentioned these before as a generic place to start: > > # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 > > # mount -o logbsize=256k > > and that those would be upcoming new defaults for mkfs. > > 4 ags may not be what you want for a ~2T filesystem. Right - the 4 AG tuning is effectively for single disk configurations to limit parallelism and therefore keep seeks between AGs down. When you have multiple disks, the [new] mkfs defaults should be just fine (i.e. just drop the agcount suggestion). Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Dec 16 15:43:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 15:43:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_65, J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBGNhYMY027740 for ; Sun, 16 Dec 2007 15:43:40 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA24275; Mon, 17 Dec 2007 10:43:39 +1100 Message-ID: <4765B82F.3020708@sgi.com> Date: Mon, 17 Dec 2007 10:43:43 +1100 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 1/2] cleanup fix handling References: <20071214202511.GA23248@lst.de> In-Reply-To: <20071214202511.GA23248@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5147/Sun Dec 16 12:56:32 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13957 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs It is looking good Christoph, I will check in the patch in the xfs dev tree. Regards, Vlad Christoph Hellwig wrote: > Cleanup various fid related bits: > > - merge xfs_fid2 into it's only caller xfs_dm_inode_to_fh. > - remove xfs_vget and opencode it in the two callers, simplifying > both of them by avoiding the awkward calling convetion. > - assign directly to the dm_fid_t members in various places in the > dmapi code instead of casting them to xfs_fid_t first (which > is identical to dm_fid_t) > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-12-13 19:14:47.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-12-13 20:10:04.000000000 +0100 > @@ -586,14 +586,12 @@ dm_dip_to_handle( > dm_handle_t *handlep) > { > dm_fid_t fid; > - struct xfs_fid *xfid; > int hsize; > > - xfid = (struct xfs_fid *)&fid; > - xfid->fid_len = sizeof(struct xfs_fid) - sizeof(xfid->fid_len); > - xfid->fid_pad = 0; > - xfid->fid_ino = ino; > - xfid->fid_gen = be32_to_cpu(dip->di_core.di_gen); > + fid.dm_fid_len = sizeof(struct dm_fid) - sizeof(fid.dm_fid_len); > + fid.dm_fid_pad = 0; > + fid.dm_fid_ino = ino; > + fid.dm_fid_gen = be32_to_cpu(dip->di_core.di_gen); > > memcpy(&handlep->ha_fsid, fsid, sizeof(*fsid)); > memcpy(&handlep->ha_fid, &fid, fid.dm_fid_len + sizeof(fid.dm_fid_len)); > @@ -3273,27 +3271,49 @@ xfs_dm_get_invis_ops( > STATIC int > xfs_dm_fh_to_inode( > struct super_block *sb, > - struct inode **ip, > + struct inode **inode, > dm_fid_t *dmfid) > { > - bhv_vnode_t *vp = NULL; > - xfs_mount_t *mp = XFS_M(sb); > - int error; > - struct xfs_fid xfid; > + xfs_mount_t *mp = XFS_M(sb); > + xfs_inode_t *ip; > + xfs_ino_t ino; > + unsigned int igen; > + int error; > > - /* Returns negative errors to DMAPI */ > + *inode = NULL; > > - *ip = NULL; > - memcpy(&xfid, dmfid, sizeof(*dmfid)); > - if (xfid.fid_len) { /* file object handle */ > - error = xfs_vget(mp, &vp, &xfid); > + if (!dmfid->dm_fid_len) { > + /* filesystem handle */ > + *inode = igrab(mp->m_rootip->i_vnode); > + if (!*inode) > + return -ENOENT; > + return 0; > } > - else { /* filesystem handle */ > - error = xfs_root(mp, &vp); > + > + if (dmfid->dm_fid_len != sizeof(*dmfid) - sizeof(dmfid->dm_fid_len)) > + return -EINVAL; > + > + ino = dmfid->dm_fid_ino; > + igen = dmfid->dm_fid_gen; > + > + /* fail requests for ino 0 gracefully. */ > + if (ino == 0) > + return -ESTALE; > + > + error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, 0); > + if (error) > + return -error; > + if (!ip) > + return -EIO; > + > + if (!ip->i_d.di_mode || ip->i_d.di_gen != igen) { > + xfs_iput_new(ip, XFS_ILOCK_SHARED); > + return -ENOENT; > } > - if (vp && (error == 0)) > - *ip = vn_to_inode(vp); > - return -error; /* Return negative error to DMAPI */ > + > + *inode = ip->i_vnode; > + xfs_iunlock(ip, XFS_ILOCK_SHARED); > + return 0; > } > > STATIC int > @@ -3303,18 +3323,21 @@ xfs_dm_inode_to_fh( > dm_fsid_t *dmfsid) > { > xfs_inode_t *ip = XFS_I(inode); > - int error; > - struct xfs_fid xfid; > > /* Returns negative errors to DMAPI */ > > if (ip->i_mount->m_fixedfsid == NULL) > return -EINVAL; > - error = xfs_fid2(ip, &xfid); > - if (error) > - return -error; /* Return negative error to DMAPI */ > > - memcpy(dmfid, &xfid, sizeof(*dmfid)); > + dmfid->dm_fid_len = sizeof(dm_fid_t) - sizeof(dmfid->dm_fid_len); > + dmfid->dm_fid_pad = 0; > + /* > + * use memcpy because the inode is a long long and there's no > + * assurance that dmfid->dm_fid_ino is properly aligned. > + */ > + memcpy(&dmfid->dm_fid_ino, &ip->i_ino, sizeof(dmfid->dm_fid_ino)); > + dmfid->dm_fid_gen = ip->i_d.di_gen; > + > memcpy(dmfsid, ip->i_mount->m_fixedfsid, sizeof(*dmfsid)); > return 0; > } > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_export.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_export.c 2007-12-13 19:14:47.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_export.c 2007-12-13 19:18:49.000000000 +0100 > @@ -118,20 +118,29 @@ xfs_nfs_get_inode( > u64 ino, > u32 generation) > { > - xfs_fid_t xfid; > - bhv_vnode_t *vp; > + xfs_mount_t *mp = XFS_M(sb); > + xfs_inode_t *ip; > int error; > > - xfid.fid_len = sizeof(xfs_fid_t) - sizeof(xfid.fid_len); > - xfid.fid_pad = 0; > - xfid.fid_ino = ino; > - xfid.fid_gen = generation; > + /* > + * NFS can sometimes send requests for ino 0. Fail them gracefully. > + */ > + if (ino == 0) > + return ERR_PTR(-ESTALE); > > - error = xfs_vget(XFS_M(sb), &vp, &xfid); > + error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, 0); > if (error) > return ERR_PTR(-error); > + if (!ip) > + return ERR_PTR(-EIO); > > - return vp ? vn_to_inode(vp) : NULL; > + if (!ip->i_d.di_mode || ip->i_d.di_gen != generation) { > + xfs_iput_new(ip, XFS_ILOCK_SHARED); > + return ERR_PTR(-ENOENT); > + } > + > + xfs_iunlock(ip, XFS_ILOCK_SHARED); > + return ip->i_vnode; > } > > STATIC struct dentry * > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-13 19:19:52.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-13 19:22:10.000000000 +0100 > @@ -267,7 +267,6 @@ EXPORT_SYMBOL(xfs_read_buf); > EXPORT_SYMBOL(xfs_rwlock); > EXPORT_SYMBOL(xfs_rwunlock); > EXPORT_SYMBOL(xfs_setattr); > -EXPORT_SYMBOL(xfs_fid2); > EXPORT_SYMBOL(xfs_attr_get); > EXPORT_SYMBOL(xfs_attr_set); > EXPORT_SYMBOL(xfs_fsync); > @@ -310,5 +309,4 @@ EXPORT_SYMBOL(xfs_ichgtime_fast); > EXPORT_SYMBOL(xfs_free_eofblocks); > > EXPORT_SYMBOL(xfs_do_force_shutdown); > -EXPORT_SYMBOL(xfs_vget); > EXPORT_SYMBOL(xfs_root); > Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-12-13 19:14:47.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-12-13 19:19:37.000000000 +0100 > @@ -1408,56 +1408,3 @@ xfs_syncsub( > > return XFS_ERROR(last_error); > } > - > -/* > - * xfs_vget - called by DMAPI and NFSD to get vnode from file handle > - */ > -int > -xfs_vget( > - xfs_mount_t *mp, > - bhv_vnode_t **vpp, > - xfs_fid_t *xfid) > -{ > - xfs_inode_t *ip; > - int error; > - xfs_ino_t ino; > - unsigned int igen; > - > - /* > - * Invalid. Since handles can be created in user space and passed in > - * via gethandle(), this is not cause for a panic. > - */ > - if (xfid->fid_len != sizeof(*xfid) - sizeof(xfid->fid_len)) > - return XFS_ERROR(EINVAL); > - > - ino = xfid->fid_ino; > - igen = xfid->fid_gen; > - > - /* > - * NFS can sometimes send requests for ino 0. Fail them gracefully. > - */ > - if (ino == 0) > - return XFS_ERROR(ESTALE); > - > - error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, 0); > - if (error) { > - *vpp = NULL; > - return error; > - } > - > - if (ip == NULL) { > - *vpp = NULL; > - return XFS_ERROR(EIO); > - } > - > - if (ip->i_d.di_mode == 0 || ip->i_d.di_gen != igen) { > - xfs_iput_new(ip, XFS_ILOCK_SHARED); > - *vpp = NULL; > - return XFS_ERROR(ENOENT); > - } > - > - *vpp = XFS_ITOV(ip); > - xfs_iunlock(ip, XFS_ILOCK_SHARED); > - return 0; > -} > - > Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.h 2007-12-13 19:19:40.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.h 2007-12-13 19:19:45.000000000 +0100 > @@ -15,7 +15,6 @@ int xfs_mntupdate(struct xfs_mount *mp, > struct xfs_mount_args *args); > int xfs_root(struct xfs_mount *mp, bhv_vnode_t **vpp); > int xfs_sync(struct xfs_mount *mp, int flags); > -int xfs_vget(struct xfs_mount *mp, bhv_vnode_t **vpp, struct xfs_fid *xfid); > void xfs_do_force_shutdown(struct xfs_mount *mp, int flags, char *fname, > int lnnum); > void xfs_attr_quiesce(struct xfs_mount *mp); > Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-12-13 19:20:41.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-12-13 19:20:53.000000000 +0100 > @@ -3457,27 +3457,6 @@ std_return: > goto std_return; > } > > - > -int > -xfs_fid2( > - xfs_inode_t *ip, > - xfs_fid_t *xfid) > -{ > - xfs_itrace_entry(ip); > - > - xfid->fid_len = sizeof(xfs_fid_t) - sizeof(xfid->fid_len); > - xfid->fid_pad = 0; > - /* > - * use memcpy because the inode is a long long and there's no > - * assurance that xfid->fid_ino is properly aligned. > - */ > - memcpy(&xfid->fid_ino, &ip->i_ino, sizeof(xfid->fid_ino)); > - xfid->fid_gen = ip->i_d.di_gen; > - > - return 0; > -} > - > - > int > xfs_rwlock( > xfs_inode_t *ip, > Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.h 2007-12-13 19:20:04.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.h 2007-12-13 19:22:04.000000000 +0100 > @@ -39,7 +39,6 @@ int xfs_readdir(struct xfs_inode *dp, vo > int xfs_symlink(struct xfs_inode *dp, bhv_vname_t *dentry, > char *target_path, mode_t mode, bhv_vnode_t **vpp, > struct cred *credp); > -int xfs_fid2(struct xfs_inode *ip, struct xfs_fid *xfid); > int xfs_rwlock(struct xfs_inode *ip, bhv_vrwlock_t locktype); > void xfs_rwunlock(struct xfs_inode *ip, bhv_vrwlock_t locktype); > int xfs_inode_flush(struct xfs_inode *ip, int flags); > > From owner-xfs@oss.sgi.com Sun Dec 16 15:47:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 15:47:20 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBGNlIY4028310 for ; Sun, 16 Dec 2007 15:47:18 -0800 X-ASG-Debug-ID: 1197848847-0c13021e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2F52F48CAD4 for ; Sun, 16 Dec 2007 15:47:27 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id LMZvgdMbhIc0fDYG for ; Sun, 16 Dec 2007 15:47:27 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id ADF561C000263; Sun, 16 Dec 2007 18:47:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id A8BA840195BB; Sun, 16 Dec 2007 18:47:26 -0500 (EST) Date: Sun, 16 Dec 2007 18:47:26 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: David Chinner cc: Eric Sandeen , Alex Madarasz , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Subject: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? In-Reply-To: <20071216233127.GY4612@sgi.com> Message-ID: References: <1197653927.3841.1226620089@webmail.messagingengine.com> <4764AB08.7040608@sandeen.net> <20071216233127.GY4612@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1197848850 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36826 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5147/Sun Dec 16 12:56:32 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13958 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Mon, 17 Dec 2007, David Chinner wrote: > On Sat, Dec 15, 2007 at 10:35:20PM -0600, Eric Sandeen wrote: >> Alex Madarasz wrote: >>> We're building a new Fedora 8.0.1 Linux system to stream data from a >>> 250Msps ADC to disk, and want to start tuning the system configuration >>> for maximum XFS write performance. To date, without any significant >>> effort at tuning our Fedora 7 dev system, we're seeing 250MBps write >>> with 8-bit samples and ~ 300MBps write with 16-bit samples. We want to >>> push the tuning as far as we can go with this architecture before we >>> start looking at other hardware options. Looking at various other >>> tuning pages on the Web finds few that are interested in maxing out >>> sequential writes to very large arrays while using SAS HW RAID with big >>> fast SAS drives too. >> >> ... >> >>> XFS Tuning Options? >>> >>> - HW RAID0: >>> - Array/logical disk HW RAID stripe size? >> >> At any rate you'll want to match xfs's geometry with the raid geometry. >> >>> - Cache enabled (some reports that cache s/b turned off?)? >> >> If it's battery-backed cache, leave it on, and disable barriers in xfs >> (it's a mount option) >> >>> - xfs mkfs / mount options? >> >> David mentioned these before as a generic place to start: >> >> # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 >> >> # mount -o logbsize=256k >> >> and that those would be upcoming new defaults for mkfs. >> >> 4 ags may not be what you want for a ~2T filesystem. > > Right - the 4 AG tuning is effectively for single disk configurations to > limit parallelism and therefore keep seeks between AGs down. When you > have multiple disks, the [new] mkfs defaults should be just fine (i.e. > just drop the agcount suggestion). > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > Dave, The mkfs.xfs defaults will be just fine for a HW raid device? Justin. From owner-xfs@oss.sgi.com Sun Dec 16 15:57:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 15:57: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=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBGNuvjN029167 for ; Sun, 16 Dec 2007 15:57:00 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA24661; Mon, 17 Dec 2007 10:57:04 +1100 Message-ID: <4765BB55.5040906@sgi.com> Date: Mon, 17 Dec 2007 10:57:09 +1100 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com CC: xfs@oss.sgi.com Subject: TAKE 974747 - PATCH: Cleanup various fid related bits Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5147/Sun Dec 16 12:56:32 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13959 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Cleanup various fid related bits: - merge xfs_fid2 into it's only caller xfs_dm_inode_to_fh. - remove xfs_vget and opencode it in the two callers, simplifying both of them by avoiding the awkward calling convetion. - assign directly to the dm_fid_t members in various places in the dmapi code instead of casting them to xfs_fid_t first (which is identical to dm_fid_t) Signed-off-by: Christoph Hellwig Date: Mon Dec 17 10:54:18 AEDT 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs-patch-reviews Inspected by: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30258a fs/xfs/xfs_vnodeops.c - 1.727 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.727&r2=text&tr2=1.726&f=h - pv 974747, author Christoph Hellwig , rv vapo - Cleanup various fid related bits fs/xfs/xfs_vfsops.c - 1.549 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.549&r2=text&tr2=1.548&f=h - pv 974747, author Christoph Hellwig , rv vapo - Cleanup various fid related bits fs/xfs/linux-2.6/xfs_ksyms.c - 1.76 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.76&r2=text&tr2=1.75&f=h - pv 974747, author Christoph Hellwig , rv vapo - Cleanup various fid related bits fs/xfs/linux-2.6/xfs_export.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h - pv 974747, author Christoph Hellwig , rv vapo - Cleanup various fid related bits fs/xfs/dmapi/xfs_dm.c - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h - pv 974747, author Christoph Hellwig , rv vapo - Cleanup various fid related bits fs/xfs/xfs_vnodeops.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h - pv 974747, author Christoph Hellwig , rv vapo - Cleanup various fid related bits fs/xfs/xfs_vfsops.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h - pv 974747, author Christoph Hellwig , rv vapo - Cleanup various fid related bits From owner-xfs@oss.sgi.com Sun Dec 16 16:37:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 16:37:22 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBH0bAtg003941 for ; Sun, 16 Dec 2007 16:37:13 -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 LAA25658; Mon, 17 Dec 2007 11:37:20 +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 lBH0bHIN11045681; Mon, 17 Dec 2007 11:37:18 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBH0bEWB11047157; Mon, 17 Dec 2007 11:37:14 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 17 Dec 2007 11:37:14 +1100 From: David Chinner To: Justin Piszcz Cc: David Chinner , Eric Sandeen , Alex Madarasz , xfs@oss.sgi.com Subject: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Message-ID: <20071217003714.GN4396912@sgi.com> References: <1197653927.3841.1226620089@webmail.messagingengine.com> <4764AB08.7040608@sandeen.net> <20071216233127.GY4612@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5147/Sun Dec 16 12:56:32 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13960 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 Sun, Dec 16, 2007 at 06:47:26PM -0500, Justin Piszcz wrote: > > The mkfs.xfs defaults will be just fine for a HW raid device? If you get a mkfs.xfs from CVS. When barry releases an updated xfsprogs tarball the defaults from there will be as we've been talking about. You may still need to tweak sunit/swidth for hardware raid (depending on you config) but that is no different to now.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Dec 16 16:41:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 16:41:12 -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 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBH0f32U004421 for ; Sun, 16 Dec 2007 16:41:07 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA25789; Mon, 17 Dec 2007 11:41:09 +1100 Message-ID: <4765C5AA.5050504@sgi.com> Date: Mon, 17 Dec 2007 11:41:14 +1100 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 1/2] stop updating inode->i_blocks References: <20071216163352.GB2107@lst.de> In-Reply-To: <20071216163352.GB2107@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5147/Sun Dec 16 12:56:32 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13961 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs It is looking good from DMAPI point of view. Regards, Vlad Christoph Hellwig wrote: > The VFS doesn't use i_blocks, it's only used by generic_fillattr and > the generic quota code which XFS doesn't use. In XFS there is one use > to check whether we have an inline or out of line sumlink, but we can > replace that with a check of the XFS_IFINLINE inode flag. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-11-30 10:14:10.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-11-30 10:18:38.000000000 +0100 > @@ -2503,11 +2503,6 @@ xfs_dm_punch_hole( > */ > if (!error && (len == 0)) { > error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_NOLOCK); > - if (!error) { > - /* Update linux inode block count after free above */ > - inode->i_blocks = XFS_FSB_TO_BB(mp, > - ip->i_d.di_nblocks + ip->i_delayed_blks); > - } > } > > /* > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-11-30 10:15:48.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-11-30 10:18:38.000000000 +0100 > @@ -202,9 +202,6 @@ xfs_validate_fields( > loff_t size; > > inode->i_nlink = ip->i_d.di_nlink; > - inode->i_blocks = > - XFS_FSB_TO_BB(ip->i_mount, ip->i_d.di_nblocks + > - ip->i_delayed_blks); > /* we're under i_sem so i_size can't change under us */ > size = XFS_ISIZE(ip); > if (i_size_read(inode) != size) > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2007-11-30 10:15:48.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2007-11-30 10:18:38.000000000 +0100 > @@ -568,7 +568,7 @@ xfs_set_inodeops( > break; > case S_IFLNK: > inode->i_op = &xfs_symlink_inode_operations; > - if (inode->i_blocks) > + if (!(XFS_I(inode)->i_df.if_flags & XFS_IFINLINE)) > inode->i_mapping->a_ops = &xfs_address_space_operations; > break; > default: > @@ -605,8 +605,6 @@ xfs_revalidate_inode( > > inode->i_generation = ip->i_d.di_gen; > i_size_write(inode, ip->i_d.di_size); > - inode->i_blocks = > - XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); > inode->i_atime.tv_sec = ip->i_d.di_atime.t_sec; > inode->i_atime.tv_nsec = ip->i_d.di_atime.t_nsec; > inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2007-11-30 10:14:10.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2007-11-30 10:18:38.000000000 +0100 > @@ -106,8 +106,6 @@ vn_revalidate( > inode->i_nlink = ip->i_d.di_nlink; > inode->i_uid = ip->i_d.di_uid; > inode->i_gid = ip->i_d.di_gid; > - inode->i_blocks = > - XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); > inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; > inode->i_mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; > inode->i_ctime.tv_sec = ip->i_d.di_ctime.t_sec; > Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-11-30 10:14:10.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-11-30 10:18:38.000000000 +0100 > @@ -1557,9 +1557,6 @@ xfs_release( > error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); > if (error) > return error; > - /* Update linux inode block count after free above */ > - vn_to_inode(vp)->i_blocks = XFS_FSB_TO_BB(mp, > - ip->i_d.di_nblocks + ip->i_delayed_blks); > } > } > > @@ -1633,9 +1630,6 @@ xfs_inactive( > error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); > if (error) > return VN_INACTIVE_CACHE; > - /* Update linux inode block count after free above */ > - vn_to_inode(vp)->i_blocks = XFS_FSB_TO_BB(mp, > - ip->i_d.di_nblocks + ip->i_delayed_blks); > } > goto out; > } > > From owner-xfs@oss.sgi.com Sun Dec 16 16:49:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 16:49:47 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBH0nfMR005196 for ; Sun, 16 Dec 2007 16:49:44 -0800 X-ASG-Debug-ID: 1197852590-01c400470000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D3D8F48CA47 for ; Sun, 16 Dec 2007 16:49:51 -0800 (PST) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id 1ww150Mp85INFF3p for ; Sun, 16 Dec 2007 16:49:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAC9UZUc7p6NmWmdsb2JhbACBV44kASCYBw X-IronPort-AV: E=Sophos;i="4.24,174,1196602200"; d="scan'208";a="18563000" Received: from ppp59-167-163-102.lns1.mel4.internode.on.net (HELO jdc.jasonjgw.net) ([59.167.163.102]) by ipmail05.adl2.internode.on.net with ESMTP; 17 Dec 2007 11:19:48 +1030 Received: from jdc.jasonjgw.net (ip6-localhost [IPv6:::1]) by jdc.jasonjgw.net (8.14.2/8.14.2/Debian-2) with ESMTP id lBH0njmk013347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 17 Dec 2007 11:49:45 +1100 Received: (from jason@localhost) by jdc.jasonjgw.net (8.14.2/8.14.2/Submit) id lBH0njsP013346 for xfs@oss.sgi.com; Mon, 17 Dec 2007 11:49:45 +1100 Date: Mon, 17 Dec 2007 11:49:45 +1100 From: Jason White To: xfs@oss.sgi.com X-ASG-Orig-Subj: Installing grub onto a system with XFS root fs Subject: Installing grub onto a system with XFS root fs Message-ID: <20071217004945.GA13335@jdc.jasonjgw.net> Mail-Followup-To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1197852593 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36830 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5147/Sun Dec 16 12:56:32 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13962 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jason@jasonjgw.net Precedence: bulk X-list: xfs I am trying to install Grub onto a system with a single XFS partition serving as both / and /boot. Distribution: Debian Unstable (Sid). Architecture: x86_64 When I run grub-install I get: Searching for GRUB installation directory ... found: /boot/grub Due to a bug in xfs_freeze, the following command might produce a segmentation fault when /boot/grub is not in an XFS filesystem. This error is harmless and can be ignored. At this point the install script hangs and the only way to recover is to reboot the machine (with a hard reset). Needless to say, Grub isn't installed. Any suggestions? Note that the installation of grub failed during the Debian installation process for a reason that wasn't specified (no helpful error message). I have an x86 "live CD" with grub available if that will help, but it isn't x86_64. Thanks. From owner-xfs@oss.sgi.com Sun Dec 16 17:07:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 17:07:12 -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 cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBH178nh006437 for ; Sun, 16 Dec 2007 17:07:09 -0800 X-ASG-Debug-ID: 1197853634-43cc00430000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 58A0511689B2 for ; Sun, 16 Dec 2007 17:07:14 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id XCivC1yNmRqWACji for ; Sun, 16 Dec 2007 17:07:14 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A0B20182DD1D9 for ; Sun, 16 Dec 2007 19:07:12 -0600 (CST) Message-ID: <4765CBBF.1020207@sandeen.net> Date: Sun, 16 Dec 2007 19:07:11 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Installing grub onto a system with XFS root fs Subject: Re: Installing grub onto a system with XFS root fs References: <20071217004945.GA13335@jdc.jasonjgw.net> In-Reply-To: <20071217004945.GA13335@jdc.jasonjgw.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197853640 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36831 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5147/Sun Dec 16 12:56:32 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13963 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Jason White wrote: > I am trying to install Grub onto a system with a single XFS partition serving > as both / and /boot. > > Distribution: Debian Unstable (Sid). > Architecture: x86_64 > > When I run grub-install I get: > Searching for GRUB installation directory ... found: /boot/grub > Due to a bug in xfs_freeze, the following command might produce a segmentation > fault when /boot/grub is not in an XFS filesystem. This error is harmless and > can be ignored. Hrm, that's funky. > At this point the install script hangs and the only way to recover is to > reboot the machine (with a hard reset). Needless to say, Grub isn't installed. > > Any suggestions? > > Note that the installation of grub failed during the Debian installation > process for a reason that wasn't specified (no helpful error message). > Hard to say - in a nutshell, grub just sucks w.r.t. how it (ab)uses the filesystem it's trying to install on. In some invocations, it actually writes directly to the block device *while it is mounted* - this leads to data corruption and/or filesystem corruption. In other cases, in a "verification" phase, it tries to directly read filesystem structures off the disk *while it is mounted* after a couple of wishful sync; sync;'s - this often can lead to a grub hang when it goes off in the weeds on inconsistent disk data that it finds. I think various distros have tried to hack around these problems in different ways; the freeze above is probably an effort to coalesce the filesystem before grub goes groveling around the disk to verify what it just wrote(!). If you: a) don't write to the bdev while mounted and b) don't try to read the mounted filesystem via the bdev (skip verification steps) it should all work ok. (for fedora grub, a) means passing the path to the stage2 files on the commandline to grub-install, ymmv): install --stage2=/boot/grub/stage2 (hd0,7)/grub/stage1 d (hd0) /grub/stage2 p (hd0,7)/grub/grub.conf for some reason this stops grub from writing to the mounted block device. Otherwise, I'd bug debian - honestly, this isn't an xfs bug. -Eric From owner-xfs@oss.sgi.com Sun Dec 16 17:18:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 17:18:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBH1I4na007464 for ; Sun, 16 Dec 2007 17:18:08 -0800 X-ASG-Debug-ID: 1197854296-2be900880000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from out3.smtp.messagingengine.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 376E81168A3B for ; Sun, 16 Dec 2007 17:18:16 -0800 (PST) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by cuda.sgi.com with ESMTP id jkE0M1118TCvpqOS for ; Sun, 16 Dec 2007 17:18:16 -0800 (PST) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id C65F97DAA6 for ; Sun, 16 Dec 2007 20:17:44 -0500 (EST) Received: from web8.messagingengine.com ([10.202.2.217]) by compute1.internal (MEProxy); Sun, 16 Dec 2007 20:17:44 -0500 Received: by web8.messagingengine.com (Postfix, from userid 99) id A2AC84B9B2; Sun, 16 Dec 2007 20:17:44 -0500 (EST) Message-Id: <1197854264.9694.1226902133@webmail.messagingengine.com> X-Sasl-Enc: KHTjyunmGeVI2BE1betF48Ppx4z0a/2T97ANdLBun2Ip 1197854264 From: "Alex Madarasz" To: xfs@oss.sgi.com Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface References: <1197653927.3841.1226620089@webmail.messagingengine.com> <4764AB08.7040608@sandeen.net> X-ASG-Orig-Subj: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Subject: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? In-Reply-To: <4764AB08.7040608@sandeen.net> Reply-To: List@madalexlists.nospammail.net Date: Sun, 16 Dec 2007 20:17:44 -0500 X-Barracuda-Connect: out3.smtp.messagingengine.com[66.111.4.27] X-Barracuda-Start-Time: 1197854297 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36831 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13964 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: List@madalexlists.nospammail.net Precedence: bulk X-list: xfs On Sat, 15 Dec 2007 22:35:20 -0600, "Eric Sandeen" said: > Alex Madarasz wrote: > > We're building a new Fedora 8.0.1 Linux system to stream data from a > > 250Msps ADC to disk, and want to start tuning the system > > configuration for maximum XFS write performance. To date, without > > any significant effort at tuning our Fedora 7 dev system, we're > > seeing 250MBps write with 8-bit samples and ~ 300MBps write with 16- > > bit samples. We want to push the tuning as far as we can go with > > this architecture before we start looking at other hardware options. > > Looking at various other tuning pages on the Web finds few that are > > interested in maxing out sequential writes to very large arrays > > while using SAS HW RAID with big fast SAS drives too. > ... > > > XFS Tuning Options? > > > > - HW RAID0: > > - Array/logical disk HW RAID stripe size? > > At any rate you'll want to match xfs's geometry with the raid > geometry. The HP P400 stripe size defaults to 128K and can go up to 256K (and down to 64K, 32K, ...). Any reason, with big sequential XFS write loads, I shouldn't just max it out at 256K and move on? I understand Linux XFS block size is limited to 4KiB max on Intel 32-bit architectures ... including PAE? > > - Cache enabled (some reports that cache s/b turned off?)? > > If it's battery-backed cache, leave it on, and disable barriers in xfs > (it's a mount option) It is indeed 512M of HP Battery-Backed Write Cache (BBWC). > > - xfs mkfs / mount options? > > David mentioned these before as a generic place to start: > > # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d > # agcount=4 > > # mount -o logbsize=256k > > and that those would be upcoming new defaults for mkfs. > > 4 ags may not be what you want for a ~2T filesystem. > > - External Log? > > - How big a partition on the E200i? > > - mkfs / mount options? > > not sure if an external log would be beneficial or not. From owner-xfs@oss.sgi.com Sun Dec 16 17:48:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 17:48:56 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBH1mooI009086 for ; Sun, 16 Dec 2007 17:48:51 -0800 X-ASG-Debug-ID: 1197856136-44c300120000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 86B3B48CE4F for ; Sun, 16 Dec 2007 17:48:57 -0800 (PST) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id s47q29H8FZDbdfmY for ; Sun, 16 Dec 2007 17:48:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAFJiZUc7p6NmWmdsb2JhbACBV44kASCYNw X-IronPort-AV: E=Sophos;i="4.24,174,1196602200"; d="scan'208";a="18602914" Received: from ppp59-167-163-102.lns1.mel4.internode.on.net (HELO jdc.jasonjgw.net) ([59.167.163.102]) by ipmail05.adl2.internode.on.net with ESMTP; 17 Dec 2007 12:18:51 +1030 Received: from jdc.jasonjgw.net (ip6-localhost [IPv6:::1]) by jdc.jasonjgw.net (8.14.2/8.14.2/Debian-2) with ESMTP id lBH1kRh7013913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 17 Dec 2007 12:46:27 +1100 Received: (from jason@localhost) by jdc.jasonjgw.net (8.14.2/8.14.2/Submit) id lBH1kRLo013912 for xfs@oss.sgi.com; Mon, 17 Dec 2007 12:46:27 +1100 Date: Mon, 17 Dec 2007 12:46:27 +1100 From: Jason White To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Installing grub onto a system with XFS root fs Subject: Re: Installing grub onto a system with XFS root fs Message-ID: <20071217014627.GA13692@jdc.jasonjgw.net> Mail-Followup-To: xfs@oss.sgi.com References: <20071217004945.GA13335@jdc.jasonjgw.net> <4765CBBF.1020207@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4765CBBF.1020207@sandeen.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1197856142 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36834 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13965 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jason@jasonjgw.net Precedence: bulk X-list: xfs On Sun, Dec 16, 2007 at 07:07:11PM -0600, Eric Sandeen wrote: > Hard to say - in a nutshell, grub just sucks w.r.t. how it (ab)uses the > filesystem it's trying to install on. > > In some invocations, it actually writes directly to the block device > *while it is mounted* - this leads to data corruption and/or filesystem > corruption. > > In other cases, in a "verification" phase, it tries to directly read > filesystem structures off the disk *while it is mounted* after a couple > of wishful sync; sync;'s - this often can lead to a grub hang when it > goes off in the weeds on inconsistent disk data that it finds. > > I think various distros have tried to hack around these problems in > different ways; the freeze above is probably an effort to coalesce the > filesystem before grub goes groveling around the disk to verify what it > just wrote(!). > Thanks for the background. The most up to date bug report and discussion I could find is here: https://bugs.launchpad.net/debian/+source/grub/+bug/8058 (for Ubuntu). There are also Debian bugs for this, such as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111 Manually unfreezing the file system with xfs_freeze -u / worked for me on one machine. (This was done while grub-install was executing, after it executed xfs_freeze). From owner-xfs@oss.sgi.com Sun Dec 16 19:12:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 19:12:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBH3CfiA014034 for ; Sun, 16 Dec 2007 19:12:42 -0800 X-ASG-Debug-ID: 1197861172-039600170000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8A2E048D5AD for ; Sun, 16 Dec 2007 19:12:52 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id itdeLyfGkYEHuIUi for ; Sun, 16 Dec 2007 19:12:52 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 7B545182DD2DB for ; Sun, 16 Dec 2007 21:12:50 -0600 (CST) Message-ID: <4765E932.7060605@sandeen.net> Date: Sun, 16 Dec 2007 21:12:50 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Installing grub onto a system with XFS root fs Subject: Re: Installing grub onto a system with XFS root fs References: <20071217004945.GA13335@jdc.jasonjgw.net> <4765CBBF.1020207@sandeen.net> <20071217014627.GA13692@jdc.jasonjgw.net> In-Reply-To: <20071217014627.GA13692@jdc.jasonjgw.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197861173 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36838 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13966 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Jason White wrote: > Manually unfreezing the file system with xfs_freeze -u / > worked for me on one machine. (This was done while grub-install was executing, > after it executed xfs_freeze). > > sounds like a bug in the scripts, then. -Eric From owner-xfs@oss.sgi.com Sun Dec 16 19:26:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 19:26: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.2 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBH3QJbh016373 for ; Sun, 16 Dec 2007 19:26:22 -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 OAA29351 for ; Mon, 17 Dec 2007 14:26:31 +1100 Message-ID: <4765EC66.5020202@sgi.com> Date: Mon, 17 Dec 2007 14:26:30 +1100 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: xfs-oss Subject: [review] Remove the xfs refcache Content-Type: multipart/mixed; boundary="------------040608040207030606030106" X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13967 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 This is a multi-part message in MIME format. --------------040608040207030606030106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Remove the xfs_refcache, it was only needed while we were still building for 2.4 kernels. --------------040608040207030606030106 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="remove_xfs_refcache.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="remove_xfs_refcache.patch" --- a/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-17 11:55:09.000000000 +1100 +++ b/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-17 11:34:19.000000000 +1100 @@ -46,7 +46,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_refcache.h" #include "xfs_dir2_data.h" #include "xfs_dir2_leaf.h" #include "xfs_dir2_block.h" --- a/fs/xfs/linux-2.6/xfs_linux.h 2007-12-17 11:55:09.000000000 +1100 +++ b/fs/xfs/linux-2.6/xfs_linux.h 2007-12-17 10:30:53.000000000 +1100 @@ -99,7 +99,6 @@ /* * Feature macros (disable/enable) */ -#undef HAVE_REFCACHE /* reference cache not needed for NFS in 2.6 */ #define HAVE_SPLICE /* a splice(2) exists in 2.6, but not in 2.4 */ #ifdef CONFIG_SMP #define HAVE_PERCPU_SB /* per cpu superblock counters are a 2.6 feature */ --- a/fs/xfs/xfs_inode.h 2007-12-17 11:55:09.000000000 +1100 +++ b/fs/xfs/xfs_inode.h 2007-12-17 10:31:25.000000000 +1100 @@ -240,10 +240,6 @@ typedef struct xfs_inode { atomic_t i_pincount; /* inode pin count */ wait_queue_head_t i_ipin_wait; /* inode pinning wait queue */ spinlock_t i_flags_lock; /* inode i_flags lock */ -#ifdef HAVE_REFCACHE - struct xfs_inode **i_refcache; /* ptr to entry in ref cache */ - struct xfs_inode *i_release; /* inode to unref */ -#endif /* Miscellaneous state. */ unsigned short i_flags; /* see defined flags below */ unsigned char i_update_core; /* timestamps/size is dirty */ --- a/fs/xfs/xfs_rename.c 2007-12-17 11:55:09.000000000 +1100 +++ b/fs/xfs/xfs_rename.c 2007-12-17 10:33:32.000000000 +1100 @@ -36,7 +36,6 @@ #include "xfs_bmap.h" #include "xfs_error.h" #include "xfs_quota.h" -#include "xfs_refcache.h" #include "xfs_utils.h" #include "xfs_trans_space.h" #include "xfs_vnodeops.h" @@ -580,10 +579,8 @@ xfs_rename( * the vnode references. */ error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); - if (target_ip != NULL) { - xfs_refcache_purge_ip(target_ip); + if (target_ip != NULL) IRELE(target_ip); - } /* * Let interposed file systems know about removed links. */ --- a/fs/xfs/xfs_vfsops.c 2007-12-17 11:55:09.000000000 +1100 +++ b/fs/xfs/xfs_vfsops.c 2007-12-17 11:34:19.000000000 +1100 @@ -43,7 +43,6 @@ #include "xfs_error.h" #include "xfs_bmap.h" #include "xfs_rw.h" -#include "xfs_refcache.h" #include "xfs_buf_item.h" #include "xfs_log_priv.h" #include "xfs_dir2_trace.h" @@ -157,7 +156,6 @@ xfs_cleanup(void) xfs_cleanup_procfs(); xfs_sysctl_unregister(); - xfs_refcache_destroy(); xfs_filestream_uninit(); xfs_mru_cache_uninit(); xfs_acl_zone_destroy(xfs_acl_zone); @@ -585,11 +583,6 @@ xfs_unmount( 0 : DM_FLAGS_UNWANTED; } #endif - /* - * First blow any referenced inode from this file system - * out of the reference cache, and delete the timer. - */ - xfs_refcache_purge_mp(mp); /* * Blow away any referenced inode in the filestreams cache. @@ -653,7 +646,6 @@ xfs_quiesce_fs( { int count = 0, pincount; - xfs_refcache_purge_mp(mp); xfs_flush_buftarg(mp->m_ddev_targp, 0); xfs_finish_reclaim_all(mp, 0); @@ -1344,18 +1336,6 @@ xfs_syncsub( } /* - * If this is the periodic sync, then kick some entries out of - * the reference cache. This ensures that idle entries are - * eventually kicked out of the cache. - */ - if (flags & SYNC_REFCACHE) { - if (flags & SYNC_WAIT) - xfs_refcache_purge_mp(mp); - else - xfs_refcache_purge_some(mp); - } - - /* * If asked, update the disk superblock with incore counter values if we * are using non-persistent counters so that they don't get too far out * of sync if we crash or get a forced shutdown. We don't want to force --- a/fs/xfs/xfs_vnodeops.c 2007-12-17 11:55:09.000000000 +1100 +++ b/fs/xfs/xfs_vnodeops.c 2007-12-17 11:34:20.000000000 +1100 @@ -48,7 +48,6 @@ #include "xfs_quota.h" #include "xfs_utils.h" #include "xfs_rtalloc.h" -#include "xfs_refcache.h" #include "xfs_trans_space.h" #include "xfs_log_priv.h" #include "xfs_filestream.h" @@ -1541,12 +1540,6 @@ xfs_release( xfs_flush_pages(ip, 0, -1, XFS_B_ASYNC, FI_NONE); } -#ifdef HAVE_REFCACHE - /* If we are in the NFS reference cache then don't do this now */ - if (ip->i_refcache) - return 0; -#endif - if (ip->i_d.di_nlink != 0) { if ((((ip->i_d.di_mode & S_IFMT) == S_IFREG) && ((ip->i_size > 0) || (VN_CACHED(vp) > 0 || @@ -2476,14 +2469,6 @@ xfs_remove( } /* - * Before we drop our extra reference to the inode, purge it - * from the refcache if it is there. By waiting until afterwards - * to do the IRELE, we ensure that we won't go inactive in the - * xfs_refcache_purge_ip routine (although that would be OK). - */ - xfs_refcache_purge_ip(ip); - - /* * If we are using filestreams, kill the stream association. * If the file is still open it may get a new one but that * will get killed on last close in xfs_close() so we don't @@ -2522,14 +2507,6 @@ xfs_remove( cancel_flags |= XFS_TRANS_ABORT; xfs_trans_cancel(tp, cancel_flags); - /* - * Before we drop our extra reference to the inode, purge it - * from the refcache if it is there. By waiting until afterwards - * to do the IRELE, we ensure that we won't go inactive in the - * xfs_refcache_purge_ip routine (although that would be OK). - */ - xfs_refcache_purge_ip(ip); - IRELE(ip); goto std_return; @@ -3487,16 +3464,7 @@ xfs_rwunlock( { if (S_ISDIR(ip->i_d.di_mode)) return; - if (locktype == VRWLOCK_WRITE) { - /* - * In the write case, we may have added a new entry to - * the reference cache. This might store a pointer to - * an inode to be released in this inode. If it is there, - * clear the pointer and release the inode after unlocking - * this one. - */ - xfs_refcache_iunlock(ip, XFS_IOLOCK_EXCL); - } else { + if (locktype != VRWLOCK_WRITE) { ASSERT((locktype == VRWLOCK_READ) || (locktype == VRWLOCK_WRITE_DIRECT)); xfs_iunlock(ip, XFS_IOLOCK_SHARED); --- a/fs/xfs/xfs_refcache.h 2007-12-17 11:55:19.000000000 +1100 +++ b/fs/xfs/xfs_refcache.h 2006-06-16 23:54:00.000000000 +1000 @@ -1,52 +0,0 @@ -/* - * Copyright (c) 2000-2003,2005 Silicon Graphics, Inc. - * All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it would be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ -#ifndef __XFS_REFCACHE_H__ -#define __XFS_REFCACHE_H__ - -#ifdef HAVE_REFCACHE -/* - * Maximum size (in inodes) for the NFS reference cache - */ -#define XFS_REFCACHE_SIZE_MAX 512 - -struct xfs_inode; -struct xfs_mount; - -extern void xfs_refcache_insert(struct xfs_inode *); -extern void xfs_refcache_purge_ip(struct xfs_inode *); -extern void xfs_refcache_purge_mp(struct xfs_mount *); -extern void xfs_refcache_purge_some(struct xfs_mount *); -extern void xfs_refcache_resize(int); -extern void xfs_refcache_destroy(void); - -extern void xfs_refcache_iunlock(struct xfs_inode *, uint); - -#else - -#define xfs_refcache_insert(ip) do { } while (0) -#define xfs_refcache_purge_ip(ip) do { } while (0) -#define xfs_refcache_purge_mp(mp) do { } while (0) -#define xfs_refcache_purge_some(mp) do { } while (0) -#define xfs_refcache_resize(size) do { } while (0) -#define xfs_refcache_destroy() do { } while (0) - -#define xfs_refcache_iunlock(ip, flags) xfs_iunlock(ip, flags) - -#endif - -#endif /* __XFS_REFCACHE_H__ */ --------------040608040207030606030106-- From owner-xfs@oss.sgi.com Sun Dec 16 19:58:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 19:58: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.11/SuSE Linux 0.7) with SMTP id lBH3whPu019457 for ; Sun, 16 Dec 2007 19:58:46 -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 OAA29799; Mon, 17 Dec 2007 14:58:52 +1100 Message-ID: <4765F444.8010705@sgi.com> Date: Mon, 17 Dec 2007 15:00:04 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Donald Douwsma CC: xfs-oss Subject: Re: [review] Remove the xfs refcache References: <4765EC66.5020202@sgi.com> In-Reply-To: <4765EC66.5020202@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13968 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 Hey hold on there buddy! We may need to reactivate this code to fix some performance issues. I've acttually got this code working and proven that it is one way to fix some of the NAS/NFS issues we have. The little comment that reads "reference cache not needed for NFS in 2.6" is wrong - we do need it or something like it. Donald Douwsma wrote: > Remove the xfs_refcache, it was only needed while we were still building > for > 2.4 kernels. > > From owner-xfs@oss.sgi.com Sun Dec 16 20:12:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 20:12:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBH4COYB020427 for ; Sun, 16 Dec 2007 20:12:30 -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 PAA00426; Mon, 17 Dec 2007 15:12:33 +1100 Message-ID: <4765F730.7000307@sgi.com> Date: Mon, 17 Dec 2007 15:12:32 +1100 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: lachlan@sgi.com CC: xfs-oss Subject: Re: [review] Remove the xfs refcache References: <4765EC66.5020202@sgi.com> <4765F444.8010705@sgi.com> In-Reply-To: <4765F444.8010705@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13969 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 Lachlan McIlroy wrote: > Hey hold on there buddy! We may need to reactivate this code to fix some > performance issues. I've acttually got this code working and proven that > it is one way to fix some of the NAS/NFS issues we have. > > The little comment that reads "reference cache not needed for NFS in 2.6" > is wrong - we do need it or something like it. Cool :) I'm just trying to clean up any 2.4 build leftovers before things go upstream for .25. Bear in mind that xfs_refcache.c is only present in ptools/CVS, it was excluded for mainline when it wasn't needed for the 2.6 builds. Don From owner-xfs@oss.sgi.com Sun Dec 16 21:48:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 21:48:52 -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 cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBH5mV7g030184 for ; Sun, 16 Dec 2007 21:48:45 -0800 X-ASG-Debug-ID: 1197870522-210801b60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A52245B8B99 for ; Sun, 16 Dec 2007 21:48:43 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id u4xDg0VzF9FrmqhM for ; Sun, 16 Dec 2007 21:48:43 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E2729182DD2DB; Sun, 16 Dec 2007 23:48:40 -0600 (CST) Message-ID: <47660DB7.5000104@sandeen.net> Date: Sun, 16 Dec 2007 23:48:39 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: lachlan@sgi.com CC: Donald Douwsma , xfs-oss X-ASG-Orig-Subj: Re: [review] Remove the xfs refcache Subject: Re: [review] Remove the xfs refcache References: <4765EC66.5020202@sgi.com> <4765F444.8010705@sgi.com> In-Reply-To: <4765F444.8010705@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197870523 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36849 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13970 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Lachlan McIlroy wrote: > Hey hold on there buddy! We may need to reactivate this code to fix some > performance issues. I've acttually got this code working and proven that > it is one way to fix some of the NAS/NFS issues we have. > > The little comment that reads "reference cache not needed for NFS in 2.6" > is wrong - we do need it or something like it. So, the whole reason this was not built for 2.6 was that ostensibly the 2.6 kernel already did this sort of caching for nfs. But, last time I looked I didn't see anything obvious. Anybody know? :) -Eric > Donald Douwsma wrote: >> Remove the xfs_refcache, it was only needed while we were still building >> for >> 2.4 kernels. >> >> > > From owner-xfs@oss.sgi.com Sun Dec 16 22:56:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 22:56: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.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBH6uULD002371 for ; Sun, 16 Dec 2007 22:56:31 -0800 X-ASG-Debug-ID: 1197874599-2be000320000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F2E8E48DD3C; Sun, 16 Dec 2007 22:56:40 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id oT7WtMZbbGzp6tr5; Sun, 16 Dec 2007 22:56:40 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBH6uYF3001178 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 17 Dec 2007 07:56:34 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBH6uXRG001176; Mon, 17 Dec 2007 07:56:33 +0100 Date: Mon, 17 Dec 2007 07:56:33 +0100 From: Christoph Hellwig To: Vlad Apostolov Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] cleanup fix handling Subject: Re: [PATCH 1/2] cleanup fix handling Message-ID: <20071217065633.GA1093@lst.de> References: <20071214202511.GA23248@lst.de> <4765B82F.3020708@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4765B82F.3020708@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1197874602 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36854 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13971 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Mon, Dec 17, 2007 at 10:43:43AM +1100, Vlad Apostolov wrote: > It is looking good Christoph, > > I will check in the patch in the xfs dev tree. Btw, I typoed the subject and it should be "cleanup fid handling" of course. If you don't mind please check it in with the correct subject. From owner-xfs@oss.sgi.com Sun Dec 16 23:14:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 23:14: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.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBH7ER7t004104 for ; Sun, 16 Dec 2007 23:14:31 -0800 X-ASG-Debug-ID: 1197875668-58c101c50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 380941169F0C; Sun, 16 Dec 2007 23:14:28 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id 1qaxBLOmPQqSLySl; Sun, 16 Dec 2007 23:14:28 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J4ABH-00031O-6k; Mon, 17 Dec 2007 07:14:27 +0000 Date: Mon, 17 Dec 2007 07:14:27 +0000 From: Christoph Hellwig To: Lachlan McIlroy Cc: Donald Douwsma , xfs-oss , gnb@sgi.com X-ASG-Orig-Subj: Re: [review] Remove the xfs refcache Subject: Re: [review] Remove the xfs refcache Message-ID: <20071217071426.GA11462@infradead.org> References: <4765EC66.5020202@sgi.com> <4765F444.8010705@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4765F444.8010705@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197875680 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36855 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13972 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Dec 17, 2007 at 03:00:04PM +1100, Lachlan McIlroy wrote: > Hey hold on there buddy! We may need to reactivate this code to fix some > performance issues. I've acttually got this code working and proven that > it is one way to fix some of the NAS/NFS issues we have. > > The little comment that reads "reference cache not needed for NFS in 2.6" > is wrong - we do need it or something like it. Not in XFS, though. This thing needs to be done genericly in NFSD. Greg has been working on an open files cache in nfsd which should be helping this. Adding a cache like this back into XFS will get my veto (at least for mainline where I have a bit of a say :)) From owner-xfs@oss.sgi.com Sun Dec 16 23:15:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 23:15:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBH7FaqZ004379 for ; Sun, 16 Dec 2007 23:15:39 -0800 X-ASG-Debug-ID: 1197875747-7bf500160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8C008116A1EF; Sun, 16 Dec 2007 23:15:48 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id xBD1HHfi8VWJeVrB; Sun, 16 Dec 2007 23:15:48 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J4ACY-00031v-Tb; Mon, 17 Dec 2007 07:15:47 +0000 Date: Mon, 17 Dec 2007 07:15:46 +0000 From: Christoph Hellwig To: Eric Sandeen Cc: lachlan@sgi.com, Donald Douwsma , xfs-oss X-ASG-Orig-Subj: Re: [review] Remove the xfs refcache Subject: Re: [review] Remove the xfs refcache Message-ID: <20071217071546.GB11462@infradead.org> References: <4765EC66.5020202@sgi.com> <4765F444.8010705@sgi.com> <47660DB7.5000104@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47660DB7.5000104@sandeen.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197875748 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36855 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13973 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 Sun, Dec 16, 2007 at 11:48:39PM -0600, Eric Sandeen wrote: > Lachlan McIlroy wrote: > > Hey hold on there buddy! We may need to reactivate this code to fix some > > performance issues. I've acttually got this code working and proven that > > it is one way to fix some of the NAS/NFS issues we have. > > > > The little comment that reads "reference cache not needed for NFS in 2.6" > > is wrong - we do need it or something like it. > > So, the whole reason this was not built for 2.6 was that ostensibly the > 2.6 kernel already did this sort of caching for nfs. But, last time I > looked I didn't see anything obvious. Anybody know? :) nfsd in 2.6 keeps the inodes around, which is 90% of what the open files cache did. Now what it also does is to not release preallocations everytime but keep them while the inode is in the refcache. For that we'll need some additional support, and the best would be an open files cache like the one Greg has been hacking on for quite a while. From owner-xfs@oss.sgi.com Sun Dec 16 23:25:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 23:25: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=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBH7P7F3005266 for ; Sun, 16 Dec 2007 23:25:12 -0800 Received: from hole.melbourne.sgi.com (hole.melbourne.sgi.com [134.14.55.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA04048; Mon, 17 Dec 2007 18:25:13 +1100 Received: by hole.melbourne.sgi.com (Postfix, from userid 16345) id 6BDE61C08706A; Mon, 17 Dec 2007 18:39:17 +1100 (EST) Date: Mon, 17 Dec 2007 18:39:17 +1100 From: Greg Banks To: Christoph Hellwig Cc: Lachlan McIlroy , Donald Douwsma , xfs-oss Subject: Re: [review] Remove the xfs refcache Message-ID: <20071217073917.GA19445@sgi.com> References: <4765EC66.5020202@sgi.com> <4765F444.8010705@sgi.com> <20071217071426.GA11462@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071217071426.GA11462@infradead.org> User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: ClamAV 0.91.2/5152/Sun Dec 16 16:37:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13974 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@sgi.com Precedence: bulk X-list: xfs On Mon, Dec 17, 2007 at 07:14:27AM +0000, Christoph Hellwig wrote: > On Mon, Dec 17, 2007 at 03:00:04PM +1100, Lachlan McIlroy wrote: > > Hey hold on there buddy! We may need to reactivate this code to fix some > > performance issues. I've acttually got this code working and proven that > > it is one way to fix some of the NAS/NFS issues we have. > > > > The little comment that reads "reference cache not needed for NFS in 2.6" > > is wrong - we do need it or something like it. > > Not in XFS, though. This thing needs to be done genericly in NFSD. > Greg has been working on an open files cache in nfsd which should be > helping this. BTW, status on that: The current implementation has mutated into a filehandle-to-dentry mapping cache, because that helps some metadata-heavy workloads too. I've been testing it these last few weeks at a customer site, and it's been useful, but there are still some issues to be worked out before I can post it. > Adding a cache like this back into XFS will get my veto (at least for > mainline where I have a bit of a say :)) Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. Apparently, I'm Bedevere. Which MPHG character are you? I don't speak for SGI. From owner-xfs@oss.sgi.com Mon Dec 17 05:28:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 05:28:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBHDSjrx007357 for ; Mon, 17 Dec 2007 05:28:47 -0800 X-ASG-Debug-ID: 1197898134-66a700440000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E089C116EDAD for ; Mon, 17 Dec 2007 05:28:55 -0800 (PST) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id MpGGme7IF4CtuVP0 for ; Mon, 17 Dec 2007 05:28:55 -0800 (PST) Received: from nb27steigerwald.qs.de (unknown [212.204.70.254]) by mail.lichtvoll.de (Postfix) with ESMTP id 1C3E95AE80 for ; Mon, 17 Dec 2007 14:29:00 +0100 (CET) From: Martin Steigerwald To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Installing grub onto a system with XFS root fs Subject: Re: Installing grub onto a system with XFS root fs Date: Mon, 17 Dec 2007 14:28:51 +0100 User-Agent: KMail/1.9.7 References: <20071217004945.GA13335@jdc.jasonjgw.net> (sfid-20071217_102458_420553_1ADB1FF4) In-Reply-To: <20071217004945.GA13335@jdc.jasonjgw.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712171428.51831.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1197898137 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0706 1.0000 -1.5713 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.57 X-Barracuda-Spam-Status: No, SCORE=-1.57 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36879 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5155/Mon Dec 17 04:02:21 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13975 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Hello Jason, Am Montag 17 Dezember 2007 schrieb Jason White: > I am trying to install Grub onto a system with a single XFS partition > serving as both / and /boot. > > Distribution: Debian Unstable (Sid). > Architecture: x86_64 > > When I run grub-install I get: > Searching for GRUB installation directory ... found: /boot/grub > Due to a bug in xfs_freeze, the following command might produce a > segmentation fault when /boot/grub is not in an XFS filesystem. This > error is harmless and can be ignored. > > At this point the install script hangs and the only way to recover is > to reboot the machine (with a hard reset). Needless to say, Grub isn't > installed. > > Any suggestions? Using grub shell manually always worked for me: - grub - find /boot/grub/menu.lst - root - setup for example (hd0,0) for first harddisks MBR Remember to copy over the contents of /usr/lib/grub/i386-pc to /boot before you do a manual installation. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Mon Dec 17 05:39:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 05:39:15 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_210, J_CHICKENPOX_29,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBHDd4ZS008206 for ; Mon, 17 Dec 2007 05:39:06 -0800 X-ASG-Debug-ID: 1197898750-240300570000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sargon.lncsa.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 99B6248F54D for ; Mon, 17 Dec 2007 05:39:11 -0800 (PST) Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by cuda.sgi.com with ESMTP id k1Krrb3pUZ8GFTBl for ; Mon, 17 Dec 2007 05:39:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id DEB223026401 for ; Mon, 17 Dec 2007 14:39:07 +0100 (CET) X-Virus-Scanned: ClamAV 0.91.2/5155/Mon Dec 17 04:02:21 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2l8Z8xzLdFi5 for ; Mon, 17 Dec 2007 14:39:07 +0100 (CET) Received: by sargon.lncsa.com (Postfix, from userid 1053) id BE1FE3025A37; Mon, 17 Dec 2007 14:39:07 +0100 (CET) Date: Mon, 17 Dec 2007 14:39:07 +0100 From: Laurent Caron To: xfs@oss.sgi.com X-ASG-Orig-Subj: Issue with 2.6.23 and drbd 8.0.7 Subject: Issue with 2.6.23 and drbd 8.0.7 Message-ID: <20071217143655.chiehahh@trusted.lncsa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-11) X-Barracuda-Connect: sargon.lncsa.com[212.99.8.251] X-Barracuda-Start-Time: 1197898753 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36880 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 13976 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lcaron@lncsa.com Precedence: bulk X-list: xfs Hi, I'm still experiencing a strange behavior on one of my DRBD setup. It basically consists in: 2 servers with XFS filesystems on top of DRBD, itself on top of MD (aka soft raid). The two servers exhibit the same behavior. This strange behavior might appear between 1 day and 3 weeks after having started the machines. Slab debugging is turned on. CONFIG_SLAB=y CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_SLAB_LEAK=y Do anyone have a clue about that problem? I already posted about it some time ago, and was asked to turn slab debugging on. Thanks Laurent ---------------------------------------------------------------------------- $ lspci 00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev b1) 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 2 (rev b1) 00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 (rev b1) 00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 (rev b1) 00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 (rev b1) 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev b1) 00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 (rev b1) 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1) 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1) 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1) 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1) 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09) 00:1c.1 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 2 (rev 09) 00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09) 00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09) 00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09) 00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09) 00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9) 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09) 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09) 01:03.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) 01:04.0 System peripheral: Compaq Computer Corporation Integrated Lights Out Controller (rev 03) 01:04.2 System peripheral: Compaq Computer Corporation Integrated Lights Out Processor (rev 03) 01:04.4 USB Controller: Hewlett-Packard Company Proliant iLO2 virtual USB controller 01:04.6 IPMI SMIC interface: Hewlett-Packard Company Proliant iLO2 virtual UART 02:00.0 PCI bridge: Broadcom EPB PCI-Express to PCI-X Bridge (rev c3) 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 04:00.0 PCI bridge: Broadcom EPB PCI-Express to PCI-X Bridge (rev c3) 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 06:00.0 RAID bus controller: Hewlett-Packard Company Smart Array Controller (rev 01) 09:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01) 09:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01) 0a:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01) 0a:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 (rev 01) 0a:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01) 11:00.0 PCI bridge: Intel Corporation 6702PXH PCI Express-to-PCI Bridge A (rev 09) 12:01.0 PCI bridge: Pericom Semiconductor PI7C21P100 PCI to PCI Bridge (rev 01) 13:04.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (Copper) (rev 03) 13:04.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (Copper) (rev 03) 13:06.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (Copper) (rev 03) 13:06.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (Copper) (rev 03) ----------------------------------------------------------------------------- $ cat /etc/sysctl.conf net.ipv4.tcp_syncookies=0 net.ipv4.conf.default.forwarding=1 kernel.shmall = 2097152 kernel.shmmax = 1147483648 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 8192 174760 2097152 net.ipv4.tcp_wmem = 8192 174760 2097152 net.ipv4.tcp_window_scaling = 0 net.ipv4.tcp_ecn=0 vm.swappiness = 60 vm.dirty_background_ratio = 3 vm.dirty_ratio = 40 ----------------------------------------------------------------------------- $ grep -i xfs /var/log/syslog | wc -l 138 ------------------------------------------------------------------------------ $ cat /proc/drbd version: 8.0.7 (api:86/proto:86) GIT-hash: cf14288833afe95db396075f8530a5960d29e498 build by root@picsou, 2007-11-27 17:02:26 0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r--- ns:155783300 nr:0 dw:155790066 dr:550407420 al:5567705 bm:2877 lo:0 pe:0 ua:0 ap:0 resync: used:0/31 hits:13073 misses:1356 starving:0 dirty:0 changed:1356 act_log: used:0/509 hits:36066841 misses:7287481 starving:0 dirty:1719776 changed:5567705 ------------------------------------------------------------------------------ $ cat /var/log/syslog (partial) Dec 16 01:12:25 mailserver-1 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:25 mailserver-1 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:25 mailserver-1 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:25 mailserver-1 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:25 mailserver-1 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:25 mailserver-1 kernel: Normal per-cpu: Dec 16 01:12:25 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 35 Cold: hi: 62, btch: 15 usd: 56 Dec 16 01:12:25 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 12 Cold: hi: 62, btch: 15 usd: 57 Dec 16 01:12:25 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 57 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 92 Cold: hi: 62, btch: 15 usd: 53 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 7 Cold: hi: 62, btch: 15 usd: 52 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 51 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 37 Cold: hi: 62, btch: 15 usd: 48 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 12 Cold: hi: 62, btch: 15 usd: 49 Dec 16 01:12:27 mailserver-1 kernel: HighMem per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 130 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 13 Cold: hi: 62, btch: 15 usd: 9 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 7 Cold: hi: 62, btch: 15 usd: 5 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 182 Cold: hi: 62, btch: 15 usd: 5 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 36 Cold: hi: 62, btch: 15 usd: 14 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 42 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 159 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 42 Cold: hi: 62, btch: 15 usd: 14 Dec 16 01:12:27 mailserver-1 kernel: Active:503378 inactive:8864 dirty:159 writeback:0 unstable:0 Dec 16 01:12:27 mailserver-1 kernel: free:2397083 slab:24412 mapped:6930 pagetables:2002 bounce:0 Dec 16 01:12:27 mailserver-1 kernel: DMA free:3532kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:20 all_unreclaimable? yes Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 01:12:27 mailserver-1 kernel: Normal free:3692kB min:3744kB low:4680kB high:5616kB active:64kB inactive:0kB present:894080kB pages_scanned:13 all_unreclaimable? no Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 01:12:27 mailserver-1 kernel: HighMem free:9581108kB min:512kB low:13456kB high:26404kB active:2013452kB inactive:35524kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 01:12:27 mailserver-1 kernel: DMA: 5*4kB 11*8kB 7*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB Dec 16 01:12:27 mailserver-1 kernel: Normal: 195*4kB 82*8kB 5*16kB 9*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3788kB Dec 16 01:12:27 mailserver-1 kernel: HighMem: 37376*4kB 104969*8kB 97167*16kB 61944*32kB 34197*64kB 13138*128kB 3479*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9580920kB Dec 16 01:12:27 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 01:12:27 mailserver-1 kernel: Free swap = 1441668kB Dec 16 01:12:27 mailserver-1 kernel: Total swap = 1441776kB Dec 16 01:12:27 mailserver-1 kernel: Free swap: 1441668kB Dec 16 01:12:27 mailserver-1 kernel: syslog-ng invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Dec 16 01:12:27 mailserver-1 kernel: [] out_of_memory+0x69/0x1a4 Dec 16 01:12:27 mailserver-1 kernel: [] __alloc_pages+0x20a/0x291 Dec 16 01:12:27 mailserver-1 kernel: [] __capable+0xc/0x1f Dec 16 01:12:27 mailserver-1 kernel: [] __get_free_pages+0x39/0x47 Dec 16 01:12:27 mailserver-1 kernel: [] __pollwait+0x44/0xac Dec 16 01:12:27 mailserver-1 kernel: [] unix_poll+0x17/0x8b Dec 16 01:12:27 mailserver-1 kernel: [] sock_poll+0xc/0xe Dec 16 01:12:27 mailserver-1 kernel: [] do_sys_poll+0x19a/0x327 Dec 16 01:12:27 mailserver-1 kernel: [] __pollwait+0x0/0xac Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] sys_poll+0x34/0x37 Dec 16 01:12:27 mailserver-1 kernel: [] sysenter_past_esp+0x6b/0xa1 Dec 16 01:12:27 mailserver-1 kernel: ======================= Dec 16 01:12:27 mailserver-1 kernel: Mem-info: Dec 16 01:12:27 mailserver-1 kernel: DMA per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: Normal per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 35 Cold: hi: 62, btch: 15 usd: 56 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 12 Cold: hi: 62, btch: 15 usd: 57 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 57 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 92 Cold: hi: 62, btch: 15 usd: 53 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 7 Cold: hi: 62, btch: 15 usd: 52 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 53 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 37 Cold: hi: 62, btch: 15 usd: 48 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 12 Cold: hi: 62, btch: 15 usd: 49 Dec 16 01:12:27 mailserver-1 kernel: HighMem per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 130 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 13 Cold: hi: 62, btch: 15 usd: 9 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 7 Cold: hi: 62, btch: 15 usd: 5 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 182 Cold: hi: 62, btch: 15 usd: 5 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 36 Cold: hi: 62, btch: 15 usd: 14 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 42 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 159 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 42 Cold: hi: 62, btch: 15 usd: 14 Dec 16 01:12:27 mailserver-1 kernel: Active:503378 inactive:8864 dirty:159 writeback:0 unstable:0 Dec 16 01:12:27 mailserver-1 kernel: free:2397083 slab:24412 mapped:6930 pagetables:2002 bounce:0 Dec 16 01:12:27 mailserver-1 kernel: DMA free:3532kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:20 all_unreclaimable? yes Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 01:12:27 mailserver-1 kernel: Normal free:3692kB min:3744kB low:4680kB high:5616kB active:64kB inactive:0kB present:894080kB pages_scanned:130 all_unreclaimable? yes Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 01:12:27 mailserver-1 kernel: HighMem free:9581108kB min:512kB low:13456kB high:26404kB active:2013452kB inactive:35524kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 01:12:27 mailserver-1 kernel: DMA: 5*4kB 11*8kB 7*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB Dec 16 01:12:27 mailserver-1 kernel: Normal: 195*4kB 82*8kB 5*16kB 9*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3788kB Dec 16 01:12:27 mailserver-1 kernel: HighMem: 37376*4kB 104969*8kB 97167*16kB 61944*32kB 34197*64kB 13138*128kB 3479*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9580920kB Dec 16 01:12:27 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 01:12:27 mailserver-1 kernel: Free swap = 1441668kB Dec 16 01:12:27 mailserver-1 kernel: Total swap = 1441776kB Dec 16 01:12:27 mailserver-1 kernel: Free swap: 1441668kB Dec 16 01:12:27 mailserver-1 kernel: 3342335 pages of RAM Dec 16 01:12:27 mailserver-1 kernel: 3112959 pages of HIGHMEM Dec 16 01:12:27 mailserver-1 kernel: 224378 reserved pages Dec 16 01:12:27 mailserver-1 kernel: 230264 pages shared Dec 16 01:12:27 mailserver-1 kernel: 0 pages swap cached Dec 16 01:12:27 mailserver-1 kernel: 159 pages dirty Dec 16 01:12:27 mailserver-1 kernel: 0 pages writeback Dec 16 01:12:27 mailserver-1 kernel: 6930 pages mapped Dec 16 01:12:27 mailserver-1 kernel: 24412 pages slab Dec 16 01:12:27 mailserver-1 kernel: 2002 pages pagetables Dec 16 01:12:27 mailserver-1 kernel: Out of memory: kill process 18429 (spamd) score 13454 or a child Dec 16 01:12:27 mailserver-1 kernel: Killed process 18429 (spamd) Dec 16 01:12:27 mailserver-1 kernel: 3342335 pages of RAM Dec 16 01:12:27 mailserver-1 kernel: 3112959 pages of HIGHMEM Dec 16 01:12:27 mailserver-1 kernel: 224378 reserved pages Dec 16 01:12:27 mailserver-1 kernel: 225585 pages shared Dec 16 01:12:27 mailserver-1 kernel: 0 pages swap cached Dec 16 01:12:27 mailserver-1 kernel: 159 pages dirty Dec 16 01:12:27 mailserver-1 kernel: 0 pages writeback Dec 16 01:12:27 mailserver-1 kernel: 6930 pages mapped Dec 16 01:12:27 mailserver-1 kernel: 24412 pages slab Dec 16 01:12:27 mailserver-1 kernel: 1953 pages pagetables Dec 16 01:12:27 mailserver-1 kernel: Out of memory: kill process 12086 (spamd) score 13244 or a child Dec 16 01:12:27 mailserver-1 kernel: Killed process 12086 (spamd) Dec 16 01:12:27 mailserver-1 kernel: named invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Dec 16 01:12:27 mailserver-1 kernel: [] out_of_memory+0x69/0x1a4 Dec 16 01:12:27 mailserver-1 kernel: [] __alloc_pages+0x20a/0x291 Dec 16 01:12:27 mailserver-1 kernel: [] __get_free_pages+0x39/0x47 Dec 16 01:12:27 mailserver-1 kernel: [] __pollwait+0x44/0xac Dec 16 01:12:27 mailserver-1 kernel: [] datagram_poll+0x14/0xb1 Dec 16 01:12:27 mailserver-1 kernel: [] udp_poll+0x10/0xd5 Dec 16 01:12:27 mailserver-1 kernel: [] sock_poll+0xc/0xe Dec 16 01:12:27 mailserver-1 kernel: [] do_select+0x229/0x3c9 Dec 16 01:12:27 mailserver-1 kernel: [] __pollwait+0x0/0xac Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] core_sys_select+0x285/0x2a2 Dec 16 01:12:27 mailserver-1 kernel: [] __wake_up+0x32/0x43 Dec 16 01:12:27 mailserver-1 kernel: [] wake_futex+0x3b/0x45 Dec 16 01:12:27 mailserver-1 kernel: [] futex_wake+0xa5/0xaf Dec 16 01:12:27 mailserver-1 kernel: [] do_futex+0x7c/0x937 Dec 16 01:12:27 mailserver-1 kernel: [] sys_select+0xd6/0x187 Dec 16 01:12:27 mailserver-1 kernel: [] sys_futex+0xc2/0xd4 Dec 16 01:12:27 mailserver-1 kernel: [] sys_read+0x5f/0x67 Dec 16 01:12:27 mailserver-1 kernel: [] sysenter_past_esp+0x6b/0xa1 Dec 16 01:12:27 mailserver-1 kernel: ======================= Dec 16 01:12:27 mailserver-1 kernel: Mem-info: Dec 16 01:12:27 mailserver-1 kernel: DMA per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: Normal per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 67 Cold: hi: 62, btch: 15 usd: 56 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 12 Cold: hi: 62, btch: 15 usd: 57 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 57 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 92 Cold: hi: 62, btch: 15 usd: 53 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 39 Cold: hi: 62, btch: 15 usd: 52 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 20 Cold: hi: 62, btch: 15 usd: 53 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 38 Cold: hi: 62, btch: 15 usd: 58 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 17 Cold: hi: 62, btch: 15 usd: 49 Dec 16 01:12:27 mailserver-1 kernel: HighMem per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 166 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 29 Cold: hi: 62, btch: 15 usd: 9 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 7 Cold: hi: 62, btch: 15 usd: 5 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 182 Cold: hi: 62, btch: 15 usd: 5 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 174 Cold: hi: 62, btch: 15 usd: 14 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 42 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 159 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 42 Cold: hi: 62, btch: 15 usd: 14 Dec 16 01:12:27 mailserver-1 kernel: Active:488537 inactive:8843 dirty:159 writeback:0 unstable:0 Dec 16 01:12:27 mailserver-1 kernel: free:2411717 slab:24412 mapped:6930 pagetables:1953 bounce:0 Dec 16 01:12:27 mailserver-1 kernel: DMA free:3568kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:15 all_unreclaimable? yes Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 01:12:27 mailserver-1 kernel: Normal free:3692kB min:3744kB low:4680kB high:5616kB active:64kB inactive:0kB present:894080kB pages_scanned:132 all_unreclaimable? yes Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 01:12:27 mailserver-1 kernel: HighMem free:9639608kB min:512kB low:13456kB high:26404kB active:1954088kB inactive:35524kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 01:12:27 mailserver-1 kernel: DMA: 16*4kB 15*8kB 7*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Dec 16 01:12:27 mailserver-1 kernel: Normal: 195*4kB 106*8kB 5*16kB 9*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3980kB Dec 16 01:12:27 mailserver-1 kernel: HighMem: 50533*4kB 105248*8kB 97284*16kB 61970*32kB 34204*64kB 13139*128kB 3481*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9639572kB Dec 16 01:12:27 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 01:12:27 mailserver-1 kernel: Free swap = 1441668kB Dec 16 01:12:27 mailserver-1 kernel: Total swap = 1441776kB Dec 16 01:12:27 mailserver-1 kernel: Free swap: 1441668kB Dec 16 01:12:27 mailserver-1 kernel: syslog-ng invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Dec 16 01:12:27 mailserver-1 kernel: [] out_of_memory+0x69/0x1a4 Dec 16 01:12:27 mailserver-1 kernel: [] __alloc_pages+0x20a/0x291 Dec 16 01:12:27 mailserver-1 kernel: [] __capable+0xc/0x1f Dec 16 01:12:27 mailserver-1 kernel: [] __get_free_pages+0x39/0x47 Dec 16 01:12:27 mailserver-1 kernel: [] __pollwait+0x44/0xac Dec 16 01:12:27 mailserver-1 kernel: [] unix_poll+0x17/0x8b Dec 16 01:12:27 mailserver-1 kernel: [] sock_poll+0xc/0xe Dec 16 01:12:27 mailserver-1 kernel: [] do_sys_poll+0x19a/0x327 Dec 16 01:12:27 mailserver-1 kernel: [] __pollwait+0x0/0xac Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] sys_poll+0x34/0x37 Dec 16 01:12:27 mailserver-1 kernel: [] sysenter_past_esp+0x6b/0xa1 Dec 16 01:12:27 mailserver-1 kernel: ======================= Dec 16 01:12:27 mailserver-1 kernel: Mem-info: Dec 16 01:12:27 mailserver-1 kernel: DMA per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: Normal per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 67 Cold: hi: 62, btch: 15 usd: 56 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 12 Cold: hi: 62, btch: 15 usd: 57 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 57 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 92 Cold: hi: 62, btch: 15 usd: 53 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 39 Cold: hi: 62, btch: 15 usd: 52 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 20 Cold: hi: 62, btch: 15 usd: 53 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 38 Cold: hi: 62, btch: 15 usd: 58 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 17 Cold: hi: 62, btch: 15 usd: 49 Dec 16 01:12:27 mailserver-1 kernel: HighMem per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 166 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 29 Cold: hi: 62, btch: 15 usd: 9 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 11 Cold: hi: 62, btch: 15 usd: 5 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 184 Cold: hi: 62, btch: 15 usd: 5 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 174 Cold: hi: 62, btch: 15 usd: 14 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 42 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 159 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 42 Cold: hi: 62, btch: 15 usd: 14 Dec 16 01:12:27 mailserver-1 kernel: Active:488537 inactive:8856 dirty:159 writeback:0 unstable:0 Dec 16 01:12:27 mailserver-1 kernel: free:2411708 slab:24412 mapped:6930 pagetables:1953 bounce:0 Dec 16 01:12:27 mailserver-1 kernel: DMA free:3532kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:47 all_unreclaimable? yes Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 01:12:27 mailserver-1 kernel: Normal free:3692kB min:3744kB low:4680kB high:5616kB active:64kB inactive:0kB present:894080kB pages_scanned:165 all_unreclaimable? yes Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 01:12:27 mailserver-1 kernel: HighMem free:9639608kB min:512kB low:13456kB high:26404kB active:1954088kB inactive:35524kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 01:12:27 mailserver-1 kernel: DMA: 0*4kB 15*8kB 7*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3496kB Dec 16 01:12:27 mailserver-1 kernel: Normal: 195*4kB 106*8kB 5*16kB 9*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3980kB Dec 16 01:12:27 mailserver-1 kernel: HighMem: 50533*4kB 105248*8kB 97284*16kB 61970*32kB 34204*64kB 13139*128kB 3481*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9639572kB Dec 16 01:12:27 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 01:12:27 mailserver-1 kernel: Free swap = 1441668kB Dec 16 01:12:27 mailserver-1 kernel: Total swap = 1441776kB Dec 16 01:12:27 mailserver-1 kernel: Free swap: 1441668kB Dec 16 01:12:27 mailserver-1 kernel: 3342335 pages of RAM Dec 16 01:12:27 mailserver-1 kernel: 3112959 pages of HIGHMEM Dec 16 01:12:27 mailserver-1 kernel: 224378 reserved pages Dec 16 01:12:27 mailserver-1 kernel: 220898 pages shared Dec 16 01:12:27 mailserver-1 kernel: 0 pages swap cached Dec 16 01:12:27 mailserver-1 kernel: 159 pages dirty Dec 16 01:12:27 mailserver-1 kernel: 0 pages writeback Dec 16 01:12:27 mailserver-1 kernel: 6930 pages mapped Dec 16 01:12:27 mailserver-1 kernel: 24412 pages slab Dec 16 01:12:27 mailserver-1 kernel: 1953 pages pagetables Dec 16 01:12:27 mailserver-1 kernel: Out of memory: kill process 1324 (amavisd-new) score 8082 or a child Dec 16 01:12:27 mailserver-1 kernel: Killed process 1324 (amavisd-new) Dec 16 01:12:27 mailserver-1 kernel: named invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Dec 16 01:12:27 mailserver-1 kernel: [] out_of_memory+0x69/0x1a4 Dec 16 01:12:27 mailserver-1 kernel: [] __alloc_pages+0x20a/0x291 Dec 16 01:12:27 mailserver-1 kernel: [] __get_free_pages+0x39/0x47 Dec 16 01:12:27 mailserver-1 kernel: [] __pollwait+0x44/0xac Dec 16 01:12:27 mailserver-1 kernel: [] datagram_poll+0x14/0xb1 Dec 16 01:12:27 mailserver-1 kernel: [] udp_poll+0x10/0xd5 Dec 16 01:12:27 mailserver-1 kernel: [] sock_poll+0xc/0xe Dec 16 01:12:27 mailserver-1 kernel: [] do_select+0x229/0x3c9 Dec 16 01:12:27 mailserver-1 kernel: [] __pollwait+0x0/0xac Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] core_sys_select+0x285/0x2a2 Dec 16 01:12:27 mailserver-1 kernel: [] __wake_up+0x32/0x43 Dec 16 01:12:27 mailserver-1 kernel: [] wake_futex+0x3b/0x45 Dec 16 01:12:27 mailserver-1 kernel: [] futex_wake+0xa5/0xaf Dec 16 01:12:27 mailserver-1 kernel: [] do_futex+0x7c/0x937 Dec 16 01:12:27 mailserver-1 kernel: [] sys_select+0xd6/0x187 Dec 16 01:12:27 mailserver-1 kernel: [] sys_futex+0xc2/0xd4 Dec 16 01:12:27 mailserver-1 kernel: [] sys_read+0x5f/0x67 Dec 16 01:12:27 mailserver-1 kernel: [] sysenter_past_esp+0x6b/0xa1 Dec 16 01:12:27 mailserver-1 kernel: ======================= Dec 16 01:12:27 mailserver-1 kernel: Mem-info: Dec 16 01:12:27 mailserver-1 kernel: DMA per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 01:12:27 mailserver-1 kernel: Normal per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 67 Cold: hi: 62, btch: 15 usd: 56 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 12 Cold: hi: 62, btch: 15 usd: 57 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 57 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 92 Cold: hi: 62, btch: 15 usd: 53 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 39 Cold: hi: 62, btch: 15 usd: 52 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 20 Cold: hi: 62, btch: 15 usd: 53 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 50 Cold: hi: 62, btch: 15 usd: 58 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 17 Cold: hi: 62, btch: 15 usd: 49 Dec 16 01:12:27 mailserver-1 kernel: HighMem per-cpu: Dec 16 01:12:27 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 166 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 29 Cold: hi: 62, btch: 15 usd: 9 Dec 16 01:12:27 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 11 Cold: hi: 62, btch: 15 usd: 5 Dec 16 01:12:27 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 184 Cold: hi: 62, btch: 15 usd: 5 Dec 16 01:12:27 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 174 Cold: hi: 62, btch: 15 usd: 14 Dec 16 01:12:27 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 42 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 183 Cold: hi: 62, btch: 15 usd: 8 Dec 16 01:12:27 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 42 Cold: hi: 62, btch: 15 usd: 14 Dec 16 01:12:27 mailserver-1 kernel: Active:486985 inactive:8858 dirty:159 writeback:0 unstable:0 Dec 16 01:12:27 mailserver-1 kernel: free:2413203 slab:24412 mapped:6930 pagetables:1953 bounce:0 Dec 16 01:12:27 mailserver-1 kernel: DMA free:3532kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:30 all_unreclaimable? yes Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 01:12:27 mailserver-1 kernel: Normal free:3692kB min:3744kB low:4680kB high:5616kB active:64kB inactive:0kB present:894080kB pages_scanned:198 all_unreclaimable? yes Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 01:12:27 mailserver-1 kernel: 3342335 pages of RAM Dec 16 01:12:27 mailserver-1 kernel: 3112959 pages of HIGHMEM Dec 16 01:12:27 mailserver-1 kernel: 224378 reserved pages Dec 16 01:12:27 mailserver-1 kernel: 219240 pages shared Dec 16 01:12:27 mailserver-1 kernel: 0 pages swap cached Dec 16 01:12:27 mailserver-1 kernel: 159 pages dirty Dec 16 01:12:27 mailserver-1 kernel: 0 pages writeback Dec 16 01:12:27 mailserver-1 kernel: 6930 pages mapped Dec 16 01:12:27 mailserver-1 kernel: 24412 pages slab Dec 16 01:12:27 mailserver-1 kernel: 1953 pages pagetables Dec 16 01:12:27 mailserver-1 kernel: HighMem free:9645588kB min:512kB low:13456kB high:26404kB active:1947880kB inactive:35524kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 01:12:27 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 01:12:27 mailserver-1 kernel: DMA: 2*4kB <3>Out of memory: kill process 1530 (amavisd-new) score 8080 or a child Dec 16 01:12:27 mailserver-1 kernel: 15*8kB 7*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3504kB Dec 16 01:12:27 mailserver-1 kernel: Normal: 195*4kB 106*8kB 5*16kB 9*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3980kB Dec 16 01:12:27 mailserver-1 kernel: HighMem: 52003*4kB 105266*8kB 97289*16kB 61973*32kB 34204*64kB 13139*128kB 3481*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9645772kB Dec 16 01:12:27 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 01:12:27 mailserver-1 kernel: Free swap = 1441668kB Dec 16 01:12:27 mailserver-1 kernel: Total swap = 1441776kB Dec 16 01:12:27 mailserver-1 kernel: Free swap: 1441668kB Dec 16 01:12:27 mailserver-1 kernel: Killed process 1530 (amavisd-new) Dec 16 01:12:27 mailserver-1 kernel: syslog-ng invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Dec 16 01:12:27 mailserver-1 kernel: [] out_of_memory+0x69/0x1a4 Dec 16 01:12:27 mailserver-1 kernel: [] __alloc_pages+0x20a/0x291 Dec 16 01:12:27 mailserver-1 kernel: [] __capable+0xc/0x1f Dec 16 01:12:27 mailserver-1 kernel: [] __get_free_pages+0x39/0x47 Dec 16 01:12:27 mailserver-1 kernel: [] __pollwait+0x44/0xac Dec 16 01:12:27 mailserver-1 kernel: [] unix_poll+0x17/0x8b Dec 16 01:12:27 mailserver-1 kernel: [] sock_poll+0xc/0xe Dec 16 01:12:27 mailserver-1 kernel: [] do_sys_poll+0x19a/0x327 Dec 16 01:12:27 mailserver-1 kernel: [] __pollwait+0x0/0xac Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc Dec 16 01:12:27 mailserver-1 kernel: [] default_wake_function+0x0/0xc ...................... ..................... Dec 16 02:55:04 mailserver-1 kernel: printk: 8 messages suppressed. Dec 16 02:55:05 mailserver-1 kernel: sh invoked oom-killer: gfp_mask=0x84d0, order=0, oomkilladj=0 Dec 16 02:55:05 mailserver-1 kernel: [] out_of_memory+0x69/0x1a4 Dec 16 02:55:05 mailserver-1 kernel: [] __alloc_pages+0x20a/0x291 Dec 16 02:55:05 mailserver-1 kernel: [] __pte_alloc+0x16/0xfa Dec 16 02:55:05 mailserver-1 kernel: [] file_read_actor+0x0/0xca Dec 16 02:55:05 mailserver-1 kernel: [] handle_mm_fault+0x12b/0xca2 Dec 16 02:55:05 mailserver-1 kernel: [] xfs_iunlock+0x2a/0x6d Dec 16 02:55:05 mailserver-1 kernel: [] xfs_read+0x303/0x326 Dec 16 02:55:05 mailserver-1 kernel: [] xfs_file_aio_read+0x66/0x6e Dec 16 02:55:05 mailserver-1 kernel: [] do_sync_read+0xc7/0x10a Dec 16 02:55:05 mailserver-1 kernel: [] get_user_pages+0x285/0x363 Dec 16 02:55:05 mailserver-1 kernel: [] get_arg_page+0x42/0x8c Dec 16 02:55:05 mailserver-1 kernel: [] copy_strings+0xcd/0x173 Dec 16 02:55:05 mailserver-1 kernel: [] copy_strings_kernel+0x19/0x27 Dec 16 02:55:05 mailserver-1 kernel: [] do_execve+0xdf/0x1a4 Dec 16 02:55:05 mailserver-1 kernel: [] sys_execve+0x2f/0x7b Dec 16 02:55:05 mailserver-1 kernel: [] sysenter_past_esp+0x6b/0xa1 Dec 16 02:55:05 mailserver-1 kernel: [] wait_for_completion_timeout+0x7f/0xd6 Dec 16 02:55:05 mailserver-1 kernel: ======================= Dec 16 02:55:05 mailserver-1 kernel: Mem-info: Dec 16 02:55:05 mailserver-1 kernel: DMA per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: Normal per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 51 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 28 Cold: hi: 62, btch: 15 usd: 58 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 54 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 25 Cold: hi: 62, btch: 15 usd: 48 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 16 Cold: hi: 62, btch: 15 usd: 50 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 24 Cold: hi: 62, btch: 15 usd: 57 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 21 Cold: hi: 62, btch: 15 usd: 55 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 24 Cold: hi: 62, btch: 15 usd: 50 Dec 16 02:55:05 mailserver-1 kernel: HighMem per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 26 Cold: hi: 62, btch: 15 usd: 1 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 58 Cold: hi: 62, btch: 15 usd: 14 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 13 Cold: hi: 62, btch: 15 usd: 9 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 83 Cold: hi: 62, btch: 15 usd: 4 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 0 Cold: hi: 62, btch: 15 usd: 4 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 121 Cold: hi: 62, btch: 15 usd: 11 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 79 Cold: hi: 62, btch: 15 usd: 11 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 38 Cold: hi: 62, btch: 15 usd: 8 Dec 16 02:55:05 mailserver-1 kernel: Active:506772 inactive:7227 dirty:18 writeback:0 unstable:0 Dec 16 02:55:05 mailserver-1 kernel: free:2395747 slab:23425 mapped:6651 pagetables:1663 bounce:0 Dec 16 02:55:05 mailserver-1 kernel: DMA free:3556kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 02:55:05 mailserver-1 kernel: Normal free:3652kB min:3744kB low:4680kB high:5616kB active:104kB inactive:0kB present:894080kB pages_scanned:63 all_unreclaimable? no Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 02:55:05 mailserver-1 kernel: HighMem free:9575780kB min:512kB low:13456kB high:26404kB active:2026984kB inactive:28928kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 02:55:05 mailserver-1 kernel: DMA: 17*4kB 10*8kB 9*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3556kB Dec 16 02:55:05 mailserver-1 kernel: Normal: 138*4kB 48*8kB 38*16kB 8*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 3848kB Dec 16 02:55:05 mailserver-1 kernel: HighMem: 29918*4kB 106008*8kB 97484*16kB 62058*32kB 34230*64kB 13152*128kB 3490*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9574840kB Dec 16 02:55:05 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 02:55:05 mailserver-1 kernel: Free swap = 1441668kB Dec 16 02:55:05 mailserver-1 kernel: Total swap = 1441776kB Dec 16 02:55:05 mailserver-1 kernel: Free swap: 1441668kB Dec 16 02:55:05 mailserver-1 kernel: sh invoked oom-killer: gfp_mask=0x84d0, order=0, oomkilladj=0 Dec 16 02:55:05 mailserver-1 kernel: [] out_of_memory+0x69/0x1a4 Dec 16 02:55:05 mailserver-1 kernel: [] __alloc_pages+0x20a/0x291 Dec 16 02:55:05 mailserver-1 kernel: i: 186, btch: 31 usd: 24 Cold: hi: 62, btch: 15 usd: 57 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 21 Cold: hi: 62, btch: 15 usd: 55 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 24 Cold: hi: 62, btch: 15 usd: 50 Dec 16 02:55:05 mailserver-1 kernel: HighMem per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 26 Cold: hi: 62, btch: 15 usd: 1 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 58 Cold: hi: 62, btch: 15 usd: 14 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 13 Cold: hi: 62, btch: 15 usd: 9 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 83 Cold: hi: 62, btch: 15 usd: 4 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 4 Cold: hi: 62, btch: 15 usd: 4 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 121 Cold: hi: 62, btch: 15 usd: 11 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 79 Cold: hi: 62, btch: 15 usd: 11 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 38 Cold: hi: 62, btch: 15 usd: 8 Dec 16 02:55:05 mailserver-1 kernel: Active:506772 inactive:7276 dirty:18 writeback:0 unstable:0 Dec 16 02:55:05 mailserver-1 kernel: free:2395747 slab:23425 mapped:6651 pagetables:1663 bounce:0 Dec 16 02:55:05 mailserver-1 kernel: DMA free:3556kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 02:55:05 mailserver-1 kernel: Normal free:3652kB min:3744kB low:4680kB high:5616kB active:104kB inactive:176kB present:894080kB pages_scanned:765 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 02:55:05 mailserver-1 kernel: HighMem free:9575780kB min:512kB low:13456kB high:26404kB active:2026984kB inactive:28928kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 02:55:05 mailserver-1 kernel: DMA: Active:506772 inactive:7276 dirty:18 writeback:0 unstable:0 Dec 16 02:55:05 mailserver-1 kernel: free:2395747 slab:23425 mapped:6651 pagetables:1663 bounce:0 Dec 16 02:55:05 mailserver-1 kernel: DMA free:3556kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 02:55:05 mailserver-1 kernel: Normal free:3652kB min:3744kB low:4680kB high:5616kB active:104kB inactive:176kB present:894080kB pages_scanned:765 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 02:55:05 mailserver-1 kernel: HighMem free:9575780kB min:512kB low:13456kB high:26404kB active:2026984kB inactive:28928kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 02:55:05 mailserver-1 kernel: DMA: 17*4kB 10*8kB 9*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3556kB Dec 16 02:55:05 mailserver-1 kernel: Normal: 138*4kB 48*8kB 38*16kB 8*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 3848kB Dec 16 02:55:05 mailserver-1 kernel: HighMem: 17*4kB 10*8kB 9*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3556kB Dec 16 02:55:05 mailserver-1 kernel: Normal: [] [] [] kunmap_atomic+0x49/0x61 Dec 16 02:55:05 mailserver-1 kernel: get_arg_page+0x42/0x8c Dec 16 02:55:05 mailserver-1 kernel: copy_strings_kernel+0x19/0x27 Dec 16 02:55:05 mailserver-1 kernel: 138*4kB 48*8kB 38*16kB 8*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 3848kB Dec 16 02:55:05 mailserver-1 kernel: HighMem: 29918*4kB 106008*8kB 97484*16kB 62058*32kB 34230*64kB 13152*128kB 3490*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9574840kB Dec 16 02:55:05 mailserver-1 kernel: 29918*4kB 106008*8kB 97484*16kB 62058*32kB 34230*64kB 13152*128kB 3490*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9574840kB Dec 16 02:55:05 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 02:55:05 mailserver-1 kernel: Free swap = 1441668kB Dec 16 02:55:05 mailserver-1 kernel: Total swap = 1441776kB Dec 16 02:55:05 mailserver-1 kernel: Free swap: 1441668kB Dec 16 02:55:05 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 02:55:05 mailserver-1 kernel: Free swap = 1441668kB Dec 16 02:55:05 mailserver-1 kernel: Total swap = 1441776kB Dec 16 02:55:05 mailserver-1 kernel: Free swap: 1441668kB Dec 16 02:55:05 mailserver-1 kernel: [] do_execve+0xdf/0x1a4 Dec 16 02:55:05 mailserver-1 kernel: [] copy_strings+0xcd/0x173 Dec 16 02:55:05 mailserver-1 kernel: [] sys_execve+0x2f/0x7b Dec 16 02:55:05 mailserver-1 kernel: [] [] sysenter_past_esp+0x6b/0xa1 Dec 16 02:55:05 mailserver-1 kernel: prio_tree_insert+0x11e/0x1e3 Dec 16 02:55:05 mailserver-1 kernel: [] copy_strings_kernel+0x19/0x27 Dec 16 02:55:05 mailserver-1 kernel: [] do_execve+0xdf/0x1a4 Dec 16 02:55:05 mailserver-1 kernel: [] [] do_page_fault+0x0/0x876 Dec 16 02:55:05 mailserver-1 kernel: wait_for_completion_timeout+0x7f/0xd6 Dec 16 02:55:05 mailserver-1 kernel: [] sys_execve+0x2f/0x7b Dec 16 02:55:05 mailserver-1 kernel: [] [] sysenter_past_esp+0x6b/0xa1 Dec 16 02:55:05 mailserver-1 kernel: do_page_fault+0x3c3/0x876 Dec 16 02:55:05 mailserver-1 kernel: [] ======================= Dec 16 02:55:05 mailserver-1 kernel: vma_prio_tree_insert+0x17/0x2a Dec 16 02:55:05 mailserver-1 kernel: Mem-info: Dec 16 02:55:05 mailserver-1 kernel: DMA per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: Normal per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 51 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 29 Cold: hi: 62, btch: 15 usd: 58 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 54 Dec 16 02:55:05 mailserver-1 kernel: [] [] CPU 3: Hot: hi: 186, btch: 31 usd: 25 Cold: hi: 62, btch: 15 usd: 48 Dec 16 02:55:05 mailserver-1 kernel: vma_link+0xab/0xc7 Dec 16 02:55:05 mailserver-1 kernel: wait_for_completion_timeout+0x7f/0xd6 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 16 Cold: hi: 62, btch: 15 usd: 52 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 24 Cold: hi: 62, btch: 15 usd: 57 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 21 Cold: hi: 62, btch: 15 usd: 55 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 24 Cold: hi: 62, btch: 15 usd: 50 Dec 16 02:55:05 mailserver-1 kernel: HighMem per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 26 Cold: hi: 62, btch: 15 usd: 1 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 58 Cold: hi: 62, btch: 15 usd: 14 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 13 Cold: hi: 62, btch: 15 usd: 9 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 83 Cold: hi: 62, btch: 15 usd: 4 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 4 Cold: hi: 62, btch: 15 usd: 4 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 121 Cold: hi: 62, btch: 15 usd: 11 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 79 Cold: hi: 62, btch: 15 usd: 11 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 38 Cold: hi: 62, btch: 15 usd: 8 Dec 16 02:55:05 mailserver-1 kernel: Active:506772 inactive:7276 dirty:18 writeback:0 unstable:0 Dec 16 02:55:05 mailserver-1 kernel: free:2395747 slab:23425 mapped:6651 pagetables:1663 bounce:0 Dec 16 02:55:05 mailserver-1 kernel: DMA free:3556kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 02:55:05 mailserver-1 kernel: ======================= Dec 16 02:55:05 mailserver-1 kernel: Mem-info: Dec 16 02:55:05 mailserver-1 kernel: Normal free:3652kB min:3744kB low:4680kB high:5616kB active:104kB inactive:176kB present:894080kB pages_scanned:765 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 02:55:05 mailserver-1 kernel: HighMem free:9575780kB min:512kB low:13456kB high:26404kB active:2026984kB inactive:28928kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 02:55:05 mailserver-1 kernel: DMA: DMA per-cpu: Dec 16 02:55:05 mailserver-1 kernel: [] 17*4kB 10*8kB 9*16kB 2*32kB 2*64kB cache_alloc_debugcheck_after+0xf3/0x169 Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3556kB Dec 16 02:55:05 mailserver-1 kernel: Normal: CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: 138*4kB 48*8kB 38*16kB 8*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 3848kB Dec 16 02:55:05 mailserver-1 kernel: HighMem: Normal per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 51 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 29 Cold: hi: 62, btch: 15 usd: 58 Dec 16 02:55:05 mailserver-1 kernel: 29918*4kB 106008*8kB 97484*16kB 62058*32kB 34230*64kB 13152*128kB 3490*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9574840kB Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 54 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 25 Cold: hi: 62, btch: 15 usd: 48 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 16 Cold: hi: 62, btch: 15 usd: 52 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 24 Cold: hi: 62, btch: 15 usd: 57 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 21 Cold: hi: 62, btch: 15 usd: 55 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 24 Cold: hi: 62, btch: 15 usd: 50 Dec 16 02:55:05 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 02:55:05 mailserver-1 kernel: Free swap = 1441668kB Dec 16 02:55:05 mailserver-1 kernel: [] HighMem per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 26 Cold: hi: 62, btch: 15 usd: 1 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 58 Cold: hi: 62, btch: 15 usd: 14 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 13 Cold: hi: 62, btch: 15 usd: 9 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 83 Cold: hi: 62, btch: 15 usd: 4 Dec 16 02:55:05 mailserver-1 kernel: vma_link+0x54/0xc7 Dec 16 02:55:05 mailserver-1 kernel: Total swap = 1441776kB Dec 16 02:55:05 mailserver-1 kernel: Free swap: 1441668kB Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 4 Cold: hi: 62, btch: 15 usd: 4 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 121 Cold: hi: 62, btch: 15 usd: 11 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 79 Cold: hi: 62, btch: 15 usd: 11 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 38 Cold: hi: 62, btch: 15 usd: 8 Dec 16 02:55:05 mailserver-1 kernel: Active:506772 inactive:7276 dirty:18 writeback:0 unstable:0 Dec 16 02:55:05 mailserver-1 kernel: free:2395747 slab:23425 mapped:6651 pagetables:1663 bounce:0 Dec 16 02:55:05 mailserver-1 kernel: DMA free:3556kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 02:55:05 mailserver-1 kernel: Normal free:3652kB min:3744kB low:4680kB high:5616kB active:104kB inactive:176kB present:894080kB pages_scanned:765 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 02:55:05 mailserver-1 kernel: HighMem free:9575780kB min:512kB low:13456kB high:26404kB active:2026984kB inactive:28928kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 02:55:05 mailserver-1 kernel: DMA: 17*4kB 10*8kB 9*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3556kB Dec 16 02:55:05 mailserver-1 kernel: Normal: 138*4kB 48*8kB 38*16kB 8*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 3848kB Dec 16 02:55:05 mailserver-1 kernel: HighMem: 29918*4kB 106008*8kB 97484*16kB 62058*32kB 34230*64kB 13152*128kB 3490*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9574840kB Dec 16 02:55:05 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 02:55:05 mailserver-1 kernel: Free swap = 1441668kB Dec 16 02:55:05 mailserver-1 kernel: Total swap = 1441776kB Dec 16 02:55:05 mailserver-1 kernel: Free swap: 1441668kB Dec 16 02:55:05 mailserver-1 kernel: [] do_page_fault+0x0/0x876 Dec 16 02:55:05 mailserver-1 kernel: [] error_code+0x72/0x78 Dec 16 02:55:05 mailserver-1 kernel: [] clear_user+0x27/0x32 Dec 16 02:55:05 mailserver-1 kernel: [] padzero+0x16/0x24 Dec 16 02:55:05 mailserver-1 kernel: [] load_elf_binary+0x7d4/0x142b Dec 16 02:55:05 mailserver-1 kernel: [] kmap_high+0x2e/0x1e2 Dec 16 02:55:05 mailserver-1 kernel: [] page_address+0x78/0x98 Dec 16 02:55:05 mailserver-1 kernel: [] copy_strings+0x169/0x173 Dec 16 02:55:05 mailserver-1 kernel: [] search_binary_handler+0x84/0x19c Dec 16 02:55:05 mailserver-1 kernel: [] do_execve+0x13b/0x1a4 Dec 16 02:55:05 mailserver-1 kernel: [] sys_execve+0x2f/0x7b Dec 16 02:55:05 mailserver-1 kernel: [] sysenter_past_esp+0x6b/0xa1 Dec 16 02:55:05 mailserver-1 kernel: [] wait_for_completion_timeout+0x7f/0xd6 Dec 16 02:55:05 mailserver-1 kernel: ======================= Dec 16 02:55:05 mailserver-1 kernel: Mem-info: Dec 16 02:55:05 mailserver-1 kernel: DMA per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Dec 16 02:55:05 mailserver-1 kernel: Normal per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 51 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 29 Cold: hi: 62, btch: 15 usd: 58 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 54 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 25 Cold: hi: 62, btch: 15 usd: 48 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 16 Cold: hi: 62, btch: 15 usd: 52 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 24 Cold: hi: 62, btch: 15 usd: 57 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 21 Cold: hi: 62, btch: 15 usd: 55 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 24 Cold: hi: 62, btch: 15 usd: 50 Dec 16 02:55:05 mailserver-1 kernel: HighMem per-cpu: Dec 16 02:55:05 mailserver-1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 26 Cold: hi: 62, btch: 15 usd: 1 Dec 16 02:55:05 mailserver-1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 58 Cold: hi: 62, btch: 15 usd: 14 Dec 16 02:55:05 mailserver-1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 13 Cold: hi: 62, btch: 15 usd: 9 Dec 16 02:55:05 mailserver-1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 83 Cold: hi: 62, btch: 15 usd: 4 Dec 16 02:55:05 mailserver-1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 4 Cold: hi: 62, btch: 15 usd: 4 Dec 16 02:55:05 mailserver-1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 121 Cold: hi: 62, btch: 15 usd: 11 Dec 16 02:55:05 mailserver-1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 79 Cold: hi: 62, btch: 15 usd: 11 Dec 16 02:55:05 mailserver-1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 38 Cold: hi: 62, btch: 15 usd: 8 Dec 16 02:55:05 mailserver-1 kernel: Active:506772 inactive:7276 dirty:18 writeback:0 unstable:0 Dec 16 02:55:05 mailserver-1 kernel: free:2395747 slab:23425 mapped:6651 pagetables:1663 bounce:0 Dec 16 02:55:05 mailserver-1 kernel: DMA free:3556kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 873 12938 12938 Dec 16 02:55:05 mailserver-1 kernel: Normal free:3652kB min:3744kB low:4680kB high:5616kB active:104kB inactive:176kB present:894080kB pages_scanned:765 all_unreclaimable? yes Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 96520 96520 Dec 16 02:55:05 mailserver-1 kernel: HighMem free:9575780kB min:512kB low:13456kB high:26404kB active:2026984kB inactive:28928kB present:12354560kB pages_scanned:0 all_unreclaimable? no Dec 16 02:55:05 mailserver-1 kernel: lowmem_reserve[]: 0 0 0 0 Dec 16 02:55:05 mailserver-1 kernel: DMA: 17*4kB 10*8kB 9*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3556kB Dec 16 02:55:05 mailserver-1 kernel: Normal: 138*4kB 48*8kB 38*16kB 8*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 3848kB Dec 16 02:55:05 mailserver-1 kernel: HighMem: 29918*4kB 106008*8kB 97484*16kB 62058*32kB 34230*64kB 13152*128kB 3490*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9574840kB Dec 16 02:55:05 mailserver-1 kernel: Swap cache: add 28, delete 28, find 0/0, race 0+0 Dec 16 02:55:05 mailserver-1 kernel: Free swap = 1441668kB Dec 16 02:55:05 mailserver-1 kernel: Total swap = 1441776kB Dec 16 02:55:05 mailserver-1 kernel: Free swap: 1441668kB Dec 16 02:55:05 mailserver-1 kernel: out_of_memory+0x69/0x1a4 Dec 16 02:55:05 mailserver-1 kernel: [] __alloc_pages+0x20a/0x291 Dec 16 02:55:05 mailserver-1 kernel: [] cache_alloc_refill+0x31b/0x5d2 Dec 16 02:55:05 mailserver-1 kernel: [] pgd_alloc+0xd7/0x1d7 Dec 16 02:55:05 mailserver-1 kernel: [] kmem_cache_alloc+0x66/0xbc Dec 16 02:55:05 mailserver-1 kernel: [] pgd_alloc+0xd7/0x1d7 Dec 16 02:55:05 mailserver-1 kernel: [] pgd_alloc+0xd7/0x1d7 Dec 16 02:55:05 mailserver-1 kernel: [] mm_init+0xa1/0xc3 Dec 16 02:55:05 mailserver-1 kernel: [] copy_process+0x8ae/0x109c Dec 16 02:55:05 mailserver-1 kernel: [] alloc_pid+0x16/0x240 Dec 16 02:55:05 mailserver-1 kernel: [] kmem_cache_alloc+0x80/0xbc Dec 16 02:55:05 mailserver-1 kernel: [] alloc_pid+0x16/0x240 Dec 16 02:55:05 mailserver-1 kernel: [] do_fork+0x9a/0x1c2 Dec 16 02:55:05 mailserver-1 kernel: [] recalc_sigpending+0xb/0x1d Dec 16 02:55:05 mailserver-1 kernel: [] sigprocmask+0xa1/0xc5 Dec 16 02:55:05 mailserver-1 kernel: [] sys_clone+0x36/0x3b Dec 16 02:55:05 mailserver-1 kernel: [] sysenter_past_esp+0x6b/0xa1 Dec 16 02:55:05 mailserver-1 kernel: [] wait_for_completion_timeout+0x7f/0xd6 Dec 16 02:55:05 mailserver-1 kernel: ======================= ....................... From owner-xfs@oss.sgi.com Mon Dec 17 14:03:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 14:04: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.11/SuSE Linux 0.7) with SMTP id lBHM3ovr018708 for ; Mon, 17 Dec 2007 14:03:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA28416; Tue, 18 Dec 2007 09:03:58 +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 lBHM3uIN12094494; Tue, 18 Dec 2007 09:03:57 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBHM3sSc12093238; Tue, 18 Dec 2007 09:03:54 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 18 Dec 2007 09:03:54 +1100 From: David Chinner To: Laurent Caron Cc: xfs@oss.sgi.com Subject: Re: Issue with 2.6.23 and drbd 8.0.7 Message-ID: <20071217220354.GU4396912@sgi.com> References: <20071217143655.chiehahh@trusted.lncsa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071217143655.chiehahh@trusted.lncsa.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5160/Mon Dec 17 08:46:31 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13977 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 17, 2007 at 02:39:07PM +0100, Laurent Caron wrote: > > Hi, > > I'm still experiencing a strange behavior on one of my DRBD setup. > > It basically consists in: > > 2 servers with XFS filesystems on top of DRBD, itself on top of MD (aka > soft raid). > > The two servers exhibit the same behavior. This strange behavior might > appear between 1 day and 3 weeks after having started the machines. > > Slab debugging is turned on. > CONFIG_SLAB=y > CONFIG_DEBUG_SLAB=y > CONFIG_DEBUG_SLAB_LEAK=y > > Do anyone have a clue about that problem? The symptoms you see are the machine running out of memory and the OOM killer being invoked. There's nothing XFS here - you'd do better to post to lkml about this. > I already posted about it some time ago, and was asked to turn slab debugging on. What you posted recently appeared to be the result of memory corruption, hence the request for debugging to be turned on. This appears to be a different problem. > Dec 16 01:12:27 mailserver-1 kernel: DMA: 5*4kB 11*8kB 7*16kB 2*32kB 2*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB > Dec 16 01:12:27 mailserver-1 kernel: Normal: 195*4kB 82*8kB 5*16kB 9*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3788kB > Dec 16 01:12:27 mailserver-1 kernel: HighMem: 37376*4kB 104969*8kB 97167*16kB 61944*32kB 34197*64kB 13138*128kB 3479*256kB 502*512kB 24*1024kB 2*2048kB 2*4096kB = 9580920kB Hmmm - you appear to have a highmem based box and have run out of low memory for the kernel. So while having ~9.5GB of free high memory (that the kernel can't directly use), you're out of low memory that the kernel can use and hence it is going OOM. The output of /proc/slabinfo or watching slabtop will tell you where most of this memory is going. FWIW, I suggest upgrading to a 64 bit machine ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 17 14:18:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 14:18:48 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50,T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBHMIa0n020501 for ; Mon, 17 Dec 2007 14:18:38 -0800 X-ASG-Debug-ID: 1197929916-664a019d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sargon.lncsa.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3935B492F32 for ; Mon, 17 Dec 2007 14:18:37 -0800 (PST) Received: from sargon.lncsa.com (sargon-nerim.lncsa.com [195.5.245.101]) by cuda.sgi.com with ESMTP id mss5mfl6AjXiIgoe for ; Mon, 17 Dec 2007 14:18:37 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 9F42F302310D; Mon, 17 Dec 2007 23:17:59 +0100 (CET) X-Virus-Scanned: ClamAV 0.91.2/5160/Mon Dec 17 08:46:31 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqvhK0f6y+BH; Mon, 17 Dec 2007 23:17:59 +0100 (CET) Received: from [192.168.0.192] (gw.unix-scripts.info [62.212.121.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by sargon.lncsa.com (Postfix) with ESMTP id 7F1453022A50; Mon, 17 Dec 2007 23:17:45 +0100 (CET) Message-ID: <4766F58C.8040000@lncsa.com> Date: Mon, 17 Dec 2007 23:17:48 +0100 From: Laurent CARON User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Issue with 2.6.23 and drbd 8.0.7 Subject: Re: Issue with 2.6.23 and drbd 8.0.7 References: <20071217143655.chiehahh@trusted.lncsa.com> <20071217220354.GU4396912@sgi.com> In-Reply-To: <20071217220354.GU4396912@sgi.com> Content-Type: multipart/mixed; boundary="------------070007060605030807030603" X-Barracuda-Connect: sargon-nerim.lncsa.com[195.5.245.101] X-Barracuda-Start-Time: 1197929925 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36915 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 13978 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lcaron@lncsa.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------070007060605030807030603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David Chinner wrote: > The symptoms you see are the machine running out of memory and the OOM > killer being invoked. There's nothing XFS here - you'd do better to post > to lkml about this. So, I was wrong .... :$ > Hmmm - you appear to have a highmem based box and have run out of > low memory for the kernel. So while having ~9.5GB of free high > memory (that the kernel can't directly use), you're out of low > memory that the kernel can use and hence it is going OOM. The > output of /proc/slabinfo or watching slabtop will tell you where > most of this memory is going. Please find attached the output from /proc/slabinfo from both servers, as well as output from slabtop from server 1. > > FWIW, I suggest upgrading to a 64 bit machine ;) I'm currently migrating those 2 servers to 2 64 Bit setups ;) Thanks for your advice. Laurent --------------070007060605030807030603 Content-Type: text/plain; name="slabinfo-srv1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slabinfo-srv1" slabinfo - version: 2.1 (statistics) # name : tunables : slabdata : globalstat : cpustat nfs_direct_cache 0 0 104 37 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nfs_write_data 36 40 480 8 1 : tunables 32 16 8 : slabdata 5 5 0 : globalstat 40 40 5 0 0 0 0 0 0 : cpustat 31 5 0 0 nfs_read_data 32 32 456 8 1 : tunables 32 16 8 : slabdata 4 4 0 : globalstat 32 32 4 0 0 0 0 0 0 : cpustat 28 4 0 0 nfs_inode_cache 0 0 640 6 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nfs_page 0 0 80 48 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nfsd4_delegations 0 0 240 16 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nfsd4_stateids 0 0 96 40 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nfsd4_files 0 0 64 59 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nfsd4_stateowners 0 0 368 10 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 rpc_buffers 8 9 2072 3 2 : tunables 24 12 8 : slabdata 3 3 0 : globalstat 15 15 5 2 0 0 0 0 0 : cpustat 21 5 18 0 rpc_tasks 8 19 200 19 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 73 73 4 3 0 0 0 0 0 : cpustat 19 7 18 0 rpc_inode_cache 6 8 488 8 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 8 8 1 0 0 0 0 0 0 : cpustat 5 1 0 0 fib6_nodes 13 67 56 67 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 64 50 1 0 0 0 0 0 0 : cpustat 9 4 0 0 ip6_dst_cache 16 45 256 15 1 : tunables 32 16 8 : slabdata 3 3 0 : globalstat 72 45 3 0 0 0 0 0 0 : cpustat 34 7 25 0 ndisc_cache 1 20 192 20 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 43 36 2 1 0 0 0 0 0 : cpustat 7 4 10 0 RAWv6 11 12 672 6 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 12 12 2 0 0 0 0 0 0 : cpustat 9 2 0 0 UDPLITEv6 0 0 656 6 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 UDPv6 9 24 656 6 1 : tunables 32 16 8 : slabdata 4 4 0 : globalstat 82827 54 1316 1312 0 0 0 0 0 : cpustat 1361 6800 8152 0 tw_sock_TCPv6 2 26 152 26 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 38475 68 640 639 0 0 0 0 0 : cpustat 186 2672 2856 0 request_sock_TCPv6 0 0 136 29 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 TCPv6 29 51 1328 3 1 : tunables 24 12 8 : slabdata 17 17 0 : globalstat 132027 369 853 836 0 0 0 0 0 : cpustat 3762 14150 17883 0 ip_fib_alias 73 156 48 78 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 510 155 2 0 0 0 0 0 0 : cpustat 105 32 64 0 ip_fib_hash 73 156 48 78 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 510 155 2 0 0 0 0 0 0 : cpustat 102 32 61 0 dm_snap_pending_exception 128 132 88 44 1 : tunables 32 16 8 : slabdata 3 3 0 : globalstat 132 132 3 0 0 0 0 0 0 : cpustat 119 9 0 0 dm_snap_exception 0 0 48 78 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 dm_target_io 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 dm_io 0 0 48 78 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nf_conntrack_expect 0 0 184 21 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nf_conntrack 1288 1830 264 15 1 : tunables 32 16 8 : slabdata 122 122 0 : globalstat 695930 4560 861 9 0 0 0 0 0 : cpustat 2115732 47751 2145280 16976 drbd_ee_cache 268 396 88 44 1 : tunables 32 16 8 : slabdata 9 9 0 : globalstat 1355529 1496 8406 2718 0 3 0 0 0 : cpustat 5275151 190574 5286409 179060 drbd_req_cache 289 396 88 44 1 : tunables 32 16 8 : slabdata 8 9 0 : globalstat 2487110 6220 12750 2527 0 3 0 0 0 : cpustat 9536991 411417 9608406 339745 raid5-md3 256 256 1000 4 1 : tunables 32 16 8 : slabdata 64 64 0 : globalstat 256 256 64 0 0 0 0 0 0 : cpustat 192 64 0 0 raid5-md2 256 256 1000 4 1 : tunables 32 16 8 : slabdata 64 64 0 : globalstat 256 256 64 0 0 0 0 0 0 : cpustat 192 64 0 0 raid5-md1 256 256 1000 4 1 : tunables 32 16 8 : slabdata 64 64 0 : globalstat 256 256 64 0 0 0 0 0 0 : cpustat 192 64 0 0 sgpool-128 2 3 2584 3 2 : tunables 24 12 8 : slabdata 1 1 0 : globalstat 3 3 1 0 0 0 0 0 0 : cpustat 1 1 0 0 sgpool-64 2 3 1304 3 1 : tunables 24 12 8 : slabdata 1 1 0 : globalstat 3 3 1 0 0 0 0 0 0 : cpustat 1 1 0 0 sgpool-32 2 6 664 6 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 6 6 1 0 0 0 0 0 0 : cpustat 1 1 0 0 sgpool-16 2 11 344 11 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 11 11 1 0 0 0 0 0 0 : cpustat 1 1 0 0 sgpool-8 2 21 184 21 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 16 16 1 0 0 0 0 0 0 : cpustat 1 1 0 0 scsi_io_context 0 0 128 30 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 uhci_urb_priv 4 134 56 67 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 84 83 2 0 0 0 0 0 0 : cpustat 56 6 58 0 UNIX 704 960 456 8 1 : tunables 32 16 8 : slabdata 120 120 0 : globalstat 913635 2152 742 220 0 1 0 0 0 : cpustat 1084624 58989 1141401 1541 flow_cache 13077 13098 104 37 1 : tunables 32 16 8 : slabdata 354 354 0 : globalstat 9455477 32412 125847 0 0 0 0 0 0 : cpustat 8935534 693254 9018654 597113 cfq_io_context 557 2205 112 35 1 : tunables 32 16 8 : slabdata 63 63 0 : globalstat 317617 2361 72 5 0 0 0 0 0 : cpustat 27777 19956 47146 30 cfq_queue 564 2170 112 35 1 : tunables 32 16 8 : slabdata 62 62 0 : globalstat 317788 2361 77 10 0 0 0 0 0 : cpustat 27668 19960 47035 29 mqueue_inode_cache 1 7 536 7 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 7 7 1 0 0 0 0 0 0 : cpustat 0 1 0 0 xfs_chashlist 30513 34866 48 78 1 : tunables 32 16 8 : slabdata 447 447 0 : globalstat 647346 34836 447 0 0 0 0 0 0 : cpustat 528235 59293 528202 28813 xfs_ili 5374 8326 168 23 1 : tunables 32 16 8 : slabdata 362 362 0 : globalstat 808969 36862 2118 61 0 2 0 0 0 : cpustat 226653 56049 269154 8202 xfs_inode 227129 245574 408 9 1 : tunables 32 16 8 : slabdata 27286 27286 0 : globalstat 9651465 385191 557966 350 0 16 0 0 0 : cpustat 9202077 908677 9281594 602076 xfs_efi_item 12 13 288 13 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 440732 221 14394 14387 0 2 0 0 0 : cpustat 127853 34809 162040 621 xfs_efd_item 12 13 288 13 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 440681 221 14383 14375 0 2 0 0 0 : cpustat 127856 34806 162042 619 xfs_buf_item 99 198 176 22 1 : tunables 32 16 8 : slabdata 8 9 0 : globalstat 888702 682 2486 2269 0 1 0 0 0 : cpustat 3904057 65575 3959515 10057 fstrm_item 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 xfs_mru_cache_elem 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 xfs_acl 0 0 328 12 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 816 96 68 68 0 0 0 0 0 : cpustat 9610430 68 9610498 0 xfs_ifork 0 0 80 48 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 xfs_dabuf 66 184 40 92 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 664615 169 638 636 0 0 0 0 0 : cpustat 39276426 42121 39318508 39 xfs_da_state 20 22 360 11 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 305744 143 12529 12527 0 0 0 0 0 : cpustat 7610566 26375 7636932 9 xfs_trans 38 72 656 6 1 : tunables 32 16 8 : slabdata 9 12 0 : globalstat 953186 462 28482 28298 0 23 0 0 0 : cpustat 2929804 160990 3007558 83228 xfs_btree_cur 46 46 168 23 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 683790 131 4408 4406 0 0 0 0 0 : cpustat 2107846 47358 2155204 0 xfs_bmap_free_item 18 92 40 92 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 495962 131 3136 3135 0 0 0 0 0 : cpustat 137319 31479 168798 0 xfs_buf 164 288 216 18 1 : tunables 32 16 8 : slabdata 16 16 0 : globalstat 1015193 772 1287 890 0 3 0 0 0 : cpustat 69896276 93787 69956038 33936 xfs_ioend 92 144 80 48 1 : tunables 32 16 8 : slabdata 3 3 0 : globalstat 907532 784 6446 6219 0 2 0 0 0 : cpustat 585485 63935 642272 7116 xfs_vnode 227106 243130 392 10 1 : tunables 32 16 8 : slabdata 24313 24313 0 : globalstat 9547711 385180 500984 462 0 15 0 0 0 : cpustat 9540232 842184 9557063 598278 ext2_inode_cache 0 0 496 8 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 ext2_xattr 0 0 72 53 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 journal_handle 0 0 48 78 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 journal_head 0 0 80 48 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 revoke_table 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 revoke_record 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 ext3_inode_cache 0 0 512 8 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 ext3_xattr 0 0 72 53 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 dnotify_cache 1 78 48 78 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 16 16 1 0 0 0 0 0 0 : cpustat 0 1 0 0 dquot 0 0 128 30 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 inotify_event_cache 0 0 56 67 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 inotify_watch_cache 1 59 64 59 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 32 16 2 1 0 0 0 0 0 : cpustat 0 2 1 0 kioctx 0 0 208 19 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 kiocb 0 0 160 24 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 fasync_cache 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 192 17 11 11 0 0 0 0 0 : cpustat 0 12 12 0 shmem_inode_cache 527 608 464 8 1 : tunables 32 16 8 : slabdata 76 76 0 : globalstat 104470 624 92 16 0 0 0 0 0 : cpustat 10086 6615 16172 2 nsproxy 0 0 56 67 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 posix_timers_cache 0 0 152 26 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 uid_cache 35 288 80 48 1 : tunables 32 16 8 : slabdata 6 6 0 : globalstat 250407 312 51 45 0 0 0 0 0 : cpustat 5996 15733 21694 0 ip_mrt_cache 0 0 104 37 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 UDP-Lite 0 0 544 7 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 tcp_bind_bucket 175 644 40 92 1 : tunables 32 16 8 : slabdata 7 7 0 : globalstat 751772 614 8 0 0 0 0 0 0 : cpustat 195022 48536 241640 1775 inet_peer_cache 43 106 72 53 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 21717 103 2 0 0 0 0 0 0 : cpustat 114 1358 1429 0 secpath_cache 135 201 56 67 1 : tunables 32 16 8 : slabdata 3 3 0 : globalstat 227178 332 22 18 0 0 0 0 0 : cpustat 12014865 46791 12023500 38156 xfrm_dst_cache 125 624 288 13 1 : tunables 32 16 8 : slabdata 48 48 0 : globalstat 541378 1118 1988 2 0 0 0 0 0 : cpustat 62275 36074 92381 5845 ip_dst_cache 1342 2220 264 15 1 : tunables 32 16 8 : slabdata 148 148 0 : globalstat 1146538 4050 1768 0 0 0 0 0 0 : cpustat 422000 77235 469442 28528 arp_cache 42 147 184 21 1 : tunables 32 16 8 : slabdata 7 7 0 : globalstat 85935 310 31 24 0 0 0 0 0 : cpustat 813 5417 6187 1 RAW 10 14 528 7 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 20766 63 787 785 0 0 0 0 0 : cpustat 3801 3688 7479 0 UDP 75 91 544 7 1 : tunables 32 16 8 : slabdata 13 13 0 : globalstat 568918 147 9149 9136 0 0 0 0 0 : cpustat 213130 47456 260529 0 tw_sock_TCP 76 192 120 32 1 : tunables 32 16 8 : slabdata 6 6 0 : globalstat 801606 800 369 182 0 0 0 0 0 : cpustat 192527 54470 242102 4835 request_sock_TCP 27 120 96 40 1 : tunables 32 16 8 : slabdata 3 3 0 : globalstat 773451 240 686 682 0 0 0 0 0 : cpustat 526932 52326 575461 3788 TCP 199 207 1216 3 1 : tunables 24 12 8 : slabdata 69 69 0 : globalstat 584635 354 12556 12487 0 2 0 0 0 : cpustat 717628 63427 779057 1837 eventpoll_pwq 356 649 64 59 1 : tunables 32 16 8 : slabdata 11 11 0 : globalstat 723696 665 14 0 0 0 0 0 0 : cpustat 991533 45447 1036379 296 eventpoll_epi 356 640 96 40 1 : tunables 32 16 8 : slabdata 16 16 0 : globalstat 723672 672 20 1 0 0 0 0 0 : cpustat 991529 45451 1036378 297 blkdev_ioc 96 469 56 67 1 : tunables 32 16 8 : slabdata 7 7 0 : globalstat 169619 449 9 2 0 0 0 0 0 : cpustat 5658 10614 16175 1 blkdev_queue 31 48 1008 4 1 : tunables 32 16 8 : slabdata 12 12 0 : globalstat 71 48 12 0 0 0 0 0 0 : cpustat 17 14 0 0 blkdev_requests 333 720 216 18 1 : tunables 32 16 8 : slabdata 40 40 128 : globalstat 4195813 1186 9623 168 0 1 0 0 0 : cpustat 53673071 1459720 53709489 1423266 biovec-256 2 2 3096 2 2 : tunables 24 12 8 : slabdata 1 1 0 : globalstat 2 2 1 0 0 0 0 0 0 : cpustat 1 1 0 0 biovec-128 2 5 1560 5 2 : tunables 24 12 8 : slabdata 1 1 0 : globalstat 652 205 125 111 0 2 0 0 0 : cpustat 788 155 889 52 biovec-64 64 100 792 5 1 : tunables 32 16 8 : slabdata 18 20 0 : globalstat 848803 620 62220 60744 0 19 0 0 0 : cpustat 663524 110913 762385 12050 biovec-16 5 54 216 18 1 : tunables 32 16 8 : slabdata 2 3 0 : globalstat 897258 268 6926 6885 0 3 0 0 0 : cpustat 730705 69353 793279 6777 biovec-4 28 212 72 53 1 : tunables 32 16 8 : slabdata 3 4 0 : globalstat 1174720 509 2204 1980 0 2 0 0 0 : cpustat 2790389 103804 2863441 30750 biovec-1 265 644 40 92 1 : tunables 32 16 8 : slabdata 7 7 112 : globalstat 10001880 11304 7253 6 0 1 0 0 0 : cpustat 51100091 1714212 51139147 1675154 bio 284 600 96 40 1 : tunables 32 16 8 : slabdata 15 15 128 : globalstat 10331188 11280 31364 40 0 2 0 0 0 : cpustat 55439258 1844668 55488594 1795330 sock_inode_cache 983 1620 400 10 1 : tunables 32 16 8 : slabdata 162 162 0 : globalstat 735730 2410 334 13 0 1 0 0 0 : cpustat 2291435 52679 2335528 7664 skbuff_fclone_cache 94 170 392 10 1 : tunables 32 16 8 : slabdata 17 17 0 : globalstat 651571 1330 6042 4947 0 7 0 0 0 : cpustat 13744931 286325 13777035 254216 skbuff_head_cache 1418 2508 208 19 1 : tunables 32 16 8 : slabdata 132 132 0 : globalstat 563749 5244 420 0 0 5 0 0 0 : cpustat 147443205 630425 147454152 618190 file_lock_cache 92 224 120 32 1 : tunables 32 16 8 : slabdata 7 7 0 : globalstat 894359 282 20 12 0 0 0 0 0 : cpustat 3175262 55912 3231123 3 Acpi-Operand 561 590 64 59 1 : tunables 32 16 8 : slabdata 10 10 0 : globalstat 598 575 10 0 0 0 0 0 0 : cpustat 1786 51 1266 10 Acpi-ParseExt 0 0 72 53 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 154 106 4 2 0 0 0 0 0 : cpustat 1902 19 1909 12 Acpi-Parse 0 0 56 67 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 96 48 3 2 0 0 0 0 0 : cpustat 2647 6 2653 0 Acpi-State 0 0 72 53 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 112 48 2 1 0 0 0 0 0 : cpustat 4618 7 4625 0 Acpi-Namespace 422 468 48 78 1 : tunables 32 16 8 : slabdata 6 6 0 : globalstat 422 422 6 0 0 0 0 0 0 : cpustat 395 27 0 0 proc_inode_cache 1520 1690 376 10 1 : tunables 32 16 8 : slabdata 169 169 0 : globalstat 714611 6580 3518 322 0 7 0 0 0 : cpustat 494362 47218 537206 2860 sigqueue 51 115 168 23 1 : tunables 32 16 8 : slabdata 5 5 0 : globalstat 629811 177 663 658 0 3 0 0 0 : cpustat 2916985 143505 2952852 107636 radix_tree_node 88310 88356 312 12 1 : tunables 32 16 8 : slabdata 7363 7363 0 : globalstat 745753 115164 12973 292 0 7 0 0 0 : cpustat 519110 61596 469468 22958 bdev_cache 50 72 472 8 1 : tunables 32 16 8 : slabdata 9 9 0 : globalstat 233 72 9 0 0 0 0 0 0 : cpustat 123 20 93 0 sysfs_dir_cache 8403 8448 80 48 1 : tunables 32 16 8 : slabdata 176 176 0 : globalstat 8724 8432 176 0 0 0 0 0 0 : cpustat 8238 550 385 0 mnt_cache 28 87 136 29 1 : tunables 32 16 8 : slabdata 3 3 0 : globalstat 293 87 3 0 0 0 0 0 0 : cpustat 20 19 11 0 inode_cache 104 297 360 11 1 : tunables 32 16 8 : slabdata 27 27 0 : globalstat 658638 2101 379 179 0 12 0 0 0 : cpustat 470365 41758 511518 517 dentry 170738 215280 160 24 1 : tunables 32 16 8 : slabdata 8970 8970 0 : globalstat 10244796 397216 102210 72 0 6 0 0 0 : cpustat 13480269 753982 13406540 657036 filp 4912 10632 160 24 1 : tunables 32 16 8 : slabdata 443 443 0 : globalstat 5370475 16192 4793 20 0 6 0 0 0 : cpustat 21789897 711901 21835962 660983 names_cache 56 67 4096 1 1 : tunables 24 12 8 : slabdata 56 67 0 : globalstat 256326 125 60543 60472 0 28 0 0 0 : cpustat 78886148 93687 78970917 8918 key_jar 70 315 112 35 1 : tunables 32 16 8 : slabdata 9 9 0 : globalstat 257958 522 197 183 0 0 0 0 0 : cpustat 27040 16418 43385 3 idr_layer_cache 87 120 160 24 1 : tunables 32 16 8 : slabdata 5 5 0 : globalstat 904 136 6 1 0 0 0 0 0 : cpustat 209 59 181 0 buffer_head 150095 460752 80 48 1 : tunables 32 16 8 : slabdata 9599 9599 0 : globalstat 3166476 717184 29407 408 0 3 0 0 0 : cpustat 3275490 235016 3179139 181289 mm_struct 273 456 456 8 1 : tunables 32 16 8 : slabdata 57 57 0 : globalstat 730938 1016 497 325 0 1 0 0 0 : cpustat 1070644 47156 1116501 1050 vm_area_struct 12043 23870 112 35 1 : tunables 32 16 8 : slabdata 682 682 32 : globalstat 4061270 30972 1290 12 0 3 0 0 0 : cpustat 36608058 1142756 36652110 1086726 fs_cache 278 1003 64 59 1 : tunables 32 16 8 : slabdata 17 17 0 : globalstat 712761 1048 18 0 0 0 0 0 0 : cpustat 554624 45781 598721 1421 files_cache 271 658 280 14 1 : tunables 32 16 8 : slabdata 47 47 0 : globalstat 728709 1036 130 40 0 0 0 0 0 : cpustat 553483 46923 598617 1533 signal_cache 400 656 472 8 1 : tunables 32 16 8 : slabdata 82 82 0 : globalstat 703490 1168 621 433 0 1 0 0 0 : cpustat 555193 46478 599135 2151 sighand_cache 396 453 1328 3 1 : tunables 24 12 8 : slabdata 151 151 0 : globalstat 530997 1131 6172 5791 0 2 0 0 0 : cpustat 547368 53414 596995 3402 task_struct 482 609 1360 3 1 : tunables 24 12 8 : slabdata 203 203 0 : globalstat 585000 1212 5141 4598 0 3 0 0 0 : cpustat 583033 57116 635803 3886 anon_vma 4322 12696 40 92 1 : tunables 32 16 8 : slabdata 138 138 0 : globalstat 1454428 15154 173 0 0 0 0 0 0 : cpustat 6520030 177187 6588308 104622 pmd 759 803 4096 1 1 : tunables 24 12 8 : slabdata 759 803 0 : globalstat 647373 2793 192109 186598 0 97 0 0 0 : cpustat 3095992 257408 3329432 23221 pid 485 1180 64 59 1 : tunables 32 16 8 : slabdata 20 20 0 : globalstat 763758 1239 24 2 0 0 0 0 0 : cpustat 590266 49876 637212 2475 size-4194304(DMA) 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-2097152(DMA) 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-1048576(DMA) 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-524288(DMA) 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-262144(DMA) 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-131072 1 1 131072 1 32 : tunables 8 4 0 : slabdata 1 1 0 : globalstat 3 2 3 2 0 0 0 0 0 : cpustat 0 3 2 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-65536 2 2 65536 1 16 : tunables 8 4 0 : slabdata 2 2 0 : globalstat 4 4 4 2 0 0 0 0 0 : cpustat 0 4 2 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-32768 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 1 1 1 1 0 0 0 0 0 : cpustat 2 1 3 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-16384 262 293 16384 1 4 : tunables 8 4 0 : slabdata 262 293 0 : globalstat 4330681 360 45780 10057 0 33 0 0 0 : cpustat 3531416 1121179 3615531 1036807 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-8192 20 20 8192 1 2 : tunables 8 4 0 : slabdata 20 20 0 : globalstat 1572829 88 27111 24934 0 33 0 0 0 : cpustat 1399242 415275 1445755 368742 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-4096 245 283 4096 1 1 : tunables 24 12 8 : slabdata 245 283 12 : globalstat 516834 502 112610 112112 0 97 0 0 0 : cpustat 13810582 211281 13957057 64627 size-2048(DMA) 0 0 2072 3 2 : tunables 24 12 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-2048 1340 1383 2072 3 2 : tunables 24 12 8 : slabdata 461 461 12 : globalstat 479384 2700 7828 1112 0 33 0 0 0 : cpustat 50927863 443555 50943192 427000 size-1024(DMA) 0 0 1048 7 2 : tunables 24 12 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-1024 893 973 1048 7 2 : tunables 24 12 8 : slabdata 139 139 0 : globalstat 420740 1120 314 107 0 1 0 0 0 : cpustat 19662753 343204 19681013 324148 size-512(DMA) 0 0 536 7 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-512 1930 2002 536 7 1 : tunables 32 16 8 : slabdata 286 286 0 : globalstat 424825 2156 699 264 0 3 0 0 0 : cpustat 24256290 320736 24265425 309784 size-256(DMA) 0 0 280 14 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-256 682 742 280 14 1 : tunables 32 16 8 : slabdata 53 53 0 : globalstat 731808 938 1202 1045 0 1 0 0 0 : cpustat 1168117 50670 1213652 4496 size-192(DMA) 0 0 216 18 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-192 2126 2682 216 18 1 : tunables 32 16 8 : slabdata 149 149 0 : globalstat 710574 2734 214 59 0 0 0 0 0 : cpustat 11225961 44924 11268431 373 size-128(DMA) 0 0 152 26 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-128 14464 40456 152 26 1 : tunables 32 16 8 : slabdata 1556 1556 0 : globalstat 4771872 212748 120992 50 0 5 0 0 0 : cpustat 4580606 366443 4632729 299856 size-64(DMA) 0 0 88 44 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-32(DMA) 0 0 56 67 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-64 27959 30492 88 44 1 : tunables 32 16 8 : slabdata 693 693 2 : globalstat 887144 145068 4332 11 0 1 0 0 0 : cpustat 18149938 65422 18136641 50921 size-32 7888 10653 56 67 1 : tunables 32 16 8 : slabdata 159 159 6 : globalstat 963408 10653 161 1 0 1 0 0 0 : cpustat 6505589 83592 6552327 29008 kmem_cache 178 195 256 15 1 : tunables 32 16 8 : slabdata 13 13 0 : globalstat 322 195 13 0 0 0 0 0 0 : cpustat 119 59 0 0 --------------070007060605030807030603 Content-Type: text/plain; name="slabinfo-srv2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slabinfo-srv2" slabinfo - version: 2.1 (statistics) # name : tunables : slabdata : globalstat : cpustat nfsd4_delegations 0 0 240 16 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nfsd4_stateids 0 0 96 40 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nfsd4_files 0 0 64 59 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nfsd4_stateowners 0 0 368 10 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nf_conntrack_expect 0 0 184 21 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nf_conntrack 344 645 264 15 1 : tunables 32 16 8 : slabdata 43 43 0 : globalstat 799662 1395 142 1 0 0 0 0 0 : cpustat 338856 50069 388561 65 fib6_nodes 13 67 56 67 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 64 64 1 0 0 0 0 0 0 : cpustat 9 4 0 0 ip6_dst_cache 16 60 256 15 1 : tunables 32 16 8 : slabdata 4 4 0 : globalstat 76 60 4 0 0 0 0 0 0 : cpustat 36 5 25 0 ndisc_cache 1 20 192 20 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 40 40 2 1 0 0 0 0 0 : cpustat 7 4 10 0 RAWv6 11 12 672 6 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 12 12 2 0 0 0 0 0 0 : cpustat 9 2 0 0 UDPLITEv6 0 0 656 6 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 UDPv6 10 24 656 6 1 : tunables 32 16 8 : slabdata 3 4 0 : globalstat 267214 48 1997 1993 0 0 0 0 0 : cpustat 76092 32292 108375 0 tw_sock_TCPv6 0 0 152 26 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 request_sock_TCPv6 0 0 136 29 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 TCPv6 19 27 1328 3 1 : tunables 24 12 8 : slabdata 9 9 0 : globalstat 257188 42 940 931 0 0 0 0 0 : cpustat 11969 43309 55265 0 smb_request 0 0 272 14 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 140 56 10 10 0 0 0 0 0 : cpustat 21 10 31 0 smb_inode_cache 3 20 384 10 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 52 20 2 0 0 0 0 0 0 : cpustat 0 4 1 0 nfs_direct_cache 0 0 104 37 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 nfs_write_data 36 40 480 8 1 : tunables 32 16 8 : slabdata 5 5 0 : globalstat 40 40 5 0 0 0 0 0 0 : cpustat 31 5 0 0 nfs_read_data 32 32 456 8 1 : tunables 32 16 8 : slabdata 4 4 0 : globalstat 2217 168 189 185 0 0 0 0 0 : cpustat 1414 267 1647 2 nfs_inode_cache 1053 1056 640 6 1 : tunables 32 16 8 : slabdata 176 176 0 : globalstat 1873 1056 176 0 0 0 0 0 0 : cpustat 755 298 0 0 nfs_page 0 0 80 48 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 10512 321 165 158 0 1 0 0 0 : cpustat 11786 863 12404 245 rpc_buffers 8 9 2072 3 2 : tunables 24 12 8 : slabdata 3 3 0 : globalstat 2329 117 421 418 0 0 0 0 0 : cpustat 3981 798 4763 8 rpc_tasks 8 19 200 19 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 12581 149 346 345 0 0 0 0 0 : cpustat 2064 1066 3122 0 rpc_inode_cache 16 24 488 8 1 : tunables 32 16 8 : slabdata 3 3 0 : globalstat 32 32 4 1 0 0 0 0 0 : cpustat 26 4 14 0 ip_fib_alias 63 156 48 78 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 206 118 2 0 0 0 0 0 0 : cpustat 70 13 20 0 ip_fib_hash 62 156 48 78 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 206 118 2 0 0 0 0 0 0 : cpustat 68 13 19 0 dm_snap_pending_exception 128 132 88 44 1 : tunables 32 16 8 : slabdata 3 3 0 : globalstat 132 132 3 0 0 0 0 0 0 : cpustat 119 9 0 0 dm_snap_exception 0 0 48 78 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 dm_target_io 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 dm_io 0 0 48 78 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 drbd_ee_cache 381 484 88 44 1 : tunables 32 16 8 : slabdata 10 11 102 : globalstat 608903 1748 5189 1033 0 3 0 0 0 : cpustat 2949457 67553 2957707 59047 drbd_req_cache 419 616 88 44 1 : tunables 32 16 8 : slabdata 13 14 112 : globalstat 3164116 4592 24572 6642 0 4 0 0 0 : cpustat 6585171 443517 6651596 376825 raid5-md1 256 256 1000 4 1 : tunables 32 16 8 : slabdata 64 64 0 : globalstat 256 256 64 0 0 0 0 0 0 : cpustat 192 64 0 0 raid5-md2 256 256 1000 4 1 : tunables 32 16 8 : slabdata 64 64 0 : globalstat 256 256 64 0 0 0 0 0 0 : cpustat 192 64 0 0 raid5-md3 256 256 1000 4 1 : tunables 32 16 8 : slabdata 64 64 0 : globalstat 256 256 64 0 0 0 0 0 0 : cpustat 192 64 0 0 sgpool-128 2 3 2584 3 2 : tunables 24 12 8 : slabdata 1 1 0 : globalstat 3 3 1 0 0 0 0 0 0 : cpustat 1 1 0 0 sgpool-64 2 3 1304 3 1 : tunables 24 12 8 : slabdata 1 1 0 : globalstat 3 3 1 0 0 0 0 0 0 : cpustat 1 1 0 0 sgpool-32 2 6 664 6 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 6 6 1 0 0 0 0 0 0 : cpustat 1 1 0 0 sgpool-16 2 11 344 11 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 11 11 1 0 0 0 0 0 0 : cpustat 1 1 0 0 sgpool-8 2 21 184 21 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 16 16 1 0 0 0 0 0 0 : cpustat 1 1 0 0 scsi_io_context 0 0 128 30 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 uhci_urb_priv 4 67 56 67 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 77 67 1 0 0 0 0 0 0 : cpustat 57 6 59 0 UNIX 593 656 456 8 1 : tunables 32 16 8 : slabdata 82 82 0 : globalstat 994927 768 644 490 0 1 0 0 0 : cpustat 708962 65651 771363 2750 flow_cache 0 0 104 37 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 cfq_io_context 576 1085 112 35 1 : tunables 32 16 8 : slabdata 31 31 0 : globalstat 196213 1101 58 27 0 0 0 0 0 : cpustat 13216 12336 24960 16 cfq_queue 584 1050 112 35 1 : tunables 32 16 8 : slabdata 30 30 0 : globalstat 195940 1101 81 51 0 0 0 0 0 : cpustat 13068 12334 24801 17 mqueue_inode_cache 1 7 536 7 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 7 7 1 0 0 0 0 0 0 : cpustat 0 1 0 0 xfs_chashlist 13522 13572 48 78 1 : tunables 32 16 8 : slabdata 174 174 0 : globalstat 43409 13572 174 0 0 0 0 0 0 : cpustat 13343 2758 2510 69 xfs_ili 23826 23851 168 23 1 : tunables 32 16 8 : slabdata 1037 1037 0 : globalstat 239397 28244 2048 122 0 5 0 0 0 : cpustat 49254 16569 40520 1492 xfs_inode 386493 386505 408 9 1 : tunables 32 16 8 : slabdata 42945 42945 0 : globalstat 669376 386532 46399 235 0 12 0 0 0 : cpustat 380395 63949 55422 2444 xfs_efi_item 0 0 288 13 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 148175 234 7382 7376 0 1 0 0 0 : cpustat 24805 12543 36842 506 xfs_efd_item 0 0 288 13 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 148106 234 7374 7367 0 1 0 0 0 : cpustat 24743 12539 36776 506 xfs_buf_item 44 44 176 22 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 563618 436 2836 2805 0 1 0 0 0 : cpustat 565743 38692 604227 177 fstrm_item 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 xfs_mru_cache_elem 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 xfs_acl 0 0 328 12 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 808 96 64 64 0 0 0 0 0 : cpustat 441456 67 441523 0 xfs_ifork 0 0 80 48 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 xfs_dabuf 66 92 40 92 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 541986 138 976 975 0 0 0 0 0 : cpustat 1380537 34134 1414671 0 xfs_da_state 0 0 360 11 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 26567 99 1726 1726 0 0 0 0 0 : cpustat 160395 2394 162789 0 xfs_trans 34 36 656 6 1 : tunables 32 16 8 : slabdata 6 6 0 : globalstat 947093 1320 46740 24952 0 25 0 0 0 : cpustat 1525806 136923 1606327 56401 xfs_btree_cur 23 23 168 23 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 501297 115 4406 4405 0 0 0 0 0 : cpustat 473409 36511 509920 0 xfs_bmap_free_item 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 185635 124 3699 3699 0 0 0 0 0 : cpustat 28941 11638 40579 0 xfs_buf 119 198 216 18 1 : tunables 32 16 8 : slabdata 11 11 0 : globalstat 845845 592 710 319 0 1 0 0 0 : cpustat 3302165 55177 3355253 2029 xfs_ioend 142 288 80 48 1 : tunables 32 16 8 : slabdata 6 6 54 : globalstat 1326557 1136 8289 5288 0 2 0 0 0 : cpustat 2060028 148748 2129596 79148 xfs_vnode 386491 386510 392 10 1 : tunables 32 16 8 : slabdata 38651 38651 0 : globalstat 811017 386520 41375 391 0 12 0 0 0 : cpustat 454442 68642 134173 2437 ext2_inode_cache 0 0 496 8 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 ext2_xattr 0 0 72 53 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 journal_handle 0 0 48 78 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 journal_head 0 0 80 48 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 revoke_table 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 revoke_record 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 ext3_inode_cache 0 0 512 8 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 ext3_xattr 0 0 72 53 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 dnotify_cache 6 78 48 78 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 16 16 1 0 0 0 0 0 0 : cpustat 5 1 0 0 dquot 0 0 128 30 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 inotify_event_cache 0 0 56 67 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 inotify_watch_cache 1 59 64 59 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 32 16 2 1 0 0 0 0 0 : cpustat 0 2 1 0 kioctx 0 0 208 19 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 kiocb 0 0 160 24 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 fasync_cache 0 0 40 92 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 192 16 12 12 0 0 0 0 0 : cpustat 1 12 13 0 shmem_inode_cache 573 592 464 8 1 : tunables 32 16 8 : slabdata 74 74 0 : globalstat 648458 624 106 32 0 0 0 0 0 : cpustat 69267 40609 109336 2 nsproxy 0 0 56 67 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 posix_timers_cache 0 0 152 26 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 uid_cache 40 96 80 48 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 628587 96 4 2 0 0 0 0 0 : cpustat 16987 39290 56256 0 ip_mrt_cache 0 0 104 37 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 UDP-Lite 0 0 544 7 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 tcp_bind_bucket 86 368 40 92 1 : tunables 32 16 8 : slabdata 4 4 0 : globalstat 339197 1048 12 0 0 0 0 0 0 : cpustat 31949 21273 53037 129 inet_peer_cache 16 106 72 53 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 6821 69 2 0 0 0 0 0 0 : cpustat 8 427 419 0 secpath_cache 0 0 56 67 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 xfrm_dst_cache 0 0 288 13 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 ip_dst_cache 361 645 264 15 1 : tunables 32 16 8 : slabdata 43 43 0 : globalstat 847198 1305 2414 3 0 1 0 0 0 : cpustat 143578 57525 190304 10476 arp_cache 19 84 184 21 1 : tunables 32 16 8 : slabdata 4 4 0 : globalstat 46885 84 6 2 0 0 0 0 0 : cpustat 199 2942 3122 0 RAW 10 14 528 7 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 3122 63 198 196 0 0 0 0 0 : cpustat 1630 696 2316 0 UDP 69 98 544 7 1 : tunables 32 16 8 : slabdata 13 14 0 : globalstat 651647 133 4480 4466 0 0 0 0 0 : cpustat 286700 48762 335418 0 tw_sock_TCP 41 96 120 32 1 : tunables 32 16 8 : slabdata 3 3 0 : globalstat 553342 1056 417 353 0 0 0 0 0 : cpustat 53866 35404 88741 519 request_sock_TCP 57 80 96 40 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 821943 272 2089 2084 0 0 0 0 0 : cpustat 148260 54724 202959 25 TCP 186 186 1216 3 1 : tunables 24 12 8 : slabdata 62 62 0 : globalstat 529711 297 7138 7076 0 2 0 0 0 : cpustat 148350 54386 201989 597 eventpoll_pwq 224 413 64 59 1 : tunables 32 16 8 : slabdata 7 7 0 : globalstat 472600 386 9 1 0 0 0 0 0 : cpustat 257269 29568 286592 40 eventpoll_epi 224 360 96 40 1 : tunables 32 16 8 : slabdata 9 9 0 : globalstat 472524 381 15 3 0 0 0 0 0 : cpustat 257267 29570 286592 40 blkdev_ioc 123 268 56 67 1 : tunables 32 16 8 : slabdata 4 4 0 : globalstat 74125 268 14 10 0 0 0 0 0 : cpustat 2860 4659 7390 6 blkdev_queue 31 48 1008 4 1 : tunables 32 16 8 : slabdata 12 12 0 : globalstat 79 48 12 0 0 0 0 0 0 : cpustat 16 15 0 0 blkdev_requests 317 864 216 18 1 : tunables 32 16 8 : slabdata 48 48 128 : globalstat 4595374 1258 15833 208 0 2 0 0 0 : cpustat 46465376 1496845 46516818 1445367 biovec-256 2 2 3096 2 2 : tunables 24 12 8 : slabdata 1 1 0 : globalstat 68 68 34 33 0 0 0 0 0 : cpustat 34 34 66 0 biovec-128 2 5 1560 5 2 : tunables 24 12 8 : slabdata 1 1 0 : globalstat 249 210 48 41 0 0 0 0 0 : cpustat 276 57 316 15 biovec-64 22 30 792 5 1 : tunables 32 16 8 : slabdata 6 6 0 : globalstat 647746 625 66725 60768 0 18 0 0 0 : cpustat 713265 110950 799309 24904 biovec-16 35 36 216 18 1 : tunables 32 16 8 : slabdata 2 2 0 : globalstat 684498 216 5072 5027 0 2 0 0 0 : cpustat 325180 50766 373953 1991 biovec-4 43 53 72 53 1 : tunables 32 16 8 : slabdata 1 1 0 : globalstat 524720 477 1210 1036 0 1 0 0 0 : cpustat 339248 37378 372477 4147 biovec-1 283 828 40 92 1 : tunables 32 16 8 : slabdata 9 9 128 : globalstat 7921226 11272 4735 2 0 2 0 0 0 : cpustat 37637744 1406322 37684469 1359595 bio 260 800 96 40 1 : tunables 32 16 8 : slabdata 20 20 80 : globalstat 8239361 11296 22266 35 0 3 0 0 0 : cpustat 39147728 1473516 39201720 1419522 sock_inode_cache 830 1070 400 10 1 : tunables 32 16 8 : slabdata 107 107 0 : globalstat 740372 1120 204 56 0 0 0 0 0 : cpustat 1433842 49174 1479297 2980 skbuff_fclone_cache 115 120 392 10 1 : tunables 32 16 8 : slabdata 12 12 16 : globalstat 583511 280 4315 4300 0 6 0 0 0 : cpustat 9013937 224325 9049458 188797 skbuff_head_cache 1395 1938 208 19 1 : tunables 32 16 8 : slabdata 102 102 0 : globalstat 415251 4693 262 0 0 5 0 0 0 : cpustat 42151297 548562 42160738 537842 file_lock_cache 63 160 120 32 1 : tunables 32 16 8 : slabdata 5 5 0 : globalstat 745627 189 86 81 0 0 0 0 0 : cpustat 5982441 46774 6029168 0 Acpi-Operand 561 590 64 59 1 : tunables 32 16 8 : slabdata 10 10 0 : globalstat 614 579 10 0 0 0 0 0 0 : cpustat 1785 52 1266 10 Acpi-ParseExt 0 0 72 53 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 170 106 4 2 0 0 0 0 0 : cpustat 1901 20 1909 12 Acpi-Parse 0 0 56 67 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 112 48 3 2 0 0 0 0 0 : cpustat 2646 7 2653 0 Acpi-State 0 0 72 53 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 133 69 4 3 0 0 0 0 0 : cpustat 4616 9 4625 0 Acpi-Namespace 422 468 48 78 1 : tunables 32 16 8 : slabdata 6 6 0 : globalstat 422 422 6 0 0 0 0 0 0 : cpustat 395 27 0 0 proc_inode_cache 1877 2140 376 10 1 : tunables 32 16 8 : slabdata 214 214 0 : globalstat 861949 3430 687 155 0 0 0 0 0 : cpustat 639218 54808 691460 726 sigqueue 81 115 168 23 1 : tunables 32 16 8 : slabdata 5 5 0 : globalstat 657007 200 465 459 0 1 0 0 0 : cpustat 2060337 117019 2098328 79028 radix_tree_node 56266 56292 312 12 1 : tunables 32 16 8 : slabdata 4691 4691 0 : globalstat 466510 61440 5534 174 0 7 0 0 0 : cpustat 249389 32256 224194 1203 bdev_cache 50 96 472 8 1 : tunables 32 16 8 : slabdata 12 12 0 : globalstat 229 96 12 0 0 0 0 0 0 : cpustat 120 21 91 0 sysfs_dir_cache 7833 7872 80 48 1 : tunables 32 16 8 : slabdata 164 164 0 : globalstat 8140 7856 164 0 0 0 0 0 0 : cpustat 7698 515 380 0 mnt_cache 39 116 136 29 1 : tunables 32 16 8 : slabdata 4 4 0 : globalstat 297 103 4 0 0 0 0 0 0 : cpustat 21 19 1 0 inode_cache 193 374 360 11 1 : tunables 32 16 8 : slabdata 34 34 0 : globalstat 641265 2090 883 697 0 12 0 0 0 : cpustat 148151 40772 188497 309 dentry 425976 425976 160 24 1 : tunables 32 16 8 : slabdata 17749 17749 0 : globalstat 1445145 425992 23668 51 0 4 0 0 0 : cpustat 3101195 113333 2765767 22902 filp 6407 18720 160 24 1 : tunables 32 16 8 : slabdata 780 780 96 : globalstat 3280184 22960 2130 71 0 6 0 0 0 : cpustat 14685939 647868 14739187 588471 names_cache 43 47 4096 1 1 : tunables 24 12 8 : slabdata 43 47 0 : globalstat 239891 119 47517 47470 0 41 0 0 0 : cpustat 38549707 82965 38627347 5325 key_jar 74 105 112 35 1 : tunables 32 16 8 : slabdata 3 3 0 : globalstat 676064 156 26 23 0 0 0 0 0 : cpustat 70270 42284 112512 0 idr_layer_cache 88 120 160 24 1 : tunables 32 16 8 : slabdata 5 5 0 : globalstat 504 136 6 1 0 0 0 0 0 : cpustat 196 34 142 0 buffer_head 794845 794976 80 48 1 : tunables 32 16 8 : slabdata 16562 16562 32 : globalstat 2313373 794960 19236 157 0 3 0 0 0 : cpustat 5189617 331841 4504768 221912 mm_struct 389 440 456 8 1 : tunables 32 16 8 : slabdata 55 55 0 : globalstat 866743 496 663 583 0 0 0 0 0 : cpustat 560425 56839 614822 2151 vm_area_struct 16324 25795 112 35 1 : tunables 32 16 8 : slabdata 737 737 96 : globalstat 3086332 27281 1784 25 0 4 0 0 0 : cpustat 23836095 914708 23898494 836218 fs_cache 393 531 64 59 1 : tunables 32 16 8 : slabdata 9 9 0 : globalstat 897242 522 13 4 0 0 0 0 0 : cpustat 314122 58691 369722 2787 files_cache 387 490 280 14 1 : tunables 32 16 8 : slabdata 35 35 0 : globalstat 902879 532 110 54 0 1 0 0 0 : cpustat 313680 59132 369615 2900 signal_cache 501 560 472 8 1 : tunables 32 16 8 : slabdata 70 70 0 : globalstat 878195 656 619 539 0 2 0 0 0 : cpustat 317661 56146 372640 740 sighand_cache 482 486 1328 3 1 : tunables 24 12 8 : slabdata 161 162 0 : globalstat 646396 615 7154 6990 0 1 0 0 0 : cpustat 310422 62699 371594 1100 task_struct 570 570 1360 3 1 : tunables 24 12 8 : slabdata 190 190 0 : globalstat 668675 690 7415 7183 0 3 0 0 0 : cpustat 323143 64312 385522 1432 anon_vma 3618 4876 40 92 1 : tunables 32 16 8 : slabdata 53 53 16 : globalstat 1581946 4800 69 3 0 1 0 0 0 : cpustat 4076459 166059 4161166 77911 pmd 940 940 4096 1 1 : tunables 24 12 8 : slabdata 940 940 0 : globalstat 862430 1269 57660 52384 0 97 0 0 0 : cpustat 1708852 142940 1835533 15386 pid 584 767 64 59 1 : tunables 32 16 8 : slabdata 13 13 0 : globalstat 906649 750 16 2 0 0 0 0 0 : cpustat 329916 57532 385933 1018 size-4194304(DMA) 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-2097152(DMA) 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-1048576(DMA) 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-524288(DMA) 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-262144(DMA) 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-131072 2 2 131072 1 32 : tunables 8 4 0 : slabdata 2 2 0 : globalstat 2 2 2 0 0 0 0 0 0 : cpustat 0 2 0 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-65536 2 2 65536 1 16 : tunables 8 4 0 : slabdata 2 2 0 : globalstat 4 3 3 1 0 0 0 0 0 : cpustat 0 4 2 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-32768 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 1 1 1 1 0 0 0 0 0 : cpustat 2 1 3 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-16384 270 294 16384 1 4 : tunables 8 4 0 : slabdata 270 294 0 : globalstat 3516777 321 12222 5265 0 33 0 0 0 : cpustat 2883025 890709 2938527 834950 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-8192 21 21 8192 1 2 : tunables 8 4 0 : slabdata 21 21 0 : globalstat 1169879 88 17943 17434 0 33 0 0 0 : cpustat 902200 308848 942028 268999 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-4096 797 797 4096 1 1 : tunables 24 12 8 : slabdata 797 797 0 : globalstat 713783 956 62223 60550 0 97 0 0 0 : cpustat 3065218 145591 3187693 22345 size-2048(DMA) 0 0 2072 3 2 : tunables 24 12 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-2048 1310 1389 2072 3 2 : tunables 24 12 8 : slabdata 463 463 0 : globalstat 246723 1464 1083 580 0 32 0 0 0 : cpustat 7617180 58434 7634243 40137 size-1024(DMA) 0 0 1048 7 2 : tunables 24 12 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-1024 745 833 1048 7 2 : tunables 24 12 8 : slabdata 119 119 0 : globalstat 444771 938 297 153 0 5 0 0 0 : cpustat 15244362 383299 15265342 361690 size-512(DMA) 0 0 536 7 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-512 710 763 536 7 1 : tunables 32 16 8 : slabdata 109 109 0 : globalstat 407124 882 359 222 0 2 0 0 0 : cpustat 14768006 404798 14778919 393278 size-256(DMA) 0 0 280 14 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-256 333 364 280 14 1 : tunables 32 16 8 : slabdata 26 26 0 : globalstat 787900 406 1621 1583 0 1 0 0 0 : cpustat 554775 53785 604387 3921 size-192(DMA) 0 0 216 18 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-192 3830 3870 216 18 1 : tunables 32 16 8 : slabdata 215 215 0 : globalstat 911778 3922 312 92 0 0 0 0 0 : cpustat 1240863 57400 1294422 106 size-128(DMA) 0 0 152 26 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-128 9102 9152 152 26 1 : tunables 32 16 8 : slabdata 352 352 0 : globalstat 93791 9152 369 16 0 0 0 0 0 : cpustat 43165 6079 40086 56 size-64(DMA) 0 0 88 44 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-32(DMA) 0 0 56 67 1 : tunables 32 16 8 : slabdata 0 0 0 : globalstat 0 0 0 0 0 0 0 0 0 : cpustat 0 0 0 0 size-64 41735 41888 88 44 1 : tunables 32 16 8 : slabdata 952 952 0 : globalstat 764753 41888 1084 1 0 0 0 0 0 : cpustat 774192 48648 779861 1311 size-32 8350 8844 56 67 1 : tunables 32 16 8 : slabdata 132 132 0 : globalstat 945360 8825 132 0 0 0 0 0 0 : cpustat 4171677 94421 4220718 37129 kmem_cache 180 210 256 15 1 : tunables 32 16 8 : slabdata 14 14 0 : globalstat 340 210 14 0 0 0 0 0 0 : cpustat 120 60 0 0 --------------070007060605030807030603 Content-Type: text/plain; name="slabtop" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slabtop" Active / Total Objects (% used) : 1031308 / 1501486 (68.7%) Active / Total Slabs (% used) : 87577 / 87659 (99.9%) Active / Total Caches (% used) : 116 / 179 (64.8%) Active / Total Size (% used) : 275759.16K / 331390.36K (83.2%) Minimum / Average / Maximum Object : 0.04K / 0.22K / 4096.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 460752 150236 32% 0.08K 9599 48 38396K buffer_head 244413 225674 92% 0.40K 27157 9 108628K xfs_inode 242010 225657 93% 0.38K 24201 10 96804K xfs_vnode 215280 171465 79% 0.16K 8970 24 35880K dentry 88368 88272 99% 0.30K 7364 12 29456K radix_tree_node 40456 14457 35% 0.15K 1556 26 6224K size-128 34866 30182 86% 0.05K 447 78 1788K xfs_chashlist 30492 28569 93% 0.09K 693 44 2772K size-64 26936 26931 99% 0.10K 728 37 2912K flow_cache 23870 11671 48% 0.11K 682 35 2728K vm_area_struct 12696 4196 33% 0.04K 138 92 552K anon_vma 10653 7978 74% 0.05K 159 67 636K size-32 10632 4728 44% 0.16K 443 24 1772K filp 8448 8403 99% 0.08K 176 48 704K sysfs_dir_cache 8326 5410 64% 0.16K 362 23 1448K xfs_ili 2682 2158 80% 0.21K 149 18 596K size-192 2508 1456 58% 0.20K 132 19 528K skbuff_head_cache 2220 1423 64% 0.26K 148 15 592K ip_dst_cache 2205 550 24% 0.11K 63 35 252K cfq_io_context 2170 557 25% 0.11K 62 35 248K cfq_queue 2002 1959 97% 0.52K 286 7 1144K size-512 1815 1298 71% 0.26K 121 15 484K nf_conntrack 1690 1514 89% 0.37K 169 10 676K proc_inode_cache 1620 1005 62% 0.39K 162 10 648K sock_inode_cache 1380 1352 97% 2.02K 460 3 3680K size-2048 1180 537 45% 0.06K 20 59 80K pid 1003 328 32% 0.06K 17 59 68K fs_cache 973 898 92% 1.02K 139 7 1112K size-1024 960 684 71% 0.45K 120 8 480K UNIX 855 809 94% 4.00K 855 1 3420K pmd 784 715 91% 0.27K 56 14 224K size-256 658 320 48% 0.27K 47 14 188K files_cache 656 460 70% 0.46K 82 8 328K signal_cache 649 263 40% 0.06K 11 59 44K eventpoll_pwq 644 243 37% 0.04K 7 92 28K biovec-1 644 177 27% 0.04K 7 92 28K tcp_bind_bucket 640 263 41% 0.09K 16 40 64K eventpoll_epi 624 230 36% 0.28K 48 13 192K xfrm_dst_cache 612 269 43% 0.21K 34 18 136K blkdev_requests 609 529 86% 1.33K 203 3 812K task_struct 608 527 86% 0.45K 76 8 304K shmem_inode_cache 600 245 40% 0.09K 15 40 60K bio 590 561 95% 0.06K 10 59 40K Acpi-Operand 484 330 68% 0.09K 11 44 44K drbd_req_cache 469 93 19% 0.05K 7 67 28K blkdev_ioc 468 434 92% 1.30K 156 3 624K sighand_cache 468 422 90% 0.05K 6 78 24K Acpi-Namespace 456 315 69% 0.45K 57 8 228K mm_struct 315 70 22% 0.11K 9 35 36K key_jar 308 278 90% 0.09K 7 44 28K drbd_ee_cache 297 142 47% 0.35K 27 11 108K inode_cache 288 35 12% 0.08K 6 48 24K uid_cache 282 278 98% 16.00K 282 1 4512K size-16384 278 256 92% 4.00K 278 1 1112K size-4096 256 256 100% 0.98K 64 4 256K raid5-md1 256 256 100% 0.98K 64 4 256K raid5-md2 256 256 100% 0.98K 64 4 256K raid5-md3 252 144 57% 0.21K 14 18 56K xfs_buf 243 243 100% 1.19K 81 3 324K TCP 224 154 68% 0.12K 7 32 28K file_lock_cache 212 31 14% 0.07K 4 53 16K biovec-4 201 153 76% 0.05K 3 67 12K secpath_cache 195 178 91% 0.25K 13 15 52K kmem_cache 192 140 72% 0.12K 6 32 24K tw_sock_TCP 176 102 57% 0.17K 8 22 32K xfs_buf_item 170 144 84% 0.38K 17 10 68K skbuff_fclone_cache 160 160 100% 0.09K 4 40 16K request_sock_TCP 156 73 46% 0.05K 2 78 8K ip_fib_hash 156 73 46% 0.05K 2 78 8K ip_fib_alias 147 42 28% 0.18K 7 21 28K arp_cache 134 4 2% 0.05K 2 67 8K uhci_urb_priv 132 128 96% 0.09K 3 44 12K dm_snap_pending_exception 120 87 72% 0.16K 5 24 20K idr_layer_cache 119 101 84% 0.53K 17 7 68K UDP 115 102 88% 0.16K 5 23 20K sigqueue 114 46 40% 0.64K 19 6 76K xfs_trans 106 43 40% 0.07K 2 53 8K inet_peer_cache 96 51 53% 0.08K 2 48 8K xfs_ioend 92 5 5% 0.04K 1 92 4K xfs_bmap_free_item 92 23 25% 0.16K 4 23 16K xfs_btree_cur 92 25 27% 0.04K 1 92 4K xfs_dabuf 87 28 32% 0.13K 3 29 12K mnt_cache --------------070007060605030807030603-- From owner-xfs@oss.sgi.com Mon Dec 17 15:04:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 15:04:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBHN4W9s024103 for ; Mon, 17 Dec 2007 15:04:36 -0800 X-ASG-Debug-ID: 1197932682-7112025d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DD499117603C for ; Mon, 17 Dec 2007 15:04:42 -0800 (PST) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id y0smsRbzZiNjR9xs for ; Mon, 17 Dec 2007 15:04:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HACiNZkc7p6NmWmdsb2JhbACBV44kASCaXQ X-IronPort-AV: E=Sophos;i="4.24,178,1196602200"; d="scan'208";a="19163580" Received: from ppp59-167-163-102.lns1.mel4.internode.on.net (HELO jdc.jasonjgw.net) ([59.167.163.102]) by ipmail05.adl2.internode.on.net with ESMTP; 18 Dec 2007 09:34:40 +1030 Received: from jdc.jasonjgw.net (ip6-localhost [IPv6:::1]) by jdc.jasonjgw.net (8.14.2/8.14.2/Debian-2) with ESMTP id lBHN4cVv007352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Dec 2007 10:04:38 +1100 Received: (from jason@localhost) by jdc.jasonjgw.net (8.14.2/8.14.2/Submit) id lBHN4bem007351 for xfs@oss.sgi.com; Tue, 18 Dec 2007 10:04:37 +1100 Date: Tue, 18 Dec 2007 10:04:37 +1100 From: Jason White To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Installing grub onto a system with XFS root fs Subject: Re: Installing grub onto a system with XFS root fs Message-ID: <20071217230437.GA7169@jdc.jasonjgw.net> Mail-Followup-To: xfs@oss.sgi.com References: <20071217004945.GA13335@jdc.jasonjgw.net> <200712171428.51831.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712171428.51831.Martin@lichtvoll.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1197932684 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36916 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5160/Mon Dec 17 08:46:31 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13979 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jason@jasonjgw.net Precedence: bulk X-list: xfs On Mon, Dec 17, 2007 at 02:28:51PM +0100, Martin Steigerwald wrote: > Using grub shell manually always worked for me: > > - grub > - find /boot/grub/menu.lst > - root > - setup for example (hd0,0) for first harddisks MBR > > Remember to copy over the contents of /usr/lib/grub/i386-pc to /boot > before you do a manual installation. Thanks. Apparently there is XFS support in Grub 2 as well, which is where all development is now taking place. I hope it receives adequate testing and attention before distributions start using Grub 2. I'll gladly volunteer to be part of the beta testing once Grub 2 (and its XFS support) reaches the point of being available for general use and beta testing. Also, I've added a note to the Debian bug report on this subject, referring to this thread. From owner-xfs@oss.sgi.com Mon Dec 17 15:38:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 15:38:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBHNbwKR027030 for ; Mon, 17 Dec 2007 15:38:01 -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 KAA02287; Tue, 18 Dec 2007 10:38:02 +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 lBHNc0IN12121041; Tue, 18 Dec 2007 10:38:01 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBHNbx3F12118440; Tue, 18 Dec 2007 10:37:59 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 18 Dec 2007 10:37:59 +1100 From: David Chinner To: Laurent CARON Cc: David Chinner , xfs@oss.sgi.com Subject: Re: Issue with 2.6.23 and drbd 8.0.7 Message-ID: <20071217233759.GB4396912@sgi.com> References: <20071217143655.chiehahh@trusted.lncsa.com> <20071217220354.GU4396912@sgi.com> <4766F58C.8040000@lncsa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4766F58C.8040000@lncsa.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5160/Mon Dec 17 08:46:31 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13980 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 17, 2007 at 11:17:48PM +0100, Laurent CARON wrote: > David Chinner wrote: > > The symptoms you see are the machine running out of memory and the OOM > > killer being invoked. There's nothing XFS here - you'd do better to post > > to lkml about this. > > So, I was wrong .... :$ > > > Hmmm - you appear to have a highmem based box and have run out of > > low memory for the kernel. So while having ~9.5GB of free high > > memory (that the kernel can't directly use), you're out of low > > memory that the kernel can use and hence it is going OOM. The > > output of /proc/slabinfo or watching slabtop will tell you where > > most of this memory is going. > > Please find attached the output from /proc/slabinfo from both servers, > as well as output from slabtop from server 1. > > > > > FWIW, I suggest upgrading to a 64 bit machine ;) > > I'm currently migrating those 2 servers to 2 64 Bit setups ;) > > Thanks for your advice. > > Laurent > slabinfo - version: 2.1 (statistics) > # name : tunables : slabdata : globalstat : cpustat > xfs_inode 227129 245574 408 9 1 : tunables 32 16 8 : slabdata 27286 27286 > xfs_vnode 227106 243130 392 10 1 : tunables 32 16 8 : slabdata 24313 24313 > radix_tree_node 88310 88356 312 12 1 : tunables 32 16 8 : slabdata 7363 7363 > dentry 170738 215280 160 24 1 : tunables 32 16 8 : slabdata 8970 8970 > buffer_head 150095 460752 80 48 1 : tunables 32 16 8 : slabdata 9599 9599 > slabinfo - version: 2.1 (statistics) > xfs_inode 386493 386505 408 9 1 : tunables 32 16 8 : slabdata 42945 42945 > xfs_vnode 386491 386510 392 10 1 : tunables 32 16 8 : slabdata 38651 38651 > radix_tree_node 56266 56292 312 12 1 : tunables 32 16 8 : slabdata 4691 4691 > dentry 425976 425976 160 24 1 : tunables 32 16 8 : slabdata 17749 17749 > buffer_head 794845 794976 80 48 1 : tunables 32 16 8 : slabdata 16562 16562 > Active / Total Objects (% used) : 1031308 / 1501486 (68.7%) > Active / Total Slabs (% used) : 87577 / 87659 (99.9%) > Active / Total Caches (% used) : 116 / 179 (64.8%) > Active / Total Size (% used) : 275759.16K / 331390.36K (83.2%) > Minimum / Average / Maximum Object : 0.04K / 0.22K / 4096.00K > > OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME > 460752 150236 32% 0.08K 9599 48 38396K buffer_head > 244413 225674 92% 0.40K 27157 9 108628K xfs_inode > 242010 225657 93% 0.38K 24201 10 96804K xfs_vnode > 215280 171465 79% 0.16K 8970 24 35880K dentry > 88368 88272 99% 0.30K 7364 12 29456K radix_tree_node Hmmm - no real surprises there, but the numbers are well lower than the ~960MB low memory limit. I suspect that there's something at around 2.55am that does a filesystem traversal and that blows out the memory usage of these slab caches and you run out of lowmem... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 17 16:35:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 16:35:40 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBI0ZQDZ003651 for ; Mon, 17 Dec 2007 16:35:29 -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 LAA04295 for ; Tue, 18 Dec 2007 11:35:38 +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 lBI0ZbIN12136908 for ; Tue, 18 Dec 2007 11:35:38 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBI0Zawp12137607 for xfs@oss.sgi.com; Tue, 18 Dec 2007 11:35:36 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 18 Dec 2007 11:35:36 +1100 From: David Chinner To: xfs@oss.sgi.com Subject: Re: Installing grub onto a system with XFS root fs Message-ID: <20071218003536.GD4396912@sgi.com> References: <20071217004945.GA13335@jdc.jasonjgw.net> <200712171428.51831.Martin@lichtvoll.de> <20071217230437.GA7169@jdc.jasonjgw.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071217230437.GA7169@jdc.jasonjgw.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5160/Mon Dec 17 08:46:31 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13981 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 10:04:37AM +1100, Jason White wrote: > On Mon, Dec 17, 2007 at 02:28:51PM +0100, Martin Steigerwald wrote: > > > Using grub shell manually always worked for me: > > > > - grub > > - find /boot/grub/menu.lst > > - root > > - setup for example (hd0,0) for first harddisks MBR > > > > Remember to copy over the contents of /usr/lib/grub/i386-pc to /boot > > before you do a manual installation. > > Thanks. > > Apparently there is XFS support in Grub 2 as well, which is where all > development is now taking place. I hope it receives adequate testing and > attention before distributions start using Grub 2. I just looked at the XFS code in ithe grub 2 CVS repository and had a read of the wiki (http://grub.enbug.org/). From the code and the wiki, I note that there is no indication of grub 2 fixing the worst design mistakes in grub and is persisting with stuffing around with filesystem internals to find files and get block mappings for file data. Hence grub 2 will break just like grub if we ever change things on disk like the inode, directory or extent format. Lucky it doesn't support btree formats yet, so that won't break if we change them.... And there's plans on doing *journal replay* for filesystems! (#1 item on the todo list here: http://grub.enbug.org/TodoList). That's an insane layering violation and completely unsupportable by anyone. I certainly hope this part of the plan for grub 2 never gets implemented. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 17 17:51:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 17:51: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=2.1 required=5.0 tests=BAYES_05,HTML_MESSAGE, J_CHICKENPOX_53,J_CHICKENPOX_54 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBI1pCov009561 for ; Mon, 17 Dec 2007 17:51:13 -0800 X-ASG-Debug-ID: 1197942682-1756002b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1A0154941AC for ; Mon, 17 Dec 2007 17:51:23 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by cuda.sgi.com with ESMTP id oLF7u1tTo9fmp8d4 for ; Mon, 17 Dec 2007 17:51:23 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so4017158waf.18 for ; Mon, 17 Dec 2007 17:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=EttJba9Una9pnjZNIjWfHcVrfZHAWnI65zZ74LY4a0w=; b=CE6izH2p66TrPPfGdhraZW/CcYO5KNjkwxwWrJjMUM1kESzjnXu8qGfZk6Zvh9WjDJOTE9udJc2/ZTqzyfznubL+eH5JSwe5hxKPlEk3gIa8cX27Z/6SkvMJBPGWenNhAiTo4P6SkXp1aM0Dxt9sy5HIK5yS+mIOMaUZFpZlIh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=OUk3eAuUu2WWipYZtOWa2jlHQ4EhZO/AGA86NrAD/zc/q3n+XjxeEaqJfwCBaXWRa1WMN9LKzst3B0yEYD52Ua2+WdduddhfApQmlIy15FeXpUlaJKdVLHuA2q1+P3jki8cvDydI0fipPlCDCwKkbDm5ajAmC4SdU0Dwtw7QOMQ= Received: by 10.114.151.13 with SMTP id y13mr740217wad.60.1197942681198; Mon, 17 Dec 2007 17:51:21 -0800 (PST) Received: by 10.114.180.4 with HTTP; Mon, 17 Dec 2007 17:51:21 -0800 (PST) Message-ID: Date: Tue, 18 Dec 2007 07:21:21 +0530 From: sudheer To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs problem ? Subject: xfs problem ? MIME-Version: 1.0 X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.182] X-Barracuda-Start-Time: 1197942684 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_RULE7568M, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36929 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M BODY: Custom Rule 7568M 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5163/Mon Dec 17 16:29:09 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 3534 X-archive-position: 13982 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ssudheer@gmail.com Precedence: bulk X-list: xfs Sir , When i run tail -f /var/log/messages -------------------------------------------------------------- Dec 17 20:50:42 u15200848 kernel: [] pdflush+0x0/0x50 Dec 17 20:50:42 u15200848 kernel: [] __pdflush+0xbc/0x1b0 Dec 17 20:50:42 u15200848 kernel: [] pdflush+0x3d/0x50 Dec 17 20:50:42 u15200848 kernel: [] wb_kupdate+0x0/0x140 Dec 17 20:50:42 u15200848 kernel: [] kthread+0xba/0xc0 Dec 17 20:50:42 u15200848 kernel: [] kthread+0x0/0xc0 Dec 17 20:50:42 u15200848 kernel: [] kernel_thread_helper+0x5/0x10 Dec 17 20:50:42 u15200848 kernel: 0x0: 58 41 47 46 00 00 00 01 00 00 00 0a 00 18 c5 15 Dec 17 20:50:42 u15200848 kernel: Filesystem "hda7": XFS internal error xfs_alloc_read_agf at line 2173 of file fs/xfs/xfs_alloc.c. Caller 0xc01dc223 Dec 17 20:50:42 u15200848 kernel: [] xfs_alloc_read_agf+0xed/0x1b0 Dec 17 20:50:42 u15200848 kernel: [] xfs_alloc_pagf_init+0x33/0x60 Dec 17 20:50:42 u15200848 last message repeated 2 times Dec 17 20:50:42 u15200848 kernel: [] xfs_bmap_alloc+0x8e4/0xed0 Dec 17 20:50:42 u15200848 kernel: [] xfs_bmap_search_extents+0x80/0x130 Dec 17 20:50:42 u15200848 kernel: [] xfs_dqunlock+0x40/0x50 Dec 17 20:50:42 u15200848 kernel: [] xfs_bmapi+0x1270/0x1730 Dec 17 20:50:42 u15200848 kernel: [] xfs_bmbt_get_state+0x2f/0x40 Dec 17 20:50:42 u15200848 kernel: [] xfs_bmap_do_search_extents+0xf8/0x440 Dec 17 20:50:42 u15200848 kernel: [] xlog_grant_push_ail+0x44/0x130 Dec 17 20:50:42 u15200848 kernel: [] xfs_log_reserve+0xc6/0xd0 Dec 17 20:50:42 u15200848 kernel: [] xfs_iomap_write_allocate+0x2ee/0x5d0 Dec 17 20:50:42 u15200848 kernel: [] xfs_iomap+0x406/0x540 Dec 17 20:50:42 u15200848 kernel: [] xfs_map_blocks+0x58/0x90 Dec 17 20:50:42 u15200848 kernel: [] xfs_page_state_convert+0x48c/0x7c0 Dec 17 20:50:42 u15200848 kernel: [] submit_bio+0x62/0x100 Dec 17 20:50:42 u15200848 kernel: [] find_get_pages_tag+0x41/0x90 ------------------------------------------------------------------------------------------------------------------------- Is this a problem with the xfs file system ? in the hda7 partition ? .How can i correct this on live server ? Filesystem "hda7": LABEL=/ / ext3 defaults 1 1 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/hda2 swap swap defaults 0 0 LABEL=usr /usr xfs defaults 1 2 LABEL=var /var xfs defaults,usrquota 1 2 LABEL=home /home xfs defaults,usrquota 1 2 --------------------------------------------------------------------------------------------------------------------------------------- Filesystem Size Used Avail Use% Mounted on /dev/hda1 989M 513M 426M 55% / none 1010M 0 1010M 0% /dev/shm /dev/hda5 4.9G 1.9G 3.0G 39% /usr /dev/hda7 100G 50G 50G 50% /var /dev/hda6 4.9G 148K 4.9G 1% /home ------------------------------------------------------------------------------------------------------- Thanks for all the help Sudheer [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Dec 17 20:10:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 20:10:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-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.11/SuSE Linux 0.7) with SMTP id lBI4AkZm019629 for ; Mon, 17 Dec 2007 20:10:49 -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 PAA10873; Tue, 18 Dec 2007 15:10:47 +1100 Message-ID: <47674892.9070506@sgi.com> Date: Tue, 18 Dec 2007 15:12:02 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Christoph Hellwig CC: Donald Douwsma , xfs-oss , gnb@sgi.com Subject: Re: [review] Remove the xfs refcache References: <4765EC66.5020202@sgi.com> <4765F444.8010705@sgi.com> <20071217071426.GA11462@infradead.org> In-Reply-To: <20071217071426.GA11462@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5163/Mon Dec 17 16:29:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13983 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 Christoph Hellwig wrote: > On Mon, Dec 17, 2007 at 03:00:04PM +1100, Lachlan McIlroy wrote: >> Hey hold on there buddy! We may need to reactivate this code to fix some >> performance issues. I've acttually got this code working and proven that >> it is one way to fix some of the NAS/NFS issues we have. >> >> The little comment that reads "reference cache not needed for NFS in 2.6" >> is wrong - we do need it or something like it. > > Not in XFS, though. This thing needs to be done genericly in NFSD. > Greg has been working on an open files cache in nfsd which should be > helping this. > > Adding a cache like this back into XFS will get my veto (at least for > mainline where I have a bit of a say :)) > Greg's NFS OFC will provide better performance for strictly NFS workloads and if all we are trying to fix here is the NFS issues then I agree with you that the OFC should not go into XFS. Since I have been able to reproduce some of our NAS/NFS performance problems without NFS (that is demonstrate that the problems are in XFS) it makes some sense to fix these in XFS. I have observed that for some non-NFS workloads we see a significant reduction in log traffic with the OFC in XFS so for reasons beyond NFS there may be a need to reactivate the refcache code. For the moment we are still analysing the pros/cons. From owner-xfs@oss.sgi.com Mon Dec 17 20:48:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 20:48: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=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBI4mUqZ003305 for ; Mon, 17 Dec 2007 20:48:32 -0800 X-ASG-Debug-ID: 1197953322-353900130000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wr-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2B91A494E4C for ; Mon, 17 Dec 2007 20:48:42 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by cuda.sgi.com with ESMTP id 8T8VEOo4Zj2SaryQ for ; Mon, 17 Dec 2007 20:48:42 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id c48so1458137wra.23 for ; Mon, 17 Dec 2007 20:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=Kn8+gxiWB3mrEJRJtQipsEhwwY2YYo9As1xVg4uJUJI=; b=Mxo3MBZ3dUxRUj9YGf86lvImL4Roxi7iacoo+yjk5mKItI8nJeCtPQIiWm7Dq7ezMmXGPI7iwb96stxXYV/MZd7usxAAAB4eICKX35ZvP+dJJ5/u3/iB80cVi3fnNGQSIKCs3XblHNn1HkwOUEwuLNgUyGfKbCFd8I8koL2rxjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nuObdAIcdlcNrW2xFvASIjEM6ZCxk1ufbPLkDAr9llF1BkI+EB/4QLaaQvstyOAfZHd5DADgC2jyM/WdrgQW4TqhTi+YYurlxWjcmvljF/F5RCZyRDlRAvV7eSFrpq9xGakJ8WoajiRRcBXfCanM2uPVTegdAmxs0RprqJeSlr8= Received: by 10.151.6.2 with SMTP id j2mr2768849ybi.86.1197953320534; Mon, 17 Dec 2007 20:48:40 -0800 (PST) Received: by 10.151.8.1 with HTTP; Mon, 17 Dec 2007 20:48:40 -0800 (PST) Message-ID: Date: Mon, 17 Dec 2007 20:48:40 -0800 From: "Bret Towe" To: linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: xfs mknod regression Subject: xfs mknod regression MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Barracuda-Connect: wr-out-0506.google.com[64.233.184.230] X-Barracuda-Start-Time: 1197953323 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36940 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5163/Mon Dec 17 16:29:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13984 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: magnade@gmail.com Precedence: bulk X-list: xfs I hit a bug in 2.6.24-rc looks to be in 2.6.23 also so not sure how long it's been there with an xfs filesystem pbuilder has an issue using device files it makes for chroot the mknod command looks to work fine the file is created however when attempting to use one of the created files you see something like the below ghoststar dev # echo "hi" > null bash: null: No such device or address ghoststar dev # ls -l null crw-rw-rw- 1 root root 1, 3 2007-12-17 20:34 null ghoststar dev # ls -l /dev/null crw-rw-rw- 1 root root 1, 3 2007-10-05 17:29 /dev/null ghoststar dev # echo "hi" > /dev/null ghoststar dev # I have not done any bisecting yet if needed I can narrow it down the minor work around I found was to just mount an ext3 filesystem where pbuilder builds From owner-xfs@oss.sgi.com Mon Dec 17 22:59:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 22:59:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBI6x6Hs020325 for ; Mon, 17 Dec 2007 22:59:10 -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 RAA14608; Tue, 18 Dec 2007 17:59:12 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id EDC8158C4C0F; Tue, 18 Dec 2007 17:59:11 +1100 (EST) Date: Tue, 18 Dec 2007 17:59:11 +1100 To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.24-rc6 User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20071218065911.EDC8158C4C0F@chook.melbourne.sgi.com> From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/5163/Mon Dec 17 16:29:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13985 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/linux-2.6/xfs_file.c | 4 ++-- fs/xfs/xfs_dir2_block.c | 6 ++---- fs/xfs/xfs_dir2_leaf.c | 2 +- fs/xfs/xfs_dir2_sf.c | 9 +++------ fs/xfs/xfs_inode.c | 6 ++++-- 5 files changed, 12 insertions(+), 15 deletions(-) through these commits: commit 041388b54ed95cd169546bd83bacd08ee32bd7ea Author: Lachlan McIlroy Date: Tue Dec 18 16:19:34 2007 +1100 [XFS] Put the correct offset in dirent d_off The recent filldir regression fix was not putting the correct d_off in each dirent. This was resulting in incorrect cookies being passed to dmapi ioctls and the wrong offset appearing in the dirents. readdir was unaffected as the filp->f_pos was being updated with the correct offset and this was being written into the last dirent in each buffer. Fix the XFS code to do the right thing. SGI-PV: 973746 SGI-Modid: xfs-linux-melb:xfs-kern:30240a Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Lachlan McIlroy commit c734c79bc397eace039bea406997efa89f879c14 Author: Lachlan McIlroy Date: Tue Dec 18 16:17:41 2007 +1100 [XFS] Don't wait for pending I/Os when purging blocks beyond eof. On last close of a file we purge blocks beyond eof. The same code is used when we truncate the file size down. In this case we need to wait for any pending I/Os for dirty pages beyond the new eof. For the last close case we are not changing the file size and therefore do not need to wait for any I/Os to complete. This fixes a performance bottleneck where writes into the page cache and cache flushes can become mutually exclusive. SGI-PV: 964002 SGI-Modid: xfs-linux-melb:xfs-kern:30220a Signed-off-by: Lachlan McIlroy Signed-off-by: Peter Leckie From owner-xfs@oss.sgi.com Mon Dec 17 23:44:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 17 Dec 2007 23:44: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.11/SuSE Linux 0.7) with SMTP id lBI7i3Zt024379 for ; Mon, 17 Dec 2007 23:44:08 -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 SAA15738; Tue, 18 Dec 2007 18:44:07 +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 lBI7i6IN11151831; Tue, 18 Dec 2007 18:44:07 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBI7i5Xn12150898; Tue, 18 Dec 2007 18:44:05 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 18 Dec 2007 18:44:05 +1100 From: David Chinner To: Lachlan McIlroy Cc: Christoph Hellwig , Donald Douwsma , xfs-oss , gnb@sgi.com Subject: Re: [review] Remove the xfs refcache Message-ID: <20071218074405.GI4396912@sgi.com> References: <4765EC66.5020202@sgi.com> <4765F444.8010705@sgi.com> <20071217071426.GA11462@infradead.org> <47674892.9070506@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47674892.9070506@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5163/Mon Dec 17 16:29:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13986 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 03:12:02PM +1100, Lachlan McIlroy wrote: > Since I have been able to reproduce some of our NAS/NFS performance problems > without NFS (that is demonstrate that the problems are in XFS) it makes some > sense to fix these in XFS. I have observed that for some non-NFS workloads > we see a significant reduction in log traffic with the OFC in XFS so for > reasons beyond NFS there may be a need to reactivate the refcache code. For > the moment we are still analysing the pros/cons. Reactivating the ref cache is fundamentally the wrong thing to do. Most of these problems come from the mismatch of inode life cycles between Linux and XFS and this is the basic problem we need to solve. For example - do the open-write-close related performance issues go away if you remove the xfs_free_eofblocks() call in xfs_release()? i.e. are we just being stupid about the way we deal with closing of file descriptors? This should work because the linux inode will remain around with a ref-count of 1 on the unused list due to the dentry pinning it in place. Only when the dentry gets reclaimed (e.g. memory pressure, unlink, unmount, etc) will the truncate occur, and hence repeated single file open-write-close based workloads (like the nfsd) don't issue a truncate transaction and trash the EOF preallocation on every close.... And look at the code - the *only thing* the refcache does is avoid the truncate in xfs_release(). So, the patch below is the equivalent of re-introducing the refcache into XFS but uses the linux inode life cycle to keep references around. FWIW, this means that EOF pre-allocations will not get trimmed immediately which may have disk usage implications for users with small quotas, those that create lots of small files, or there are lots of written inodes with prealocated space cached in memory when a crash occurs. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group Don't truncate EOF blocks on ->release Avoid truncating EOF blocks on final close of an filp and delay it till the inode is reclaimed. While this puts more pressure on xfs_inactive() during reclaim, it means that we avoid lots of needless transactions on open-write-close type workloads (eg as done by the nfsd code). Note that this means that while inodes are cached in memory they may be consuming more blocks than their size may indicate and this space will not be reclaimed if the machine crashes. Signed-off-by: Dave Chinner --- fs/xfs/xfs_vnodeops.c | 24 ------------------------ 1 file changed, 24 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vnodeops.c 2007-12-10 12:04:17.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c 2007-12-18 18:17:57.188146022 +1100 @@ -1504,7 +1504,6 @@ xfs_release( { bhv_vnode_t *vp = XFS_ITOV(ip); xfs_mount_t *mp = ip->i_mount; - int error; if (!VN_ISREG(vp) || (ip->i_d.di_mode == 0)) return 0; @@ -1540,29 +1539,6 @@ xfs_release( if (truncated && VN_DIRTY(vp) && ip->i_delayed_blks > 0) xfs_flush_pages(ip, 0, -1, XFS_B_ASYNC, FI_NONE); } - -#ifdef HAVE_REFCACHE - /* If we are in the NFS reference cache then don't do this now */ - if (ip->i_refcache) - return 0; -#endif - - if (ip->i_d.di_nlink != 0) { - if ((((ip->i_d.di_mode & S_IFMT) == S_IFREG) && - ((ip->i_size > 0) || (VN_CACHED(vp) > 0 || - ip->i_delayed_blks > 0)) && - (ip->i_df.if_flags & XFS_IFEXTENTS)) && - (!(ip->i_d.di_flags & - (XFS_DIFLAG_PREALLOC | XFS_DIFLAG_APPEND)))) { - error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); - if (error) - return error; - /* Update linux inode block count after free above */ - vn_to_inode(vp)->i_blocks = XFS_FSB_TO_BB(mp, - ip->i_d.di_nblocks + ip->i_delayed_blks); - } - } - return 0; } From owner-xfs@oss.sgi.com Tue Dec 18 00:13:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 00:13:22 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBI8DGng028706 for ; Tue, 18 Dec 2007 00:13:18 -0800 X-ASG-Debug-ID: 1197965606-438400420000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sargon.lncsa.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6CB93495A01 for ; Tue, 18 Dec 2007 00:13:27 -0800 (PST) Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by cuda.sgi.com with ESMTP id L8LUIxg4uF8lFTCF for ; Tue, 18 Dec 2007 00:13:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id A17EC311D4B4; Tue, 18 Dec 2007 09:13:24 +0100 (CET) X-Virus-Scanned: ClamAV 0.91.2/5163/Mon Dec 17 16:29:09 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4EZjAFYmRiO; Tue, 18 Dec 2007 09:13:24 +0100 (CET) Received: from [192.168.0.31] (donald.lncsa.com [192.168.0.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by sargon.lncsa.com (Postfix) with ESMTP id 8C5AE311CD13; Tue, 18 Dec 2007 09:13:24 +0100 (CET) Message-ID: <47678124.80906@lncsa.com> Date: Tue, 18 Dec 2007 09:13:24 +0100 From: Laurent CARON User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Issue with 2.6.23 and drbd 8.0.7 Subject: Re: Issue with 2.6.23 and drbd 8.0.7 References: <20071217143655.chiehahh@trusted.lncsa.com> <20071217220354.GU4396912@sgi.com> <4766F58C.8040000@lncsa.com> <20071217233759.GB4396912@sgi.com> In-Reply-To: <20071217233759.GB4396912@sgi.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sargon.lncsa.com[212.99.8.251] X-Barracuda-Start-Time: 1197965609 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36952 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 13987 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lcaron@lncsa.com Precedence: bulk X-list: xfs David Chinner wrote: > Hmmm - no real surprises there, but the numbers are well lower than the > ~960MB low memory limit. I suspect that there's something at around > 2.55am that does a filesystem traversal and that blows out the memory > usage of these slab caches and you run out of lowmem... Thanks David for this information, On the previous setup (same pieces of software), we didn't had that kind of problem. Do you think that more memory is used while using XFS on a filesystem traversal than with ReiserFS (the previous setup used ReiserFS)? I'm of course not trying to blame XFS, but trying to understand what really happens there. Laurent From owner-xfs@oss.sgi.com Tue Dec 18 01:00:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 01:00:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_50,SUBJ_ALL_CAPS autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBI903te004282 for ; Tue, 18 Dec 2007 01:00:07 -0800 X-ASG-Debug-ID: 1197968414-438400b10000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ro-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8944B495B2B for ; Tue, 18 Dec 2007 01:00:14 -0800 (PST) Received: from ro-out-1112.google.com (ro-out-1112.google.com [72.14.202.177]) by cuda.sgi.com with ESMTP id z8nbGJhgRlRCIt7W for ; Tue, 18 Dec 2007 01:00:14 -0800 (PST) Received: by ro-out-1112.google.com with SMTP id o32so3556025rog.12 for ; Tue, 18 Dec 2007 01:00:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:subject:mime-version:content-type; bh=BEFBK4XNan5CWfoleI6oBajTZAJb5/JzZVi5OAczl/A=; b=mU/a9AtsmQGs80R9pR9MS73S8f/QTo3gMfIWi/6QxTzE2onsQTV4UqFgeN9yUtqD8XArbNnnzSAnBb31FEAjEWDGbCNaZO13bAAuCKaCJr+wjHgdlE5leiKwetNcBJnXqXR5PsIS3jMc7v/kPHaaUihj0ttVa4wS0JbPfs6Yo2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:subject:mime-version:content-type; b=Cf+zdPuwwhSEREheFZu972lTRiOuwvBcdQ0KexPdDaAwbO91YKBTmNxk0aiC2z8A0Q3d1kUILCkv/STR14iM4jbFiF0BnCSflAeKlls90lmOcl+WlIxAXScORY2ZYvudE9epnRyg40i8pSld8MhZeUlZ85w5lEE0Y/N6g6+FI0k= Received: by 10.141.171.6 with SMTP id y6mr4742476rvo.85.1197968379047; Tue, 18 Dec 2007 00:59:39 -0800 (PST) Received: by 10.141.163.20 with HTTP; Tue, 18 Dec 2007 00:59:38 -0800 (PST) Message-ID: <3629bd3a0712180059l44e9fb79m79c6be2ae0a735d1@mail.gmail.com> Date: Tue, 18 Dec 2007 00:59:38 -0800 From: "James Reynolds" X-ASG-Orig-Subj: LETTER FOR WARNER Subject: LETTER FOR WARNER MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6551_12916419.1197968379043" X-Barracuda-Connect: ro-out-1112.google.com[72.14.202.177] X-Barracuda-Start-Time: 1197968415 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0034 1.0000 -1.9988 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.68 X-Barracuda-Spam-Status: No, SCORE=-1.68 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=MISSING_HEADERS, TO_CC_NONE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36956 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.19 MISSING_HEADERS Missing To: header 0.13 TO_CC_NONE No To: or Cc: header To: undisclosed-recipients:; X-Virus-Scanned: ClamAV 0.91.2/5163/Mon Dec 17 16:29:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13988 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jamesreynoldslawfirm023@gmail.com Precedence: bulk X-list: xfs ------=_Part_6551_12916419.1197968379043 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline PLEASE VIEW ATTACHMENT REGARDING LATE DR.EDWARD WARNER ESTATE ------=_Part_6551_12916419.1197968379043 Content-Type: application/msword; name="LETTER FOR WARNER.doc" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 Content-Disposition: attachment; filename="LETTER FOR WARNER.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAANQAAAAAAAAAAEAAANwAAAAEAAAD+////AAAAADQAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////spcEAcWAJBAAA+BK/AAAAAAAAEAAAAAAABgAA XxEAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAAAAAJBBYALiAAABM6AQAT OgEAXwkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAA AAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAOADAAAA AAAA4AMAAOADAAAAAAAA4AMAAAAAAADgAwAAAAAAAOADAAAAAAAA4AMAABQA AAAAAAAAAAAAAPQDAAAAAAAAnAgAAAAAAACcCAAAAAAAAJwIAAAAAAAAnAgA ACQAAADACAAAFAAAAPQDAAAAAAAA/g8AAMoBAADgCAAAFgAAAPYIAAAAAAAA 9ggAAAAAAAD2CAAAAAAAAPYIAAAAAAAA5QoAAAAAAADlCgAAAAAAAOUKAAAA AAAAfQ8AAAIAAAB/DwAAAAAAAH8PAAAAAAAAfw8AAAAAAAB/DwAAAAAAAH8P AAAAAAAAfw8AACQAAADIEQAAaAIAADAUAABoAAAAow8AABUAAAAAAAAAAAAA AAAAAAAAAAAA4AMAAAAAAAAvDAAAAAAAAAAAAAAAAAAAAAAAAAAAAADhCgAA BAAAAOUKAAAAAAAALwwAAAAAAAAvDAAAAAAAAKMPAAAAAAAAAAAAAAAAAADg AwAAAAAAAOADAAAAAAAA9ggAAAAAAAAAAAAAAAAAAPYIAADrAQAAuA8AABYA AAAXDQAAAAAAABcNAAAAAAAAFw0AAAAAAAAvDAAACgAAAOADAAAAAAAA9ggA AAAAAADgAwAAAAAAAPYIAAAAAAAAfQ8AAAAAAAAAAAAAAAAAABcNAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAALwwAAAAAAAB9DwAAAAAAAAAAAAAAAAAAFw0AAAAAAAAAAAAAAAAAABcN AAAAAAAA4AMAAAAAAADgAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFw0AAAAAAAD2CAAA AAAAANQIAAAMAAAA4Ik1BkVByAEAAAAAAAAAAJwIAAAAAAAAOQwAAAoAAAAX DQAAAAAAAAAAAAAAAAAAfQ8AAAAAAADODwAAMAAAAP4PAAAAAAAAFw0AAAAA AACYFAAAAAAAAEMMAADKAAAAmBQAAAAAAAAXDQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAXDQAAJgAAAJgUAAAAAAAAAAAAAAAAAADgAwAAAAAAAD0NAABA AgAA5QoAADAAAAAVCwAAIgAAABcNAAAAAAAANwsAABwAAABTCwAA3AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5QoAAAAAAADlCgAAAAAA AOUKAAAAAAAAow8AAAAAAACjDwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADQ0AAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAOUKAAAAAAAA5QoAAAAAAADlCgAAAAAAAP4PAAAAAAAALwwAAAAA AAAvDAAAAAAAAC8MAAAAAAAALwwAAAAAAAAAAAAAAAAAAPQDAAAAAAAA9AMA AAAAAAD0AwAAJAMAABgHAACEAQAA9AMAAAAAAAD0AwAAAAAAAPQDAAAAAAAA GAcAAAAAAAD0AwAAAAAAAPQDAAAAAAAA9AMAAAAAAADgAwAAAAAAAOADAAAA AAAA4AMAAAAAAADgAwAAAAAAAOADAAAAAAAA4AMAAAAAAAD/////AAAAAAIA DAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1KQU1F UyBSRVlOT0xEUyBMQVcgRklSTQ1MZWdhbCBQcmFjdGl0aW9uZXJzIA1Oby40 MCBSaWJhZHUgV2F5IElrb3lpIExhZ29zDQ0NQVRURU5USU9OIFdBUk5FUjog IAkJCQkJCQkJICAgICAgICAgICAgICAgICAgICAgICAgIA0NUkVRVUVTVCBG T1IgQVNTSVNUQU5DRS9UUkFOU0ZFUiBPRiBVTkNMQUlNRUQgRlVORFMNDQ1E TyBBQ0NFUFQgTVkgU0lOQ0VSRSBBUE9MT0dJRVMgSUYgTVkgTUFJTCBET0VT IE5PVCBNRUVUIFlPVVIgUEVSU09OQUwgRVRISUNTLiBGT1IgSSBOT1cgVEhJ UyBNQVkgU0VFTSBMSUtFIEEgQ09NUExFVEUgSU5UUlVTSU9OIFRPIFlPVVIg UFJJVkFDWSBCVVQgUklHSFQgQUJPVVQgTk9XIFRISVMgSVMgTVkgT1BUSU9O IE9GIENPTU1VTklDQVRJT04uIEJVVCBJIEJFTElFVkUgVEhJUyBJUyBTVElM TCBUSEUgTU9TVCBHRU5VSU5FIFdBWSBPRiBDT05UQUNUSU5HIEEgVFJVRSBD SEFSQUNURVIuDQ1JIEpBTUVTIFJFWU5PTERTLCBBIFNPTElDSVRPUiBBVCBM QVcuIEkgQU0gVEhFIFBFUlNPTkFMIEFUVE9STkVZIFRPIExBVEUgRFIuRURX QVJEIFdBUk5FUiBXSE8gV0FTIEFOIE9JTCBNRVJDSEFOVCBBTkQgQ09OVFJB Q1RPUiBXSVRIIFRIRSBGRURFUkFMIEdPVkVSTk1FTlQgT0YgTklHRVJJQSBV TlRJTCBISVMgREVBVEggT05CT0FSRCBUSEUgSUxMIEZBVEVEIEJFTklOIEFJ UldBWVMgQlVTIHtBMzEwMzAwfSBPTiBUSEUgMjZUSCBPRiBERUNFTUJFUiAy MDAzIFdBUyBBIENVU1RPTUVSIEFUIFRIRSBDQVBJVEFMIFRSVVNUIEJBTksg UExDIEFORCBIQUQgQSBCQUxBTkNFIE9GIFVTJDMyIE1JTExJT04gV0hJQ0gg VEhFIEJBTksgTk9XIEVYUEVDVFMgSElTIE5FWFQgT0YgS0lOIFRPIENMQUlN IEFTIFRIRSBCRU5FRklDSUFSWS4NDVNPIEZBUiwgVkFMVUFCTEUgRUZGT1JU UyBIQVMgQkVFTiBNQURFIFRPIEdFVCBUTyBISVMgUEVPUExFIEJVVCBUTyBO TyBBVkFJTCwgQVMgSEUgSEFEIE5PIEtOT1dOIFJFTEFUSVZFUyBCRUNBVVNF IEhFIExFRlQgSElTIE5FWFQgT0YgS0lOIENPTFVNTiBJTiBISVMgQUNDT1VO VCBPUEVOSU5HIEZPUk1TIEJMQU5LLCBJIEtOT1cgVEhBVCBUSElTIE1JR0hU IE1BS0UgWU9VIFdPUlJZIEFORCBBUFBSRUhFTlNJVkUsIEJVVCBJIEhBVkUg TUFERSBGUkFOVElDIEVGRk9SVFMgSU4gTE9DQVRJTkcgTVkgQ0xJRU5UUyBF WFRFTkRFRCBSRUxBVElWRVMgRFVFIFRPIFRISVMgREVWRUxPUE1FTlQgVEhF IE1BTkFHRU1FTlQgQU5EIFRIRSBCT0FSRCBPRiBESVJFQ1RPUlMgT0YgQ0FQ SVRBTCBUUlVTVCBCQU5LIElTU1VFRCBNRSBBIE5PVElDRSBUTyBQUk9WSURF IFRIRSBORVhUIE9GIEtJTiBPUiBUSEVZIFdJTEwgREVDTEFSRSBGVU5EUyBV TkNMQUlNRUQgQU5EIFNVQlNFUVVFTlRMWSBQQVkgSVQgSU5UTyBUSEUgR09W RVJOTUVOVCBQVVJTRSBJTiBBQ0NPUkRBTkNFIFRPIFRIRSBOSUdFUklBIEJB TktJTkcgTEFXUy4gVVNVQUxMWSBGVU5EUyBPRiBUSElTIE5BVFVSRSBFTkQg VVAgSU4gVEhFIEdSRUVEWSBQT0NLRVRTIE9GIE9VUiBQT0xJVElDSUFOUyBE VUUgVE8gT1VSIENPUlJVUFQgU09DSUVUWSBUSEFUIElTIFdIWSBJIEFNIFdP UlJJRUQuIA0NVE8gQVZFUlQgVEhJUyBORUdBVElWRSBERVZFTE9QTUVOVCwg U0lOQ0UgSSBIQVZFIEJFRU4gVU5TVUNDRVNTRlVMIElOIExPQ0FUSU5HIEEg UkVMQVRJVkUsIEkgU0VFSyBZT1VSIENPTlNFTlQgVE8gUFJFU0VOVCBZT1Ug QVMgVEhFIE5FWFQgT0YgS0lOIFRPIE1ZIExBVEUgQ0xJRU5ULCBTTyBUSEFU IFRIRSBQUk9DRUVEUyBPRiBUSElTIERFUE9TSVQgQkUgU0VOVCBUTyBZT1VS IEFDQ09VTlQgRk9SIE9VUiBPV04gQkVORUZJVC4gQUxMIExFR0FMIERPQ1VN RU5UUyBUTyBBSUQgWU9VUiBDTEFJTSBGT1IgVEhJUyBGVU5EIEFORCBUTyBQ Uk9WRSBZT1VSIFJFTEFUSU9OU0hJUCBXSVRIIFRIRSBERUNFQVNFRCBXSUxM IEJFIEFSUkFOR0VEIEJZIE1ZIEFTU09DSUFURVMgQU5EIEkuIFlPVVIgSEVM UCBXSUxMIEJFIEFQUFJFQ0lBVEVEIFdJVEggMjAlIE9GIFRIRSBUT1RBTCBT VU0gKFVTJDYsNDAwLDAwMCkuIFBMRUFTRSBBQ0NFUFQgTVkgQVBPTE9HSUVT LCBLRUVQIE1ZIENPTkZJREVOQ0UgQU5EIERJU1JFR0FSRCBUSElTIExFVFRF UiBJRiBZT1UgRE8gTk9UIEFQUFJFQ0lBVEUgVEhJUyBQUk9QT1NJVElPTiBJ IEhBVkUgT0ZGRVJFRCBZT1UuIEkgV0FJVCBBTlhJT1VTTFkgRk9SIFlPVVIg UkVTUE9OU0UuDQ1ZT1VSUyBGQUlUSEZVTExZLA0NQkFSUklTVEVSIEpBTUVT IFJFWU5PTERTLg1QSE9ORTogMjM0LTgwLTM0MTE2ODA5DVBSRUZFUlJFRCBF TUFJTDogEyBIWVBFUkxJTksgIm1haWx0bzpKQU1FU1JFWU5PTERTTEFXRklS TTZAWUFIT08uQ08uVUsiIAEUSkFNRVNSRVlOT0xEU0xBV0ZJUk02QFlBSE9P LkNPLlVLFQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAQgAAA8I AAAYCAAAGQgAAB8IAAAsCAAALQgAAC4IAAA7CAAASggAAEsIAABMCAAA6tXA r5d/l2dWRTQqAAAAAAAAAAAAAAAAAAAAAAAAAAASFmjLSAEAQ0oUAE9KAwBR SgMAACAWaMtIAQA1CIFDSh4AT0oCAFFKAgBcCIFeSgIAYUoeAAAgFmjnL44A NQiBQ0oeAE9KAgBRSgIAXAiBXkoCAGFKHgAAIBZooTCHADUIgUNKHgBPSgIA UUoCAFwIgV5KAgBhSh4AAC8VaAgYXgAWaMtIAQA1CIFCKgRDSiQAT0oCAFFK AgBcCIFeSgIAYUokAHBoM5lmAC8VaAgYXgAWaMF8lgA2CIFCKgRDSiQAT0oC AFFKAgBdCIFeSgIAYUokAHBoM5lmAC8VaAgYXgAWaMtIAQA2CIFCKgRDSiQA T0oCAFFKAgBdCIFeSgIAYUokAHBoM5lmACAWaMtIAQA1CIFDSiQAT0oCAFFK AgBcCIFeSgIAYUokAAApFmjcZe8ANQiBQioJQ0oyAE9KAgBRSgIAXAiBXkoC AGFKMgBwaBAZiAApFmiPFsAANQiBQioJQ0oyAE9KAgBRSgIAXAiBXkoCAGFK MgBwaBAZiAApFmgLK6EANQiBQioJQ0oyAE9KAgBRSgIAXAiBXkoCAGFKMgBw aBAZiAAADAAGAAABCAAAGQgAAC4IAABLCAAATAgAAE0IAACCCAAAgwgAALYI AAC3CAAAuAgAANEJAADSCQAAcQsAAHILAAA0DgAANQ4AAKwQAACtEAAAvxAA AMAQAADaEAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA6AAA AAAAAAAAAAAAAOMAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA1QAAAAAAAAAA AAAAAMwAAAAAAAAAAAAAAADDAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAMMA AAAAAAAAAAAAAADDAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAMMAAAAAAAAA AAAAAADDAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAMMAAAAAAAAAAAAAAADD AAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAADckADgk AEgkAGdk5y+OAAkAADckADgkAEgkAGdkf3vVAAABAAAMAAADJAE3JAA4JABI JABhJAFnZAgYXgAABAAAZ2TcZe8AAAQAAGdkayLaAAkAAAMkAzckADgkAEgk AGEkAwkAAAMkATckADgkAEgkAGEkAQAWAAYAAF8RAAD+AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQFMCAAA TQgAAFYIAABXCAAAXQgAAF4IAABgCAAAYwgAAGgIAACBCAAAgggAAIMIAACP CAAArwgAALUIAAC2CAAAtwgAAPLk1si6rKKViKJ+ZE1kOCoaFmjLSAEAQ0oU AE9KAgBRSgIAXkoCAGFKFgAAKRVoCBheABZoy0gBAEIqAUNKFABPSgIAUUoC AF5KAgBhShYAcGgAAAAALBZojxbAADUIgT4qAUIqAUNKJABPSgIAUUoCAFwI gV5KAgBhSiQAcGgAAAAAADIVaAgYXgAWaAgYXgA1CIE+KgFCKgFDSiQAT0oC AFFKAgBcCIFeSgIAYUokAHBoAAAAAAASFmgIGF4AQ0oUAE9KBABRSgQAABgW aAgYXgA2CIFDShQAT0oEAFFKBABdCIEAGBZoqim9ADYIgUNKFABPSgQAUUoE AF0IgQASFmjLSAEAQ0oUAE9KBABRSgQAABoWaMtIAQBDShYAT0oEAFFKBABe SgIAYUoWAAAaFmjcZe8AQ0oWAE9KBABRSgQAXkoCAGFKFgAAGhZoJHjkAENK FgBPSgQAUUoEAF5KAgBhShYAABoWaCsREQBDShYAT0oEAFFKBABeSgIAYUoW AAAaFmhuWyUAQ0oWAE9KBABRSgQAXkoCAGFKFgAAGhZoy0gBAENKDABPSgIA UUoCAF5KAgBhSgwAELcIAAC4CAAAEQkAADEJAAAyCQAANAkAACUKAAArCgAA +AoAAPsKAAAgDAAAJQwAAPcMAAD6DAAAMg0AADsNAAA8DQAAQw0AAEQNAABK DQAAaw0AAJgPAACgDwAA9xAAAAIRAADz3sy6qN6W3oTect5y3nLect5dct5y 3ksAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMWaFo7ogBCKgFDShYAT0oF AFFKBQBeSgYAYUoWAHBoAAAAACkVaOcvjgAWaHUP8gBCKgFDShYAT0oFAFFK BQBeSgYAYUoWAHBoAAAAACMWaHUP8gBCKgFDShYAT0oFAFFKBQBeSgYAYUoW AHBoAAAAACMWaBl7aABCKgFDShYAT0oFAFFKBQBeSgYAYUoWAHBoAAAAACMW aCR45ABCKgFDShYAT0oFAFFKBQBeSgYAYUoWAHBoAAAAACMWaNJffgBCKgFD ShYAT0oFAFFKBQBeSgYAYUoWAHBoAAAAACMWaKwgzgBCKgFDShYAT0oFAFFK BQBeSgYAYUoWAHBoAAAAACMWaDImfABCKgFDShYAT0oFAFFKBQBeSgYAYUoW AHBoAAAAACkVaOcvjgAWaOcvjgBCKgFDShYAT0oFAFFKBQBeSgYAYUoWAHBo AAAAABgVaOcvjgAWaH971QBPSgIAUUoCAF5KAgAY2hAAAPEQAABeEQAAXxEA APYAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABAAAZ2TnL44ACQAANyQAOCQASCQAZ2TnL44A AAMCEQAAAxEAACsRAAA3EQAAOREAADoRAAA7EQAAXBEAAF0RAABeEQAAXxEA AOnXwtel6ZLpgNcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIxZoy0gBAEIqAUNK FgBPSgUAUUoFAF5KBgBhShYAcGgAAAAAJBVoEWkIABZoISk+ADBKDwBDShYA T0oFAFFKBQBeSgYAYUoWAAA4AgiBA2oAAAAABggBFWgRaQgAFmghKT4AQioB Q0oWAE9KBQBRSgUAVQgBXkoGAGFKFgBwaAAAAAAAKRVo5y+OABZoISk+AEIq AUNKFgBPSgUAUUoFAF5KBgBhShYAcGgAAAAAIxZoISk+AEIqAUNKFgBPSgUA UUoFAF5KBgBhShYAcGgAAAAALANqAAAAABZoISk+AEIqAUNKFgBPSgUAUUoF AFUIAV5KBgBhShYAcGgAAAAACiwAMZBoAR+w0C8gsOA9IbAcAiKwHAIjkBwC JJBoASWwAAAXsNACGLDQAgyQ0AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwEAAEQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAIgAAAEoA QQBNAEUAUwBSAEUAWQBOAE8ATABEAFMATABBAFcARgBJAFIATQA2AEAAWQBB AEgATwBPAC4AQwBPAC4AVQBLAAAA4Mnqefm6zhGMggCqAEupC1IAAABtAGEA aQBsAHQAbwA6AEoAQQBNAEUAUwBSAEUAWQBOAE8ATABEAFMATABBAFcARgBJ AFIATQA2AEAAWQBBAEgATwBPAC4AQwBPAC4AVQBLAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYCEAASAAEA nAAPAAQAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEAAAEDx/wIAQAAMAAAAAAAAAAAABgBOAG8AcgBtAGEAbAAA AAIAAAAYAENKGABfSAEEYUoYAG1ICQRzSAkEdEgJBAAAAAAAAAAAAAAAAAAA AAAAAEQAQUDy/6EARAAMAQAAAAAAAAAAFgBEAGUAZgBhAHUAbAB0ACAAUABh AHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABWAGkA8/+zAFYADAEAAAAA AAAAAAwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX9gMAADTW BgABBQMAADTWBgABCgNsAGH2AwAAAgALAAAAKABrAPT/wQAoAAABAAAAAAAA AAAHAE4AbwAgAEwAaQBzAHQAAAACAAwAAAAAADYAVUCiAPEANgAMBAAAISk+ AAAACQBIAHkAcABlAHIAbABpAG4AawAAAAwAPioBQioCcGgAAP8AAAAAAF8J AAAFAAAgAAAAAP////8AAAAAAQAAABkAAAAuAAAASwAAAEwAAABNAAAAggAA AIMAAAC2AAAAtwAAALgAAADRAQAA0gEAAHEDAAByAwAANAYAADUGAACsCAAA rQgAAL8IAADACAAA2ggAAPEIAABeCQAAYQkAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY QAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAAAAAAAAQAAABkAAAAuAAAASwAAAEwAAABNAAAAggAAAMAIAADa CAAA8QgAAF4JAABhCQAAS4gAMAAwAAAAAAAAAQAAAAkAAAABAAAAuCHMB0mI ADAAMAAAAAAAAAEAAAAIAAAAAAAAAAAAgAFJiAAwADAAAAAAAAACAAAABgAA AAAAAAAAAIABSYgAMAAwAAAAAAAAAQAAAAMAAAAAAAAAAACAAUmIADAAMAAA AAAAAAEAAAAEAAAAAAAAAAAAgAFLyAAwADAAAAAAAAABAAAABAAAAAAAAAAA AIABS4gAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAACAB0uIADAAMAAAAAAAAAEA AAAEAAAAAQAAAHwOqgdJiAAwADAAAAAAAAABAAAAAwAAAAAAAAAAAIABSYgA MAAwAAAAAAAAAgAAAAEAAAAAAAAAAACAAf3///8A8AAAgAAAAAAAAQAAAAAA AAAAAAAAAAFJiAAwADAAAAAAAAABAAAAAAAAAAAAAAAAAIABAAYAAEwIAAC3 CAAAAhEAAF8RAAAJAAAADAAAAA0AAAAPAAAAAAYAANoQAABfEQAACgAAAA4A AAAABgAAXxEAAAsAAAACCQAAOgkAAFwJAABfCQAAE1gU/xWADwAA8EgBAAAA AAbwGAAAAAIIAAACAAAADwAAAAEAAAABAAAAEAAAAG8AAfAIAQAAIgAH8CQA AAACBLyPGOSJKX9v9PwwNC5EUIn/AI0LAAAAAAAA/////wAAAAAiAAfwJAAA AAIEyhK8qooP8Miv+xI3/JVIfP8AdQwAAAAAAAD/////AAAAACIAB/AkAAAA AgQj3QOwJWuvzlbjC8IIkUuk/wBSHAAAAAAAAP////8AAAAAIgAH8CQAAAAC BMzRCX2s2zQtaUp6H/WZjyn/ACALAAAAAAAA/////wAAAAAiAAfwJAAAAAIE Q0Gk7WMJX7atweAvX47UJ/8ArikAAAAAAAD/////AAAAACIAB/AkAAAAAgQm N8qcTRvKn3pN8MZO4zkI/wBjVwAAAAAAAP////8AAAAAQAAe8RAAAAAAgIAA /wAAAICAgAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAADwQAAA8AA/AwAAAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAF AAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAA AAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAABfCQAA//8DAAAABgCS VU0ACAABAKR4HAAGAJNVTQARAAEAlJ8dAAYAlFVNABAAAQDUnx0ANAAAADQA AAC2BwAAYQkAAAAAAAACAAEAAAACAAIAAAABAD4AAAA+AAAAuAcAAGEJAAAA AAAAAQAAAAIAAAADAAAAOgAAAAIAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOnNtYXJ0dGFncwaAU3RyZWV0AIA7AAAAAwAAACqAdXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzB4BhZGRy ZXNzAIA5AAAAAQAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6c21hcnR0YWdzBYBwbGFjZQCADAAAAQQB+gMAAAAAAwAAAAAAAgAAAAAA AQAAAAAAAAAAAGEJAAAHAAAAAABhCQAABwAAAAAAAQAAABkAAABMAAAATAAA AE0AAABNAAAAVgAAAF0AAACDAAAAMAEAADEBAAAyAQAANAEAACUCAAArAgAA +AIAAPsCAAAgBAAAJQQAAPcEAAD6BAAAMgUAADsFAABDBQAAQwUAAEQFAABK BQAAZwUAAGsFAACgBwAAoAcAAAIJAABhCQAABwAFAAcABAAHAAQABQAEAAUA BwAEAAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcABAAH AAQAAAAAAGEJAAAHAAIAiSRuJQAAAAAAAAAAAAECAAIAcRVGPAAAAAAAAAAA AAECAAIAigAAAAQAAAAIAAAA5QAAAAAAAACJAAAAAisBAMtIAQCkYQMAuQIF AF8VBQDMbwYA7G0KAHpiDQAAdQ0AKxERAGltEQD4AxQAN3sUAENvFQDrdhYA eyAYAMZHGABqWRwAo10cAGRLJABuWyUAJRgqAJgxKwAbQTQA+D46AEZROwAh KT4Axn4+AFkgQQDCIkEAyFhBAIRyRQDgNksAEhJPAK4TTwDrKE8A4G5PAAQY UABSZVEAEg5SAEB8VgBtRloABEhcAAgYXgBQA18AoCFfABc8XwAhO2EAKWdh AMhvYQCITWIAL1tiAGMFZADXUmUApmtnABl7aAA8B2oA7ClwAFs4cACsWHcA OUV7ADZoewAyJnwAHEh8ABURfQDXJX0A0l9+ADQ5hgChMIcAbS6IAIhxiQAw cIsA5y+OAH03jwB9KZEA+A2TAMF8lgBYVZkAhGOZAEYinQBcRp0A6ymhAAsr oQBaO6IAzC6jAAoxowAaWKUALQSrAKtMqwCKcq0AOkCwAKhBsABfT7QA7GG3 ALpuuAAXUroA92S6AO83vABZFr0Aqim9AJg3vQBAW74AJ0W/AI8WwAA4OcAA 6m/DANYlxADjXMQACxjFAKt0xwA3fMwArCDOAIo61AB/e9UAI2nXAGwa2ACI EdoAayLaAGFu2wDydN0AOATiAP1E5AAkeOQA+y3pAP0U6gCXLesArTfuANhK 7wDcZe8AdQ/yAHl38gCLHfUA2nf5ANEo+gD4TPsArDP8ADYp/wBVSf8A/0AD gAEA0QEAANEBAADYITEBAQAAANEBAAAAAAAA0QEAAAAAAAACEAAAAAAAAABf CQAAUAAAEABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAA AAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABwAAAEcWkAEA AAICBgMFBAUCAwSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMA IABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAA EAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgIC AgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA5EpABAAAA AAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAATQBTACAAUwBlAHIA aQBmAAAATSaQAQAHAgtyAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAAAAAA AEEAZwBhAHQAaABhAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAPyaQAQAA AgsKBAIBAgICBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAEEAcgBpAGEAbAAg AEIAbABhAGMAawAAAEsQkAEAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA AQAAAAAAAABUAGkAbQBlAHMATgBlAHcAUgBvAG0AYQBuAFAAUwBNAFQAAAAi AAQA8QiIGADw0AIAAGgBAAAAAAqSvEYKkrxGAAAAAAIAAQAAAGYBAAD5BwAA AQAEAAAABAADEBEAAABmAQAA+QcAAAEABAAAABEAAAAAAAAAJQMA8BAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAIcArQA tACBgXI0AAAQABkAZAAAABkAAABbCQAAWwkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AAALAQAAAAAIMoNRAPAQAAjcAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AExYAAAAACjw/w8BAAE/AADkBAAA////f////3////9/////f////3////9/ ////f8F8lgAAAAAAMgAAAAAAAAAAAAAAAAAAAAAA//8SAAAAAAAAABYATwBO AE8AVgBPACAAJgAgAE8ATgBPAFYATwAgAEMASABBAE0AQgBFAFIAUwAAAAAA AAAFAHUAdQBzAGUAcgAEAHUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+ /wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAA AAB8AQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAAuAAAAAQAAADEAAAABQAA ANQAAAAGAAAA4AAAAAcAAADsAAAACAAAAPwAAAAJAAAADAEAABIAAAAYAQAA CgAAADgBAAAMAAAARAEAAA0AAABQAQAADgAAAFwBAAAPAAAAZAEAABAAAABs AQAAEwAAAHQBAAACAAAA5AQAAB4AAAAYAAAAT05PVk8gJiBPTk9WTyBDSEFN QkVSUwAAHgAAAAQAAAAAAAAAHgAAAAgAAAB1dXNlcgAAAB4AAAAEAAAAAAAA AB4AAAAEAAAAAAAAAB4AAAAIAAAATm9ybWFsAAAeAAAACAAAAHVzZXIAAAAA HgAAAAQAAAAyAAAAHgAAABgAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQAAABA AAAAAEbDIwAAAABAAAAAANStAEVByAFAAAAAANStAEVByAEDAAAAAQAAAAMA AABmAQAAAwAAAPkHAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA /v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5E AAAABdXN1ZwuGxCTlwgAKyz5rkgBAAAEAQAADAAAAAEAAABoAAAADwAAAHAA AAAFAAAAgAAAAAYAAACIAAAAEQAAAJAAAAAXAAAAmAAAAAsAAACgAAAAEAAA AKgAAAATAAAAsAAAABYAAAC4AAAADQAAAMAAAAAMAAAA4wAAAAIAAADkBAAA HgAAAAgAAAB1c2VyY28AAAMAAAARAAAAAwAAAAQAAAADAAAAWwkAAAMAAADm FQsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAABcA AABPTk9WTyAmIE9OT1ZPIENIQU1CRVJTAAwQAAACAAAAHgAAAAYAAABUaXRs ZQADAAAAAQAAAAAAANQAAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAA AQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAAjAAAAAYAAAAD AAAAKwAZAAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8AAAApAAAAbQBhAGkA bAB0AG8AOgBKAEEATQBFAFMAUgBFAFkATgBPAEwARABTAEwAQQBXAEYASQBS AE0ANgBAAFkAQQBIAE8ATwAuAEMATwAuAFUASwAAAAAAHwAAAAEAAAAAADsE AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAA DAAAAA0AAAAOAAAADwAAABAAAAD+////EgAAABMAAAAUAAAAFQAAABYAAAAX AAAAGAAAAP7///8aAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIA AAAjAAAA/v///yUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAD+////LQAA AC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAAP7////9////NgAAAP7////+//// /v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH///// /////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAQKJYBkVByAE4 AAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAAAAEAAA AAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAJgUAAAAAAAAVwBv AHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALiAAAAAAAAAFAFMAdQBtAG0A YQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACQAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAALAAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAcQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////AQD+/wMKAAD/////BgkCAAAAAADA AAAAAAAARh8AAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgRG9jdW1lbnQACgAA AE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_Part_6551_12916419.1197968379043-- From owner-xfs@oss.sgi.com Tue Dec 18 01:20:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 01:20:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBI9KlfB006449 for ; Tue, 18 Dec 2007 01:20:50 -0800 X-ASG-Debug-ID: 1197969658-438500cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-tls.univ-nantes.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B9F6B495C51 for ; Tue, 18 Dec 2007 01:20:58 -0800 (PST) Received: from smtp-tls.univ-nantes.fr (Smtp-Tls1.univ-nantes.fr [193.52.101.145]) by cuda.sgi.com with ESMTP id XBR2Qu3LBn4reKS8 for ; Tue, 18 Dec 2007 01:20:58 -0800 (PST) Received: from localhost (debian [127.0.0.1]) by smtp-tls.univ-nantes.fr (Postfix) with ESMTP id 94D9A50071C; Tue, 18 Dec 2007 10:20:24 +0100 (CET) Received: from smtp-tls.univ-nantes.fr ([193.52.101.145]) by localhost (SMTP-TLS.univ-nantes.fr [193.52.101.145]) (amavisd-new, port 10024) with LMTP id 01073-01-50; Tue, 18 Dec 2007 10:20:24 +0100 (CET) Received: from [172.20.13.9] (tomintoul.cri.univ-nantes.prive [172.20.13.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-tls.univ-nantes.fr (Postfix) with ESMTP id 8219050070D; Tue, 18 Dec 2007 10:20:24 +0100 (CET) Message-ID: <476790D5.6040205@univ-nantes.fr> Date: Tue, 18 Dec 2007 10:20:21 +0100 From: Yann Dupont Organization: CRIUN User-Agent: Thunderbird 3.0a1pre (X11/2007120904) MIME-Version: 1.0 To: xfs@oss.sgi.com Cc: Jacky Carimalo X-ASG-Orig-Subj: kernel oops on debian , 2.6.18-5 Subject: kernel oops on debian , 2.6.18-5 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.91.2/5163/Mon Dec 17 16:29:09 2007 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at smtp.univ-nantes.fr X-Barracuda-Connect: Smtp-Tls1.univ-nantes.fr[193.52.101.145] X-Barracuda-Start-Time: 1197969659 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36958 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 13989 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Yann.Dupont@univ-nantes.fr Precedence: bulk X-list: xfs Hello, we got a kernel oops, probably in xfs on a debian kernel. This volume is on SAN + device mapper. this is a 1 TB volume. It was in service for more than 2 ou 3 years. There is a high humber of files on it, as this volume serves for a rsyncd, where 200+ servers sync their root filesystem on it every day. here is the oops : Dec 16 23:27:32 inchgower kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1561 of file fs/xfs/xfs_alloc.c. Caller 0xffffffff881857b7 Dec 16 23:27:32 inchgower kernel: Dec 16 23:27:32 inchgower kernel: Call Trace: Dec 16 23:27:32 inchgower kernel: [] :xfs:xfs_free_ag_extent+0x19f/0x67f Dec 16 23:27:32 inchgower kernel: [] :xfs:xfs_free_extent+0xa9/0xc9 Dec 16 23:27:32 inchgower kernel: [] :xfs:xfs_bmap_finish+0xf0/0x169 Dec 16 23:27:32 inchgower kernel: [] :xfs:xfs_itruncate_finish+0x172/0x2b3 Dec 16 23:27:32 inchgower kernel: [] :xfs:xfs_inactive+0x22e/0x823 Dec 16 23:27:32 inchgower kernel: [] pagevec_lookup+0x17/0x1e Dec 16 23:27:32 inchgower kernel: [] truncate_inode_pages_range+0x1b1/0x277 Dec 16 23:27:32 inchgower kernel: [] :xfs:xfs_fs_clear_inode+0xa5/0xec Dec 16 23:27:32 inchgower kernel: [] clear_inode+0xc5/0xf6 Dec 16 23:27:32 inchgower kernel: [] generic_delete_inode+0xde/0x143 Dec 16 23:27:32 inchgower kernel: [] dput+0x135/0x153 Dec 16 23:27:32 inchgower kernel: [] sys_renameat+0x19b/0x20a Dec 16 23:27:32 inchgower kernel: [] _atomic_dec_and_lock+0x39/0x57 Dec 16 23:27:32 inchgower kernel: [] mntput_no_expire+0x19/0x8b Dec 16 23:27:32 inchgower kernel: [] ia32_sysret+0x0/0xa Dec 16 23:27:32 inchgower kernel: Dec 16 23:27:32 inchgower kernel: xfs_force_shutdown(dm-3,0x8) called from line 4267 of file fs/xfs/xfs_bmap.c. Return address = 0xffffffff88192563 Dec 16 23:27:32 inchgower kernel: Filesystem "dm-3": Corruption of in-memory data detected. Shutting down filesystem: dm-3 Dec 16 23:27:32 inchgower kernel: Please umount the filesystem, and rectify the problem(s) and the kernel : inchgower:/var/log# uname -a Linux inchgower 2.6.18-5-vserver-amd64 #1 SMP Fri Jun 1 00:27:03 UTC 2007 x86_64 GNU/Linux Please note that it is not the "generic" debian kernel, but the vserver one - but stock etch version anyway. We had not seen any problems with this combination, (xfs + debian kernel-vserver) which is very largely deployed here. This is a first. Do you think the problems is due to xfs or other factors ? Sincerely, -- Yann Dupont, Cri de l'universit de Nantes Tel: 02.51.12.53.91 - Fax: 02.51.12.58.60 - Yann.Dupont@univ-nantes.fr From owner-xfs@oss.sgi.com Tue Dec 18 02:06:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 02:06:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBIA6QBD010329 for ; Tue, 18 Dec 2007 02:06:31 -0800 X-ASG-Debug-ID: 1197972397-485001af0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hu-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4A3D427FD0F for ; Tue, 18 Dec 2007 02:06:38 -0800 (PST) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.234]) by cuda.sgi.com with ESMTP id bYt1cYsTAOOvXj58 for ; Tue, 18 Dec 2007 02:06:38 -0800 (PST) Received: by hu-out-0506.google.com with SMTP id 16so860225hue.17 for ; Tue, 18 Dec 2007 02:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=EgotPEBulyR4MqZV8MTSDSyLo5a5uAQTTI5M0pYp2t4=; b=qBR+17qdvgWDX4dUIcNSO8oGewiRaeGqNwTpWhS+VzxdE6VLB4GtIKbMbrBMofvKKkpLXWCLo+tRqJnO+V6Frusu3Fjg0a57wuS2XvhvD3yDutL6hkceV+TP5b/L0wk1O3fPXTdYZn6q4lHRUfozqHfLgpIfVAD0EwV/L6Eex2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=yCcVBChNdcEwbrZ5NkivJwRTX/RBWfipyyPgMo700o9qWtaUMcPV50kz9dWIQkqd9TQl1aZrMq5L/v5XIL6wzfm12EL3ju2QNuA8QjztbMDBs74x9eW5RarbyPvSQUEWrDucIjMPXy+9FdDfc5VtsNjPN/u78X43diJTkG2I71k= Received: by 10.86.78.4 with SMTP id a4mr7492593fgb.0.1197972395384; Tue, 18 Dec 2007 02:06:35 -0800 (PST) Received: by 10.86.31.18 with HTTP; Tue, 18 Dec 2007 02:06:35 -0800 (PST) Message-ID: <97134a2f0712180206q6bb03425veb9cb7a91ffc6215@mail.gmail.com> Date: Tue, 18 Dec 2007 02:06:35 -0800 From: "Sallie BIEL" To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Wait till you see whats happening Subject: Wait till you see whats happening MIME-Version: 1.0 X-Barracuda-Connect: hu-out-0506.google.com[72.14.214.234] X-Barracuda-Start-Time: 1197972399 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0100 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.65 X-Barracuda-Spam-Status: No, SCORE=0.65 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_00_10, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36961 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.64 HTML_00_10 BODY: Message is 0% to 10% HTML 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5163/Mon Dec 17 16:29:09 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 919 X-archive-position: 13990 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sheree4671@gmail.com Precedence: bulk X-list: xfs TSPD Moving To Acquire AMS! Tradeshow Products Inc. TSPD $1.04 UP 9% TSPD, a promotional products company, is expanding its scope and has issued a letter of intent to acquire AMS LLC. This move can mean the expansion of revenues by more than $10 Million in 2008, with initial revenues already coming in by close of the first quarter. These are 4 things you should know about TSPD! 1. A new strategic financial plan has been put in place by Bay Side Financial and results are already coming in. 2. The new acquisition of AMS is expected to bring in revenues of over 10 Million. 3. According to the CEO, their new financial plan will be made available to the public within a few weeks. 4. More investors are becoming interested in TSPD as it is increasing its investors awareness in the market. There is no better time then now to act on TSPD. Get ready to move Tuesday morning! [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Dec 18 03:28:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 03:28:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_05 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBIBSO3L016764 for ; Tue, 18 Dec 2007 03:28:24 -0800 X-ASG-Debug-ID: 1197977315-2dc601860000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kraid.nerim.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2C439117EFC9 for ; Tue, 18 Dec 2007 03:28:36 -0800 (PST) Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by cuda.sgi.com with ESMTP id gxf6Yf4Qya00MEvG for ; Tue, 18 Dec 2007 03:28:36 -0800 (PST) Received: from brouette (damien.wyart.pck.nerim.net [213.41.244.197]) by kraid.nerim.net (Postfix) with ESMTP id 1B1B3CF0B4; Tue, 18 Dec 2007 12:28:04 +0100 (CET) Received: by brouette (Postfix, from userid 1000) id 2430D45BCF; Tue, 18 Dec 2007 12:28:04 +0100 (CET) Date: Tue, 18 Dec 2007 12:28:04 +0100 From: Damien Wyart To: David Chinner , Christoph Hellwig , Lachlan McIlroy , Peter Leckie , Linus Torvalds Cc: linux-xfs@oss.sgi.com, LKML X-ASG-Orig-Subj: Important regression with XFS update for 2.6.24-rc6 Subject: Important regression with XFS update for 2.6.24-rc6 Message-ID: <20071218112804.GA3069@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: smtp-102-tuesday.nerim.net[62.4.16.102] X-Barracuda-Start-Time: 1197977317 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-ASG-Whitelist: BODY (http://marc.info/\?) X-Virus-Scanned: ClamAV 0.91.2/5164/Tue Dec 18 01:56:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13991 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: damien.wyart@free.fr Precedence: bulk X-list: xfs Hello, As a follow-up to (LKML seems down right now so I am not linking to it), I have detected an important problem with these two patches: after applying them by hand (downloaded them raw from SGI's gitweb) on top of 2.6.24-rc5-git5 (they have not yet been pulled into mainline by Linux as of this morning) for testing purposes, I noticed upon reboot that "ls -l" on directories with many files and subdirectories (around 5000 entries) takes several hundreds of MB in RAM and then dies with "memory exhausted" error. I also noticed that ldconfig takes a lot of time to complete, and firefox seems also to eat much more memory than usual. Reverting the two patches (going back to vanilla rc5-git5) makes these problems go away. I am not able to test right now if only one of the patches is bogus or if both of them are concerned. As the symptoms are easy to reproduce, I guess this is some kind of brown paper bag bug and will be easy for XFS experts to spot. Best, -- Damien Wyart From owner-xfs@oss.sgi.com Tue Dec 18 04:24:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 04:25:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBICOqsS025474 for ; Tue, 18 Dec 2007 04:24:55 -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 XAA21164; Tue, 18 Dec 2007 23:24:50 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lBICOmIN12440407; Tue, 18 Dec 2007 23:24:48 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBICOjhk12436654; Tue, 18 Dec 2007 23:24:45 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 18 Dec 2007 23:24:45 +1100 From: David Chinner To: Damien Wyart Cc: David Chinner , Christoph Hellwig , Lachlan McIlroy , Peter Leckie , Linus Torvalds , linux-xfs@oss.sgi.com, LKML Subject: Re: Important regression with XFS update for 2.6.24-rc6 Message-ID: <20071218122445.GJ4396912@sgi.com> References: <20071218112804.GA3069@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071218112804.GA3069@localhost.localdomain> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5164/Tue Dec 18 01:56:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13992 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 12:28:04PM +0100, Damien Wyart wrote: > Hello, > > As a follow-up to > (LKML seems down right now so I am not linking to it), I have detected an > important problem with these two patches: after applying them by hand > (downloaded them raw from SGI's gitweb) on top of 2.6.24-rc5-git5 (they have > not yet been pulled into mainline by Linux as of this morning) for testing > purposes, I noticed upon reboot that "ls -l" on directories with many files > and subdirectories (around 5000 entries) takes several hundreds of MB in RAM > and then dies with "memory exhausted" error. Ok. I haven't noticed anything wrong with directories up to about 250,000 files in the last few days. The ls -l I just did on a directory with 15000 entries (btree format) used about 5MB of RAM. extent format directories appear to work fine as well (tested 500 entries). Can you: a) isolate the problem to one patch or the other. My guess would be the directory mod, but..... b) show your working ;) - what platform (i386, x86_64, etc) - what debug options - commands and output that shows the problem - strace of ls -l going bad - xfs_info from filesystem in question > I also noticed that ldconfig takes a lot of time to complete, and firefox > seems also to eat much more memory than usual. Reverting the two patches > (going back to vanilla rc5-git5) makes these problems go away. I am not > able to test right now if only one of the patches is bogus or if both of > them are concerned. Well, there goes a)..... > As the symptoms are easy to reproduce, I guess this is some kind of brown > paper bag bug and will be easy for XFS experts to spot. Well, not reproducable on my test boxes. It may well be a brown paper bag job, but it's not obvious. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 18 04:29:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 04:29: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=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBICT02P026070 for ; Tue, 18 Dec 2007 04:29:02 -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 XAA21281; Tue, 18 Dec 2007 23:29:04 +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 lBICT2IN12441216; Tue, 18 Dec 2007 23:29:03 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBICT0uX12440290; Tue, 18 Dec 2007 23:29:00 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 18 Dec 2007 23:29:00 +1100 From: David Chinner To: Laurent CARON Cc: David Chinner , xfs@oss.sgi.com Subject: Re: Issue with 2.6.23 and drbd 8.0.7 Message-ID: <20071218122900.GK4396912@sgi.com> References: <20071217143655.chiehahh@trusted.lncsa.com> <20071217220354.GU4396912@sgi.com> <4766F58C.8040000@lncsa.com> <20071217233759.GB4396912@sgi.com> <47678124.80906@lncsa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47678124.80906@lncsa.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5164/Tue Dec 18 01:56:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13993 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 09:13:24AM +0100, Laurent CARON wrote: > David Chinner wrote: > > Hmmm - no real surprises there, but the numbers are well lower than the > > ~960MB low memory limit. I suspect that there's something at around > > 2.55am that does a filesystem traversal and that blows out the memory > > usage of these slab caches and you run out of lowmem... > > Thanks David for this information, > > On the previous setup (same pieces of software), we didn't had that kind > of problem. > > Do you think that more memory is used while using XFS on a filesystem > traversal than with ReiserFS (the previous setup used ReiserFS)? Yes, XFS will use more memory - XFS's inodes are substantially larger in memory than for reiserfs and so will consume more memory for the same number of cached inodes. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 18 04:32:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 04:33:03 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBICWtwg026687 for ; Tue, 18 Dec 2007 04:32:58 -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 XAA21495; Tue, 18 Dec 2007 23:33:02 +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 lBICX1IN12444945; Tue, 18 Dec 2007 23:33:02 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBICWxFv12432812; Tue, 18 Dec 2007 23:32:59 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 18 Dec 2007 23:32:59 +1100 From: David Chinner To: Yann Dupont Cc: xfs@oss.sgi.com, Jacky Carimalo Subject: Re: kernel oops on debian , 2.6.18-5 Message-ID: <20071218123259.GL4396912@sgi.com> References: <476790D5.6040205@univ-nantes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476790D5.6040205@univ-nantes.fr> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5164/Tue Dec 18 01:56:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13994 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 10:20:21AM +0100, Yann Dupont wrote: > Hello, we got a kernel oops, probably in xfs on a debian kernel. > > This volume is on SAN + device mapper. > this is a 1 TB volume. It was in service for more than 2 ou 3 years. > There is a high humber of files on it, as this volume serves for a > rsyncd, where 200+ servers sync their root filesystem on it every day. > > here is the oops : > > Dec 16 23:27:32 inchgower kernel: XFS internal error > XFS_WANT_CORRUPTED_GOTO at line 1561 of file fs/xfs/xfs_alloc.c. Caller > 0xffffffff881857b7 > Dec 16 23:27:32 inchgower kernel: > Dec 16 23:27:32 inchgower kernel: Call Trace: > Dec 16 23:27:32 inchgower kernel: [] > :xfs:xfs_free_ag_extent+0x19f/0x67f corrupted freespace btree. what does xfs_check tell you about the filesystem on dm-3? > Please note that it is not the "generic" debian kernel, but the vserver > one - but stock etch version anyway. We had not seen any problems with > this combination, (xfs + debian kernel-vserver) which is very largely > deployed here. This is a first. > > Do you think the problems is due to xfs or other factors ? Could be a hardware problem. Could be an XFs problem. Coul dbe a dm problem. I really can't say from a shutdown message like this - all it tells us is that a btree block was corrupted by something since the last time it was checked.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 18 04:39:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 04:39:52 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBICdjKw027398 for ; Tue, 18 Dec 2007 04:39: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 XAA21590; Tue, 18 Dec 2007 23:39:53 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lBICdpIN12443799; Tue, 18 Dec 2007 23:39:52 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBICdolS12428922; Tue, 18 Dec 2007 23:39:50 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 18 Dec 2007 23:39:50 +1100 From: David Chinner To: sudheer Cc: xfs@oss.sgi.com Subject: Re: xfs problem ? Message-ID: <20071218123950.GM4396912@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/5164/Tue Dec 18 01:56:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13995 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 07:21:21AM +0530, sudheer wrote: > Sir , > > When i run tail -f /var/log/messages > -------------------------------------------------------------- > Dec 17 20:50:42 u15200848 kernel: [] pdflush+0x0/0x50 > Dec 17 20:50:42 u15200848 kernel: [] __pdflush+0xbc/0x1b0 > Dec 17 20:50:42 u15200848 kernel: [] pdflush+0x3d/0x50 > Dec 17 20:50:42 u15200848 kernel: [] wb_kupdate+0x0/0x140 > Dec 17 20:50:42 u15200848 kernel: [] kthread+0xba/0xc0 > Dec 17 20:50:42 u15200848 kernel: [] kthread+0x0/0xc0 > Dec 17 20:50:42 u15200848 kernel: [] > kernel_thread_helper+0x5/0x10 > Dec 17 20:50:42 u15200848 kernel: 0x0: 58 41 47 46 00 00 00 01 00 00 00 0a > 00 18 c5 15 > Dec 17 20:50:42 u15200848 kernel: Filesystem "hda7": XFS internal error > xfs_alloc_read_agf at line 2173 of file fs/xfs/xfs_alloc.c. Caller That indicates a corrupted AGF. The magic number looks good: #define XFS_AGF_MAGIC 0x58414746 so that leaves: agf_ok = be32_to_cpu(agf->agf_magicnum) == XFS_AGF_MAGIC && XFS_AGF_GOOD_VERSION(be32_to_cpu(agf->agf_versionnum)) && be32_to_cpu(agf->agf_freeblks) <= be32_to_cpu(agf->agf_length) && be32_to_cpu(agf->agf_flfirst) < XFS_AGFL_SIZE(mp) && be32_to_cpu(agf->agf_fllast) < XFS_AGFL_SIZE(mp) && be32_to_cpu(agf->agf_flcount) <= XFS_AGFL_SIZE(mp); Fromteh hex dump above I can see the version is also good, but nothing else. You should run xfs_check on teh filesystem and report the output to us, then run xfs_repair to correct the problem (also send us the output). The output of the two programs might tell use what was wrong.... > Is this a problem with the xfs file system ? in the hda7 partition ? Could be either - is you disk reporting errors? What does smart tell you? > .How > can i correct this on live server ? unmount the filesystem, check it, repair it, mount it back up. You can't fix it online. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 18 05:46:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 05:46:52 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBIDkhR5002469 for ; Tue, 18 Dec 2007 05:46:47 -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 AAA23239; Wed, 19 Dec 2007 00:46: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 lBIDklIN12914334; Wed, 19 Dec 2007 00:46:48 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBIDkiKk12917258; Wed, 19 Dec 2007 00:46:44 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 19 Dec 2007 00:46:44 +1100 From: David Chinner To: Bret Towe Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: xfs mknod regression Message-ID: <20071218134644.GO4396912@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/5165/Tue Dec 18 04:31:02 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13996 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 17, 2007 at 08:48:40PM -0800, Bret Towe wrote: > I hit a bug in 2.6.24-rc looks to be in 2.6.23 also so not sure how > long it's been there > with an xfs filesystem pbuilder has an issue using device files it > makes for chroot > the mknod command looks to work fine the file is created > however when attempting to use one of the created files you see > something like the below > > ghoststar dev # echo "hi" > null > bash: null: No such device or address > ghoststar dev # ls -l null > crw-rw-rw- 1 root root 1, 3 2007-12-17 20:34 null > ghoststar dev # ls -l /dev/null > crw-rw-rw- 1 root root 1, 3 2007-10-05 17:29 /dev/null > ghoststar dev # echo "hi" > /dev/null > ghoststar dev # Ok. Works on 2.6.22. doesn't work on latest xfsdev. I'll look into it. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 18 06:04:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 06:04:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_22 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBIE4Tha004017 for ; Tue, 18 Dec 2007 06:04:30 -0800 X-ASG-Debug-ID: 1197986675-763801700000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sovereign.computergmbh.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4C364496F78 for ; Tue, 18 Dec 2007 06:04:36 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by cuda.sgi.com with ESMTP id hM0iJajM6qP7pACA for ; Tue, 18 Dec 2007 06:04:36 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 3ACB8180173F8; Tue, 18 Dec 2007 15:04:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 30B231C008734; Tue, 18 Dec 2007 15:04:03 +0100 (CET) Date: Tue, 18 Dec 2007 15:04:03 +0100 (CET) From: Jan Engelhardt To: xfs@oss.sgi.com cc: Linux Kernel Mailing List X-ASG-Orig-Subj: Do not reset xfsquota flags on quotaless ro mount Subject: Do not reset xfsquota flags on quotaless ro mount Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Barracuda-Connect: sovereign.computergmbh.de[85.214.69.204] X-Barracuda-Start-Time: 1197986681 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36976 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5165/Tue Dec 18 04:31:02 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13997 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 Hi, In https://bugzilla.novell.com/show_bug.cgi?id=345338 it is claimed that resetting the quota flags in the mounting sequence rw,ro,rw is a bug, but I would say this is not the case, as quota is metadata, and the log is replayed in ro mode even for other filesystems. Yet, it is still not nice, and I have been trying with this patch, which does not do the right thing yet. (It does a recovery when mounting for the 3rd time, which probably just says that I did not know too much of xfs internals to cook up a nicely working patch.) Opinions? === In the following action sequence, quota is unnecessarily recalculated at the 3rd mount invocation: mount -o usrquota,grpquota /dev/mapper/myxfs /mnt umount /mnt mount -o ro /dev/mapper/myxfs /mnt umount /mnt mount -o usrquota,grpquota /dev/mapper/myxfs /mnt This patch skips clearing the quota flags on read-only mounts. --- fs/xfs/xfs_qmops.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) Index: linux-2.6/fs/xfs/xfs_qmops.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_qmops.c +++ linux-2.6/fs/xfs/xfs_qmops.c @@ -134,7 +134,14 @@ static struct xfs_qmops xfs_qmcore_stub int xfs_qmops_get(struct xfs_mount *mp, struct xfs_mount_args *args) { - if (args->flags & (XFSMNT_UQUOTA | XFSMNT_PQUOTA | XFSMNT_GQUOTA)) { + bool c; + + c = args->flags & (XFSMNT_UQUOTA | XFSMNT_GQUOTA | XFSMNT_PQUOTA); +#ifdef CONFIG_XFS_QUOTA + c |= mp->m_flags & XFS_MOUNT_RDONLY; +#endif + + if (c) { #ifdef CONFIG_XFS_QUOTA mp->m_qm_ops = &xfs_qmcore_xfs; #else From owner-xfs@oss.sgi.com Tue Dec 18 06:30:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 06:30:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBIEUQeD006596 for ; Tue, 18 Dec 2007 06:30:27 -0800 X-ASG-Debug-ID: 1197988233-5b6c00c40000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mallaury.nerim.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2C9B44971C1 for ; Tue, 18 Dec 2007 06:30:34 -0800 (PST) Received: from mallaury.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by cuda.sgi.com with ESMTP id KwHMKe13OoEWEblC for ; Tue, 18 Dec 2007 06:30:34 -0800 (PST) Received: from brouette (damien.wyart.pck.nerim.net [213.41.244.197]) by mallaury.nerim.net (Postfix) with ESMTP id 703634F480; Tue, 18 Dec 2007 15:30:23 +0100 (CET) Received: by brouette (Postfix, from userid 1000) id F0CD245BCF; Tue, 18 Dec 2007 15:30:31 +0100 (CET) From: Damien Wyart To: David Chinner Cc: Christoph Hellwig , Lachlan McIlroy , Peter Leckie , Linus Torvalds , linux-xfs@oss.sgi.com, LKML X-ASG-Orig-Subj: Re: Important regression with XFS update for 2.6.24-rc6 Subject: Re: Important regression with XFS update for 2.6.24-rc6 References: <20071218112804.GA3069@localhost.localdomain> <20071218122445.GJ4396912@sgi.com> Date: Tue, 18 Dec 2007 15:30:31 +0100 In-Reply-To: <20071218122445.GJ4396912@sgi.com> (David Chinner's message of "Tue, 18 Dec 2007 23:24:45 +1100") Message-ID: <877ijckrco.fsf@free.fr> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Barracuda-Connect: smtp-102-tuesday.noc.nerim.net[62.4.17.102] X-Barracuda-Start-Time: 1197988238 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36978 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5165/Tue Dec 18 04:31:02 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13998 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: damien.wyart@free.fr Precedence: bulk X-list: xfs * David Chinner [071218 13:24]: > Ok. I haven't noticed anything wrong with directories up to about > 250,000 files in the last few days. The ls -l I just did on > a directory with 15000 entries (btree format) used about 5MB of RAM. > extent format directories appear to work fine as well (tested 500 > entries). Ok, nice to know the problem is not so frequent. > Can you: > a) isolate the problem to one patch or the other. My guess > would be the directory mod, but..... Yes, it is indeed the directory patch. But even if I still sometimes get huge memory usage with ls (using the patched kernel), this is quite rare, and the problem is now mainly getting entries in the listing repeated, and the ls process taking longer than without the patch. But this is mainly after booting. I guess the cache plays a role and even using drop_caches, I can't reproduce the problem. Only on fresh reboot do I get it systematically, but much less often the memory problem. And as said earlier, after fresh boot on rc5-git5 without the directory patch, the ls -l goes normal (no repeated entries). > b) show your working ;) Sorry, I forgot this part in my initial report. > - what platform (i386, x86_64, etc) i386. > - what debug options Nothing special, the kernel has 4K stacks, and xfs partitions are mounted with noatime,nodiratime. > - commands and output that shows the problem It is mainly "ls -l" in a quite crowded directory. > - strace of ls -l going bad > - xfs_info from filesystem in question I have put the files at http://damien.wyart.free.fr/xfs/ strace_xfs_problem.1.gz and strace_xfs_problem.2.gz have been created with the problematic kernel, and are quite bigger than strace_xfs_problem.normal.gz, which has been created with the vanilla rc5-git5. There is also xfs_info. I can provide further details if needed (maybe kernel config, but nothing special on the xfs side), but I confirm the behavior is different with and without the directory patch (041388b54ed95cd169546bd83bacd08ee32bd7ea on oss.sgi), and doesn't look normal with the patch. -- Damien Wyart From owner-xfs@oss.sgi.com Tue Dec 18 06:38:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 06:38:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_22, J_CHICKENPOX_28 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBIEcmQD007390 for ; Tue, 18 Dec 2007 06:38:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA24665; Wed, 19 Dec 2007 01:38:54 +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 lBIEcqIN13054228; Wed, 19 Dec 2007 01:38:53 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBIEcnWm6217924; Wed, 19 Dec 2007 01:38:49 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 19 Dec 2007 01:38:49 +1100 From: David Chinner To: Jan Engelhardt Cc: xfs@oss.sgi.com, Linux Kernel Mailing List Subject: Re: Do not reset xfsquota flags on quotaless ro mount Message-ID: <20071218143849.GP4396912@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/5165/Tue Dec 18 04:31:02 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13999 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 03:04:03PM +0100, Jan Engelhardt wrote: > Hi, > > > In https://bugzilla.novell.com/show_bug.cgi?id=345338 it is claimed that > resetting the quota flags in the mounting sequence rw,ro,rw is a bug, but I You mounted without quotas in the middle step, thereby invalidating them. > would say this is not the case, as quota is metadata, and the log is replayed > in ro mode even for other filesystems. Yet, it is still not nice, and I have > been trying with this patch, which does not do the right thing yet. (It does a > recovery when mounting for the 3rd time, which probably just says that I did > not know too much of xfs internals to cook up a nicely working patch.) > Opinions? Log recovery occurs on read only mounts. Log recovery on filesystems without quota enabled ignores quota changes in the log (as quotas are not enabled and hence we can't assume that there's dquots still on disk). Hence a mount read only without quota enabled will leave quota inconsistent on disk. i.e > mount -o usrquota,grpquota /dev/mapper/myxfs /mnt > umount /mnt > mount -o ro /dev/mapper/myxfs /mnt Quota is now potentially inconsistent, and hence: > umount /mnt > mount -o usrquota,grpquota /dev/mapper/myxfs /mnt This mount *must* recalculate it. So, behaviour is as expected given the above command sequence. You should use this as the middle step: mount -o ro,usrquota,grpquota /dev/mapper/myxfs /mnt So that log replay replays all the journalled quota changes so that the quota remains consistent with the rest of the filesystem. Then you wont see a recalc when you remount rw. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 18 06:42:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 06:42: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.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBIEg01g007829 for ; Tue, 18 Dec 2007 06:42:03 -0800 X-ASG-Debug-ID: 1197988931-4e9400860000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-tls.univ-nantes.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7B91C1180318 for ; Tue, 18 Dec 2007 06:42:11 -0800 (PST) Received: from smtp-tls.univ-nantes.fr (Smtp-Tls1.univ-nantes.fr [193.52.101.145]) by cuda.sgi.com with ESMTP id lTSqu7l7HqVfPAjm for ; Tue, 18 Dec 2007 06:42:11 -0800 (PST) Received: from localhost (debian [127.0.0.1]) by smtp-tls.univ-nantes.fr (Postfix) with ESMTP id 4479B500719; Tue, 18 Dec 2007 15:41:37 +0100 (CET) Received: from smtp-tls.univ-nantes.fr ([193.52.101.145]) by localhost (SMTP-TLS.univ-nantes.fr [193.52.101.145]) (amavisd-new, port 10024) with LMTP id 11665-01-16; Tue, 18 Dec 2007 15:41:37 +0100 (CET) Received: from [172.20.13.9] (tomintoul.cri.univ-nantes.prive [172.20.13.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-tls.univ-nantes.fr (Postfix) with ESMTP id 2636750070D; Tue, 18 Dec 2007 15:41:37 +0100 (CET) Message-ID: <4767DC20.1080406@univ-nantes.fr> Date: Tue, 18 Dec 2007 15:41:36 +0100 From: Yann Dupont Organization: CRIUN User-Agent: Thunderbird 3.0a1pre (X11/2007120904) MIME-Version: 1.0 To: David Chinner Cc: xfs@oss.sgi.com, Jacky Carimalo X-ASG-Orig-Subj: Re: kernel oops on debian , 2.6.18-5 Subject: Re: kernel oops on debian , 2.6.18-5 References: <476790D5.6040205@univ-nantes.fr> <20071218123259.GL4396912@sgi.com> In-Reply-To: <20071218123259.GL4396912@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.91.2/5165/Tue Dec 18 04:31:02 2007 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at smtp.univ-nantes.fr X-Barracuda-Connect: Smtp-Tls1.univ-nantes.fr[193.52.101.145] X-Barracuda-Start-Time: 1197988932 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36979 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14000 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Yann.Dupont@univ-nantes.fr Precedence: bulk X-list: xfs David Chinner wrote: > On Tue, Dec 18, 2007 at 10:20:21AM +0100, Yann Dupont wrote: > >> Hello, we got a kernel oops, probably in xfs on a debian kernel. >> >> This volume is on SAN + device mapper. >> this is a 1 TB volume. It was in service for more than 2 ou 3 years. >> There is a high humber of files on it, as this volume serves for a >> rsyncd, where 200+ servers sync their root filesystem on it every day. >> >> here is the oops : >> >> Dec 16 23:27:32 inchgower kernel: XFS internal error >> XFS_WANT_CORRUPTED_GOTO at line 1561 of file fs/xfs/xfs_alloc.c. Caller >> 0xffffffff881857b7 >> Dec 16 23:27:32 inchgower kernel: >> Dec 16 23:27:32 inchgower kernel: Call Trace: >> Dec 16 23:27:32 inchgower kernel: [] >> :xfs:xfs_free_ag_extent+0x19f/0x67f >> > > corrupted freespace btree. what does xfs_check tell you about the > filesystem on dm-3? > > xfs_check tells me to run xfs_repair -L, the attempts to mount the FS to clear the logs ending in kernel oops. XFS internal error XFS_WANT_CORRUPTED_RETURN at line 281 of file fs/xfs/xfs_alloc.c. Caller 0xffffffff88182f74 Call Trace: [] :xfs:xfs_alloc_fixup_trees+0x2fa/0x30b [] :xfs:xfs_btree_setbuf+0x1f/0x89 [] :xfs:xfs_alloc_ag_vextent+0xbd4/0xf5e [] :xfs:xfs_alloc_vextent+0x2ce/0x401 [] :xfs:xfs_bmapi+0x1068/0x1c85 [] :xfs:kmem_zone_alloc+0x56/0xa3 [] :xfs:xfs_dir2_grow_inode+0xca/0x2d4 [] :xfs:xfs_dir2_sf_to_block+0xad/0x5ba [] :xfs:xfs_inode_item_init+0x1e/0x7a [] :xfs:xfs_dir2_sf_addname+0x19d/0x4cf [] :xfs:xfs_dir_createname+0xc4/0x134 [] :xfs:kmem_zone_zalloc+0x1e/0x2f [] :xfs:xfs_inode_item_init+0x1e/0x7a [] :xfs:xfs_create+0x39d/0x5dd [] :xfs:xfs_vn_mknod+0x1bd/0x3c8inchgower:~# strace -fp 7885 Process 17194 attached with 6 threads - interrupt to quit [] __up_read+0x13/0x8a [] :xfs:xfs_iunlock+0x57/0x79 [] :xfs:xfs_access+0x3d/0x46 [] :xfs:xfs_dir_lookup+0xa2/0x122 [] link_path_walk+0xd3/0xe5 [] vfs_create+0xe7/0x12c [] open_namei+0x18c/0x6a0 [] :xfs:xfs_file_open+0x27/0x2c [] do_filp_open+0x1c/0x3d [] do_sys_open+0x44/0xc5 [] ia32_sysret+0x0/0xa Filesystem "dm-1": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0xffffffff881c6253 Call Trace: [] :xfs:xfs_trans_cancel+0x5b/0xfe [] :xfs:xfs_create+0x58b/0x5dd [] :xfs:xfs_vn_mknod+0x1bd/0x3c8 [] __up_read+0x13/0x8a [] :xfs:xfs_iunlock+0x57/0x79 [] :xfs:xfs_access+0x3d/0x46 [] :xfs:xfs_dir_lookup+0xa2/0x122 [] link_path_walk+0xd3/0xe5 [] vfs_create+0xe7/0x12c [] open_namei+0x18c/0x6a0 [] :xfs:xfs_file_open+0x27/0x2c [] do_filp_open+0x1c/0x3d [] do_sys_open+0x44/0xc5 [] ia32_sysret+0x0/0xa I've been upgrading the xfs_repair to last version available on debian (xfs_repair version 2.9.4) There are lots of errors reported (don't have the beginning on the console) ... data fork in ino 3628932549 claims free block 226749351 data fork in ino 3628932549 claims free block 226749352 data fork in ino 3628932549 claims free block 226749353 data fork in ino 3628932549 claims free block 226749354 data fork in ino 3628932549 claims free block 226749355 data fork in ino 3628932549 claims free block 226749356 data fork in ino 3628932549 claims free block 226749357 data fork in ino 3628932549 claims free block 226749358 data fork in ino 3628932549 claims free block 226749359 data fork in ino 3628932549 claims free block 226749360 data fork in ino 3628932549 claims free block 226749361 data fork in ino 3628932549 claims free block 226749362 data fork in ino 3628932549 claims free block 226749363 imap claims a free inode 3629547632 is in use, correcting imap and clearing inode - agno = 28 - agno = 29 data fork in ino 3894217924 claims free block 243388605 data fork in ino 3894217924 claims free block 243388606 data fork in ino 3899211601 claims free block 243702250 data fork in ino 3899211601 claims free block 243702251 data fork in ino 3899211601 claims free block 243702252 data fork in ino 3907562994 claims free block 244222632 data fork in ino 3907562994 claims free block 244222633 data fork in ino 3907562994 claims free block 244222634 data fork in ino 3907562994 claims free block 244222635 data fork in ino 3907562994 claims free block 244222636 data fork in ino 3910289697 claims free block 244393117 data fork in ino 3910289697 claims free block 244393118 data fork in ino 3910289699 claims free block 244393113 .... and in the end : - agno = 31 correcting imap correcting imap correcting imap correcting imap correcting imap - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 ) And now the process seems stuck. There is no activity on the san disk ; a ps show this : root 7885 6466 7885 0 6 1447133 5660020 6 09:55 pts/0 00:00:19 xfs_repair -L /dev/evms/DATAXFS2 root 7885 6466 17190 0 6 1447133 5660020 6 10:16 pts/0 00:00:00 xfs_repair -L /dev/evms/DATAXFS2 root 7885 6466 17191 0 6 1447133 5660020 6 10:16 pts/0 00:00:00 xfs_repair -L /dev/evms/DATAXFS2 root 7885 6466 17192 0 6 1447133 5660020 6 10:16 pts/0 00:00:00 xfs_repair -L /dev/evms/DATAXFS2 root 7885 6466 17193 0 6 1447133 5660020 6 10:16 pts/0 00:00:00 xfs_repair -L /dev/evms/DATAXFS2 root 7885 6466 17194 0 6 1447133 5660020 6 10:16 pts/0 00:00:00 xfs_repair -L /dev/evms/DATAXFS2 and a strace this : inchgower:~# strace -fp 7885 Process 17194 attached with 6 threads - interrupt to quit [pid 17191] futex(0x2aab3c8fa884, FUTEX_WAIT, 44, NULL [pid 17192] futex(0x2aab3c8fa884, FUTEX_WAIT, 44, NULL [pid 17193] futex(0x2aab3c8fa884, FUTEX_WAIT, 44, NULL [pid 17194] futex(0x2aab3c8fa884, FUTEX_WAIT, 44, NULL [pid 17190] futex(0x67e4f8, FUTEX_WAIT, 2, NULL Can I stop the process and start another version without risking problems ? > Could be a hardware problem. Could be an XFs problem. Coul dbe a dm problem. > I really can't say from a shutdown message like this - all it tells us is > that a btree block was corrupted by something since the last time it was > checked.... > > Cheers, > > Dave. > OK, cheers, -- Yann Dupont, Cri de l'universit de Nantes Tel: 02.51.12.53.91 - Fax: 02.51.12.58.60 - Yann.Dupont@univ-nantes.fr From owner-xfs@oss.sgi.com Tue Dec 18 06:49:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 06:49:08 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_22 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBIEmt1S008511 for ; Tue, 18 Dec 2007 06:49:01 -0800 X-ASG-Debug-ID: 1197989345-0827008c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sovereign.computergmbh.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C30664970A8 for ; Tue, 18 Dec 2007 06:49:05 -0800 (PST) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by cuda.sgi.com with ESMTP id 2qnQc3FiBSbZDEGU for ; Tue, 18 Dec 2007 06:49:05 -0800 (PST) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id C0F58181AA0CF; Tue, 18 Dec 2007 15:49:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id B9E201C008734; Tue, 18 Dec 2007 15:49:02 +0100 (CET) Date: Tue, 18 Dec 2007 15:49:02 +0100 (CET) From: Jan Engelhardt To: David Chinner cc: xfs@oss.sgi.com, Linux Kernel Mailing List X-ASG-Orig-Subj: Re: Do not reset xfsquota flags on quotaless ro mount Subject: Re: Do not reset xfsquota flags on quotaless ro mount In-Reply-To: <20071218143849.GP4396912@sgi.com> Message-ID: References: <20071218143849.GP4396912@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Barracuda-Connect: sovereign.computergmbh.de[85.214.69.204] X-Barracuda-Start-Time: 1197989346 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36980 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5165/Tue Dec 18 04:31:02 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14001 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 19 2007 01:38, David Chinner wrote: >> >> In https://bugzilla.novell.com/show_bug.cgi?id=345338 it is >> claimed that resetting the quota flags in the mounting sequence >> rw,ro,rw is a bug, but I would say this is not the case, > >You mounted without quotas in the middle step, thereby invalidating >them. > That's clear to me, but according to the commenter, the filesystem is in read-only mode (that is, if no recovery was necessary for the ro mount), hence they should not be invalidated as they cannot change anyway. Or can they? From owner-xfs@oss.sgi.com Tue Dec 18 07:19:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 07:20:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBIFJq57010580 for ; Tue, 18 Dec 2007 07:19:57 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA25866; Wed, 19 Dec 2007 02:19:51 +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 lBIFJnIN12881000; Wed, 19 Dec 2007 02:19:49 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBIFJlpC13073078; Wed, 19 Dec 2007 02:19:47 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 19 Dec 2007 02:19:47 +1100 From: David Chinner To: Damien Wyart Cc: David Chinner , Christoph Hellwig , Lachlan McIlroy , Peter Leckie , Linus Torvalds , linux-xfs@oss.sgi.com, LKML Subject: Re: Important regression with XFS update for 2.6.24-rc6 Message-ID: <20071218151946.GQ4396912@sgi.com> References: <20071218112804.GA3069@localhost.localdomain> <20071218122445.GJ4396912@sgi.com> <877ijckrco.fsf@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877ijckrco.fsf@free.fr> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5169/Tue Dec 18 06:29:04 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14002 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 03:30:31PM +0100, Damien Wyart wrote: > * David Chinner [071218 13:24]: > > Ok. I haven't noticed anything wrong with directories up to about > > 250,000 files in the last few days. The ls -l I just did on > > a directory with 15000 entries (btree format) used about 5MB of RAM. > > extent format directories appear to work fine as well (tested 500 > > entries). > > Ok, nice to know the problem is not so frequent. ..... > I have put the files at http://damien.wyart.free.fr/xfs/ > > strace_xfs_problem.1.gz and strace_xfs_problem.2.gz have been created > with the problematic kernel, and are quite bigger than > strace_xfs_problem.normal.gz, which has been created with the vanilla > rc5-git5. There is also xfs_info. Looks like several getdents() through the directory the getdents() call starts outputting the first files again. It gets to a certain point and always goes back to the beginning. However, it appears to get to the end eventually (without ever getting past the bad offset). I'll ook into this more in the morning as it's not obvious what is wrong in my sleep-deprived state.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 18 09:36:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 09:36:40 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBIHaYII023884 for ; Tue, 18 Dec 2007 09:36:35 -0800 X-ASG-Debug-ID: 1197999405-4e8b02630000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3518011839E7 for ; Tue, 18 Dec 2007 09:36:45 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id ExATT1u1nM4qPmRy for ; Tue, 18 Dec 2007 09:36:45 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J4gN1-0001xG-08; Tue, 18 Dec 2007 17:36:43 +0000 Date: Tue, 18 Dec 2007 17:36:42 +0000 From: Christoph Hellwig To: Bret Towe Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs mknod regression Subject: Re: xfs mknod regression Message-ID: <20071218173642.GA7338@infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197999407 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36991 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5171/Tue Dec 18 08:59:19 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14003 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 This was broken by my '[XFS] simplify xfs_create/mknod/symlink prototype', which assigned the re-shuffled ondisk dev_t back to the rdev variable in xfs_vn_mknod. Because of that i_rdev is set to the ondisk dev_t instead of the linux dev_t later down the function. Fortunately the fix for it is trivial: we can just remove the assignment because xfs_revalidate_inode has done the proper job before unlocking the inode. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-12-18 18:23:32.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-12-18 18:23:43.000000000 +0100 @@ -345,9 +345,7 @@ xfs_vn_mknod( ASSERT(vp); ip = vn_to_inode(vp); - if (S_ISCHR(mode) || S_ISBLK(mode)) - ip->i_rdev = rdev; - else if (S_ISDIR(mode)) + if (S_ISDIR(mode)) xfs_validate_fields(ip); d_instantiate(dentry, ip); xfs_validate_fields(dir); From owner-xfs@oss.sgi.com Tue Dec 18 09:48:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 09:48:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBIHmOBx025081 for ; Tue, 18 Dec 2007 09:48:26 -0800 X-ASG-Debug-ID: 1198000114-4e8b02840000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 99DE11184D5B for ; Tue, 18 Dec 2007 09:48:35 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 37qJ7uEdAawmTupX for ; Tue, 18 Dec 2007 09:48:35 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBIHmTF3003360 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 18 Dec 2007 18:48:29 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBIHmTHd003358 for xfs@oss.sgi.com; Tue, 18 Dec 2007 18:48:29 +0100 Date: Tue, 18 Dec 2007 18:48:29 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] remove superflous xfs_readsb call in xfs_mountfs Subject: [PATCH] remove superflous xfs_readsb call in xfs_mountfs Message-ID: <20071218174829.GA3195@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1198000116 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36991 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5171/Tue Dec 18 08:59:19 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14004 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs When xfs_mountfs is called by xfs_mount xfs_readsb was called 35 lines above unconditionally, so there is no need to try to read the superblock if it's not present. If any other port doesn't have the superblock read at this point it should just call it directly from it's xfs_mount equivalent. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_mount.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c 2007-12-17 14:34:57.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_mount.c 2007-12-17 14:35:17.000000000 +0100 @@ -968,11 +968,6 @@ xfs_mountfs( int uuid_mounted = 0; int error = 0; - if (mp->m_sb_bp == NULL) { - error = xfs_readsb(mp, mfsi_flags); - if (error) - return error; - } xfs_mount_common(mp, sbp); /* From owner-xfs@oss.sgi.com Tue Dec 18 14:03:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 14:03: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=0.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBIM3Ul9020125 for ; Tue, 18 Dec 2007 14:03:32 -0800 X-ASG-Debug-ID: 1198015421-30d102680000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 78B83118778F for ; Tue, 18 Dec 2007 14:03:41 -0800 (PST) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id 1i1oKAoP9BFzftfX for ; Tue, 18 Dec 2007 14:03:41 -0800 (PST) Received: from [192.168.1.21] (dslb-084-057-098-054.pools.arcor-ip.net [84.57.98.54]) by mail.lichtvoll.de (Postfix) with ESMTP id 8F7D75ADE2 for ; Tue, 18 Dec 2007 23:03:10 +0100 (CET) From: Martin Steigerwald To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Installing grub onto a system with XFS root fs Subject: Re: Installing grub onto a system with XFS root fs Date: Tue, 18 Dec 2007 23:03:04 +0100 User-Agent: KMail/1.9.7 References: <20071217004945.GA13335@jdc.jasonjgw.net> <20071217230437.GA7169@jdc.jasonjgw.net> <20071218003536.GD4396912@sgi.com> (sfid-20071218_094441_108310_A0063363) In-Reply-To: <20071218003536.GD4396912@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712182303.05098.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1198015422 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37007 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5174/Tue Dec 18 11:07:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14005 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Am Dienstag 18 Dezember 2007 schrieb David Chinner: > On Tue, Dec 18, 2007 at 10:04:37AM +1100, Jason White wrote: > > On Mon, Dec 17, 2007 at 02:28:51PM +0100, Martin Steigerwald wrote: [...] > > Apparently there is XFS support in Grub 2 as well, which is where all > > development is now taking place. I hope it receives adequate testing > > and attention before distributions start using Grub 2. > > I just looked at the XFS code in ithe grub 2 CVS repository and had a > read of the wiki (http://grub.enbug.org/). > > From the code and the wiki, I note that there is no indication of grub > 2 fixing the worst design mistakes in grub and is persisting with > stuffing around with filesystem internals to find files and get block > mappings for file data. Hence grub 2 will break just like grub if we > ever change things on disk like the inode, directory or extent format. > Lucky it doesn't support btree formats yet, so that won't break if we > change them.... > > And there's plans on doing *journal replay* for filesystems! > (#1 item on the todo list here: http://grub.enbug.org/TodoList). That's > an insane layering violation and completely unsupportable by anyone. I > certainly hope this part of the plan for grub 2 never gets implemented. Hi David! I think it may be a good idea to contact the GRUB development team about your concerns. I bet they won't read this mailing list. But how do you think GRUB is supposed the kernel and initrd without knowing at least enough details of the filesystem in order to load the file. The only other alternative I see is LILO which uses map of the blocks to load and thus has to be rewritten on any change. It might be just me, but I cannot recall having trouble with GRUB and XFS beside that grub-install didn't work. Well grub shell always worked for me so I didn't bother that much. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Dec 18 14:05:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 14:05:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBIM5I3F020394 for ; Tue, 18 Dec 2007 14:05:20 -0800 X-ASG-Debug-ID: 1198015528-519a00380000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sargon.lncsa.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B536049A8DC for ; Tue, 18 Dec 2007 14:05:29 -0800 (PST) Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by cuda.sgi.com with ESMTP id Fvgw5yqmV2qgFk4H for ; Tue, 18 Dec 2007 14:05:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 20A1D301E6C9; Tue, 18 Dec 2007 23:04:51 +0100 (CET) X-Virus-Scanned: ClamAV 0.91.2/5174/Tue Dec 18 11:07:58 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vZyaVtjD80g; Tue, 18 Dec 2007 23:04:51 +0100 (CET) Received: from [192.168.0.192] (gw.unix-scripts.info [62.212.121.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by sargon.lncsa.com (Postfix) with ESMTP id 36204301C63D; Tue, 18 Dec 2007 23:04:45 +0100 (CET) Message-ID: <47684404.6010809@lncsa.com> Date: Tue, 18 Dec 2007 23:04:52 +0100 From: Laurent CARON User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Issue with 2.6.23 and drbd 8.0.7 Subject: Re: Issue with 2.6.23 and drbd 8.0.7 References: <20071217143655.chiehahh@trusted.lncsa.com> <20071217220354.GU4396912@sgi.com> <4766F58C.8040000@lncsa.com> <20071217233759.GB4396912@sgi.com> <47678124.80906@lncsa.com> <20071218122900.GK4396912@sgi.com> In-Reply-To: <20071218122900.GK4396912@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sargon.lncsa.com[212.99.8.251] X-Barracuda-Start-Time: 1198015530 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37008 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14006 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lcaron@lncsa.com Precedence: bulk X-list: xfs David Chinner wrote: > Yes, XFS will use more memory - XFS's inodes are substantially larger > in memory than for reiserfs and so will consume more memory for the > same number of cached inodes. Hi, As a temporary workaround (while finishing tests on the x64 system), is there a way to decrease the amount of cached inodes to avoid such "crashes" ? Thanks From owner-xfs@oss.sgi.com Tue Dec 18 16:38:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 16:38:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBJ0bumH005493 for ; Tue, 18 Dec 2007 16:37:59 -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 LAA11684; Wed, 19 Dec 2007 11:37:54 +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 lBJ0boIN13222686; Wed, 19 Dec 2007 11:37:51 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBJ0bj7L13213799; Wed, 19 Dec 2007 11:37:45 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 19 Dec 2007 11:37:45 +1100 From: David Chinner To: Christoph Hellwig Cc: Bret Towe , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, rjw@sisk.pl Subject: Re: xfs mknod regression Message-ID: <20071219003745.GR4396912@sgi.com> References: <20071218173642.GA7338@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071218173642.GA7338@infradead.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5174/Tue Dec 18 11:07:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14007 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 05:36:42PM +0000, Christoph Hellwig wrote: > > This was broken by my '[XFS] simplify xfs_create/mknod/symlink prototype', > which assigned the re-shuffled ondisk dev_t back to the rdev variable in > xfs_vn_mknod. Because of that i_rdev is set to the ondisk dev_t instead > of the linux dev_t later down the function. > > Fortunately the fix for it is trivial: we can just remove the > assignment because xfs_revalidate_inode has done the proper job before > unlocking the inode. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-12-18 18:23:32.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-12-18 18:23:43.000000000 +0100 > @@ -345,9 +345,7 @@ xfs_vn_mknod( > ASSERT(vp); > ip = vn_to_inode(vp); > > - if (S_ISCHR(mode) || S_ISBLK(mode)) > - ip->i_rdev = rdev; > - else if (S_ISDIR(mode)) > + if (S_ISDIR(mode)) > xfs_validate_fields(ip); > d_instantiate(dentry, ip); > xfs_validate_fields(dir); Thanks for this, Christoph - I'll run some tests on it and check it in. Rafael - this is a regression introduced in 2.6.24-rc1 if you want to track it. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 18 16:38:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 16:38:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.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.11/SuSE Linux 0.7) with SMTP id lBJ0c9Rd005507 for ; Tue, 18 Dec 2007 16:38:14 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11697; Wed, 19 Dec 2007 11:38:10 +1100 Date: Wed, 19 Dec 2007 11:38:52 +1100 To: "Yann Dupont" , "David Chinner" Subject: Re: kernel oops on debian , 2.6.18-5 From: "Barry Naujok" Organization: SGI Cc: xfs@oss.sgi.com, "Jacky Carimalo" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <476790D5.6040205@univ-nantes.fr> <20071218123259.GL4396912@sgi.com> <4767DC20.1080406@univ-nantes.fr> Message-ID: In-Reply-To: <4767DC20.1080406@univ-nantes.fr> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/5174/Tue Dec 18 11:07:58 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id lBJ0cGRd005523 X-archive-position: 14008 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Wed, 19 Dec 2007 01:41:36 +1100, Yann Dupont wrote: > David Chinner wrote: >> On Tue, Dec 18, 2007 at 10:20:21AM +0100, Yann Dupont wrote: >> >>> Hello, we got a kernel oops, probably in xfs on a debian kernel. >>> >>> This volume is on SAN + device mapper. >>> this is a 1 TB volume. It was in service for more than 2 ou 3 years. >>> There is a high humber of files on it, as this volume serves for a >>> rsyncd, where 200+ servers sync their root filesystem on it every day. >>> >>> here is the oops : >>> >>> Dec 16 23:27:32 inchgower kernel: XFS internal error >>> XFS_WANT_CORRUPTED_GOTO at line 1561 of file fs/xfs/xfs_alloc.c. >>> Caller >>> 0xffffffff881857b7 >>> Dec 16 23:27:32 inchgower kernel: >>> Dec 16 23:27:32 inchgower kernel: Call Trace: >>> Dec 16 23:27:32 inchgower kernel: [] >>> :xfs:xfs_free_ag_extent+0x19f/0x67f >>> >> >> corrupted freespace btree. what does xfs_check tell you about the >> filesystem on dm-3? >> >> > xfs_check tells me to run xfs_repair -L, the attempts to mount the FS > to clear the logs ending in kernel oops. [snip] > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - check for inodes claiming duplicate blocks... > - agno = 0 > > ) > > And now the process seems stuck. > There is no activity on the san disk ; > > a ps show this : > > root 7885 6466 7885 0 6 1447133 5660020 6 09:55 pts/0 > 00:00:19 xfs_repair -L /dev/evms/DATAXFS2 > root 7885 6466 17190 0 6 1447133 5660020 6 10:16 pts/0 > 00:00:00 xfs_repair -L /dev/evms/DATAXFS2 > root 7885 6466 17191 0 6 1447133 5660020 6 10:16 pts/0 > 00:00:00 xfs_repair -L /dev/evms/DATAXFS2 > root 7885 6466 17192 0 6 1447133 5660020 6 10:16 pts/0 > 00:00:00 xfs_repair -L /dev/evms/DATAXFS2 > root 7885 6466 17193 0 6 1447133 5660020 6 10:16 pts/0 > 00:00:00 xfs_repair -L /dev/evms/DATAXFS2 > root 7885 6466 17194 0 6 1447133 5660020 6 10:16 pts/0 > 00:00:00 xfs_repair -L /dev/evms/DATAXFS2 > > > and a strace this : > inchgower:~# strace -fp 7885 > Process 17194 attached with 6 threads - interrupt to quit > [pid 17191] futex(0x2aab3c8fa884, FUTEX_WAIT, 44, NULL > [pid 17192] futex(0x2aab3c8fa884, FUTEX_WAIT, 44, NULL > [pid 17193] futex(0x2aab3c8fa884, FUTEX_WAIT, 44, NULL > [pid 17194] futex(0x2aab3c8fa884, FUTEX_WAIT, 44, NULL > [pid 17190] futex(0x67e4f8, FUTEX_WAIT, 2, NULL > > Can I stop the process and start another version without risking > problems ? Yes, you can stop and restart. In your scenario, run xfs_repair -P to disable prefetch which is getting stuck. Barry. From owner-xfs@oss.sgi.com Tue Dec 18 16:41:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 16:41: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=-0.3 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBJ0fP0W006272 for ; Tue, 18 Dec 2007 16:41: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 LAA11858; Wed, 19 Dec 2007 11:41: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 lBJ0fRIN13204502; Wed, 19 Dec 2007 11:41:28 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBJ0fQXR13216166; Wed, 19 Dec 2007 11:41:26 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 19 Dec 2007 11:41:26 +1100 From: David Chinner To: Lachlan McIlroy Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: Re: [GIT PULL] XFS update for 2.6.24-rc6 Message-ID: <20071219004126.GS4396912@sgi.com> References: <20071218065911.EDC8158C4C0F@chook.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071218065911.EDC8158C4C0F@chook.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5174/Tue Dec 18 11:07:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14009 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 05:59:11PM +1100, Lachlan McIlroy wrote: > Please pull from the for-linus branch: > git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus Linus, please don't pull this yet. A problem has been found in the dirent fix, and we've just fixed another mknod related regression so we've got another couple of fixes still to go in XFS for 2.6.24. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 18 17:06:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 17:06:12 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBJ162rl008295 for ; Tue, 18 Dec 2007 17:06:07 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12667; Wed, 19 Dec 2007 12:06: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 lBJ169IN13233318; Wed, 19 Dec 2007 12:06:10 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBJ167v213232277; Wed, 19 Dec 2007 12:06:07 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 19 Dec 2007 12:06:07 +1100 From: David Chinner To: David Chinner Cc: Christoph Hellwig , Bret Towe , xfs@oss.sgi.com Subject: Re: xfs mknod regression Message-ID: <20071219010607.GT4396912@sgi.com> References: <20071218173642.GA7338@infradead.org> <20071219003745.GR4396912@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071219003745.GR4396912@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5174/Tue Dec 18 11:07:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14010 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 19, 2007 at 11:37:45AM +1100, David Chinner wrote: > On Tue, Dec 18, 2007 at 05:36:42PM +0000, Christoph Hellwig wrote: > > > > This was broken by my '[XFS] simplify xfs_create/mknod/symlink prototype', > > which assigned the re-shuffled ondisk dev_t back to the rdev variable in > > xfs_vn_mknod. Because of that i_rdev is set to the ondisk dev_t instead > > of the linux dev_t later down the function. > > > > Fortunately the fix for it is trivial: we can just remove the > > assignment because xfs_revalidate_inode has done the proper job before > > unlocking the inode. > > > > > > Signed-off-by: Christoph Hellwig > > > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c > > =================================================================== > > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-12-18 18:23:32.000000000 +0100 > > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-12-18 18:23:43.000000000 +0100 > > @@ -345,9 +345,7 @@ xfs_vn_mknod( > > ASSERT(vp); > > ip = vn_to_inode(vp); > > > > - if (S_ISCHR(mode) || S_ISBLK(mode)) > > - ip->i_rdev = rdev; > > - else if (S_ISDIR(mode)) > > + if (S_ISDIR(mode)) > > xfs_validate_fields(ip); > > d_instantiate(dentry, ip); > > xfs_validate_fields(dir); > > Thanks for this, Christoph - I'll run some tests on it and check it in. Can I get an eyeball or two on the qa test below so i can check it in at the same time? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- xfstests/184 | 43 +++++++++++++++++++++++++++++++++++++++++++ xfstests/184.out | 1 + xfstests/group | 1 + 3 files changed, 45 insertions(+) Index: xfs-cmds/xfstests/group =================================================================== --- xfs-cmds.orig/xfstests/group 2007-12-19 12:01:13.000000000 +1100 +++ xfs-cmds/xfstests/group 2007-12-19 12:02:25.141919445 +1100 @@ -271,3 +271,4 @@ filestreams dgc@sgi.com 181 log auto 182 metadata rw auto 183 rw other auto +184 metadata auto Index: xfs-cmds/xfstests/184 =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfs-cmds/xfstests/184 2007-12-19 12:05:39.756887566 +1100 @@ -0,0 +1,43 @@ +#! /bin/sh +# FS QA Test No. 184 +# +# check mknod makes working nodes. +# +#----------------------------------------------------------------------- +# Copyright (c) 2007 Silicon Graphics, Inc. All Rights Reserved. +#----------------------------------------------------------------------- +# +# creator +owner=dgc@sgi.com + +seq=`basename $0` +echo "QA output created by $seq - silence is golden" + +here=`pwd` +tmp=/tmp/$$ +status=1 # failure is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + cd / + rm -f $tmp.* + _cleanup_testdir +} + +# get standard environment, filters and checks +. ./common.rc +. ./common.filter + +# real QA test starts here +_supported_fs xfs udf nfs +_supported_os IRIX Linux + +_setup_testdir + +mknod $testdir/null c 1 3 +chmod 666 $testdir/null +echo fred > $testdir/null + +status=$? +exit Index: xfs-cmds/xfstests/184.out =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfs-cmds/xfstests/184.out 2007-12-19 12:03:13.835636262 +1100 @@ -0,0 +1 @@ +QA output created by 184 - silence is golden From owner-xfs@oss.sgi.com Tue Dec 18 17:12:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 17:12: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=-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.11/SuSE Linux 0.7) with SMTP id lBJ1C9nG008938 for ; Tue, 18 Dec 2007 17:12:11 -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 MAA12796; Wed, 19 Dec 2007 12:12:12 +1100 Message-ID: <4768703A.2000603@sgi.com> Date: Wed, 19 Dec 2007 12:13:30 +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: Christoph Hellwig , Bret Towe , xfs@oss.sgi.com Subject: Re: xfs mknod regression References: <20071218173642.GA7338@infradead.org> <20071219003745.GR4396912@sgi.com> <20071219010607.GT4396912@sgi.com> In-Reply-To: <20071219010607.GT4396912@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5175/Tue Dec 18 16:28:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14011 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 19, 2007 at 11:37:45AM +1100, David Chinner wrote: >> On Tue, Dec 18, 2007 at 05:36:42PM +0000, Christoph Hellwig wrote: >>> This was broken by my '[XFS] simplify xfs_create/mknod/symlink prototype', >>> which assigned the re-shuffled ondisk dev_t back to the rdev variable in >>> xfs_vn_mknod. Because of that i_rdev is set to the ondisk dev_t instead >>> of the linux dev_t later down the function. >>> >>> Fortunately the fix for it is trivial: we can just remove the >>> assignment because xfs_revalidate_inode has done the proper job before >>> unlocking the inode. >>> >>> >>> Signed-off-by: Christoph Hellwig >>> >>> Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c >>> =================================================================== >>> --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-12-18 18:23:32.000000000 +0100 >>> +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-12-18 18:23:43.000000000 +0100 >>> @@ -345,9 +345,7 @@ xfs_vn_mknod( >>> ASSERT(vp); >>> ip = vn_to_inode(vp); >>> >>> - if (S_ISCHR(mode) || S_ISBLK(mode)) >>> - ip->i_rdev = rdev; >>> - else if (S_ISDIR(mode)) >>> + if (S_ISDIR(mode)) >>> xfs_validate_fields(ip); >>> d_instantiate(dentry, ip); >>> xfs_validate_fields(dir); >> Thanks for this, Christoph - I'll run some tests on it and check it in. > > Can I get an eyeball or two on the qa test below so i can check it in at the > same time? > QA test looks fine Dave. From owner-xfs@oss.sgi.com Tue Dec 18 18:46:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 18:46:31 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBJ2kOO6015690 for ; Tue, 18 Dec 2007 18:46:26 -0800 X-ASG-Debug-ID: 1198032392-458200980000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hs-out-2122.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 021ED49BDD4 for ; Tue, 18 Dec 2007 18:46:32 -0800 (PST) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.247]) by cuda.sgi.com with ESMTP id Z6ziMsoRBd2K8o3E for ; Tue, 18 Dec 2007 18:46:32 -0800 (PST) Received: by hs-out-2122.google.com with SMTP id m63so630914hsc.4 for ; Tue, 18 Dec 2007 18:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=oljgLXD15oy16UYG67gWJBEDHI4kZx0QPzQFGK7LhDc=; b=oXallLNn78eRzjPrgGzJ+w6iF8OcRoYxL3NONMM4cMJjAFo67N05SJcgtOdmCdWIEjdz2XR/vBy3WG6c8nGHeoPS3y7ntYllZnxs7my4oAGV/T6XMusCwkq9idjPm7VhbMKm0VEW9ZTi3SdBrAlvpvruUFnlCXTC9xKLTXPLzH0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YKoJiL3tGrtMoEEHz2H/qUiNcSCn1QcHab1X1KD3y1VktA/3PP4eH+y3xU1STODuZqHmWV65uPDVv53Z1WA/1p8QkuznSufuEXRGIuELC0Jbu+XpraQwKwwgISrY+lVRdp8TJEtSEBf0tmmUETyMhmt4ax1bbUhgFMmC/Frg2Os= Received: by 10.150.149.19 with SMTP id w19mr3332268ybd.121.1198032390331; Tue, 18 Dec 2007 18:46:30 -0800 (PST) Received: by 10.151.8.2 with HTTP; Tue, 18 Dec 2007 18:46:30 -0800 (PST) Message-ID: Date: Tue, 18 Dec 2007 18:46:30 -0800 From: "Bret Towe" To: "Christoph Hellwig" X-ASG-Orig-Subj: Re: xfs mknod regression Subject: Re: xfs mknod regression Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20071218173642.GA7338@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071218173642.GA7338@infradead.org> X-Barracuda-Connect: hs-out-0708.google.com[64.233.178.247] X-Barracuda-Start-Time: 1198032397 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37026 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5175/Tue Dec 18 16:28:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14012 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: magnade@gmail.com Precedence: bulk X-list: xfs On Dec 18, 2007 9:36 AM, Christoph Hellwig wrote: > > This was broken by my '[XFS] simplify xfs_create/mknod/symlink prototype', > which assigned the re-shuffled ondisk dev_t back to the rdev variable in > xfs_vn_mknod. Because of that i_rdev is set to the ondisk dev_t instead > of the linux dev_t later down the function. > > Fortunately the fix for it is trivial: we can just remove the > assignment because xfs_revalidate_inode has done the proper job before > unlocking the inode. > > > Signed-off-by: Christoph Hellwig tested the patch on 2 machines and works fine for me Thanks From owner-xfs@oss.sgi.com Tue Dec 18 19:12:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 19:12:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBJ3CLOF017544 for ; Tue, 18 Dec 2007 19:12:25 -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 OAA15509; Wed, 19 Dec 2007 14:12:29 +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 lBJ3CRIN13034741; Wed, 19 Dec 2007 14:12:28 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBJ3CPaj13261839; Wed, 19 Dec 2007 14:12:25 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 19 Dec 2007 14:12:25 +1100 From: David Chinner To: Linus Torvalds Cc: David Chinner , Lachlan McIlroy , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: Re: [GIT PULL] XFS update for 2.6.24-rc6 Message-ID: <20071219031225.GB4612@sgi.com> References: <20071218065911.EDC8158C4C0F@chook.melbourne.sgi.com> <20071219004126.GS4396912@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5176/Tue Dec 18 18:03:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14013 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 05:19:04PM -0800, Linus Torvalds wrote: > > > On Wed, 19 Dec 2007, David Chinner wrote: > > > > On Tue, Dec 18, 2007 at 05:59:11PM +1100, Lachlan McIlroy wrote: > > > Please pull from the for-linus branch: > > > git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus > > > > Linus, please don't pull this yet. A problem has been found in > > the dirent fix, and we've just fixed another mknod related regression > > so we've got another couple of fixes still to go in XFS for 2.6.24. > > Too late, it's already long since pulled. Ok, we'll just have to get the fixes to you ASAP. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 18 19:18:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 19:18:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBJ3IKtB018437 for ; Tue, 18 Dec 2007 19:18:24 -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 OAA15748; Wed, 19 Dec 2007 14:18:28 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 40C2358C4C0F; Wed, 19 Dec 2007 14:18:28 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: PARTIAL TAKE 974873 - Fix mknod regression Message-Id: <20071219031828.40C2358C4C0F@chook.melbourne.sgi.com> Date: Wed, 19 Dec 2007 14:18:28 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5176/Tue Dec 18 18:03:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14014 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Fix mknod regression This was broken by my '[XFS] simplify xfs_create/mknod/symlink prototype', which assigned the re-shuffled ondisk dev_t back to the rdev variable in xfs_vn_mknod. Because of that i_rdev is set to the ondisk dev_t instead of the linux dev_t later down the function. Fortunately the fix for it is trivial: we can just remove the assignment because xfs_revalidate_inode has done the proper job before unlocking the inode. Signed-off-by: Christoph Hellwig Date: Wed Dec 19 14:17:51 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30273a fs/xfs/linux-2.6/xfs_iops.c - 1.272 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.272&r2=text&tr2=1.271&f=h - fix xfs_vn_mknod regression due to writing the wrong format dev_t to i_rdev. From owner-xfs@oss.sgi.com Tue Dec 18 19:22:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 19:22: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.11/SuSE Linux 0.7) with SMTP id lBJ3MIpI018947 for ; Tue, 18 Dec 2007 19:22:27 -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 OAA15809; Wed, 19 Dec 2007 14:22:26 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id BB45D58C4C0F; Wed, 19 Dec 2007 14:22:26 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 974873 - Add mknod sanity test Message-Id: <20071219032226.BB45D58C4C0F@chook.melbourne.sgi.com> Date: Wed, 19 Dec 2007 14:22:26 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5176/Tue Dec 18 18:03:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14015 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 Add mknod sanity test. Date: Wed Dec 19 14:22:04 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/xfs-cmds Inspected by: lachlan@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:30274a xfstests/184 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/184 - mknod sanity test xfstests/184.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/184.out - mknod sanity test output xfstests/group - 1.117 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/group.diff?r1=text&tr1=1.117&r2=text&tr2=1.116&f=h - Add mknod sanity test to metadata and auto groups From owner-xfs@oss.sgi.com Tue Dec 18 19:43:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 18 Dec 2007 19:43: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.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBJ3hkM8020244 for ; Tue, 18 Dec 2007 19:43:49 -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 OAA16307; Wed, 19 Dec 2007 14:43:51 +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 lBJ3hoIN13275084; Wed, 19 Dec 2007 14:43:50 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBJ3hnAv13277876; Wed, 19 Dec 2007 14:43:49 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 19 Dec 2007 14:43:49 +1100 From: David Chinner To: David Chinner Cc: Lachlan McIlroy , Christoph Hellwig , Donald Douwsma , xfs-oss , gnb@sgi.com Subject: Re: [review] Remove the xfs refcache Message-ID: <20071219034349.GU4396912@sgi.com> References: <4765EC66.5020202@sgi.com> <4765F444.8010705@sgi.com> <20071217071426.GA11462@infradead.org> <47674892.9070506@sgi.com> <20071218074405.GI4396912@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071218074405.GI4396912@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5176/Tue Dec 18 18:03:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14016 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 18, 2007 at 06:44:05PM +1100, David Chinner wrote: > On Tue, Dec 18, 2007 at 03:12:02PM +1100, Lachlan McIlroy wrote: > > Since I have been able to reproduce some of our NAS/NFS performance problems > > without NFS (that is demonstrate that the problems are in XFS) it makes some > > sense to fix these in XFS. I have observed that for some non-NFS workloads > > we see a significant reduction in log traffic with the OFC in XFS so for > > reasons beyond NFS there may be a need to reactivate the refcache code. For > > the moment we are still analysing the pros/cons. > > Reactivating the ref cache is fundamentally the wrong thing to do. > Most of these problems come from the mismatch of inode life cycles > between Linux and XFS and this is the basic problem we need to solve. > > For example - do the open-write-close related performance issues go > away if you remove the xfs_free_eofblocks() call in xfs_release()? > i.e. are we just being stupid about the way we deal with closing > of file descriptors? > > This should work because the linux inode will remain around with a > ref-count of 1 on the unused list due to the dentry pinning it > in place. Only when the dentry gets reclaimed (e.g. memory pressure, > unlink, unmount, etc) will the truncate occur, and hence repeated > single file open-write-close based workloads (like the nfsd) don't > issue a truncate transaction and trash the EOF preallocation on > every close.... > > And look at the code - the *only thing* the refcache does is avoid > the truncate in xfs_release(). So, the patch below is the equivalent > of re-introducing the refcache into XFS but uses the linux inode > life cycle to keep references around. > > FWIW, this means that EOF pre-allocations will not get trimmed > immediately which may have disk usage implications for users with > small quotas, those that create lots of small files, or there are > lots of written inodes with prealocated space cached in memory > when a crash occurs. FYI - numbers to back this up. As an example of where the failure to truncate EOF blocks (i.e. speculative preallocation) is bad, try creating several thousand small files (say 1 byte) and seeing how long they take to sync to disk. With EOF truncation, we get all the data blocks allocated adjacently so the elevator merges them together and we see large I/Os going to disk (i.e. 512k I/os going to disk where 128 different file datai writes have been merged). Without EOF truncation, these files retain their speculative allocation (default 64k) and so when written out we get a stream of 4k I/Os separated by 64k. That is, one seek per inode written out instead of it being large sequential I/O convering 128 files per I/O. To demonstrate, sequntial creation of 1 byte files in a 30s period followed by a (timed) sync: With EOF truncation: Creates | Deletes Loads Files rate usr sys intr csw/s| rate usr sys intr csw/s ----- ------- ---- ----- ----- ----- -----| ---- ----- ----- ----- ----- 1 39312 1070 6.8 91.8 4.3 1959 1572 0.9 107.1 0.4 1109 2 68458 1627 9.9 155.4 2.6 1316 2535 1.7 207.5 0.7 1157 Without EOF truncation: Creates | Deletes Loads Files rate usr sys intr csw/s| rate usr sys intr csw/s ----- ------- ---- ----- ----- ----- -----| ---- ----- ----- ----- ----- 1 42691 461 3.0 37.7 2.2 1535 1579 1.0 123.2 0.6 1105 2 72785 530 3.3 44.4 2.8 1684 1774 37.8 179.7 5.1 2754 Note that without EOF truncation we create 5-10% more files in the 30s period this test ran for (due to it being CPU bound and not issuing empty EOF truncation transactions), but the overall rate includes the time it takes to write the data to disk as well. The data write is far slower without EOF truncation.... Hence we see that the overall create+data write rate suffers *greatly* due to the lack of EOF truncation, and hence why avoiding EOF truncation on file close for local I/O is generally considered a bad thing. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 19 01:43:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 01:43:43 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBJ9hXD1021261 for ; Wed, 19 Dec 2007 01:43:34 -0800 X-ASG-Debug-ID: 1198057421-221c01080000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D126FB6D19E; Wed, 19 Dec 2007 01:43:41 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id wCyVxiGiWtQ2lUaq; Wed, 19 Dec 2007 01:43:41 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBJ9W9F3008826 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Dec 2007 10:32:09 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBJ9W99i008824; Wed, 19 Dec 2007 10:32:09 +0100 Date: Wed, 19 Dec 2007 10:32:09 +0100 From: Christoph Hellwig To: xfs-masters@oss.sgi.com Cc: Andrew Morton , linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] XFS: don't expose sysv device encoding in inode->i_rdev Subject: Re: [xfs-masters] [PATCH] XFS: don't expose sysv device encoding in inode->i_rdev Message-ID: <20071219093209.GA8775@lst.de> References: <200712190404.lBJ44IOf003182@agora.fsl.cs.sunysb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712190404.lBJ44IOf003182@agora.fsl.cs.sunysb.edu> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1198057426 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37053 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5177/Tue Dec 18 23:03:02 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14017 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs I've sent Dave a patch yesterday that fixes the problem in an even nicer way by just removing the assignment in xfs_vn_mknod because we're doing the proper translation deeper down in the stack. The patch should already be on it's way to Linus. From owner-xfs@oss.sgi.com Wed Dec 19 02:27:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 02:27:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBJARdWW024813 for ; Wed, 19 Dec 2007 02:27:42 -0800 X-ASG-Debug-ID: 1198060070-7d2200180000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-tls.univ-nantes.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 24B2249D4EE for ; Wed, 19 Dec 2007 02:27:51 -0800 (PST) Received: from smtp-tls.univ-nantes.fr (Smtp-Tls1.univ-nantes.fr [193.52.101.145]) by cuda.sgi.com with ESMTP id AOWnb5qDBw51Lxjz for ; Wed, 19 Dec 2007 02:27:51 -0800 (PST) Received: from localhost (debian [127.0.0.1]) by smtp-tls.univ-nantes.fr (Postfix) with ESMTP id DA18A500719; Wed, 19 Dec 2007 11:27:16 +0100 (CET) Received: from smtp-tls.univ-nantes.fr ([193.52.101.145]) by localhost (SMTP-TLS.univ-nantes.fr [193.52.101.145]) (amavisd-new, port 10024) with LMTP id 13741-09-3; Wed, 19 Dec 2007 11:27:16 +0100 (CET) Received: from [172.20.13.9] (tomintoul.cri.univ-nantes.prive [172.20.13.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-tls.univ-nantes.fr (Postfix) with ESMTP id BB59750070D; Wed, 19 Dec 2007 11:27:16 +0100 (CET) Message-ID: <4768F204.8060506@univ-nantes.fr> Date: Wed, 19 Dec 2007 11:27:16 +0100 From: Yann Dupont Organization: CRIUN User-Agent: Thunderbird 3.0a1pre (X11/2007120904) MIME-Version: 1.0 To: Barry Naujok Cc: David Chinner , xfs@oss.sgi.com, Jacky Carimalo X-ASG-Orig-Subj: Re: kernel oops on debian , 2.6.18-5 Subject: Re: kernel oops on debian , 2.6.18-5 References: <476790D5.6040205@univ-nantes.fr> <20071218123259.GL4396912@sgi.com> <4767DC20.1080406@univ-nantes.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.91.2/5177/Tue Dec 18 23:03:02 2007 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at smtp.univ-nantes.fr X-Barracuda-Connect: Smtp-Tls1.univ-nantes.fr[193.52.101.145] X-Barracuda-Start-Time: 1198060072 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37056 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14018 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Yann.Dupont@univ-nantes.fr Precedence: bulk X-list: xfs Barry Naujok wrote: > >> >> Can I stop the process and start another version without risking >> problems ? > > Yes, you can stop and restart. In your scenario, run xfs_repair -P to > disable prefetch which is getting stuck. > > Barry. > > > Thanks for the tip, xfs_repair -P did the job. Only minimal problems found : (9856 K in lost+found for a 1 TB volume) inchgower:/var/lib/vservers/VS_Archive/Archive/lost+found# ls -al total 9860 drwxr-xr-x 2 root root 4096 2007-12-19 10:28 . drwxr-xr-x 32 root root 4096 2007-12-04 16:26 .. -rw-r----- 1 root root 0 2007-12-16 19:33 1311409765 -rwx------ 1 root www-data 4992 2007-11-13 11:47 1388664851 -rwx------ 1 root root 4643 2007-09-27 15:51 1388664852 -rw------- 1 ntp 104 369 2007-12-16 22:36 1624155084 -rw-r----- 1 root root 0 2007-12-16 22:03 17043457 -rw-r--r-- 1 root root 8358 2005-05-10 21:54 1810860709 -rw-r--r-- 1 root root 7644 2005-05-10 21:54 1818650492 -rw-r--r-- 1 root root 45620 2005-05-10 21:54 1818650493 -rw-r--r-- 1 root root 5304 2005-05-10 21:54 1818840419 -rw-r--r-- 1 root root 5034 2005-05-10 21:54 1818841748 -rw-r--r-- 1 root root 1300 2005-05-10 21:54 1818842113 -rw-r--r-- 1 root root 6040 2005-05-10 21:54 1818842115 -rw-r--r-- 1 root root 4008 2005-05-10 21:54 1818842134 -rw-r--r-- 1 root root 4019 2005-05-10 21:54 1818873357 -rwx------ 1 root www-data 732 2007-12-14 15:24 1900698499 -rw-r--r-- 1 root root 1060 2007-02-21 18:48 2041002887 -rw-r--r-- 1 root root 152 2005-11-10 17:09 2041002903 -rwx------ 1 root www-data 0 2007-12-15 23:33 2153644053 -rwx------ 1 root www-data 0 2007-12-15 23:33 2158002845 -rw-r--r-- 1 root root 20480 2007-12-16 22:03 2572244357 drwxr-xr-x 2 root root 75 2007-12-16 23:27 268556858 drwxr-xr-x 2 root root 6 2007-12-16 23:27 268556859 -rw-r--r-- 1 root root 20480 2007-12-16 19:33 273918729 -rw-r--r-- 1 root root 1193201 2007-12-16 16:06 3223675010 -rw-r----- 1 root root 0 2007-12-16 19:33 3226075506 -rw-r--r-- 1 root root 22451 2007-12-16 16:07 3226075507 -rwx------ 1 root www-data 19211 2007-12-14 11:22 3361035798 -rwx------ 1 root www-data 1265 2007-12-14 17:58 3628814835 -rwx------ 1 root www-data 0 2007-12-15 22:00 3910289706 -rwx------ 1 root www-data 19211 2007-12-14 13:57 4055379312 -rwx------ 1 root www-data 14360 2007-12-14 17:58 4055415347 -rwx------ 1 root www-data 14346 2007-12-10 18:01 4055415352 -rwx------ 1 root www-data 19225 2007-12-14 17:58 4055415353 drwxr-xr-x 2 root root 19 2007-12-16 23:27 4160831758 drwxr-xr-x 2 root root 20 2007-12-16 23:27 4160831759 drwxr-xr-x 2 root root 6 2005-09-15 11:44 4160831760 -rw-r--r-- 1 root root 1387921 2007-11-05 02:02 620696741 -rw-r--r-- 1 root root 4715935 2007-11-06 02:02 620696742 -rw-r--r-- 1 root root 1389488 2007-11-07 02:02 620696743 -rw-r--r-- 1 root root 1193251 2007-12-16 20:49 633648296 as you can see, some entries on lost+found are from 2005-05-10 (we had some bad power fault at that time), so maybe the corruption was there since a very long time. Cheers, -- Yann Dupont, Cri de l'université de Nantes Tel: 02.51.12.53.91 - Fax: 02.51.12.58.60 - Yann.Dupont@univ-nantes.fr From owner-xfs@oss.sgi.com Wed Dec 19 02:45:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 02:46:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBJAjq13026160 for ; Wed, 19 Dec 2007 02:45:55 -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 VAA24550; Wed, 19 Dec 2007 21:45:51 +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 lBJAjmIN13383543; Wed, 19 Dec 2007 21:45:48 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBJAjiB213383180; Wed, 19 Dec 2007 21:45:44 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 19 Dec 2007 21:45:44 +1100 From: David Chinner To: David Chinner Cc: Damien Wyart , Christoph Hellwig , Lachlan McIlroy , Peter Leckie , Linus Torvalds , linux-xfs@oss.sgi.com, LKML Subject: Re: Important regression with XFS update for 2.6.24-rc6 Message-ID: <20071219104544.GC4612@sgi.com> References: <20071218112804.GA3069@localhost.localdomain> <20071218122445.GJ4396912@sgi.com> <877ijckrco.fsf@free.fr> <20071218151946.GQ4396912@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071218151946.GQ4396912@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5177/Tue Dec 18 23:03:02 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14019 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 19, 2007 at 02:19:47AM +1100, David Chinner wrote: > On Tue, Dec 18, 2007 at 03:30:31PM +0100, Damien Wyart wrote: > > * David Chinner [071218 13:24]: > > > Ok. I haven't noticed anything wrong with directories up to about > > > 250,000 files in the last few days. The ls -l I just did on > > > a directory with 15000 entries (btree format) used about 5MB of RAM. > > > extent format directories appear to work fine as well (tested 500 > > > entries). > > > > Ok, nice to know the problem is not so frequent. > > ..... > > > I have put the files at http://damien.wyart.free.fr/xfs/ > > > > strace_xfs_problem.1.gz and strace_xfs_problem.2.gz have been created > > with the problematic kernel, and are quite bigger than > > strace_xfs_problem.normal.gz, which has been created with the vanilla > > rc5-git5. There is also xfs_info. > > Looks like several getdents() through the directory the getdents() > call starts outputting the first files again. It gets to a certain > point and always goes back to the beginning. However, it appears to > get to the end eventually (without ever getting past the bad offset). UML and a bunch of printk's to the rescue. So we went back to double buffering, which then screwed up the d_off of the dirents. I changed the temporary dirents to point to the current offset so that filldir got what it expected when filling the user buffer. Except it appears that it I didn't to initialise the current offset for the first dirent read from the temporary buffer so filldir occasionally got an uninitialised offset. Can someone pass me a brown paper bag, please? In my local testing, more often than not, that uninitialised offset reads as zero which is where the looping comes from. Sometimes it points off into wacko-land, which is probably how we eventually get the looping terminating before you run out of memory. That also explains why we haven't seen it - it requires the user buffer to fill on the first entry of a backing buffer and so it is largely dependent on the pattern of name lengths, page size and filesystem block size aligning just right to trigger the problem. Can you test this patch, Damien? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/linux-2.6/xfs_file.c | 1 + 1 file changed, 1 insertion(+) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2007-12-19 00:26:40.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c 2007-12-19 21:26:38.701143555 +1100 @@ -348,6 +348,7 @@ xfs_file_readdir( size = buf.used; de = (struct hack_dirent *)buf.dirent; + curr_offset = de->offset /* & 0x7fffffff */; while (size > 0) { if (filldir(dirent, de->name, de->namlen, curr_offset & 0x7fffffff, From owner-xfs@oss.sgi.com Wed Dec 19 03:17:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 03:17:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBJBHp7D028797 for ; Wed, 19 Dec 2007 03:17:54 -0800 X-ASG-Debug-ID: 1198063083-576a00f70000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mallaury.nerim.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4389549D615 for ; Wed, 19 Dec 2007 03:18:03 -0800 (PST) Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by cuda.sgi.com with ESMTP id lq50nRIUnsl80SVz for ; Wed, 19 Dec 2007 03:18:03 -0800 (PST) Received: from brouette (damien.wyart.pck.nerim.net [213.41.244.197]) by mallaury.nerim.net (Postfix) with ESMTP id 73E2C4F427; Wed, 19 Dec 2007 12:17:24 +0100 (CET) Received: by brouette (Postfix, from userid 1000) id E594045BCF; Wed, 19 Dec 2007 12:17:30 +0100 (CET) From: Damien Wyart To: David Chinner Cc: Christoph Hellwig , Lachlan McIlroy , Peter Leckie , Linus Torvalds , linux-xfs@oss.sgi.com, LKML X-ASG-Orig-Subj: Re: Important regression with XFS update for 2.6.24-rc6 Subject: Re: Important regression with XFS update for 2.6.24-rc6 References: <20071218112804.GA3069@localhost.localdomain> <20071218122445.GJ4396912@sgi.com> <877ijckrco.fsf@free.fr> <20071218151946.GQ4396912@sgi.com> <20071219104544.GC4612@sgi.com> Date: Wed, 19 Dec 2007 12:17:30 +0100 In-Reply-To: <20071219104544.GC4612@sgi.com> (David Chinner's message of "Wed, 19 Dec 2007 21:45:44 +1100") Message-ID: <87r6hjaq7p.fsf@free.fr> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Barracuda-Connect: smtp-103-wednesday.noc.nerim.net[62.4.17.103] X-Barracuda-Start-Time: 1198063084 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37059 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5177/Tue Dec 18 23:03:02 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14020 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: damien.wyart@free.fr Precedence: bulk X-list: xfs * David Chinner [071219 11:45]: > Can someone pass me a brown paper bag, please? My first impression on this bug was not so wrong, after all ;-) > That also explains why we haven't seen it - it requires the user > buffer to fill on the first entry of a backing buffer and so it is > largely dependent on the pattern of name lengths, page size and > filesystem block size aligning just right to trigger the problem. I guess I was lucky to trigger it quite easily... > Can you test this patch, Damien? Works fine, all the bad symptoms have disappeared and strace output is normal. So you can add: Tested-by: Damien Wyart -- Damien From owner-xfs@oss.sgi.com Wed Dec 19 03:31:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 03:31:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBJBVJt1030333 for ; Wed, 19 Dec 2007 03:31:25 -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 WAA25539; Wed, 19 Dec 2007 22:31:18 +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 lBJBVFIN13413196; Wed, 19 Dec 2007 22:31:16 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBJBVDMv13411937; Wed, 19 Dec 2007 22:31:13 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 19 Dec 2007 22:31:12 +1100 From: David Chinner To: Damien Wyart Cc: David Chinner , Christoph Hellwig , Lachlan McIlroy , Peter Leckie , Linus Torvalds , linux-xfs@oss.sgi.com, LKML Subject: Re: Important regression with XFS update for 2.6.24-rc6 Message-ID: <20071219113112.GD4612@sgi.com> References: <20071218112804.GA3069@localhost.localdomain> <20071218122445.GJ4396912@sgi.com> <877ijckrco.fsf@free.fr> <20071218151946.GQ4396912@sgi.com> <20071219104544.GC4612@sgi.com> <87r6hjaq7p.fsf@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r6hjaq7p.fsf@free.fr> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5177/Tue Dec 18 23:03:02 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14021 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 19, 2007 at 12:17:30PM +0100, Damien Wyart wrote: > * David Chinner [071219 11:45]: > > Can someone pass me a brown paper bag, please? > > My first impression on this bug was not so wrong, after all ;-) > > > That also explains why we haven't seen it - it requires the user buffer to > > fill on the first entry of a backing buffer and so it is largely dependent > > on the pattern of name lengths, page size and filesystem block size > > aligning just right to trigger the problem. > > I guess I was lucky to trigger it quite easily... > > > Can you test this patch, Damien? > > Works fine, all the bad symptoms have disappeared and strace output is > normal. > > So you can add: > > Tested-by: Damien Wyart Thanks for reporting the bug and testing the fix so quickly, Damien. I'll give it some more QA before I push it, though. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 19 08:23:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 08:23:36 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBJGNQQA029551 for ; Wed, 19 Dec 2007 08:23:30 -0800 X-ASG-Debug-ID: 1198081417-5a7101ff0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from chef.nerp.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7A333B70314 for ; Wed, 19 Dec 2007 08:23:37 -0800 (PST) Received: from chef.nerp.net (chef.nerp.net [199.199.210.160]) by cuda.sgi.com with ESMTP id hPsMrTSgDB4lKHUo for ; Wed, 19 Dec 2007 08:23:37 -0800 (PST) Received: from chef.nerp.net (localhost [127.0.0.1]) by chef.nerp.net (Postfix) with ESMTP id 1BD1B14023C3 for ; Wed, 19 Dec 2007 10:23:52 -0600 (CST) Received: from webmail.nerp.net (localhost [127.0.0.1]) by chef.nerp.net (Postfix) with ESMTP id 055C21402673 for ; Wed, 19 Dec 2007 10:23:52 -0600 (CST) Received: from 132.250.11.79 (SquirrelMail authenticated user dan) by webmail.nerp.net with HTTP; Wed, 19 Dec 2007 08:23:52 -0800 (PST) Message-ID: <3136.132.250.11.79.1198081432.squirrel@webmail.nerp.net> Date: Wed, 19 Dec 2007 08:23:52 -0800 (PST) X-ASG-Orig-Subj: Real time volume free space Subject: Real time volume free space From: "Dan" To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.91.2/5179/Wed Dec 19 05:59:03 2007 on oss.sgi.com X-Virus-Scanned: ClamAV using ClamSMTP X-Barracuda-Connect: chef.nerp.net[199.199.210.160] X-Barracuda-Start-Time: 1198081419 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1144 1.0000 -1.3069 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.71 X-Barracuda-Spam-Status: No, SCORE=-0.71 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37078 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Status: Clean X-archive-position: 14022 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dan@nerp.net Precedence: bulk X-list: xfs I've been trying to figure out how to determine the free space of a real time volume. It seems xfs_db might hold the key but no luck so far... Simply running df -h tells me the free space of the meta-data drive only which basically doesn't change even after Terabyte data collections. I created the filesystem like this: mkfs.xfs -r rtdev=/dev/md0 /dev/sda How would I tell how much space is left on /dev/md0? Thank you, Dan From owner-xfs@oss.sgi.com Wed Dec 19 11:44:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 11:44: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=-1.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBJJi29k012521 for ; Wed, 19 Dec 2007 11:44:06 -0800 X-ASG-Debug-ID: 1198093454-2fe700720000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E9A1F118A98C for ; Wed, 19 Dec 2007 11:44:14 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by cuda.sgi.com with ESMTP id Icq7a2iPIBtcW67K for ; Wed, 19 Dec 2007 11:44:14 -0800 (PST) Received: from mail.aconex.com (castle.yarra.acx [192.168.3.3]) by postoffice.aconex.com (Postfix) with ESMTP id 71A9292C2B2; Thu, 20 Dec 2007 06:44:12 +1100 (EST) Received: from 192.168.3.1 (proxying for 58.107.42.33) (SquirrelMail authenticated user nscott) by mail.aconex.com with HTTP; Thu, 20 Dec 2007 06:44:41 +1100 (EST) Message-ID: <50214.192.168.3.1.1198093481.squirrel@mail.aconex.com> In-Reply-To: <3136.132.250.11.79.1198081432.squirrel@webmail.nerp.net> References: <3136.132.250.11.79.1198081432.squirrel@webmail.nerp.net> Date: Thu, 20 Dec 2007 06:44:41 +1100 (EST) X-ASG-Orig-Subj: Re: Real time volume free space Subject: Re: Real time volume free space From: nscott@aconex.com To: "Dan" Cc: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: mail.app.aconex.com[203.89.192.138] X-Barracuda-Start-Time: 1198093454 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.87 X-Barracuda-Spam-Status: No, SCORE=-0.87 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=MARKETING_SUBJECT, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37092 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words 0.55 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV 0.91.2/5182/Wed Dec 19 09:36:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14023 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs > > I've been trying to figure out how to determine the free space of a real > time volume. It seems xfs_db might hold the key but no luck so far... > Simply running df -h tells me the free space of the meta-data drive only > which basically doesn't change even after Terabyte data collections. > > I created the filesystem like this: > > mkfs.xfs -r rtdev=/dev/md0 /dev/sda > > How would I tell how much space is left on /dev/md0? The XFS_IOC_FSCOUNTS ioctl exposes this information, and you can use the xfs_quota "free" command to see it (even if you're not using quotas). The df command has no knowledge of the realtime subvolume. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Dec 19 13:29:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 13:29:12 -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.5 required=5.0 tests=BAYES_50,HTML_FONT_SIZE_HUGE, HTML_MESSAGE,J_CHICKENPOX_47,J_CHICKENPOX_65,URIBL_GREY,WHOIS_NETSOLPR autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBJLT4kq023380 for ; Wed, 19 Dec 2007 13:29:06 -0800 X-ASG-Debug-ID: 1198099753-399501be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from zt5.broadcasttoemail.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B1E4A4A1249 for ; Wed, 19 Dec 2007 13:29:13 -0800 (PST) Received: from zt5.broadcasttoemail.com (Zt5.broadcasttoemail.com [216.83.2.135]) by cuda.sgi.com with ESMTP id dfT6evkhgkh9kKJc for ; Wed, 19 Dec 2007 13:29:13 -0800 (PST) Received: from PS3 (app.mailworkz.com [216.83.31.133]) by zt5.broadcasttoemail.com (Postfix) with ESMTP id EA57F2419C1B for ; Wed, 19 Dec 2007 13:39:26 -0400 (AST) x-zt-og-id: 1219320 x-zt-to-id: 3002233 x-zt-gp-id: 1219274 Reply-To: info@pecoproducts.com From: "Daniel Van Waes" To: ", " Message-ID: <23d68094bab44f0694ecd9d344af8d2e@pecoproducts.com> Date: Wed, 19 Dec 2007 14:13:35 -0400 X-ASG-Orig-Subj: Retractable Banner Stand Promotion Subject: Retractable Banner Stand Promotion MIME-Version: 1.0 X-Barracuda-Connect: Zt5.broadcasttoemail.com[216.83.2.135] X-Barracuda-Start-Time: 1198099756 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4914 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.26 X-Barracuda-Spam-Status: No, SCORE=0.26 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_FONT_BIG, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37099 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.26 HTML_FONT_BIG BODY: HTML tag for a big font size X-Virus-Scanned: ClamAV 0.91.2/5182/Wed Dec 19 09:36:58 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1160 X-archive-position: 14024 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: info@pecoproducts.com Precedence: bulk X-list: xfs Having trouble viewing this e-mail? please use this link ( http://app.mailworkz.com/email_view.asp?group_idno=1219274&outgoing_idno=1219320&email_idno=3002233 ) . Wide Format Printing*Graphic Design*Trade Show Displayswww.pecoproducts.com1-866-477-0600 Retractable Banner Stands 3'Retractable Banner Stands (36" x 80" ea.) printed in professional Full- Color Graphics from your print ready file!Special Sale Price:(1) $369.00 plus SHIP*(2) $649.00 plus SHIP*(3) $849.00 plus SHIP*(4) $999.00 plus SHIP*(Call for discounted pricing on 5 or more)Reference Code:RBS1219Offer Expires: 12-21-20071-866-477-0600jimmye@pecoproducts.comapril@pecoproducts.com This email was sent to xfs@oss.sgi.com. Please Remove Me ( http://app.mailworkz.com/unsubscribe.asp?outgoing_idno=1219320&e=3002233&gId=1219274 ) Peco Products LLC | 2344 US Hwy. 641 South | Murray | KY | 42071 | US [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Dec 19 15:45:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 15:45:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBJNjPxJ032165 for ; Wed, 19 Dec 2007 15:45:27 -0800 X-ASG-Debug-ID: 1198107933-446b009e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ogre.sisk.pl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 52D234A1D72 for ; Wed, 19 Dec 2007 15:45:33 -0800 (PST) Received: from ogre.sisk.pl (ogre.sisk.pl [217.79.144.158]) by cuda.sgi.com with ESMTP id ZUuNmEGSWMwJjA8d for ; Wed, 19 Dec 2007 15:45:33 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by ogre.sisk.pl (Postfix) with ESMTP id B0FB57BB7D; Thu, 20 Dec 2007 00:35:31 +0100 (CET) Received: from ogre.sisk.pl ([127.0.0.1]) by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04234-03; Thu, 20 Dec 2007 00:35:16 +0100 (CET) Received: from [192.168.100.100] (nat-be3.aster.pl [212.76.37.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ogre.sisk.pl (Postfix) with ESMTP id A82E37BB2C; Thu, 20 Dec 2007 00:35:16 +0100 (CET) From: "Rafael J. Wysocki" To: David Chinner X-ASG-Orig-Subj: Re: xfs mknod regression Subject: Re: xfs mknod regression Date: Thu, 20 Dec 2007 01:04:49 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: Christoph Hellwig , Bret Towe , linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20071218173642.GA7338@infradead.org> <20071219003745.GR4396912@sgi.com> In-Reply-To: <20071219003745.GR4396912@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712200104.50252.rjw@sisk.pl> X-Virus-Scanned: ClamAV 0.91.2/5183/Wed Dec 19 14:23:52 2007 on oss.sgi.com X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux X-Barracuda-Connect: ogre.sisk.pl[217.79.144.158] X-Barracuda-Start-Time: 1198107937 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37107 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14025 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rjw@sisk.pl Precedence: bulk X-list: xfs On Wednesday, 19 of December 2007, David Chinner wrote: > On Tue, Dec 18, 2007 at 05:36:42PM +0000, Christoph Hellwig wrote: > > > > This was broken by my '[XFS] simplify xfs_create/mknod/symlink prototype', > > which assigned the re-shuffled ondisk dev_t back to the rdev variable in > > xfs_vn_mknod. Because of that i_rdev is set to the ondisk dev_t instead > > of the linux dev_t later down the function. > > > > Fortunately the fix for it is trivial: we can just remove the > > assignment because xfs_revalidate_inode has done the proper job before > > unlocking the inode. > > > > > > Signed-off-by: Christoph Hellwig > > > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c > > =================================================================== > > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-12-18 18:23:32.000000000 +0100 > > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-12-18 18:23:43.000000000 +0100 > > @@ -345,9 +345,7 @@ xfs_vn_mknod( > > ASSERT(vp); > > ip = vn_to_inode(vp); > > > > - if (S_ISCHR(mode) || S_ISBLK(mode)) > > - ip->i_rdev = rdev; > > - else if (S_ISDIR(mode)) > > + if (S_ISDIR(mode)) > > xfs_validate_fields(ip); > > d_instantiate(dentry, ip); > > xfs_validate_fields(dir); > > Thanks for this, Christoph - I'll run some tests on it and check it in. > > Rafael - this is a regression introduced in 2.6.24-rc1 if you want to > track it. I do, thanks. Added to the list, http://bugzilla.kernel.org/show_bug.cgi?id=9608 . I'll close it when the fix is upstream. Thanks, Rafael From owner-xfs@oss.sgi.com Wed Dec 19 16:01:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 16:01:40 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBK01Zwv000939 for ; Wed, 19 Dec 2007 16:01:38 -0800 X-ASG-Debug-ID: 1198108906-5de700510000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from email.msoe.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E4498B78841 for ; Wed, 19 Dec 2007 16:01:47 -0800 (PST) Received: from email.msoe.edu (email.msoe.edu [155.92.194.61]) by cuda.sgi.com with ESMTP id KKvotXyp1oZVz0el for ; Wed, 19 Dec 2007 16:01:47 -0800 (PST) Received: from localhost ([155.92.193.21]) by email.msoe.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Dec 2007 18:01:44 -0600 Date: Wed, 19 Dec 2007 18:01:44 -0600 To: xfs@oss.sgi.com X-ASG-Orig-Subj: mount prob: "log inconsistent or not a log" Subject: mount prob: "log inconsistent or not a log" Message-ID: <20071220000144.GQ19770@msoe.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: Jonathan.Detert@msoe.edu X-OriginalArrivalTime: 20 Dec 2007 00:01:44.0218 (UTC) FILETIME=[81A027A0:01C8429B] X-Barracuda-Connect: email.msoe.edu[155.92.194.61] X-Barracuda-Start-Time: 1198108907 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.47 X-Barracuda-Spam-Status: No, SCORE=-1.47 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37108 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV 0.91.2/5183/Wed Dec 19 14:23:52 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14026 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jonathan.Detert@msoe.edu Precedence: bulk X-list: xfs Hello, I have an xfs filesystem that had been mounted and functioning for several months. An event (see [1] below) occurred which left me unable to mount the file system. The host o.s. is linux 2.6.20 (ubuntu server is the distribution). Here's what I get: -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- root@quartz:/mnt # mount -t xfs -o defaults,_netdev /dev/sdb /usr/local/vms mount: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so root@quartz:/mnt # -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Note that it is an iscsi disk device (hence the '_netdev' mount option). I tried the mount with and without the _netdev option. This is what /var/log/messages has to say about the mount attempt: -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS mounting filesystem sdb Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: Log inconsistent or not a log (last==0, first!=1) Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: empty log check failed Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: log mount/recovery failed: error 22 Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: log mount failed -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- xfs_check is no help; it segfaults: -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- root@quartz:/mnt # xfs_check /dev/sdb cache_node_purge: refcount was 1, not zero (node=0x80c2610) xfs_check: cannot read root inode (22) cache_node_purge: refcount was 1, not zero (node=0x80c4808) xfs_check: cannot read realtime bitmap inode (22) Segmentation fault root@quartz:/mnt # -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- I tried to xfs_repair the file system. xfs_repair returned without noticable errors, and then I could mount the fs. However, the fs was basically empty - it just had a lost+found dir, with a subdir named '128'. This hierarchy repeated itself for several levels. I stopped looking after about the 4th level. The fs is on an iscsi SAN. I have daily snapshots of the SAN volume, going back several days. However, after connecting to the most recent snapshot, I have the same problem - the same errors when trying to mount the fs or xfs_check the fs. I haven't tried to xfs_repair the snapshotted fs, because I don't want the same thing to happen to the snapshot. Lastly, I don't know if this is significant or not, so I'll mention that the iscsi disk device never had a partition table on it. I just used the raw disk device (e.g. /dev/sdb as opposed to /dev/sdb1, etc). Any idea what to do? Thanks [1] the server 'quartz' lost its iscsi connection while the xfs file system was in use. After restoring the iscsi connection, quartz still could not read the xfs file system. I rebooted quartz, and attempted to manually mount /dev/sdb, and got the error messages shown above. -- Jon Detert IT Systems Administrator, Milwaukee School of Engineering 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A. -- Linus Torvalds once found a segmentation fault in the universe. From owner-xfs@oss.sgi.com Wed Dec 19 16:50:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 16:50:27 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBK0oJGh008520 for ; Wed, 19 Dec 2007 16:50:22 -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 LAA16313; Thu, 20 Dec 2007 11:50:27 +1100 Message-ID: <4769BD13.5040303@sgi.com> Date: Thu, 20 Dec 2007 11:53:39 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jonathan.Detert@msoe.edu CC: xfs@oss.sgi.com Subject: Re: mount prob: "log inconsistent or not a log" References: <20071220000144.GQ19770@msoe.edu> In-Reply-To: <20071220000144.GQ19770@msoe.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5183/Wed Dec 19 14:23:52 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14027 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 Jonathan, I'm not giving a high level view but in regards to the log message about the xfs log :) Jonathan.Detert@msoe.edu wrote: > This is what /var/log/messages has to say about the mount attempt: > -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS mounting filesystem sdb > Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: Log inconsistent or not a log (last==0, first!=1) > Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: empty log check failed > Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: log mount/recovery failed: error 22 > Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: log mount failed > -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Every 512 bytes of the log is stamped with the cycle#. The cycle# is effectively the number of times the log has wrapped around. The cycle# is at the start of each sector or near the start for a log record. The cycle# is used to find where the log was last written to (the head of the log). What the message is saying is that the first sector of the log has a cycle# which is not 1 and the last sector has a cycle# of zero. Looking at the code (xlog_find_zeroed), the first sector cycle# is not zero either. => first sector cycle# >1 => last sectir cycle# == 0 Now this can't really happen. If the last cycle# is zero then the first cycle# should be 1 (or possibly 0 on irix). An "xfs_logprint -d /dev/sdb" will show what the cycle#s are and where the log records are. It might give an idea of the extent of the corruption. --Tim From owner-xfs@oss.sgi.com Wed Dec 19 17:16:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 17:16:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBK1GTdC010448 for ; Wed, 19 Dec 2007 17:16:32 -0800 X-ASG-Debug-ID: 1198113395-5de901060000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from email.msoe.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DD6FDB7996D for ; Wed, 19 Dec 2007 17:16:35 -0800 (PST) Received: from email.msoe.edu (email.msoe.edu [155.92.194.61]) by cuda.sgi.com with ESMTP id I0ZKTARZ63i1HnGw for ; Wed, 19 Dec 2007 17:16:35 -0800 (PST) Received: from localhost ([155.92.193.21]) by email.msoe.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Dec 2007 19:16:01 -0600 Date: Wed, 19 Dec 2007 19:16:01 -0600 From: "Jonathan C. Detert" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount prob: "log inconsistent or not a log" Subject: Re: mount prob: "log inconsistent or not a log" Message-ID: <20071220011601.GU19770@msoe.edu> References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4769BD13.5040303@sgi.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 20 Dec 2007 01:16:01.0268 (UTC) FILETIME=[E23C0340:01C842A5] X-Barracuda-Connect: email.msoe.edu[155.92.194.61] X-Barracuda-Start-Time: 1198113398 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3090 1.0000 -0.3106 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.31 X-Barracuda-Spam-Status: No, SCORE=-0.31 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37114 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5185/Wed Dec 19 16:56:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14028 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jonathan.Detert@msoe.edu Precedence: bulk X-list: xfs * Timothy Shimmin [071219 18:53]: > Hi Jonathan, > > I'm not giving a high level view but > in regards to the log message about the xfs log :) > > Jonathan.Detert@msoe.edu wrote: > >This is what /var/log/messages has to say about the mount attempt: > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS mounting filesystem sdb > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: Log inconsistent or not > >a log (last==0, first!=1) > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: empty log check failed > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: log mount/recovery > >failed: error 22 > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: log mount failed > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > Every 512 bytes of the log is stamped with the cycle#. > The cycle# is effectively the number of times the log has wrapped -- snip -- > An "xfs_logprint -d /dev/sdb" will show what the cycle#s are > and where the log records are. It might give an idea of the > extent of the corruption. Ok. It doesn't enlighten me, but hopefully you or others can take time to see it, and maybe it will enlighten you. Here it is: -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- root@quartz:~ # xfs_logprint -d /dev/sdb > xfs_logprint.out xfs_logprint: data device: 0x810 log device: 0x810 daddr: 39859232 length: 38920 [00000 - 00000] Cycle 0xffffffff New Cycle 0x00000256 12 HEADER Cycle 598 tail 598:000010 len 224 ops 5 14 HEADER Cycle 598 tail 598:000044 len 32256 ops 142 78 HEADER Cycle 598 tail 598:000044 len 32256 ops 116 142 HEADER Cycle 598 tail 598:000044 len 32256 ops 82 206 HEADER Cycle 598 tail 598:000044 len 32256 ops 139 270 HEADER Cycle 598 tail 598:000044 len 32256 ops 69 334 HEADER Cycle 598 tail 598:000044 len 32256 ops 102 398 HEADER Cycle 598 tail 598:000044 len 32256 ops 96 462 HEADER Cycle 598 tail 598:000044 len 32256 ops 67 526 HEADER Cycle 598 tail 598:000046 len 32256 ops 86 590 HEADER Cycle 598 tail 598:000046 len 32256 ops 101 654 HEADER Cycle 598 tail 598:000046 len 32256 ops 100 718 HEADER Cycle 598 tail 598:000046 len 32256 ops 98 782 HEADER Cycle 598 tail 598:000046 len 32252 ops 82 846 HEADER Cycle 598 tail 598:000046 len 32256 ops 63 910 HEADER Cycle 598 tail 598:000046 len 32256 ops 150 974 HEADER Cycle 598 tail 598:000046 len 32256 ops 85 1038 HEADER Cycle 598 tail 598:000046 len 32256 ops 113 1102 HEADER Cycle 598 tail 598:000046 len 32256 ops 129 1166 HEADER Cycle 598 tail 598:000046 len 32256 ops 164 1230 HEADER Cycle 598 tail 598:000046 len 32256 ops 93 1294 HEADER Cycle 598 tail 598:000046 len 1052 ops 4 1298 HEADER Cycle 598 tail 598:001326 len 32256 ops 128 1362 HEADER Cycle 598 tail 598:001326 len 32256 ops 85 1426 HEADER Cycle 598 tail 598:001330 len 32256 ops 138 1490 HEADER Cycle 598 tail 598:001330 len 32256 ops 140 1554 HEADER Cycle 598 tail 598:001330 len 32256 ops 184 1618 HEADER Cycle 598 tail 598:001330 len 32256 ops 119 1682 HEADER Cycle 598 tail 598:001330 len 32252 ops 149 1746 HEADER Cycle 598 tail 598:001330 len 32256 ops 89 1810 HEADER Cycle 598 tail 598:001330 len 32256 ops 135 1874 HEADER Cycle 598 tail 598:001330 len 30168 ops 88 1934 HEADER Cycle 598 tail 598:001906 len 32256 ops 143 1998 HEADER Cycle 598 tail 598:001906 len 32256 ops 106 2062 HEADER Cycle 598 tail 598:001906 len 32256 ops 116 2126 HEADER Cycle 598 tail 598:001906 len 32256 ops 112 2190 HEADER Cycle 598 tail 598:001906 len 32256 ops 138 2254 HEADER Cycle 598 tail 598:001906 len 32256 ops 96 2318 HEADER Cycle 598 tail 598:001906 len 32256 ops 92 2382 HEADER Cycle 598 tail 598:001906 len 32236 ops 98 2446 HEADER Cycle 598 tail 598:001966 len 32256 ops 118 2510 HEADER Cycle 598 tail 598:001966 len 32252 ops 147 2574 HEADER Cycle 598 tail 598:001966 len 32256 ops 137 2638 HEADER Cycle 598 tail 598:001966 len 32256 ops 126 2702 HEADER Cycle 598 tail 598:001966 len 32256 ops 139 2766 HEADER Cycle 598 tail 598:001966 len 32256 ops 80 2830 HEADER Cycle 598 tail 598:001966 len 32256 ops 133 2894 HEADER Cycle 598 tail 598:001966 len 32256 ops 112 2958 HEADER Cycle 598 tail 598:001966 len 6708 ops 22 2973 HEADER Cycle 598 tail 598:002990 len 224 ops 5 2975 HEADER Cycle 598 tail 598:003005 len 32256 ops 133 3039 HEADER Cycle 598 tail 598:003005 len 32256 ops 108 3103 HEADER Cycle 598 tail 598:003005 len 32256 ops 95 3167 HEADER Cycle 598 tail 598:003005 len 32256 ops 90 3231 HEADER Cycle 598 tail 598:003005 len 32256 ops 155 3295 HEADER Cycle 598 tail 598:003005 len 32256 ops 163 3359 HEADER Cycle 598 tail 598:003005 len 32256 ops 102 3423 HEADER Cycle 598 tail 598:003005 len 32256 ops 81 3487 HEADER Cycle 598 tail 598:003007 len 32256 ops 93 3551 HEADER Cycle 598 tail 598:003007 len 32256 ops 150 3615 HEADER Cycle 598 tail 598:003007 len 32256 ops 144 3679 HEADER Cycle 598 tail 598:003007 len 32256 ops 106 3743 HEADER Cycle 598 tail 598:003007 len 13128 ops 26 3770 HEADER Cycle 598 tail 598:003007 len 32256 ops 180 3834 HEADER Cycle 598 tail 598:003007 len 32256 ops 109 3898 HEADER Cycle 598 tail 598:003007 len 32256 ops 95 3962 HEADER Cycle 598 tail 598:003007 len 32256 ops 135 4026 HEADER Cycle 598 tail 598:003007 len 32256 ops 91 4090 HEADER Cycle 598 tail 598:003007 len 32256 ops 116 4154 HEADER Cycle 598 tail 598:003007 len 32256 ops 104 4218 HEADER Cycle 598 tail 598:003007 len 32256 ops 113 4282 HEADER Cycle 598 tail 598:003007 len 32256 ops 131 4346 HEADER Cycle 598 tail 598:003007 len 32256 ops 195 4410 HEADER Cycle 598 tail 598:003007 len 32256 ops 63 4474 HEADER Cycle 598 tail 598:003007 len 32256 ops 89 4538 HEADER Cycle 598 tail 598:003007 len 32256 ops 83 4602 HEADER Cycle 598 tail 598:003007 len 32256 ops 124 4666 HEADER Cycle 598 tail 598:003007 len 32256 ops 122 4730 HEADER Cycle 598 tail 598:003007 len 32256 ops 111 4794 HEADER Cycle 598 tail 598:003007 len 32256 ops 134 4858 HEADER Cycle 598 tail 598:003007 len 32256 ops 94 4922 HEADER Cycle 598 tail 598:003007 len 32256 ops 112 4986 HEADER Cycle 598 tail 598:003007 len 32256 ops 109 5050 HEADER Cycle 598 tail 598:003007 len 13784 ops 44 5078 HEADER Cycle 598 tail 598:005082 len 32256 ops 157 5142 HEADER Cycle 598 tail 598:005082 len 32256 ops 171 5206 HEADER Cycle 598 tail 598:005082 len 32256 ops 127 5270 HEADER Cycle 598 tail 598:005082 len 32244 ops 188 5334 HEADER Cycle 598 tail 598:005082 len 32256 ops 133 5398 HEADER Cycle 598 tail 598:005082 len 32256 ops 118 5462 HEADER Cycle 598 tail 598:005082 len 32256 ops 145 5526 HEADER Cycle 598 tail 598:005082 len 32256 ops 153 5590 HEADER Cycle 598 tail 598:005110 len 32256 ops 163 5654 HEADER Cycle 598 tail 598:005110 len 32256 ops 198 5718 HEADER Cycle 598 tail 598:005110 len 32256 ops 148 5782 HEADER Cycle 598 tail 598:005110 len 32256 ops 129 5846 HEADER Cycle 598 tail 598:005110 len 32256 ops 108 5910 HEADER Cycle 598 tail 598:005110 len 32256 ops 103 5974 HEADER Cycle 598 tail 598:005110 len 32256 ops 60 6038 HEADER Cycle 598 tail 598:005110 len 32256 ops 86 6102 HEADER Cycle 598 tail 598:005110 len 32256 ops 59 6166 HEADER Cycle 598 tail 598:005110 len 32256 ops 46 6230 HEADER Cycle 598 tail 598:005110 len 32256 ops 90 6294 HEADER Cycle 598 tail 598:005110 len 32256 ops 162 6358 HEADER Cycle 598 tail 598:005110 len 32256 ops 135 6422 HEADER Cycle 598 tail 598:005110 len 32256 ops 79 6486 HEADER Cycle 598 tail 598:005110 len 32252 ops 75 6550 HEADER Cycle 598 tail 598:005110 len 32256 ops 68 6614 HEADER Cycle 598 tail 598:005110 len 32256 ops 81 6678 HEADER Cycle 598 tail 598:005110 len 32256 ops 98 6742 HEADER Cycle 598 tail 598:005110 len 32256 ops 128 6806 HEADER Cycle 598 tail 598:005110 len 32256 ops 97 6870 HEADER Cycle 598 tail 598:005110 len 32256 ops 122 6934 HEADER Cycle 598 tail 598:005110 len 6068 ops 6 6947 HEADER Cycle 598 tail 598:006902 len 32256 ops 112 7011 HEADER Cycle 598 tail 598:006902 len 32256 ops 125 7075 HEADER Cycle 598 tail 598:006902 len 32256 ops 118 7139 HEADER Cycle 598 tail 598:006902 len 32256 ops 107 7203 HEADER Cycle 598 tail 598:006902 len 32256 ops 89 7267 HEADER Cycle 598 tail 598:006902 len 32256 ops 69 7331 HEADER Cycle 598 tail 598:006966 len 32256 ops 135 7395 HEADER Cycle 598 tail 598:006966 len 32256 ops 125 7459 HEADER Cycle 598 tail 598:006979 len 32256 ops 94 7523 HEADER Cycle 598 tail 598:006979 len 32256 ops 108 7587 HEADER Cycle 598 tail 598:006979 len 32256 ops 197 7651 HEADER Cycle 598 tail 598:006979 len 24684 ops 74 7701 HEADER Cycle 598 tail 598:007683 len 32256 ops 137 7765 HEADER Cycle 598 tail 598:007683 len 32256 ops 119 7829 HEADER Cycle 598 tail 598:007683 len 32256 ops 116 7893 HEADER Cycle 598 tail 598:007683 len 32256 ops 102 7957 HEADER Cycle 598 tail 598:007683 len 32256 ops 122 8021 HEADER Cycle 598 tail 598:007683 len 32256 ops 95 8085 HEADER Cycle 598 tail 598:007683 len 32256 ops 98 8149 HEADER Cycle 598 tail 598:007683 len 32256 ops 98 8213 HEADER Cycle 598 tail 598:007733 len 15556 ops 83 8245 HEADER Cycle 598 tail 598:007733 len 32256 ops 95 8309 HEADER Cycle 598 tail 598:007733 len 32256 ops 81 8373 HEADER Cycle 598 tail 598:007733 len 32256 ops 95 8437 HEADER Cycle 598 tail 598:007733 len 15084 ops 52 8468 HEADER Cycle 598 tail 598:008469 len 32256 ops 100 8532 HEADER Cycle 598 tail 598:008469 len 32256 ops 83 8596 HEADER Cycle 598 tail 598:008469 len 32256 ops 108 8660 HEADER Cycle 598 tail 598:008469 len 32256 ops 99 8724 HEADER Cycle 598 tail 598:008469 len 32256 ops 100 8788 HEADER Cycle 598 tail 598:008469 len 32256 ops 99 8852 HEADER Cycle 598 tail 598:008500 len 6696 ops 29 8867 HEADER Cycle 598 tail 598:008500 len 32256 ops 108 8931 HEADER Cycle 598 tail 598:008500 len 32256 ops 60 8995 HEADER Cycle 598 tail 598:008500 len 32256 ops 75 9059 HEADER Cycle 598 tail 598:008500 len 32256 ops 102 9123 HEADER Cycle 598 tail 598:008500 len 32256 ops 109 9187 HEADER Cycle 598 tail 598:008500 len 32256 ops 98 9251 HEADER Cycle 598 tail 598:008500 len 32256 ops 85 9315 HEADER Cycle 598 tail 598:008500 len 32256 ops 99 9379 HEADER Cycle 598 tail 598:008500 len 32256 ops 63 9443 HEADER Cycle 598 tail 598:008500 len 32256 ops 79 9507 HEADER Cycle 598 tail 598:008500 len 32256 ops 147 9571 HEADER Cycle 598 tail 598:008500 len 32256 ops 121 9635 HEADER Cycle 598 tail 598:008500 len 32256 ops 140 9699 HEADER Cycle 598 tail 598:008500 len 32252 ops 124 9763 HEADER Cycle 598 tail 598:008500 len 32256 ops 163 9827 HEADER Cycle 598 tail 598:008500 len 31064 ops 132 9889 HEADER Cycle 598 tail 598:008899 len 32256 ops 100 9953 HEADER Cycle 598 tail 598:008899 len 32256 ops 87 10017 HEADER Cycle 598 tail 598:008899 len 14464 ops 45 10047 HEADER Cycle 598 tail 598:010049 len 32256 ops 129 10111 HEADER Cycle 598 tail 598:010049 len 32256 ops 124 10175 HEADER Cycle 598 tail 598:010049 len 32256 ops 60 10239 HEADER Cycle 598 tail 598:010049 len 32256 ops 84 10303 HEADER Cycle 598 tail 598:010049 len 32256 ops 88 10367 HEADER Cycle 598 tail 598:010079 len 32256 ops 84 10431 HEADER Cycle 598 tail 598:010079 len 32256 ops 81 10495 HEADER Cycle 598 tail 598:010079 len 32256 ops 121 10559 HEADER Cycle 598 tail 598:010079 len 32256 ops 161 10623 HEADER Cycle 598 tail 598:010079 len 32256 ops 130 10687 HEADER Cycle 598 tail 598:010079 len 32256 ops 106 10751 HEADER Cycle 598 tail 598:010079 len 32256 ops 104 10815 HEADER Cycle 598 tail 598:010079 len 32256 ops 118 10879 HEADER Cycle 598 tail 598:010079 len 1784 ops 4 10884 HEADER Cycle 598 tail 598:010847 len 32256 ops 114 10948 HEADER Cycle 598 tail 598:010847 len 32256 ops 168 11012 HEADER Cycle 598 tail 598:010847 len 32256 ops 121 11076 HEADER Cycle 598 tail 598:010847 len 32256 ops 88 11140 HEADER Cycle 598 tail 598:010847 len 32256 ops 75 11204 HEADER Cycle 598 tail 598:010916 len 32256 ops 106 11268 HEADER Cycle 598 tail 598:010916 len 32256 ops 69 11332 HEADER Cycle 598 tail 598:010916 len 32256 ops 131 11396 HEADER Cycle 598 tail 598:010916 len 32256 ops 109 11460 HEADER Cycle 598 tail 598:010980 len 32256 ops 119 11524 HEADER Cycle 598 tail 598:010980 len 32256 ops 121 11588 HEADER Cycle 598 tail 598:010980 len 32256 ops 158 11652 HEADER Cycle 598 tail 598:010980 len 32256 ops 150 11716 HEADER Cycle 598 tail 598:010980 len 32256 ops 133 11780 HEADER Cycle 598 tail 598:010980 len 32256 ops 155 11844 HEADER Cycle 598 tail 598:010980 len 8760 ops 19 11863 HEADER Cycle 598 tail 598:011876 len 32256 ops 161 11927 HEADER Cycle 598 tail 598:011876 len 32256 ops 170 11991 HEADER Cycle 598 tail 598:011895 len 32256 ops 98 12055 HEADER Cycle 598 tail 598:011895 len 32256 ops 76 12119 HEADER Cycle 598 tail 598:011895 len 32256 ops 84 12183 HEADER Cycle 598 tail 598:011895 len 32256 ops 80 12247 HEADER Cycle 598 tail 598:011895 len 5220 ops 20 12259 HEADER Cycle 598 tail 598:012279 len 32256 ops 109 12323 HEADER Cycle 598 tail 598:012279 len 32256 ops 145 12387 HEADER Cycle 598 tail 598:012279 len 32256 ops 117 12451 HEADER Cycle 598 tail 598:012291 len 32256 ops 120 12515 HEADER Cycle 598 tail 598:012291 len 32256 ops 116 12579 HEADER Cycle 598 tail 598:012291 len 32256 ops 180 12643 HEADER Cycle 598 tail 598:012291 len 32256 ops 81 12707 HEADER Cycle 598 tail 598:012291 len 32256 ops 87 12771 HEADER Cycle 598 tail 598:012291 len 32252 ops 124 12835 HEADER Cycle 598 tail 598:012291 len 32256 ops 168 12899 HEADER Cycle 598 tail 598:012291 len 32256 ops 91 12963 HEADER Cycle 598 tail 598:012291 len 26220 ops 44 13016 HEADER Cycle 598 tail 598:012291 len 32256 ops 122 13080 HEADER Cycle 598 tail 598:012291 len 32256 ops 118 13144 HEADER Cycle 598 tail 598:012291 len 32256 ops 105 13208 HEADER Cycle 598 tail 598:012291 len 32256 ops 83 13272 HEADER Cycle 598 tail 598:012291 len 32256 ops 85 13336 HEADER Cycle 598 tail 598:012291 len 32256 ops 66 13400 HEADER Cycle 598 tail 598:012291 len 27456 ops 119 13455 HEADER Cycle 598 tail 598:013432 len 32256 ops 167 13519 HEADER Cycle 598 tail 598:013432 len 32256 ops 103 13583 HEADER Cycle 598 tail 598:013432 len 32256 ops 101 13647 HEADER Cycle 598 tail 598:013432 len 32256 ops 126 13711 HEADER Cycle 598 tail 598:013432 len 32256 ops 136 13775 HEADER Cycle 598 tail 598:013432 len 32256 ops 86 13839 HEADER Cycle 598 tail 598:013432 len 32256 ops 79 13903 HEADER Cycle 598 tail 598:013432 len 32256 ops 80 13967 HEADER Cycle 598 tail 598:013487 len 32256 ops 74 14031 HEADER Cycle 598 tail 598:013487 len 32256 ops 82 14095 HEADER Cycle 598 tail 598:013487 len 32256 ops 153 14159 HEADER Cycle 598 tail 598:013487 len 32256 ops 104 14223 HEADER Cycle 598 tail 598:013487 len 32256 ops 190 14287 HEADER Cycle 598 tail 598:013487 len 32256 ops 97 14351 HEADER Cycle 598 tail 598:013487 len 32256 ops 99 14415 HEADER Cycle 598 tail 598:013487 len 32256 ops 123 14479 HEADER Cycle 598 tail 598:013487 len 32256 ops 125 14543 HEADER Cycle 598 tail 598:013487 len 32256 ops 112 14607 HEADER Cycle 598 tail 598:013487 len 3968 ops 5 14616 HEADER Cycle 598 tail 598:013487 len 32256 ops 114 14680 HEADER Cycle 598 tail 598:013487 len 32256 ops 122 14744 HEADER Cycle 598 tail 598:013487 len 32256 ops 80 14808 HEADER Cycle 598 tail 598:013487 len 32256 ops 104 14872 HEADER Cycle 598 tail 598:013487 len 32256 ops 79 14936 HEADER Cycle 598 tail 598:013487 len 32256 ops 62 15000 HEADER Cycle 598 tail 598:013487 len 32256 ops 98 15064 HEADER Cycle 598 tail 598:013487 len 32256 ops 115 15128 HEADER Cycle 598 tail 598:013487 len 32256 ops 70 15192 HEADER Cycle 598 tail 598:013487 len 32256 ops 80 15256 HEADER Cycle 598 tail 598:013487 len 32256 ops 118 15320 HEADER Cycle 598 tail 598:013487 len 32256 ops 69 15384 HEADER Cycle 598 tail 598:013487 len 32256 ops 154 15448 HEADER Cycle 598 tail 598:013487 len 10088 ops 34 15469 HEADER Cycle 598 tail 598:015480 len 32256 ops 149 15533 HEADER Cycle 598 tail 598:015480 len 32256 ops 85 15597 HEADER Cycle 598 tail 598:015480 len 32256 ops 78 15661 HEADER Cycle 598 tail 598:015480 len 32256 ops 104 15725 HEADER Cycle 598 tail 598:015480 len 32256 ops 149 15789 HEADER Cycle 598 tail 598:015480 len 32256 ops 57 15853 HEADER Cycle 598 tail 598:015480 len 32256 ops 56 15917 HEADER Cycle 598 tail 598:015480 len 32256 ops 41 15981 HEADER Cycle 598 tail 598:015501 len 32256 ops 56 16045 HEADER Cycle 598 tail 598:015501 len 32256 ops 80 16109 HEADER Cycle 598 tail 598:015501 len 32256 ops 134 16173 HEADER Cycle 598 tail 598:015501 len 32248 ops 144 16237 HEADER Cycle 598 tail 598:015501 len 32256 ops 96 16301 HEADER Cycle 598 tail 598:015501 len 32256 ops 76 16365 HEADER Cycle 598 tail 598:015501 len 32256 ops 111 16429 HEADER Cycle 598 tail 598:015501 len 32256 ops 127 16493 HEADER Cycle 598 tail 598:015501 len 32256 ops 119 16557 HEADER Cycle 598 tail 598:015501 len 32256 ops 104 16621 HEADER Cycle 598 tail 598:015501 len 32256 ops 101 16685 HEADER Cycle 598 tail 598:015501 len 32256 ops 106 16749 HEADER Cycle 598 tail 598:015501 len 32256 ops 190 16813 HEADER Cycle 598 tail 598:015501 len 32252 ops 162 16877 HEADER Cycle 598 tail 598:015501 len 32256 ops 141 16941 HEADER Cycle 598 tail 598:015501 len 32256 ops 99 17005 HEADER Cycle 598 tail 598:015501 len 32256 ops 101 17069 HEADER Cycle 598 tail 598:015501 len 18592 ops 46 17107 HEADER Cycle 598 tail 598:017101 len 32256 ops 148 17171 HEADER Cycle 598 tail 598:017101 len 32256 ops 95 17235 HEADER Cycle 598 tail 598:017139 len 32252 ops 147 17299 HEADER Cycle 598 tail 598:017139 len 32256 ops 130 17363 HEADER Cycle 598 tail 598:017139 len 32256 ops 106 17427 HEADER Cycle 598 tail 598:017139 len 32256 ops 109 17491 HEADER Cycle 598 tail 598:017139 len 32256 ops 121 17555 HEADER Cycle 598 tail 598:017139 len 32256 ops 119 17619 HEADER Cycle 598 tail 598:017139 len 32256 ops 86 17683 HEADER Cycle 598 tail 598:017139 len 32256 ops 106 17747 HEADER Cycle 598 tail 598:017139 len 11080 ops 40 17770 HEADER Cycle 598 tail 598:017779 len 32256 ops 112 17834 HEADER Cycle 598 tail 598:017779 len 32256 ops 118 17898 HEADER Cycle 598 tail 598:017779 len 32256 ops 137 17962 HEADER Cycle 598 tail 598:017779 len 32256 ops 159 18026 HEADER Cycle 598 tail 598:017779 len 32256 ops 145 18090 HEADER Cycle 598 tail 598:017779 len 32256 ops 133 18154 HEADER Cycle 598 tail 598:017779 len 32244 ops 106 18218 HEADER Cycle 598 tail 598:017802 len 32256 ops 106 18282 HEADER Cycle 598 tail 598:017802 len 32256 ops 159 18346 HEADER Cycle 598 tail 598:017802 len 15884 ops 25 18379 HEADER Cycle 598 tail 598:017802 len 32256 ops 117 18443 HEADER Cycle 598 tail 598:017802 len 32256 ops 137 18507 HEADER Cycle 598 tail 598:017802 len 32256 ops 138 18571 HEADER Cycle 598 tail 598:017802 len 32256 ops 152 18635 HEADER Cycle 598 tail 598:017866 len 10988 ops 29 18658 HEADER Cycle 598 tail 598:018667 len 32256 ops 110 18722 HEADER Cycle 598 tail 598:018690 len 900 ops 7 18725 HEADER Cycle 598 tail 598:018690 len 32256 ops 139 18789 HEADER Cycle 598 tail 598:018690 len 32256 ops 111 18853 HEADER Cycle 598 tail 598:018690 len 32256 ops 81 18917 HEADER Cycle 598 tail 598:018690 len 32256 ops 81 18981 HEADER Cycle 598 tail 598:018690 len 32256 ops 78 19045 HEADER Cycle 598 tail 598:018690 len 32256 ops 91 19109 HEADER Cycle 598 tail 598:018690 len 32256 ops 97 19173 HEADER Cycle 598 tail 598:018690 len 32256 ops 62 19237 HEADER Cycle 598 tail 598:018757 len 32256 ops 97 19301 HEADER Cycle 598 tail 598:018757 len 32256 ops 75 19365 HEADER Cycle 598 tail 598:018757 len 32256 ops 60 19429 HEADER Cycle 598 tail 598:018757 len 32256 ops 98 19493 HEADER Cycle 598 tail 598:018757 len 32256 ops 83 19557 HEADER Cycle 598 tail 598:018757 len 32256 ops 70 19621 HEADER Cycle 598 tail 598:018757 len 32248 ops 110 19685 HEADER Cycle 598 tail 598:018757 len 32256 ops 95 19749 HEADER Cycle 598 tail 598:018757 len 32256 ops 88 19813 HEADER Cycle 598 tail 598:018757 len 32256 ops 93 19877 HEADER Cycle 598 tail 598:018757 len 32256 ops 104 19941 HEADER Cycle 598 tail 598:018757 len 32256 ops 101 20005 HEADER Cycle 598 tail 598:018757 len 29988 ops 84 20065 HEADER Cycle 598 tail 598:020037 len 32256 ops 138 20129 HEADER Cycle 598 tail 598:020037 len 32256 ops 105 20193 HEADER Cycle 598 tail 598:020037 len 32256 ops 168 20257 HEADER Cycle 598 tail 598:020037 len 32244 ops 112 20321 HEADER Cycle 598 tail 598:020037 len 32256 ops 131 20385 HEADER Cycle 598 tail 598:020037 len 32256 ops 84 20449 HEADER Cycle 598 tail 598:020037 len 32256 ops 81 20513 HEADER Cycle 598 tail 598:020037 len 32256 ops 112 20577 HEADER Cycle 598 tail 598:020097 len 3512 ops 6 20585 HEADER Cycle 598 tail 598:020609 len 224 ops 5 20587 HEADER Cycle 598 tail 598:020617 len 32256 ops 191 20651 HEADER Cycle 598 tail 598:020617 len 2772 ops 6 20658 HEADER Cycle 598 tail 598:020619 len 32256 ops 124 20722 HEADER Cycle 598 tail 598:020619 len 32256 ops 153 20786 HEADER Cycle 598 tail 598:020619 len 32256 ops 105 20850 HEADER Cycle 598 tail 598:020619 len 32256 ops 115 20914 HEADER Cycle 598 tail 598:020619 len 32256 ops 112 20978 HEADER Cycle 598 tail 598:020619 len 32256 ops 119 21042 HEADER Cycle 598 tail 598:020619 len 32256 ops 114 21106 HEADER Cycle 598 tail 598:020619 len 32256 ops 98 21170 HEADER Cycle 598 tail 598:020619 len 32256 ops 80 21234 HEADER Cycle 598 tail 598:020619 len 32256 ops 64 21298 HEADER Cycle 598 tail 598:020619 len 32256 ops 64 21362 HEADER Cycle 598 tail 598:020619 len 12728 ops 58 21388 HEADER Cycle 598 tail 598:021394 len 224 ops 5 21390 HEADER Cycle 598 tail 598:021420 len 32256 ops 133 21454 HEADER Cycle 598 tail 598:021420 len 32256 ops 77 21518 HEADER Cycle 598 tail 598:021420 len 32256 ops 131 21582 HEADER Cycle 598 tail 598:021420 len 32256 ops 101 21646 HEADER Cycle 598 tail 598:021420 len 32256 ops 101 21710 HEADER Cycle 598 tail 598:021420 len 32256 ops 87 21774 HEADER Cycle 598 tail 598:021420 len 32256 ops 102 21838 HEADER Cycle 598 tail 598:021420 len 32256 ops 85 21902 HEADER Cycle 598 tail 598:021422 len 32256 ops 110 21966 HEADER Cycle 598 tail 598:021422 len 18988 ops 58 22005 HEADER Cycle 598 tail 598:021998 len 32256 ops 120 22069 HEADER Cycle 598 tail 598:022037 len 4972 ops 19 22080 HEADER Cycle 598 tail 598:022101 len 32256 ops 117 22144 HEADER Cycle 598 tail 598:022112 len 26100 ops 78 22196 HEADER Cycle 598 tail 598:022176 len 32256 ops 84 22260 HEADER Cycle 598 tail 598:022176 len 32256 ops 106 22324 HEADER Cycle 598 tail 598:022176 len 32256 ops 117 22388 HEADER Cycle 598 tail 598:022228 len 13768 ops 31 22416 HEADER Cycle 598 tail 598:022420 len 32256 ops 97 22480 HEADER Cycle 598 tail 598:022420 len 32256 ops 113 22544 HEADER Cycle 598 tail 598:022512 len 5256 ops 36 22556 HEADER Cycle 598 tail 598:022512 len 13112 ops 48 22583 HEADER Cycle 598 tail 598:022588 len 32256 ops 145 22647 HEADER Cycle 598 tail 598:022615 len 20896 ops 79 22689 HEADER Cycle 598 tail 598:022615 len 32256 ops 111 22753 HEADER Cycle 598 tail 598:022615 len 6508 ops 52 22767 HEADER Cycle 598 tail 598:022785 len 32256 ops 109 22831 HEADER Cycle 598 tail 598:022799 len 10684 ops 44 22853 HEADER Cycle 598 tail 598:022863 len 32248 ops 98 22917 HEADER Cycle 598 tail 598:022863 len 32256 ops 99 22981 HEADER Cycle 598 tail 598:022863 len 32256 ops 95 23045 HEADER Cycle 598 tail 598:022949 len 23184 ops 54 23092 HEADER Cycle 598 tail 598:023013 len 12820 ops 45 23119 HEADER Cycle 598 tail 598:023124 len 32256 ops 111 23183 HEADER Cycle 598 tail 598:023151 len 23660 ops 82 23231 HEADER Cycle 598 tail 598:023215 len 32256 ops 157 23295 HEADER Cycle 598 tail 598:023215 len 32256 ops 103 23359 HEADER Cycle 598 tail 598:023215 len 32256 ops 77 23423 HEADER Cycle 598 tail 598:023263 len 20804 ops 62 23465 HEADER Cycle 598 tail 598:023455 len 32256 ops 113 23529 HEADER Cycle 598 tail 598:023455 len 32256 ops 60 23593 HEADER Cycle 598 tail 598:023497 len 27896 ops 61 23649 HEADER Cycle 598 tail 598:023625 len 32256 ops 97 23713 HEADER Cycle 598 tail 598:023625 len 32256 ops 116 23777 HEADER Cycle 598 tail 598:023625 len 32256 ops 99 23841 HEADER Cycle 598 tail 598:023681 len 12828 ops 27 23868 HEADER Cycle 598 tail 598:023873 len 224 ops 5 23870 HEADER Cycle 598 tail 598:023900 len 21208 ops 112 23913 HEADER Cycle 598 tail 598:023902 len 224 ops 5 23915 HEADER Cycle 598 tail 598:023945 len 32256 ops 168 23979 HEADER Cycle 598 tail 598:023947 len 8564 ops 27 23997 HEADER Cycle 598 tail 598:024011 len 224 ops 5 23999 HEADER Cycle 598 tail 598:024029 len 32256 ops 129 24063 HEADER Cycle 598 tail 598:024029 len 32256 ops 116 24127 HEADER Cycle 598 tail 598:024031 len 6024 ops 19 24140 HEADER Cycle 598 tail 598:024159 len 3304 ops 16 24148 HEADER Cycle 598 tail 598:024172 len 224 ops 5 24150 HEADER Cycle 598 tail 598:024180 len 224 ops 5 24152 HEADER Cycle 598 tail 598:024182 len 1896 ops 16 24157 HEADER Cycle 598 tail 598:024184 len 224 ops 5 24159 HEADER Cycle 598 tail 598:024189 len 224 ops 5 24161 HEADER Cycle 598 tail 598:024191 len 32256 ops 140 24225 HEADER Cycle 598 tail 598:024193 len 27864 ops 120 24281 HEADER Cycle 598 tail 598:024257 len 224 ops 5 24283 HEADER Cycle 598 tail 598:024313 len 1896 ops 16 24288 HEADER Cycle 598 tail 598:024315 len 4304 ops 20 24298 HEADER Cycle 598 tail 598:024320 len 22476 ops 93 24343 HEADER Cycle 598 tail 598:024330 len 224 ops 5 24345 HEADER Cycle 598 tail 598:024375 len 224 ops 5 24347 HEADER Cycle 598 tail 598:024377 len 1768 ops 16 24352 HEADER Cycle 598 tail 598:024379 len 224 ops 5 24354 HEADER Cycle 598 tail 598:024384 len 1640 ops 16 24359 HEADER Cycle 598 tail 598:024386 len 224 ops 5 24361 HEADER Cycle 598 tail 598:024391 len 17356 ops 75 24396 HEADER Cycle 598 tail 598:024393 len 224 ops 5 24398 HEADER Cycle 598 tail 598:024428 len 224 ops 5 24400 HEADER Cycle 598 tail 598:024430 len 1512 ops 16 24404 HEADER Cycle 598 tail 598:024432 len 224 ops 5 24406 HEADER Cycle 598 tail 598:024436 len 224 ops 5 24408 HEADER Cycle 598 tail 598:024438 len 5712 ops 20 24421 HEADER Cycle 598 tail 598:024440 len 224 ops 5 24423 HEADER Cycle 598 tail 598:024453 len 224 ops 5 24425 HEADER Cycle 598 tail 598:024455 len 6352 ops 20 24439 HEADER Cycle 598 tail 598:024457 len 224 ops 5 24441 HEADER Cycle 598 tail 598:024471 len 224 ops 5 24443 HEADER Cycle 598 tail 598:024473 len 5072 ops 20 24454 HEADER Cycle 598 tail 598:024475 len 224 ops 5 24456 HEADER Cycle 598 tail 598:024486 len 224 ops 5 24458 HEADER Cycle 598 tail 598:024488 len 4072 ops 16 24467 HEADER Cycle 598 tail 598:024490 len 224 ops 5 24469 HEADER Cycle 598 tail 598:024499 len 224 ops 5 24471 HEADER Cycle 598 tail 598:024501 len 1896 ops 16 24476 HEADER Cycle 598 tail 598:024503 len 224 ops 5 24478 HEADER Cycle 598 tail 598:024508 len 224 ops 5 24480 HEADER Cycle 598 tail 598:024510 len 5584 ops 20 24492 HEADER Cycle 598 tail 598:024512 len 224 ops 5 24494 HEADER Cycle 598 tail 598:024524 len 224 ops 5 24496 HEADER Cycle 598 tail 598:024526 len 2280 ops 16 24502 HEADER Cycle 598 tail 598:024528 len 224 ops 5 24504 HEADER Cycle 598 tail 598:024534 len 224 ops 5 24506 HEADER Cycle 598 tail 598:024536 len 2408 ops 16 24512 HEADER Cycle 598 tail 598:024538 len 224 ops 5 24514 HEADER Cycle 598 tail 598:024544 len 2280 ops 16 24520 HEADER Cycle 598 tail 598:024546 len 224 ops 5 24522 HEADER Cycle 598 tail 598:024552 len 224 ops 5 24524 HEADER Cycle 598 tail 598:024554 len 2280 ops 16 24530 HEADER Cycle 598 tail 598:024556 len 224 ops 5 24532 HEADER Cycle 598 tail 598:024562 len 224 ops 5 24534 HEADER Cycle 598 tail 598:024564 len 2408 ops 16 24540 HEADER Cycle 598 tail 598:024566 len 224 ops 5 24542 HEADER Cycle 598 tail 598:024572 len 224 ops 5 24544 HEADER Cycle 598 tail 598:024574 len 2280 ops 16 24550 HEADER Cycle 598 tail 598:024576 len 224 ops 5 24552 HEADER Cycle 598 tail 598:024582 len 224 ops 5 24554 HEADER Cycle 598 tail 598:024584 len 2280 ops 16 24560 HEADER Cycle 598 tail 598:024586 len 224 ops 5 24562 HEADER Cycle 598 tail 598:024592 len 224 ops 5 24564 HEADER Cycle 598 tail 598:024594 len 2280 ops 16 24570 HEADER Cycle 598 tail 598:024596 len 224 ops 5 24572 HEADER Cycle 598 tail 598:024602 len 224 ops 5 24574 HEADER Cycle 598 tail 598:024604 len 2280 ops 16 24580 HEADER Cycle 598 tail 598:024606 len 224 ops 5 24582 HEADER Cycle 598 tail 598:024612 len 224 ops 5 24584 HEADER Cycle 598 tail 598:024614 len 2408 ops 16 24590 HEADER Cycle 598 tail 598:024616 len 224 ops 5 24592 HEADER Cycle 598 tail 598:024622 len 2408 ops 16 24598 HEADER Cycle 598 tail 598:024624 len 224 ops 5 24600 HEADER Cycle 598 tail 598:024630 len 224 ops 5 24602 HEADER Cycle 598 tail 598:024632 len 2408 ops 16 24608 HEADER Cycle 598 tail 598:024634 len 224 ops 5 24610 HEADER Cycle 598 tail 598:024640 len 2408 ops 16 24616 HEADER Cycle 598 tail 598:024642 len 224 ops 5 24618 HEADER Cycle 598 tail 598:024648 len 224 ops 5 24620 HEADER Cycle 598 tail 598:024650 len 2408 ops 16 24626 HEADER Cycle 598 tail 598:024652 len 224 ops 5 24628 HEADER Cycle 598 tail 598:024658 len 224 ops 5 24630 HEADER Cycle 598 tail 598:024660 len 2408 ops 16 24636 HEADER Cycle 598 tail 598:024662 len 224 ops 5 24638 HEADER Cycle 598 tail 598:024668 len 224 ops 5 24640 HEADER Cycle 598 tail 598:024670 len 2408 ops 16 24646 HEADER Cycle 598 tail 598:024672 len 224 ops 5 24648 HEADER Cycle 598 tail 598:024678 len 2408 ops 16 24654 HEADER Cycle 598 tail 598:024680 len 224 ops 5 24656 HEADER Cycle 598 tail 598:024686 len 224 ops 5 24658 HEADER Cycle 598 tail 598:024688 len 2408 ops 16 24664 HEADER Cycle 598 tail 598:024690 len 224 ops 5 24666 HEADER Cycle 598 tail 598:024696 len 2408 ops 16 24672 HEADER Cycle 598 tail 598:024698 len 224 ops 5 24674 HEADER Cycle 598 tail 598:024704 len 224 ops 5 24676 HEADER Cycle 598 tail 598:024706 len 2536 ops 16 24682 HEADER Cycle 598 tail 598:024708 len 224 ops 5 24684 HEADER Cycle 598 tail 598:024714 len 224 ops 5 24686 HEADER Cycle 598 tail 598:024716 len 5072 ops 32 24697 HEADER Cycle 598 tail 598:024718 len 224 ops 5 24699 HEADER Cycle 598 tail 598:024729 len 224 ops 5 24701 HEADER Cycle 598 tail 598:024731 len 10784 ops 64 24724 HEADER Cycle 598 tail 598:024733 len 224 ops 5 24726 HEADER Cycle 598 tail 598:024756 len 224 ops 5 24728 HEADER Cycle 598 tail 598:024758 len 7608 ops 48 24744 HEADER Cycle 598 tail 598:024760 len 224 ops 5 24746 HEADER Cycle 598 tail 598:024776 len 224 ops 5 24748 HEADER Cycle 598 tail 598:024778 len 10144 ops 64 24769 HEADER Cycle 598 tail 598:024780 len 224 ops 5 24771 HEADER Cycle 598 tail 598:024801 len 224 ops 5 24773 HEADER Cycle 598 tail 598:024803 len 5584 ops 32 24785 HEADER Cycle 598 tail 598:024805 len 224 ops 5 24787 HEADER Cycle 598 tail 598:024817 len 224 ops 5 24789 HEADER Cycle 598 tail 598:024819 len 10656 ops 64 24811 HEADER Cycle 598 tail 598:024821 len 224 ops 5 24813 HEADER Cycle 598 tail 598:024843 len 224 ops 5 24815 HEADER Cycle 598 tail 598:024845 len 17264 ops 96 24850 HEADER Cycle 598 tail 598:024847 len 224 ops 5 24852 HEADER Cycle 598 tail 598:024882 len 224 ops 5 24854 HEADER Cycle 598 tail 598:024884 len 2408 ops 16 24860 HEADER Cycle 598 tail 598:024886 len 224 ops 5 24862 HEADER Cycle 598 tail 598:024892 len 224 ops 5 24864 HEADER Cycle 598 tail 598:024894 len 2920 ops 16 24871 HEADER Cycle 598 tail 598:024896 len 224 ops 5 24873 HEADER Cycle 598 tail 598:024903 len 224 ops 5 24875 HEADER Cycle 598 tail 598:024905 len 2280 ops 16 24881 HEADER Cycle 598 tail 598:024907 len 224 ops 5 24883 HEADER Cycle 598 tail 598:024913 len 224 ops 5 24885 HEADER Cycle 598 tail 598:024915 len 2920 ops 16 24892 HEADER Cycle 598 tail 598:024917 len 224 ops 5 24894 HEADER Cycle 598 tail 598:024924 len 224 ops 5 24896 HEADER Cycle 598 tail 598:024926 len 2536 ops 16 24902 HEADER Cycle 598 tail 598:024928 len 224 ops 5 24904 HEADER Cycle 598 tail 598:024934 len 224 ops 5 24906 HEADER Cycle 598 tail 598:024936 len 2792 ops 16 24913 HEADER Cycle 598 tail 598:024938 len 224 ops 5 24915 HEADER Cycle 598 tail 598:024945 len 224 ops 5 24917 HEADER Cycle 598 tail 598:024947 len 2536 ops 16 24923 HEADER Cycle 598 tail 598:024949 len 224 ops 5 24925 HEADER Cycle 598 tail 598:024955 len 224 ops 5 24927 HEADER Cycle 598 tail 598:024957 len 2408 ops 16 24933 HEADER Cycle 598 tail 598:024959 len 224 ops 5 24935 HEADER Cycle 598 tail 598:024965 len 224 ops 5 24937 HEADER Cycle 598 tail 598:024967 len 3048 ops 16 24944 HEADER Cycle 598 tail 598:024969 len 224 ops 5 24946 HEADER Cycle 598 tail 598:024976 len 224 ops 5 24948 HEADER Cycle 598 tail 598:024978 len 2664 ops 16 24955 HEADER Cycle 598 tail 598:024980 len 224 ops 5 24957 HEADER Cycle 598 tail 598:024987 len 224 ops 5 24959 HEADER Cycle 598 tail 598:024989 len 2280 ops 16 24965 HEADER Cycle 598 tail 598:024991 len 224 ops 5 24967 HEADER Cycle 598 tail 598:024997 len 224 ops 5 24969 HEADER Cycle 598 tail 598:024999 len 2792 ops 16 24976 HEADER Cycle 598 tail 598:025001 len 224 ops 5 24978 HEADER Cycle 598 tail 598:025008 len 224 ops 5 24980 HEADER Cycle 598 tail 598:025010 len 2408 ops 16 24986 HEADER Cycle 598 tail 598:025012 len 224 ops 5 24988 HEADER Cycle 598 tail 598:025018 len 224 ops 5 24990 HEADER Cycle 598 tail 598:025020 len 3176 ops 16 24998 HEADER Cycle 598 tail 598:025022 len 224 ops 5 25000 HEADER Cycle 598 tail 598:025030 len 224 ops 5 25002 HEADER Cycle 598 tail 598:025032 len 2920 ops 16 25009 HEADER Cycle 598 tail 598:025034 len 224 ops 5 25011 HEADER Cycle 598 tail 598:025041 len 224 ops 5 25013 HEADER Cycle 598 tail 598:025043 len 3048 ops 16 25020 HEADER Cycle 598 tail 598:025045 len 224 ops 5 25022 HEADER Cycle 598 tail 598:025052 len 224 ops 5 25024 HEADER Cycle 598 tail 598:025054 len 5840 ops 32 25037 HEADER Cycle 598 tail 598:025056 len 224 ops 5 25039 HEADER Cycle 598 tail 598:025069 len 224 ops 5 25041 HEADER Cycle 598 tail 598:025071 len 8132 ops 19 25058 HEADER Cycle 598 tail 598:025073 len 224 ops 5 25060 HEADER Cycle 598 tail 598:025090 len 224 ops 5 25062 HEADER Cycle 598 tail 598:025092 len 996 ops 14 25065 HEADER Cycle 598 tail 598:025094 len 224 ops 5 25067 HEADER Cycle 598 tail 598:025097 len 224 ops 5 25069 HEADER Cycle 598 tail 598:025099 len 996 ops 14 25072 HEADER Cycle 598 tail 598:025101 len 224 ops 5 25074 HEADER Cycle 598 tail 598:025104 len 224 ops 5 25076 HEADER Cycle 598 tail 598:025106 len 996 ops 14 25079 HEADER Cycle 598 tail 598:025108 len 224 ops 5 25081 HEADER Cycle 598 tail 598:025111 len 224 ops 5 25083 HEADER Cycle 598 tail 598:025113 len 996 ops 14 25086 HEADER Cycle 598 tail 598:025115 len 224 ops 5 25088 HEADER Cycle 598 tail 598:025118 len 224 ops 5 25090 HEADER Cycle 598 tail 598:025120 len 996 ops 14 25093 HEADER Cycle 598 tail 598:025122 len 224 ops 5 25095 HEADER Cycle 598 tail 598:025125 len 224 ops 5 25097 HEADER Cycle 598 tail 598:025127 len 996 ops 14 25100 HEADER Cycle 598 tail 598:025129 len 224 ops 5 25102 HEADER Cycle 598 tail 598:025132 len 224 ops 5 25104 HEADER Cycle 598 tail 598:025134 len 996 ops 14 25107 HEADER Cycle 598 tail 598:025136 len 224 ops 5 25109 HEADER Cycle 598 tail 598:025139 len 224 ops 5 25111 HEADER Cycle 598 tail 598:025141 len 996 ops 14 25114 HEADER Cycle 598 tail 598:025143 len 224 ops 5 25116 HEADER Cycle 598 tail 598:025146 len 224 ops 5 25118 HEADER Cycle 598 tail 598:025148 len 996 ops 14 25121 HEADER Cycle 598 tail 598:025150 len 224 ops 5 25123 HEADER Cycle 598 tail 598:025153 len 224 ops 5 25125 HEADER Cycle 598 tail 598:025155 len 996 ops 14 25128 HEADER Cycle 598 tail 598:025157 len 224 ops 5 25130 HEADER Cycle 598 tail 598:025160 len 224 ops 5 25132 HEADER Cycle 598 tail 598:025162 len 996 ops 14 25135 HEADER Cycle 598 tail 598:025164 len 224 ops 5 25137 HEADER Cycle 598 tail 598:025167 len 224 ops 5 25139 HEADER Cycle 598 tail 598:025169 len 996 ops 14 25142 HEADER Cycle 598 tail 598:025171 len 224 ops 5 25144 HEADER Cycle 598 tail 598:025174 len 224 ops 5 25146 HEADER Cycle 598 tail 598:025176 len 996 ops 14 25149 HEADER Cycle 598 tail 598:025178 len 224 ops 5 25151 HEADER Cycle 598 tail 598:025181 len 224 ops 5 25153 HEADER Cycle 598 tail 598:025183 len 996 ops 14 25156 HEADER Cycle 598 tail 598:025185 len 224 ops 5 25158 HEADER Cycle 598 tail 598:025188 len 224 ops 5 25160 HEADER Cycle 598 tail 598:025190 len 996 ops 14 25163 HEADER Cycle 598 tail 598:025192 len 224 ops 5 25165 HEADER Cycle 598 tail 598:025195 len 224 ops 5 25167 HEADER Cycle 598 tail 598:025197 len 996 ops 14 25170 HEADER Cycle 598 tail 598:025199 len 224 ops 5 25172 HEADER Cycle 598 tail 598:025202 len 224 ops 5 25174 HEADER Cycle 598 tail 598:025204 len 996 ops 14 25177 HEADER Cycle 598 tail 598:025206 len 224 ops 5 25179 HEADER Cycle 598 tail 598:025209 len 224 ops 5 25181 HEADER Cycle 598 tail 598:025211 len 996 ops 14 25184 HEADER Cycle 598 tail 598:025213 len 224 ops 5 25186 HEADER Cycle 598 tail 598:025216 len 224 ops 5 25188 HEADER Cycle 598 tail 598:025218 len 996 ops 14 25191 HEADER Cycle 598 tail 598:025220 len 224 ops 5 25193 HEADER Cycle 598 tail 598:025223 len 224 ops 5 25195 HEADER Cycle 598 tail 598:025225 len 996 ops 14 25198 HEADER Cycle 598 tail 598:025227 len 224 ops 5 25200 HEADER Cycle 598 tail 598:025230 len 224 ops 5 25202 HEADER Cycle 598 tail 598:025232 len 996 ops 14 25205 HEADER Cycle 598 tail 598:025234 len 224 ops 5 25207 HEADER Cycle 598 tail 598:025237 len 224 ops 5 25209 HEADER Cycle 598 tail 598:025239 len 996 ops 14 25212 HEADER Cycle 598 tail 598:025241 len 224 ops 5 25214 HEADER Cycle 598 tail 598:025244 len 224 ops 5 25216 HEADER Cycle 598 tail 598:025246 len 996 ops 14 25219 HEADER Cycle 598 tail 598:025248 len 224 ops 5 25221 HEADER Cycle 598 tail 598:025251 len 224 ops 5 25223 HEADER Cycle 598 tail 598:025253 len 996 ops 14 25226 HEADER Cycle 598 tail 598:025255 len 224 ops 5 25228 HEADER Cycle 598 tail 598:025258 len 224 ops 5 25230 HEADER Cycle 598 tail 598:025260 len 996 ops 14 25233 HEADER Cycle 598 tail 598:025262 len 224 ops 5 25235 HEADER Cycle 598 tail 598:025265 len 224 ops 5 25237 HEADER Cycle 598 tail 598:025267 len 996 ops 14 25240 HEADER Cycle 598 tail 598:025269 len 224 ops 5 25242 HEADER Cycle 598 tail 598:025272 len 224 ops 5 25244 HEADER Cycle 598 tail 598:025274 len 996 ops 14 25247 HEADER Cycle 598 tail 598:025276 len 224 ops 5 25249 HEADER Cycle 598 tail 598:025279 len 224 ops 5 25251 HEADER Cycle 598 tail 598:025281 len 996 ops 14 25254 HEADER Cycle 598 tail 598:025283 len 224 ops 5 25256 HEADER Cycle 598 tail 598:025286 len 224 ops 5 25258 HEADER Cycle 598 tail 598:025288 len 996 ops 14 25261 HEADER Cycle 598 tail 598:025290 len 224 ops 5 25263 HEADER Cycle 598 tail 598:025293 len 224 ops 5 25265 HEADER Cycle 598 tail 598:025295 len 996 ops 14 25268 HEADER Cycle 598 tail 598:025297 len 224 ops 5 25270 HEADER Cycle 598 tail 598:025300 len 224 ops 5 25272 HEADER Cycle 598 tail 598:025302 len 996 ops 14 25275 HEADER Cycle 598 tail 598:025304 len 224 ops 5 25277 HEADER Cycle 598 tail 598:025307 len 224 ops 5 25279 HEADER Cycle 598 tail 598:025309 len 996 ops 14 25282 HEADER Cycle 598 tail 598:025311 len 224 ops 5 25284 HEADER Cycle 598 tail 598:025314 len 224 ops 5 25286 HEADER Cycle 598 tail 598:025316 len 996 ops 14 25289 HEADER Cycle 598 tail 598:025318 len 224 ops 5 25291 HEADER Cycle 598 tail 598:025321 len 224 ops 5 25293 HEADER Cycle 598 tail 598:025323 len 996 ops 14 25296 HEADER Cycle 598 tail 598:025325 len 224 ops 5 25298 HEADER Cycle 598 tail 598:025328 len 224 ops 5 25300 HEADER Cycle 598 tail 598:025330 len 996 ops 14 25303 HEADER Cycle 598 tail 598:025332 len 224 ops 5 25305 HEADER Cycle 598 tail 598:025335 len 224 ops 5 25307 HEADER Cycle 598 tail 598:025337 len 996 ops 14 25310 HEADER Cycle 598 tail 598:025339 len 224 ops 5 25312 HEADER Cycle 598 tail 598:025342 len 224 ops 5 25314 HEADER Cycle 598 tail 598:025344 len 996 ops 14 25317 HEADER Cycle 598 tail 598:025346 len 224 ops 5 25319 HEADER Cycle 598 tail 598:025349 len 224 ops 5 25321 HEADER Cycle 598 tail 598:025351 len 996 ops 14 25324 HEADER Cycle 598 tail 598:025353 len 224 ops 5 25326 HEADER Cycle 598 tail 598:025356 len 224 ops 5 25328 HEADER Cycle 598 tail 598:025358 len 996 ops 14 25331 HEADER Cycle 598 tail 598:025360 len 224 ops 5 25333 HEADER Cycle 598 tail 598:025363 len 224 ops 5 25335 HEADER Cycle 598 tail 598:025365 len 996 ops 14 25338 HEADER Cycle 598 tail 598:025367 len 224 ops 5 25340 HEADER Cycle 598 tail 598:025370 len 224 ops 5 25342 HEADER Cycle 598 tail 598:025372 len 996 ops 14 25345 HEADER Cycle 598 tail 598:025374 len 224 ops 5 25347 HEADER Cycle 598 tail 598:025377 len 224 ops 5 25349 HEADER Cycle 598 tail 598:025379 len 996 ops 14 25352 HEADER Cycle 598 tail 598:025381 len 224 ops 5 25354 HEADER Cycle 598 tail 598:025384 len 224 ops 5 25356 HEADER Cycle 598 tail 598:025386 len 996 ops 14 25359 HEADER Cycle 598 tail 598:025388 len 224 ops 5 25361 HEADER Cycle 598 tail 598:025391 len 224 ops 5 25363 HEADER Cycle 598 tail 598:025393 len 996 ops 14 25366 HEADER Cycle 598 tail 598:025395 len 224 ops 5 25368 HEADER Cycle 598 tail 598:025398 len 224 ops 5 25370 HEADER Cycle 598 tail 598:025400 len 996 ops 14 25373 HEADER Cycle 598 tail 598:025402 len 224 ops 5 25375 HEADER Cycle 598 tail 598:025405 len 224 ops 5 25377 HEADER Cycle 598 tail 598:025407 len 996 ops 14 25380 HEADER Cycle 598 tail 598:025409 len 224 ops 5 25382 HEADER Cycle 598 tail 598:025412 len 224 ops 5 25384 HEADER Cycle 598 tail 598:025414 len 996 ops 14 25387 HEADER Cycle 598 tail 598:025416 len 224 ops 5 25389 HEADER Cycle 598 tail 598:025419 len 224 ops 5 25391 HEADER Cycle 598 tail 598:025421 len 996 ops 14 25394 HEADER Cycle 598 tail 598:025423 len 224 ops 5 25396 HEADER Cycle 598 tail 598:025426 len 224 ops 5 25398 HEADER Cycle 598 tail 598:025428 len 996 ops 14 25401 HEADER Cycle 598 tail 598:025430 len 224 ops 5 25403 HEADER Cycle 598 tail 598:025433 len 224 ops 5 [00000 - 25405] Cycle 0x00000256 New Cycle 0x00000255 25420 HEADER Cycle 597 tail 597:025329 len 32256 ops 133 25484 HEADER Cycle 597 tail 597:025329 len 32256 ops 112 25548 HEADER Cycle 597 tail 597:025329 len 32256 ops 101 25612 HEADER Cycle 597 tail 597:025329 len 32256 ops 97 25676 HEADER Cycle 597 tail 597:025329 len 32256 ops 78 25740 HEADER Cycle 597 tail 597:025329 len 32256 ops 122 25804 HEADER Cycle 597 tail 597:025329 len 32256 ops 123 25868 HEADER Cycle 597 tail 597:025388 len 32256 ops 64 25932 HEADER Cycle 597 tail 597:025388 len 32256 ops 74 25996 HEADER Cycle 597 tail 597:025388 len 32256 ops 157 26060 HEADER Cycle 597 tail 597:025388 len 32252 ops 138 26124 HEADER Cycle 597 tail 597:025388 len 32256 ops 103 26188 HEADER Cycle 597 tail 597:025388 len 32236 ops 195 26252 HEADER Cycle 597 tail 597:025388 len 32256 ops 122 26316 HEADER Cycle 597 tail 597:025388 len 32256 ops 83 26380 HEADER Cycle 597 tail 597:025388 len 32256 ops 121 26444 HEADER Cycle 597 tail 597:025388 len 17784 ops 52 26480 HEADER Cycle 597 tail 597:025388 len 32256 ops 186 26544 HEADER Cycle 597 tail 597:025388 len 32256 ops 143 26608 HEADER Cycle 597 tail 597:025388 len 32256 ops 107 26672 HEADER Cycle 597 tail 597:025388 len 32256 ops 101 26736 HEADER Cycle 597 tail 597:025388 len 32256 ops 110 26800 HEADER Cycle 597 tail 597:025388 len 32256 ops 107 26864 HEADER Cycle 597 tail 597:025388 len 32256 ops 110 26928 HEADER Cycle 597 tail 597:025388 len 32256 ops 115 26992 HEADER Cycle 597 tail 597:025388 len 32256 ops 138 27056 HEADER Cycle 597 tail 597:025388 len 32256 ops 92 27120 HEADER Cycle 597 tail 597:025388 len 300 ops 4 27122 HEADER Cycle 597 tail 597:027088 len 32256 ops 160 27186 HEADER Cycle 597 tail 597:027088 len 32256 ops 166 27250 HEADER Cycle 597 tail 597:027088 len 32256 ops 158 27314 HEADER Cycle 597 tail 597:027088 len 32256 ops 98 27378 HEADER Cycle 597 tail 597:027154 len 32256 ops 123 27442 HEADER Cycle 597 tail 597:027154 len 32256 ops 171 27506 HEADER Cycle 597 tail 597:027154 len 32256 ops 106 27570 HEADER Cycle 597 tail 597:027154 len 32256 ops 105 27634 HEADER Cycle 597 tail 597:027154 len 11628 ops 27 27658 HEADER Cycle 597 tail 597:027666 len 32256 ops 112 27722 HEADER Cycle 597 tail 597:027666 len 32256 ops 145 27786 HEADER Cycle 597 tail 597:027666 len 32256 ops 93 27850 HEADER Cycle 597 tail 597:027666 len 32256 ops 81 27914 HEADER Cycle 597 tail 597:027666 len 32256 ops 88 27978 HEADER Cycle 597 tail 597:027666 len 32256 ops 96 28042 HEADER Cycle 597 tail 597:027666 len 32256 ops 128 28106 HEADER Cycle 597 tail 597:027666 len 32256 ops 106 28170 HEADER Cycle 597 tail 597:027690 len 32256 ops 81 28234 HEADER Cycle 597 tail 597:027690 len 32256 ops 95 28298 HEADER Cycle 597 tail 597:027690 len 32248 ops 108 28362 HEADER Cycle 597 tail 597:027690 len 32256 ops 158 28426 HEADER Cycle 597 tail 597:027690 len 32256 ops 128 28490 HEADER Cycle 597 tail 597:027690 len 32244 ops 151 28554 HEADER Cycle 597 tail 597:027690 len 32256 ops 142 28618 HEADER Cycle 597 tail 597:027690 len 32256 ops 131 28682 HEADER Cycle 597 tail 597:027690 len 32256 ops 87 28746 HEADER Cycle 597 tail 597:027690 len 32256 ops 77 28810 HEADER Cycle 597 tail 597:027690 len 32256 ops 83 28874 HEADER Cycle 597 tail 597:027690 len 32256 ops 96 28938 HEADER Cycle 597 tail 597:027690 len 32256 ops 61 29002 HEADER Cycle 597 tail 597:027690 len 32256 ops 81 29066 HEADER Cycle 597 tail 597:027690 len 32256 ops 82 29130 HEADER Cycle 597 tail 597:027690 len 32256 ops 67 29194 HEADER Cycle 597 tail 597:027690 len 30676 ops 99 29255 HEADER Cycle 597 tail 597:029226 len 32256 ops 118 29319 HEADER Cycle 597 tail 597:029226 len 32256 ops 127 29383 HEADER Cycle 597 tail 597:029226 len 32256 ops 151 29447 HEADER Cycle 597 tail 597:029287 len 32244 ops 115 29511 HEADER Cycle 597 tail 597:029287 len 32256 ops 86 29575 HEADER Cycle 597 tail 597:029287 len 32256 ops 98 29639 HEADER Cycle 597 tail 597:029287 len 32256 ops 110 29703 HEADER Cycle 597 tail 597:029287 len 32256 ops 159 29767 HEADER Cycle 597 tail 597:029287 len 32256 ops 138 29831 HEADER Cycle 597 tail 597:029287 len 32256 ops 149 29895 HEADER Cycle 597 tail 597:029287 len 32256 ops 99 29959 HEADER Cycle 597 tail 597:029287 len 32256 ops 98 30023 HEADER Cycle 597 tail 597:029287 len 32256 ops 85 30087 HEADER Cycle 597 tail 597:029287 len 32256 ops 73 30151 HEADER Cycle 597 tail 597:029287 len 32256 ops 83 30215 HEADER Cycle 597 tail 597:029287 len 32256 ops 129 30279 HEADER Cycle 597 tail 597:029287 len 32256 ops 98 30343 HEADER Cycle 597 tail 597:029287 len 32256 ops 209 30407 HEADER Cycle 597 tail 597:029287 len 17304 ops 100 30442 HEADER Cycle 597 tail 597:029287 len 32256 ops 129 30506 HEADER Cycle 597 tail 597:029287 len 32256 ops 139 30570 HEADER Cycle 597 tail 597:029287 len 14436 ops 53 30600 HEADER Cycle 597 tail 597:030474 len 32256 ops 110 30664 HEADER Cycle 597 tail 597:030474 len 32256 ops 113 30728 HEADER Cycle 597 tail 597:030474 len 32256 ops 135 30792 HEADER Cycle 597 tail 597:030474 len 32256 ops 129 30856 HEADER Cycle 597 tail 597:030474 len 32256 ops 123 30920 HEADER Cycle 597 tail 597:030474 len 32256 ops 83 30984 HEADER Cycle 597 tail 597:030474 len 32256 ops 105 31048 HEADER Cycle 597 tail 597:030474 len 32256 ops 90 31112 HEADER Cycle 597 tail 597:030474 len 32256 ops 87 31176 HEADER Cycle 597 tail 597:030696 len 22356 ops 48 31221 HEADER Cycle 597 tail 597:031208 len 32256 ops 99 31285 HEADER Cycle 597 tail 597:031208 len 32256 ops 97 31349 HEADER Cycle 597 tail 597:031208 len 32256 ops 105 31413 HEADER Cycle 597 tail 597:031208 len 32256 ops 116 31477 HEADER Cycle 597 tail 597:031208 len 32256 ops 118 31541 HEADER Cycle 597 tail 597:031208 len 32256 ops 111 31605 HEADER Cycle 597 tail 597:031253 len 32256 ops 144 31669 HEADER Cycle 597 tail 597:031253 len 32256 ops 115 31733 HEADER Cycle 597 tail 597:031253 len 32256 ops 121 31797 HEADER Cycle 597 tail 597:031253 len 32256 ops 105 31861 HEADER Cycle 597 tail 597:031253 len 32256 ops 85 31925 HEADER Cycle 597 tail 597:031253 len 32256 ops 106 31989 HEADER Cycle 597 tail 597:031253 len 32256 ops 151 32053 HEADER Cycle 597 tail 597:031253 len 32256 ops 106 32117 HEADER Cycle 597 tail 597:031253 len 32256 ops 124 32181 HEADER Cycle 597 tail 597:031253 len 32256 ops 91 32245 HEADER Cycle 597 tail 597:031253 len 32256 ops 120 32309 HEADER Cycle 597 tail 597:031253 len 32256 ops 179 32373 HEADER Cycle 597 tail 597:031253 len 32256 ops 103 32437 HEADER Cycle 597 tail 597:031253 len 32256 ops 63 32501 HEADER Cycle 597 tail 597:031253 len 32256 ops 63 32565 HEADER Cycle 597 tail 597:031253 len 32256 ops 77 32629 HEADER Cycle 597 tail 597:031253 len 32256 ops 73 32693 HEADER Cycle 597 tail 597:031253 len 32256 ops 100 32757 HEADER Cycle 597 tail 597:031253 len 32256 ops 70 32821 HEADER Cycle 597 tail 597:031253 len 32256 ops 81 32885 HEADER Cycle 597 tail 597:031253 len 32256 ops 87 32949 HEADER Cycle 597 tail 597:031253 len 32256 ops 104 33013 HEADER Cycle 597 tail 597:031253 len 1384 ops 4 33017 HEADER Cycle 597 tail 597:032981 len 32256 ops 89 33081 HEADER Cycle 597 tail 597:032981 len 32256 ops 120 33145 HEADER Cycle 597 tail 597:032981 len 32256 ops 103 33209 HEADER Cycle 597 tail 597:032981 len 32256 ops 125 33273 HEADER Cycle 597 tail 597:033049 len 32256 ops 131 33337 HEADER Cycle 597 tail 597:033049 len 32256 ops 136 33401 HEADER Cycle 597 tail 597:033049 len 32256 ops 138 33465 HEADER Cycle 597 tail 597:033049 len 32256 ops 150 33529 HEADER Cycle 597 tail 597:033049 len 32256 ops 98 33593 HEADER Cycle 597 tail 597:033049 len 23320 ops 94 33640 HEADER Cycle 597 tail 597:033625 len 32256 ops 100 33704 HEADER Cycle 597 tail 597:033625 len 32256 ops 98 33768 HEADER Cycle 597 tail 597:033625 len 32256 ops 131 33832 HEADER Cycle 597 tail 597:033625 len 32256 ops 137 33896 HEADER Cycle 597 tail 597:033625 len 32256 ops 145 33960 HEADER Cycle 597 tail 597:033625 len 32256 ops 114 34024 HEADER Cycle 597 tail 597:033625 len 32256 ops 132 34088 HEADER Cycle 597 tail 597:033625 len 32256 ops 119 34152 HEADER Cycle 597 tail 597:033672 len 21060 ops 119 34195 HEADER Cycle 597 tail 597:034184 len 32256 ops 125 34259 HEADER Cycle 597 tail 597:034184 len 32256 ops 127 34323 HEADER Cycle 597 tail 597:034184 len 32256 ops 68 34387 HEADER Cycle 597 tail 597:034184 len 32256 ops 79 34451 HEADER Cycle 597 tail 597:034184 len 32256 ops 101 34515 HEADER Cycle 597 tail 597:034184 len 32256 ops 100 34579 HEADER Cycle 597 tail 597:034184 len 32256 ops 115 34643 HEADER Cycle 597 tail 597:034184 len 32256 ops 148 34707 HEADER Cycle 597 tail 597:034227 len 32256 ops 147 34771 HEADER Cycle 597 tail 597:034227 len 32256 ops 139 34835 HEADER Cycle 597 tail 597:034227 len 32256 ops 125 34899 HEADER Cycle 597 tail 597:034227 len 32256 ops 138 34963 HEADER Cycle 597 tail 597:034227 len 32256 ops 82 35027 HEADER Cycle 597 tail 597:034227 len 32256 ops 68 35091 HEADER Cycle 597 tail 597:034227 len 32256 ops 73 35155 HEADER Cycle 597 tail 597:034227 len 32256 ops 96 35219 HEADER Cycle 597 tail 597:034227 len 1848 ops 4 35224 HEADER Cycle 597 tail 597:035251 len 32256 ops 114 35288 HEADER Cycle 597 tail 597:035251 len 32256 ops 122 35352 HEADER Cycle 597 tail 597:035251 len 32256 ops 86 35416 HEADER Cycle 597 tail 597:035251 len 32256 ops 85 35480 HEADER Cycle 597 tail 597:035251 len 32256 ops 71 35544 HEADER Cycle 597 tail 597:035251 len 32256 ops 84 35608 HEADER Cycle 597 tail 597:035251 len 32256 ops 152 35672 HEADER Cycle 597 tail 597:035256 len 24944 ops 91 35722 HEADER Cycle 597 tail 597:035704 len 32256 ops 195 35786 HEADER Cycle 597 tail 597:035704 len 32256 ops 91 35850 HEADER Cycle 597 tail 597:035704 len 32256 ops 79 35914 HEADER Cycle 597 tail 597:035704 len 32256 ops 112 35978 HEADER Cycle 597 tail 597:035704 len 32256 ops 133 36042 HEADER Cycle 597 tail 597:035754 len 32256 ops 83 36106 HEADER Cycle 597 tail 597:035754 len 32256 ops 68 36170 HEADER Cycle 597 tail 597:035754 len 32256 ops 85 36234 HEADER Cycle 597 tail 597:035754 len 32256 ops 120 36298 HEADER Cycle 597 tail 597:035754 len 32256 ops 81 36362 HEADER Cycle 597 tail 597:035754 len 32244 ops 106 36426 HEADER Cycle 597 tail 597:035754 len 32256 ops 89 36490 HEADER Cycle 597 tail 597:035754 len 32256 ops 77 36554 HEADER Cycle 597 tail 597:035754 len 32256 ops 95 36618 HEADER Cycle 597 tail 597:035754 len 32256 ops 107 36682 HEADER Cycle 597 tail 597:035754 len 32256 ops 107 36746 HEADER Cycle 597 tail 597:035754 len 32248 ops 100 36810 HEADER Cycle 597 tail 597:035754 len 17772 ops 66 36846 HEADER Cycle 597 tail 597:036842 len 224 ops 5 36848 HEADER Cycle 597 tail 597:036878 len 224 ops 5 36850 HEADER Cycle 597 tail 597:036880 len 32256 ops 73 36914 HEADER Cycle 597 tail 597:036880 len 32256 ops 134 36978 HEADER Cycle 597 tail 597:036880 len 32256 ops 131 37042 HEADER Cycle 597 tail 597:036880 len 32256 ops 91 37106 HEADER Cycle 597 tail 597:036880 len 32256 ops 139 37170 HEADER Cycle 597 tail 597:036880 len 32256 ops 124 37234 HEADER Cycle 597 tail 597:036880 len 32256 ops 174 37298 HEADER Cycle 597 tail 597:036880 len 32256 ops 92 37362 HEADER Cycle 597 tail 597:036882 len 32256 ops 117 37426 HEADER Cycle 597 tail 597:036946 len 32256 ops 104 37490 HEADER Cycle 597 tail 597:036946 len 32244 ops 84 37554 HEADER Cycle 597 tail 597:036946 len 32256 ops 71 37618 HEADER Cycle 597 tail 597:036946 len 32256 ops 173 37682 HEADER Cycle 597 tail 597:036946 len 32244 ops 87 37746 HEADER Cycle 597 tail 597:036946 len 32256 ops 83 37810 HEADER Cycle 597 tail 597:036946 len 32256 ops 93 37874 HEADER Cycle 597 tail 597:036946 len 32256 ops 134 37938 HEADER Cycle 597 tail 597:036946 len 32252 ops 110 38002 HEADER Cycle 597 tail 597:036946 len 32248 ops 155 38066 HEADER Cycle 597 tail 597:036946 len 32252 ops 123 38130 HEADER Cycle 597 tail 597:036946 len 32256 ops 78 38194 HEADER Cycle 597 tail 597:036946 len 32256 ops 60 38258 HEADER Cycle 597 tail 597:036946 len 32256 ops 78 38322 HEADER Cycle 597 tail 597:036946 len 32256 ops 75 38386 HEADER Cycle 597 tail 597:036946 len 32256 ops 60 38450 HEADER Cycle 597 tail 597:036946 len 32256 ops 122 38514 HEADER Cycle 597 tail 597:036946 len 32256 ops 123 38578 HEADER Cycle 597 tail 597:036946 len 32256 ops 112 38642 HEADER Cycle 597 tail 597:036946 len 32256 ops 133 38706 HEADER Cycle 597 tail 597:036946 len 32256 ops 156 38770 HEADER Cycle 597 tail 597:036946 len 32256 ops 101 38834 HEADER Cycle 597 tail 597:036946 len 32256 ops 145 [25405 - 38888] Cycle 0x00000255 New Cycle 0x00000000 root@quartz:~ # -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -- Jon Detert IT Systems Administrator, Milwaukee School of Engineering 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A. -- “We still do not know one thousandth of one percent of what nature has revealed to us.” ~ Albert Einstein From owner-xfs@oss.sgi.com Wed Dec 19 17:18:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 17:18:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBK1IbD2010787 for ; Wed, 19 Dec 2007 17:18:41 -0800 X-ASG-Debug-ID: 1198113529-430f00490000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from email.msoe.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 99BE54A2146 for ; Wed, 19 Dec 2007 17:18:50 -0800 (PST) Received: from email.msoe.edu (email.msoe.edu [155.92.194.61]) by cuda.sgi.com with ESMTP id WzFE2NjOIvLQCRDR for ; Wed, 19 Dec 2007 17:18:50 -0800 (PST) Received: from localhost ([155.92.193.21]) by email.msoe.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Dec 2007 19:18:48 -0600 Date: Wed, 19 Dec 2007 19:18:48 -0600 From: "Jonathan C. Detert" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount prob: "log inconsistent or not a log" Subject: Re: mount prob: "log inconsistent or not a log" Message-ID: <20071220011848.GV19770@msoe.edu> References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4769BD13.5040303@sgi.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 20 Dec 2007 01:18:48.0564 (UTC) FILETIME=[45F35B40:01C842A6] X-Barracuda-Connect: email.msoe.edu[155.92.194.61] X-Barracuda-Start-Time: 1198113530 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37115 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5185/Wed Dec 19 16:56:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14029 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jonathan.Detert@msoe.edu Precedence: bulk X-list: xfs * Timothy Shimmin [071219 18:53]: > Hi Jonathan, > > I'm not giving a high level view but > in regards to the log message about the xfs log :) > > Jonathan.Detert@msoe.edu wrote: > >This is what /var/log/messages has to say about the mount attempt: > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS mounting filesystem sdb > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: Log inconsistent or not > >a log (last==0, first!=1) --snip -- > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > Every 512 bytes of the log is stamped with the cycle#. > The cycle# is effectively the number of times the log has wrapped -- snip -- > An "xfs_logprint -d /dev/sdb" will show what the cycle#s are > and where the log records are. It might give an idea of the > extent of the corruption. Something occurred to me to point out: the snapshot from yesterday has the same problem. How can that be? Is is possible that the log has been hosed for some time, and that the problem only reared its head now because I had to remount? I.e. is it possible for an xfs fs to be mounted and used, even while the log is messed up? -- Jon Detert IT Systems Administrator, Milwaukee School of Engineering 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A. -- "Most of the trouble in the world is caused by people wanting to be important." ~ T.S. Eliot From owner-xfs@oss.sgi.com Wed Dec 19 17:54:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 17:54:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBK1sLWP012864 for ; Wed, 19 Dec 2007 17:54:25 -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 MAA18794; Thu, 20 Dec 2007 12:54:29 +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 lBK1sRIN14208761; Thu, 20 Dec 2007 12:54:28 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBK1sPmO14326047; Thu, 20 Dec 2007 12:54:25 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 20 Dec 2007 12:54:25 +1100 From: David Chinner To: "Jonathan C. Detert" Cc: xfs@oss.sgi.com Subject: Re: mount prob: "log inconsistent or not a log" Message-ID: <20071220015425.GL4612@sgi.com> References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011848.GV19770@msoe.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071220011848.GV19770@msoe.edu> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5185/Wed Dec 19 16:56:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14030 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 19, 2007 at 07:18:48PM -0600, Jonathan C. Detert wrote: > * Timothy Shimmin [071219 18:53]: > > Hi Jonathan, > > > > I'm not giving a high level view but > > in regards to the log message about the xfs log :) > > > > Jonathan.Detert@msoe.edu wrote: > > >This is what /var/log/messages has to say about the mount attempt: > > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS mounting filesystem sdb > > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: Log inconsistent or not > > >a log (last==0, first!=1) > > --snip -- > > > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > > Every 512 bytes of the log is stamped with the cycle#. > > The cycle# is effectively the number of times the log has wrapped > > -- snip -- > > > An "xfs_logprint -d /dev/sdb" will show what the cycle#s are > > and where the log records are. It might give an idea of the > > extent of the corruption. > > Something occurred to me to point out: the snapshot from yesterday has > the same problem. How can that be? Is is possible that the log has > been hosed for some time, and that the problem only reared its head now > because I had to remount? I.e. is it possible for an xfs fs to be > mounted and used, even while the log is messed up? No, it should not. BTW, does "lost it's iSCSI connection" == "iSCSI server crashed"? If so, is it possible that the iSCSI server is corrupted in some way? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 19 17:56:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 17:56:42 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBK1uYQD013224 for ; Wed, 19 Dec 2007 17:56:36 -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 MAA18958; Thu, 20 Dec 2007 12:56:43 +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 lBK1ugIN14318918; Thu, 20 Dec 2007 12:56:43 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBK1uf4914330843; Thu, 20 Dec 2007 12:56:41 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 20 Dec 2007 12:56:41 +1100 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: [review please] Re: Important regression with XFS update for 2.6.24-rc6 Message-ID: <20071220015641.GM4612@sgi.com> References: <20071218112804.GA3069@localhost.localdomain> <20071218122445.GJ4396912@sgi.com> <877ijckrco.fsf@free.fr> <20071218151946.GQ4396912@sgi.com> <20071219104544.GC4612@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071219104544.GC4612@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5185/Wed Dec 19 16:56:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14031 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs This has run through several iterations of xfsqa now, and it fixes the reported problem, so can I get a review? Cheers, Dave. On Wed, Dec 19, 2007 at 09:45:44PM +1100, David Chinner wrote: > On Wed, Dec 19, 2007 at 02:19:47AM +1100, David Chinner wrote: > > On Tue, Dec 18, 2007 at 03:30:31PM +0100, Damien Wyart wrote: > > > * David Chinner [071218 13:24]: > > > > Ok. I haven't noticed anything wrong with directories up to about > > > > 250,000 files in the last few days. The ls -l I just did on > > > > a directory with 15000 entries (btree format) used about 5MB of RAM. > > > > extent format directories appear to work fine as well (tested 500 > > > > entries). > > > > > > Ok, nice to know the problem is not so frequent. > > > > ..... > > > > > I have put the files at http://damien.wyart.free.fr/xfs/ > > > > > > strace_xfs_problem.1.gz and strace_xfs_problem.2.gz have been created > > > with the problematic kernel, and are quite bigger than > > > strace_xfs_problem.normal.gz, which has been created with the vanilla > > > rc5-git5. There is also xfs_info. > > > > Looks like several getdents() through the directory the getdents() > > call starts outputting the first files again. It gets to a certain > > point and always goes back to the beginning. However, it appears to > > get to the end eventually (without ever getting past the bad offset). > > UML and a bunch of printk's to the rescue. > > So we went back to double buffering, which then screwed up the d_off > of the dirents. I changed the temporary dirents to point to the current > offset so that filldir got what it expected when filling the user buffer. > > Except it appears that it I didn't to initialise the current > offset for the first dirent read from the temporary buffer so filldir > occasionally got an uninitialised offset. Can someone pass me a > brown paper bag, please? > > In my local testing, more often than not, that uninitialised offset > reads as zero which is where the looping comes from. Sometimes it > points off into wacko-land, which is probably how we eventually get > the looping terminating before you run out of memory. > > That also explains why we haven't seen it - it requires the user buffer > to fill on the first entry of a backing buffer and so it is largely > dependent on the pattern of name lengths, page size and filesystem > block size aligning just right to trigger the problem. > > Can you test this patch, Damien? > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > --- > fs/xfs/linux-2.6/xfs_file.c | 1 + > 1 file changed, 1 insertion(+) > > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2007-12-19 00:26:40.000000000 +1100 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c 2007-12-19 21:26:38.701143555 +1100 > @@ -348,6 +348,7 @@ xfs_file_readdir( > > size = buf.used; > de = (struct hack_dirent *)buf.dirent; > + curr_offset = de->offset /* & 0x7fffffff */; > while (size > 0) { > if (filldir(dirent, de->name, de->namlen, > curr_offset & 0x7fffffff, -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 19 18:44:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 18:44:52 -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_51 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBK2ii41016761 for ; Wed, 19 Dec 2007 18:44:47 -0800 X-ASG-Debug-ID: 1198118695-5dec01e30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from email.msoe.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 53C92B7A5A3 for ; Wed, 19 Dec 2007 18:44:56 -0800 (PST) Received: from email.msoe.edu (email.msoe.edu [155.92.194.61]) by cuda.sgi.com with ESMTP id 9W87YsuhgGsQIpR7 for ; Wed, 19 Dec 2007 18:44:56 -0800 (PST) Received: from localhost ([155.92.193.21]) by email.msoe.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Dec 2007 20:44:53 -0600 Date: Wed, 19 Dec 2007 20:44:53 -0600 From: "Jonathan C. Detert" To: David Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount prob: "log inconsistent or not a log" Subject: Re: mount prob: "log inconsistent or not a log" Message-ID: <20071220024453.GX19770@msoe.edu> References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011848.GV19770@msoe.edu> <20071220015425.GL4612@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071220015425.GL4612@sgi.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 20 Dec 2007 02:44:53.0093 (UTC) FILETIME=[4C3FF150:01C842B2] X-Barracuda-Connect: email.msoe.edu[155.92.194.61] X-Barracuda-Start-Time: 1198118697 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37120 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5185/Wed Dec 19 16:56:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14032 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jonathan.Detert@msoe.edu Precedence: bulk X-list: xfs * David Chinner [071219 19:59]: > On Wed, Dec 19, 2007 at 07:18:48PM -0600, Jonathan C. Detert wrote: > > * Timothy Shimmin [071219 18:53]: > > > Hi Jonathan, -- snip -- > > > Jonathan.Detert@msoe.edu wrote: > > > >This is what /var/log/messages has to say about the mount attempt: > > > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS mounting filesystem sdb > > > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: Log inconsistent or not > > > >a log (last==0, first!=1) > > > > --snip -- > > > > > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > > > > Every 512 bytes of the log is stamped with the cycle#. > > > The cycle# is effectively the number of times the log has wrapped > > > > -- snip -- > > > > > An "xfs_logprint -d /dev/sdb" will show what the cycle#s are > > > and where the log records are. It might give an idea of the > > > extent of the corruption. > > > > Something occurred to me to point out: the snapshot from yesterday has > > the same problem. How can that be? Is is possible that the log has > > been hosed for some time, and that the problem only reared its head now > > because I had to remount? I.e. is it possible for an xfs fs to be > > mounted and used, even while the log is messed up? > > No, it should not. > > BTW, does "lost it's iSCSI connection" == "iSCSI server crashed"? I'm not sure what you mean by 'iSCSI server'. The linux 2.6.20 box (named 'quartz') is running the 'open-iscsi' 'iscsi initiator' software (v2.0.730). The ethernet cable connecting quartz to the iSCSI SAN switch got accidentally removed while the SAN volume was mounted and in use as /dev/sdb on quartz. After the ethernet cable was reconnected, I was unable to ls(1) the contents of the /dev/sdb's mountpoint. So, I rebooted quartz. Incidentally, quartz had another SAN volume mounted as /dev/sda, also with xfs on it, and it is able to mount /dev/sda just fine. > If so, is it possible that the iSCSI server is corrupted in some way? if by that you mean the software that the iSCSI controller is running on the iSCSI SAN hardware, then I suppose so. I have a call into the vendor on this already, and am waiting for a call-back. -- Jon Detert IT Systems Administrator, Milwaukee School of Engineering 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A. -- "Music washes away from the soul the dust of everyday life." Berthold Auerbach From owner-xfs@oss.sgi.com Wed Dec 19 20:41:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 20:41:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBK4fXUQ028304 for ; Wed, 19 Dec 2007 20:41:36 -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 PAA22394; Thu, 20 Dec 2007 15:41:39 +1100 Message-ID: <4769F343.9040405@sgi.com> Date: Thu, 20 Dec 2007 15:44:51 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Jonathan C. Detert" CC: xfs@oss.sgi.com Subject: Re: mount prob: "log inconsistent or not a log" References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011601.GU19770@msoe.edu> In-Reply-To: <20071220011601.GU19770@msoe.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5185/Wed Dec 19 16:56:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14033 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 Jonathan C. Detert wrote: > * Timothy Shimmin [071219 18:53]: >> Hi Jonathan, >> >> I'm not giving a high level view but >> in regards to the log message about the xfs log :) >> >> Jonathan.Detert@msoe.edu wrote: >>> This is what /var/log/messages has to say about the mount attempt: >>> -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS mounting filesystem sdb >>> Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: Log inconsistent or not >>> a log (last==0, first!=1) >>> Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: empty log check failed >>> Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: log mount/recovery >>> failed: error 22 >>> Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: log mount failed >>> -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> >> Every 512 bytes of the log is stamped with the cycle#. >> The cycle# is effectively the number of times the log has wrapped > > -- snip -- > >> An "xfs_logprint -d /dev/sdb" will show what the cycle#s are >> and where the log records are. It might give an idea of the >> extent of the corruption. > > Ok. It doesn't enlighten me, but hopefully you or others can take time > to see it, and maybe it will enlighten you. Here it is: > -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > root@quartz:~ # xfs_logprint -d /dev/sdb > xfs_logprint.out > xfs_logprint: > data device: 0x810 > log device: 0x810 daddr: 39859232 length: 38920 > > [00000 - 00000] Cycle 0xffffffff New Cycle 0x00000256 > 12 HEADER Cycle 598 tail 598:000010 len 224 ops 5 > 14 HEADER Cycle 598 tail 598:000044 len 32256 ops 142 > 78 HEADER Cycle 598 tail 598:000044 len 32256 ops 116 > 142 HEADER Cycle 598 tail 598:000044 len 32256 ops 82 > 206 HEADER Cycle 598 tail 598:000044 len 32256 ops 139 > 270 HEADER Cycle 598 tail 598:000044 len 32256 ops 69 > 334 HEADER Cycle 598 tail 598:000044 len 32256 ops 102 > 398 HEADER Cycle 598 tail 598:000044 len 32256 ops 96 > 462 HEADER Cycle 598 tail 598:000044 len 32256 ops 67 > 526 HEADER Cycle 598 tail 598:000046 len 32256 ops 86 > 590 HEADER Cycle 598 tail 598:000046 len 32256 ops 101 > 654 HEADER Cycle 598 tail 598:000046 len 32256 ops 100 > 718 HEADER Cycle 598 tail 598:000046 len 32256 ops 98 > 782 HEADER Cycle 598 tail 598:000046 len 32252 ops 82 > 846 HEADER Cycle 598 tail 598:000046 len 32256 ops 63 > 910 HEADER Cycle 598 tail 598:000046 len 32256 ops 150 > 974 HEADER Cycle 598 tail 598:000046 len 32256 ops 85 > 1038 HEADER Cycle 598 tail 598:000046 len 32256 ops 113 > 1102 HEADER Cycle 598 tail 598:000046 len 32256 ops 129 > 1166 HEADER Cycle 598 tail 598:000046 len 32256 ops 164 > 1230 HEADER Cycle 598 tail 598:000046 len 32256 ops 93 > 1294 HEADER Cycle 598 tail 598:000046 len 1052 ops 4 > 1298 HEADER Cycle 598 tail 598:001326 len 32256 ops 128 > 1362 HEADER Cycle 598 tail 598:001326 len 32256 ops 85 > 1426 HEADER Cycle 598 tail 598:001330 len 32256 ops 138 > 1490 HEADER Cycle 598 tail 598:001330 len 32256 ops 140 > 1554 HEADER Cycle 598 tail 598:001330 len 32256 ops 184 > 1618 HEADER Cycle 598 tail 598:001330 len 32256 ops 119 > 1682 HEADER Cycle 598 tail 598:001330 len 32252 ops 149 > 1746 HEADER Cycle 598 tail 598:001330 len 32256 ops 89 > 1810 HEADER Cycle 598 tail 598:001330 len 32256 ops 135 > 1874 HEADER Cycle 598 tail 598:001330 len 30168 ops 88 > 1934 HEADER Cycle 598 tail 598:001906 len 32256 ops 143 > 1998 HEADER Cycle 598 tail 598:001906 len 32256 ops 106 > 2062 HEADER Cycle 598 tail 598:001906 len 32256 ops 116 > 2126 HEADER Cycle 598 tail 598:001906 len 32256 ops 112 > 2190 HEADER Cycle 598 tail 598:001906 len 32256 ops 138 > 2254 HEADER Cycle 598 tail 598:001906 len 32256 ops 96 > 2318 HEADER Cycle 598 tail 598:001906 len 32256 ops 92 > 2382 HEADER Cycle 598 tail 598:001906 len 32236 ops 98 > 2446 HEADER Cycle 598 tail 598:001966 len 32256 ops 118 > 2510 HEADER Cycle 598 tail 598:001966 len 32252 ops 147 > 2574 HEADER Cycle 598 tail 598:001966 len 32256 ops 137 > 2638 HEADER Cycle 598 tail 598:001966 len 32256 ops 126 > 2702 HEADER Cycle 598 tail 598:001966 len 32256 ops 139 > 2766 HEADER Cycle 598 tail 598:001966 len 32256 ops 80 > 2830 HEADER Cycle 598 tail 598:001966 len 32256 ops 133 > 2894 HEADER Cycle 598 tail 598:001966 len 32256 ops 112 > 2958 HEADER Cycle 598 tail 598:001966 len 6708 ops 22 > 2973 HEADER Cycle 598 tail 598:002990 len 224 ops 5 > 2975 HEADER Cycle 598 tail 598:003005 len 32256 ops 133 > 3039 HEADER Cycle 598 tail 598:003005 len 32256 ops 108 > 3103 HEADER Cycle 598 tail 598:003005 len 32256 ops 95 > 3167 HEADER Cycle 598 tail 598:003005 len 32256 ops 90 > 3231 HEADER Cycle 598 tail 598:003005 len 32256 ops 155 > 3295 HEADER Cycle 598 tail 598:003005 len 32256 ops 163 > 3359 HEADER Cycle 598 tail 598:003005 len 32256 ops 102 > 3423 HEADER Cycle 598 tail 598:003005 len 32256 ops 81 > 3487 HEADER Cycle 598 tail 598:003007 len 32256 ops 93 > 3551 HEADER Cycle 598 tail 598:003007 len 32256 ops 150 > 3615 HEADER Cycle 598 tail 598:003007 len 32256 ops 144 > 3679 HEADER Cycle 598 tail 598:003007 len 32256 ops 106 > 3743 HEADER Cycle 598 tail 598:003007 len 13128 ops 26 > 3770 HEADER Cycle 598 tail 598:003007 len 32256 ops 180 > 3834 HEADER Cycle 598 tail 598:003007 len 32256 ops 109 > 3898 HEADER Cycle 598 tail 598:003007 len 32256 ops 95 > 3962 HEADER Cycle 598 tail 598:003007 len 32256 ops 135 > 4026 HEADER Cycle 598 tail 598:003007 len 32256 ops 91 > 4090 HEADER Cycle 598 tail 598:003007 len 32256 ops 116 > 4154 HEADER Cycle 598 tail 598:003007 len 32256 ops 104 > 4218 HEADER Cycle 598 tail 598:003007 len 32256 ops 113 > 4282 HEADER Cycle 598 tail 598:003007 len 32256 ops 131 > 4346 HEADER Cycle 598 tail 598:003007 len 32256 ops 195 > 4410 HEADER Cycle 598 tail 598:003007 len 32256 ops 63 > 4474 HEADER Cycle 598 tail 598:003007 len 32256 ops 89 > 4538 HEADER Cycle 598 tail 598:003007 len 32256 ops 83 > 4602 HEADER Cycle 598 tail 598:003007 len 32256 ops 124 > 4666 HEADER Cycle 598 tail 598:003007 len 32256 ops 122 > 4730 HEADER Cycle 598 tail 598:003007 len 32256 ops 111 > 4794 HEADER Cycle 598 tail 598:003007 len 32256 ops 134 > 4858 HEADER Cycle 598 tail 598:003007 len 32256 ops 94 > 4922 HEADER Cycle 598 tail 598:003007 len 32256 ops 112 > 4986 HEADER Cycle 598 tail 598:003007 len 32256 ops 109 > 5050 HEADER Cycle 598 tail 598:003007 len 13784 ops 44 > 5078 HEADER Cycle 598 tail 598:005082 len 32256 ops 157 > 5142 HEADER Cycle 598 tail 598:005082 len 32256 ops 171 > 5206 HEADER Cycle 598 tail 598:005082 len 32256 ops 127 > 5270 HEADER Cycle 598 tail 598:005082 len 32244 ops 188 > 5334 HEADER Cycle 598 tail 598:005082 len 32256 ops 133 > 5398 HEADER Cycle 598 tail 598:005082 len 32256 ops 118 > 5462 HEADER Cycle 598 tail 598:005082 len 32256 ops 145 > 5526 HEADER Cycle 598 tail 598:005082 len 32256 ops 153 > 5590 HEADER Cycle 598 tail 598:005110 len 32256 ops 163 > 5654 HEADER Cycle 598 tail 598:005110 len 32256 ops 198 > 5718 HEADER Cycle 598 tail 598:005110 len 32256 ops 148 > 5782 HEADER Cycle 598 tail 598:005110 len 32256 ops 129 > 5846 HEADER Cycle 598 tail 598:005110 len 32256 ops 108 > 5910 HEADER Cycle 598 tail 598:005110 len 32256 ops 103 > 5974 HEADER Cycle 598 tail 598:005110 len 32256 ops 60 > 6038 HEADER Cycle 598 tail 598:005110 len 32256 ops 86 > 6102 HEADER Cycle 598 tail 598:005110 len 32256 ops 59 > 6166 HEADER Cycle 598 tail 598:005110 len 32256 ops 46 > 6230 HEADER Cycle 598 tail 598:005110 len 32256 ops 90 > 6294 HEADER Cycle 598 tail 598:005110 len 32256 ops 162 > 6358 HEADER Cycle 598 tail 598:005110 len 32256 ops 135 > 6422 HEADER Cycle 598 tail 598:005110 len 32256 ops 79 > 6486 HEADER Cycle 598 tail 598:005110 len 32252 ops 75 > 6550 HEADER Cycle 598 tail 598:005110 len 32256 ops 68 > 6614 HEADER Cycle 598 tail 598:005110 len 32256 ops 81 > 6678 HEADER Cycle 598 tail 598:005110 len 32256 ops 98 > 6742 HEADER Cycle 598 tail 598:005110 len 32256 ops 128 > 6806 HEADER Cycle 598 tail 598:005110 len 32256 ops 97 > 6870 HEADER Cycle 598 tail 598:005110 len 32256 ops 122 > 6934 HEADER Cycle 598 tail 598:005110 len 6068 ops 6 > 6947 HEADER Cycle 598 tail 598:006902 len 32256 ops 112 > 7011 HEADER Cycle 598 tail 598:006902 len 32256 ops 125 > 7075 HEADER Cycle 598 tail 598:006902 len 32256 ops 118 > 7139 HEADER Cycle 598 tail 598:006902 len 32256 ops 107 > 7203 HEADER Cycle 598 tail 598:006902 len 32256 ops 89 > 7267 HEADER Cycle 598 tail 598:006902 len 32256 ops 69 > 7331 HEADER Cycle 598 tail 598:006966 len 32256 ops 135 > 7395 HEADER Cycle 598 tail 598:006966 len 32256 ops 125 > 7459 HEADER Cycle 598 tail 598:006979 len 32256 ops 94 > 7523 HEADER Cycle 598 tail 598:006979 len 32256 ops 108 > 7587 HEADER Cycle 598 tail 598:006979 len 32256 ops 197 > 7651 HEADER Cycle 598 tail 598:006979 len 24684 ops 74 > 7701 HEADER Cycle 598 tail 598:007683 len 32256 ops 137 > 7765 HEADER Cycle 598 tail 598:007683 len 32256 ops 119 > 7829 HEADER Cycle 598 tail 598:007683 len 32256 ops 116 > 7893 HEADER Cycle 598 tail 598:007683 len 32256 ops 102 > 7957 HEADER Cycle 598 tail 598:007683 len 32256 ops 122 > 8021 HEADER Cycle 598 tail 598:007683 len 32256 ops 95 > 8085 HEADER Cycle 598 tail 598:007683 len 32256 ops 98 > 8149 HEADER Cycle 598 tail 598:007683 len 32256 ops 98 > 8213 HEADER Cycle 598 tail 598:007733 len 15556 ops 83 > 8245 HEADER Cycle 598 tail 598:007733 len 32256 ops 95 > 8309 HEADER Cycle 598 tail 598:007733 len 32256 ops 81 > 8373 HEADER Cycle 598 tail 598:007733 len 32256 ops 95 > 8437 HEADER Cycle 598 tail 598:007733 len 15084 ops 52 > 8468 HEADER Cycle 598 tail 598:008469 len 32256 ops 100 > 8532 HEADER Cycle 598 tail 598:008469 len 32256 ops 83 > 8596 HEADER Cycle 598 tail 598:008469 len 32256 ops 108 > 8660 HEADER Cycle 598 tail 598:008469 len 32256 ops 99 > 8724 HEADER Cycle 598 tail 598:008469 len 32256 ops 100 > 8788 HEADER Cycle 598 tail 598:008469 len 32256 ops 99 > 8852 HEADER Cycle 598 tail 598:008500 len 6696 ops 29 > 8867 HEADER Cycle 598 tail 598:008500 len 32256 ops 108 > 8931 HEADER Cycle 598 tail 598:008500 len 32256 ops 60 > 8995 HEADER Cycle 598 tail 598:008500 len 32256 ops 75 > 9059 HEADER Cycle 598 tail 598:008500 len 32256 ops 102 > 9123 HEADER Cycle 598 tail 598:008500 len 32256 ops 109 > 9187 HEADER Cycle 598 tail 598:008500 len 32256 ops 98 > 9251 HEADER Cycle 598 tail 598:008500 len 32256 ops 85 > 9315 HEADER Cycle 598 tail 598:008500 len 32256 ops 99 > 9379 HEADER Cycle 598 tail 598:008500 len 32256 ops 63 > 9443 HEADER Cycle 598 tail 598:008500 len 32256 ops 79 > 9507 HEADER Cycle 598 tail 598:008500 len 32256 ops 147 > 9571 HEADER Cycle 598 tail 598:008500 len 32256 ops 121 > 9635 HEADER Cycle 598 tail 598:008500 len 32256 ops 140 > 9699 HEADER Cycle 598 tail 598:008500 len 32252 ops 124 > 9763 HEADER Cycle 598 tail 598:008500 len 32256 ops 163 > 9827 HEADER Cycle 598 tail 598:008500 len 31064 ops 132 > 9889 HEADER Cycle 598 tail 598:008899 len 32256 ops 100 > 9953 HEADER Cycle 598 tail 598:008899 len 32256 ops 87 > 10017 HEADER Cycle 598 tail 598:008899 len 14464 ops 45 > 10047 HEADER Cycle 598 tail 598:010049 len 32256 ops 129 > 10111 HEADER Cycle 598 tail 598:010049 len 32256 ops 124 > 10175 HEADER Cycle 598 tail 598:010049 len 32256 ops 60 > 10239 HEADER Cycle 598 tail 598:010049 len 32256 ops 84 > 10303 HEADER Cycle 598 tail 598:010049 len 32256 ops 88 > 10367 HEADER Cycle 598 tail 598:010079 len 32256 ops 84 > 10431 HEADER Cycle 598 tail 598:010079 len 32256 ops 81 > 10495 HEADER Cycle 598 tail 598:010079 len 32256 ops 121 > 10559 HEADER Cycle 598 tail 598:010079 len 32256 ops 161 > 10623 HEADER Cycle 598 tail 598:010079 len 32256 ops 130 > 10687 HEADER Cycle 598 tail 598:010079 len 32256 ops 106 > 10751 HEADER Cycle 598 tail 598:010079 len 32256 ops 104 > 10815 HEADER Cycle 598 tail 598:010079 len 32256 ops 118 > 10879 HEADER Cycle 598 tail 598:010079 len 1784 ops 4 > 10884 HEADER Cycle 598 tail 598:010847 len 32256 ops 114 > 10948 HEADER Cycle 598 tail 598:010847 len 32256 ops 168 > 11012 HEADER Cycle 598 tail 598:010847 len 32256 ops 121 > 11076 HEADER Cycle 598 tail 598:010847 len 32256 ops 88 > 11140 HEADER Cycle 598 tail 598:010847 len 32256 ops 75 > 11204 HEADER Cycle 598 tail 598:010916 len 32256 ops 106 > 11268 HEADER Cycle 598 tail 598:010916 len 32256 ops 69 > 11332 HEADER Cycle 598 tail 598:010916 len 32256 ops 131 > 11396 HEADER Cycle 598 tail 598:010916 len 32256 ops 109 > 11460 HEADER Cycle 598 tail 598:010980 len 32256 ops 119 > 11524 HEADER Cycle 598 tail 598:010980 len 32256 ops 121 > 11588 HEADER Cycle 598 tail 598:010980 len 32256 ops 158 > 11652 HEADER Cycle 598 tail 598:010980 len 32256 ops 150 > 11716 HEADER Cycle 598 tail 598:010980 len 32256 ops 133 > 11780 HEADER Cycle 598 tail 598:010980 len 32256 ops 155 > 11844 HEADER Cycle 598 tail 598:010980 len 8760 ops 19 > 11863 HEADER Cycle 598 tail 598:011876 len 32256 ops 161 > 11927 HEADER Cycle 598 tail 598:011876 len 32256 ops 170 > 11991 HEADER Cycle 598 tail 598:011895 len 32256 ops 98 > 12055 HEADER Cycle 598 tail 598:011895 len 32256 ops 76 > 12119 HEADER Cycle 598 tail 598:011895 len 32256 ops 84 > 12183 HEADER Cycle 598 tail 598:011895 len 32256 ops 80 > 12247 HEADER Cycle 598 tail 598:011895 len 5220 ops 20 > 12259 HEADER Cycle 598 tail 598:012279 len 32256 ops 109 > 12323 HEADER Cycle 598 tail 598:012279 len 32256 ops 145 > 12387 HEADER Cycle 598 tail 598:012279 len 32256 ops 117 > 12451 HEADER Cycle 598 tail 598:012291 len 32256 ops 120 > 12515 HEADER Cycle 598 tail 598:012291 len 32256 ops 116 > 12579 HEADER Cycle 598 tail 598:012291 len 32256 ops 180 > 12643 HEADER Cycle 598 tail 598:012291 len 32256 ops 81 > 12707 HEADER Cycle 598 tail 598:012291 len 32256 ops 87 > 12771 HEADER Cycle 598 tail 598:012291 len 32252 ops 124 > 12835 HEADER Cycle 598 tail 598:012291 len 32256 ops 168 > 12899 HEADER Cycle 598 tail 598:012291 len 32256 ops 91 > 12963 HEADER Cycle 598 tail 598:012291 len 26220 ops 44 > 13016 HEADER Cycle 598 tail 598:012291 len 32256 ops 122 > 13080 HEADER Cycle 598 tail 598:012291 len 32256 ops 118 > 13144 HEADER Cycle 598 tail 598:012291 len 32256 ops 105 > 13208 HEADER Cycle 598 tail 598:012291 len 32256 ops 83 > 13272 HEADER Cycle 598 tail 598:012291 len 32256 ops 85 > 13336 HEADER Cycle 598 tail 598:012291 len 32256 ops 66 > 13400 HEADER Cycle 598 tail 598:012291 len 27456 ops 119 > 13455 HEADER Cycle 598 tail 598:013432 len 32256 ops 167 > 13519 HEADER Cycle 598 tail 598:013432 len 32256 ops 103 > 13583 HEADER Cycle 598 tail 598:013432 len 32256 ops 101 > 13647 HEADER Cycle 598 tail 598:013432 len 32256 ops 126 > 13711 HEADER Cycle 598 tail 598:013432 len 32256 ops 136 > 13775 HEADER Cycle 598 tail 598:013432 len 32256 ops 86 > 13839 HEADER Cycle 598 tail 598:013432 len 32256 ops 79 > 13903 HEADER Cycle 598 tail 598:013432 len 32256 ops 80 > 13967 HEADER Cycle 598 tail 598:013487 len 32256 ops 74 > 14031 HEADER Cycle 598 tail 598:013487 len 32256 ops 82 > 14095 HEADER Cycle 598 tail 598:013487 len 32256 ops 153 > 14159 HEADER Cycle 598 tail 598:013487 len 32256 ops 104 > 14223 HEADER Cycle 598 tail 598:013487 len 32256 ops 190 > 14287 HEADER Cycle 598 tail 598:013487 len 32256 ops 97 > 14351 HEADER Cycle 598 tail 598:013487 len 32256 ops 99 > 14415 HEADER Cycle 598 tail 598:013487 len 32256 ops 123 > 14479 HEADER Cycle 598 tail 598:013487 len 32256 ops 125 > 14543 HEADER Cycle 598 tail 598:013487 len 32256 ops 112 > 14607 HEADER Cycle 598 tail 598:013487 len 3968 ops 5 > 14616 HEADER Cycle 598 tail 598:013487 len 32256 ops 114 > 14680 HEADER Cycle 598 tail 598:013487 len 32256 ops 122 > 14744 HEADER Cycle 598 tail 598:013487 len 32256 ops 80 > 14808 HEADER Cycle 598 tail 598:013487 len 32256 ops 104 > 14872 HEADER Cycle 598 tail 598:013487 len 32256 ops 79 > 14936 HEADER Cycle 598 tail 598:013487 len 32256 ops 62 > 15000 HEADER Cycle 598 tail 598:013487 len 32256 ops 98 > 15064 HEADER Cycle 598 tail 598:013487 len 32256 ops 115 > 15128 HEADER Cycle 598 tail 598:013487 len 32256 ops 70 > 15192 HEADER Cycle 598 tail 598:013487 len 32256 ops 80 > 15256 HEADER Cycle 598 tail 598:013487 len 32256 ops 118 > 15320 HEADER Cycle 598 tail 598:013487 len 32256 ops 69 > 15384 HEADER Cycle 598 tail 598:013487 len 32256 ops 154 > 15448 HEADER Cycle 598 tail 598:013487 len 10088 ops 34 > 15469 HEADER Cycle 598 tail 598:015480 len 32256 ops 149 > 15533 HEADER Cycle 598 tail 598:015480 len 32256 ops 85 > 15597 HEADER Cycle 598 tail 598:015480 len 32256 ops 78 > 15661 HEADER Cycle 598 tail 598:015480 len 32256 ops 104 > 15725 HEADER Cycle 598 tail 598:015480 len 32256 ops 149 > 15789 HEADER Cycle 598 tail 598:015480 len 32256 ops 57 > 15853 HEADER Cycle 598 tail 598:015480 len 32256 ops 56 > 15917 HEADER Cycle 598 tail 598:015480 len 32256 ops 41 > 15981 HEADER Cycle 598 tail 598:015501 len 32256 ops 56 > 16045 HEADER Cycle 598 tail 598:015501 len 32256 ops 80 > 16109 HEADER Cycle 598 tail 598:015501 len 32256 ops 134 > 16173 HEADER Cycle 598 tail 598:015501 len 32248 ops 144 > 16237 HEADER Cycle 598 tail 598:015501 len 32256 ops 96 > 16301 HEADER Cycle 598 tail 598:015501 len 32256 ops 76 > 16365 HEADER Cycle 598 tail 598:015501 len 32256 ops 111 > 16429 HEADER Cycle 598 tail 598:015501 len 32256 ops 127 > 16493 HEADER Cycle 598 tail 598:015501 len 32256 ops 119 > 16557 HEADER Cycle 598 tail 598:015501 len 32256 ops 104 > 16621 HEADER Cycle 598 tail 598:015501 len 32256 ops 101 > 16685 HEADER Cycle 598 tail 598:015501 len 32256 ops 106 > 16749 HEADER Cycle 598 tail 598:015501 len 32256 ops 190 > 16813 HEADER Cycle 598 tail 598:015501 len 32252 ops 162 > 16877 HEADER Cycle 598 tail 598:015501 len 32256 ops 141 > 16941 HEADER Cycle 598 tail 598:015501 len 32256 ops 99 > 17005 HEADER Cycle 598 tail 598:015501 len 32256 ops 101 > 17069 HEADER Cycle 598 tail 598:015501 len 18592 ops 46 > 17107 HEADER Cycle 598 tail 598:017101 len 32256 ops 148 > 17171 HEADER Cycle 598 tail 598:017101 len 32256 ops 95 > 17235 HEADER Cycle 598 tail 598:017139 len 32252 ops 147 > 17299 HEADER Cycle 598 tail 598:017139 len 32256 ops 130 > 17363 HEADER Cycle 598 tail 598:017139 len 32256 ops 106 > 17427 HEADER Cycle 598 tail 598:017139 len 32256 ops 109 > 17491 HEADER Cycle 598 tail 598:017139 len 32256 ops 121 > 17555 HEADER Cycle 598 tail 598:017139 len 32256 ops 119 > 17619 HEADER Cycle 598 tail 598:017139 len 32256 ops 86 > 17683 HEADER Cycle 598 tail 598:017139 len 32256 ops 106 > 17747 HEADER Cycle 598 tail 598:017139 len 11080 ops 40 > 17770 HEADER Cycle 598 tail 598:017779 len 32256 ops 112 > 17834 HEADER Cycle 598 tail 598:017779 len 32256 ops 118 > 17898 HEADER Cycle 598 tail 598:017779 len 32256 ops 137 > 17962 HEADER Cycle 598 tail 598:017779 len 32256 ops 159 > 18026 HEADER Cycle 598 tail 598:017779 len 32256 ops 145 > 18090 HEADER Cycle 598 tail 598:017779 len 32256 ops 133 > 18154 HEADER Cycle 598 tail 598:017779 len 32244 ops 106 > 18218 HEADER Cycle 598 tail 598:017802 len 32256 ops 106 > 18282 HEADER Cycle 598 tail 598:017802 len 32256 ops 159 > 18346 HEADER Cycle 598 tail 598:017802 len 15884 ops 25 > 18379 HEADER Cycle 598 tail 598:017802 len 32256 ops 117 > 18443 HEADER Cycle 598 tail 598:017802 len 32256 ops 137 > 18507 HEADER Cycle 598 tail 598:017802 len 32256 ops 138 > 18571 HEADER Cycle 598 tail 598:017802 len 32256 ops 152 > 18635 HEADER Cycle 598 tail 598:017866 len 10988 ops 29 > 18658 HEADER Cycle 598 tail 598:018667 len 32256 ops 110 > 18722 HEADER Cycle 598 tail 598:018690 len 900 ops 7 > 18725 HEADER Cycle 598 tail 598:018690 len 32256 ops 139 > 18789 HEADER Cycle 598 tail 598:018690 len 32256 ops 111 > 18853 HEADER Cycle 598 tail 598:018690 len 32256 ops 81 > 18917 HEADER Cycle 598 tail 598:018690 len 32256 ops 81 > 18981 HEADER Cycle 598 tail 598:018690 len 32256 ops 78 > 19045 HEADER Cycle 598 tail 598:018690 len 32256 ops 91 > 19109 HEADER Cycle 598 tail 598:018690 len 32256 ops 97 > 19173 HEADER Cycle 598 tail 598:018690 len 32256 ops 62 > 19237 HEADER Cycle 598 tail 598:018757 len 32256 ops 97 > 19301 HEADER Cycle 598 tail 598:018757 len 32256 ops 75 > 19365 HEADER Cycle 598 tail 598:018757 len 32256 ops 60 > 19429 HEADER Cycle 598 tail 598:018757 len 32256 ops 98 > 19493 HEADER Cycle 598 tail 598:018757 len 32256 ops 83 > 19557 HEADER Cycle 598 tail 598:018757 len 32256 ops 70 > 19621 HEADER Cycle 598 tail 598:018757 len 32248 ops 110 > 19685 HEADER Cycle 598 tail 598:018757 len 32256 ops 95 > 19749 HEADER Cycle 598 tail 598:018757 len 32256 ops 88 > 19813 HEADER Cycle 598 tail 598:018757 len 32256 ops 93 > 19877 HEADER Cycle 598 tail 598:018757 len 32256 ops 104 > 19941 HEADER Cycle 598 tail 598:018757 len 32256 ops 101 > 20005 HEADER Cycle 598 tail 598:018757 len 29988 ops 84 > 20065 HEADER Cycle 598 tail 598:020037 len 32256 ops 138 > 20129 HEADER Cycle 598 tail 598:020037 len 32256 ops 105 > 20193 HEADER Cycle 598 tail 598:020037 len 32256 ops 168 > 20257 HEADER Cycle 598 tail 598:020037 len 32244 ops 112 > 20321 HEADER Cycle 598 tail 598:020037 len 32256 ops 131 > 20385 HEADER Cycle 598 tail 598:020037 len 32256 ops 84 > 20449 HEADER Cycle 598 tail 598:020037 len 32256 ops 81 > 20513 HEADER Cycle 598 tail 598:020037 len 32256 ops 112 > 20577 HEADER Cycle 598 tail 598:020097 len 3512 ops 6 > 20585 HEADER Cycle 598 tail 598:020609 len 224 ops 5 > 20587 HEADER Cycle 598 tail 598:020617 len 32256 ops 191 > 20651 HEADER Cycle 598 tail 598:020617 len 2772 ops 6 > 20658 HEADER Cycle 598 tail 598:020619 len 32256 ops 124 > 20722 HEADER Cycle 598 tail 598:020619 len 32256 ops 153 > 20786 HEADER Cycle 598 tail 598:020619 len 32256 ops 105 > 20850 HEADER Cycle 598 tail 598:020619 len 32256 ops 115 > 20914 HEADER Cycle 598 tail 598:020619 len 32256 ops 112 > 20978 HEADER Cycle 598 tail 598:020619 len 32256 ops 119 > 21042 HEADER Cycle 598 tail 598:020619 len 32256 ops 114 > 21106 HEADER Cycle 598 tail 598:020619 len 32256 ops 98 > 21170 HEADER Cycle 598 tail 598:020619 len 32256 ops 80 > 21234 HEADER Cycle 598 tail 598:020619 len 32256 ops 64 > 21298 HEADER Cycle 598 tail 598:020619 len 32256 ops 64 > 21362 HEADER Cycle 598 tail 598:020619 len 12728 ops 58 > 21388 HEADER Cycle 598 tail 598:021394 len 224 ops 5 > 21390 HEADER Cycle 598 tail 598:021420 len 32256 ops 133 > 21454 HEADER Cycle 598 tail 598:021420 len 32256 ops 77 > 21518 HEADER Cycle 598 tail 598:021420 len 32256 ops 131 > 21582 HEADER Cycle 598 tail 598:021420 len 32256 ops 101 > 21646 HEADER Cycle 598 tail 598:021420 len 32256 ops 101 > 21710 HEADER Cycle 598 tail 598:021420 len 32256 ops 87 > 21774 HEADER Cycle 598 tail 598:021420 len 32256 ops 102 > 21838 HEADER Cycle 598 tail 598:021420 len 32256 ops 85 > 21902 HEADER Cycle 598 tail 598:021422 len 32256 ops 110 > 21966 HEADER Cycle 598 tail 598:021422 len 18988 ops 58 > 22005 HEADER Cycle 598 tail 598:021998 len 32256 ops 120 > 22069 HEADER Cycle 598 tail 598:022037 len 4972 ops 19 > 22080 HEADER Cycle 598 tail 598:022101 len 32256 ops 117 > 22144 HEADER Cycle 598 tail 598:022112 len 26100 ops 78 > 22196 HEADER Cycle 598 tail 598:022176 len 32256 ops 84 > 22260 HEADER Cycle 598 tail 598:022176 len 32256 ops 106 > 22324 HEADER Cycle 598 tail 598:022176 len 32256 ops 117 > 22388 HEADER Cycle 598 tail 598:022228 len 13768 ops 31 > 22416 HEADER Cycle 598 tail 598:022420 len 32256 ops 97 > 22480 HEADER Cycle 598 tail 598:022420 len 32256 ops 113 > 22544 HEADER Cycle 598 tail 598:022512 len 5256 ops 36 > 22556 HEADER Cycle 598 tail 598:022512 len 13112 ops 48 > 22583 HEADER Cycle 598 tail 598:022588 len 32256 ops 145 > 22647 HEADER Cycle 598 tail 598:022615 len 20896 ops 79 > 22689 HEADER Cycle 598 tail 598:022615 len 32256 ops 111 > 22753 HEADER Cycle 598 tail 598:022615 len 6508 ops 52 > 22767 HEADER Cycle 598 tail 598:022785 len 32256 ops 109 > 22831 HEADER Cycle 598 tail 598:022799 len 10684 ops 44 > 22853 HEADER Cycle 598 tail 598:022863 len 32248 ops 98 > 22917 HEADER Cycle 598 tail 598:022863 len 32256 ops 99 > 22981 HEADER Cycle 598 tail 598:022863 len 32256 ops 95 > 23045 HEADER Cycle 598 tail 598:022949 len 23184 ops 54 > 23092 HEADER Cycle 598 tail 598:023013 len 12820 ops 45 > 23119 HEADER Cycle 598 tail 598:023124 len 32256 ops 111 > 23183 HEADER Cycle 598 tail 598:023151 len 23660 ops 82 > 23231 HEADER Cycle 598 tail 598:023215 len 32256 ops 157 > 23295 HEADER Cycle 598 tail 598:023215 len 32256 ops 103 > 23359 HEADER Cycle 598 tail 598:023215 len 32256 ops 77 > 23423 HEADER Cycle 598 tail 598:023263 len 20804 ops 62 > 23465 HEADER Cycle 598 tail 598:023455 len 32256 ops 113 > 23529 HEADER Cycle 598 tail 598:023455 len 32256 ops 60 > 23593 HEADER Cycle 598 tail 598:023497 len 27896 ops 61 > 23649 HEADER Cycle 598 tail 598:023625 len 32256 ops 97 > 23713 HEADER Cycle 598 tail 598:023625 len 32256 ops 116 > 23777 HEADER Cycle 598 tail 598:023625 len 32256 ops 99 > 23841 HEADER Cycle 598 tail 598:023681 len 12828 ops 27 > 23868 HEADER Cycle 598 tail 598:023873 len 224 ops 5 > 23870 HEADER Cycle 598 tail 598:023900 len 21208 ops 112 > 23913 HEADER Cycle 598 tail 598:023902 len 224 ops 5 > 23915 HEADER Cycle 598 tail 598:023945 len 32256 ops 168 > 23979 HEADER Cycle 598 tail 598:023947 len 8564 ops 27 > 23997 HEADER Cycle 598 tail 598:024011 len 224 ops 5 > 23999 HEADER Cycle 598 tail 598:024029 len 32256 ops 129 > 24063 HEADER Cycle 598 tail 598:024029 len 32256 ops 116 > 24127 HEADER Cycle 598 tail 598:024031 len 6024 ops 19 > 24140 HEADER Cycle 598 tail 598:024159 len 3304 ops 16 > 24148 HEADER Cycle 598 tail 598:024172 len 224 ops 5 > 24150 HEADER Cycle 598 tail 598:024180 len 224 ops 5 > 24152 HEADER Cycle 598 tail 598:024182 len 1896 ops 16 > 24157 HEADER Cycle 598 tail 598:024184 len 224 ops 5 > 24159 HEADER Cycle 598 tail 598:024189 len 224 ops 5 > 24161 HEADER Cycle 598 tail 598:024191 len 32256 ops 140 > 24225 HEADER Cycle 598 tail 598:024193 len 27864 ops 120 > 24281 HEADER Cycle 598 tail 598:024257 len 224 ops 5 > 24283 HEADER Cycle 598 tail 598:024313 len 1896 ops 16 > 24288 HEADER Cycle 598 tail 598:024315 len 4304 ops 20 > 24298 HEADER Cycle 598 tail 598:024320 len 22476 ops 93 > 24343 HEADER Cycle 598 tail 598:024330 len 224 ops 5 > 24345 HEADER Cycle 598 tail 598:024375 len 224 ops 5 > 24347 HEADER Cycle 598 tail 598:024377 len 1768 ops 16 > 24352 HEADER Cycle 598 tail 598:024379 len 224 ops 5 > 24354 HEADER Cycle 598 tail 598:024384 len 1640 ops 16 > 24359 HEADER Cycle 598 tail 598:024386 len 224 ops 5 > 24361 HEADER Cycle 598 tail 598:024391 len 17356 ops 75 > 24396 HEADER Cycle 598 tail 598:024393 len 224 ops 5 > 24398 HEADER Cycle 598 tail 598:024428 len 224 ops 5 > 24400 HEADER Cycle 598 tail 598:024430 len 1512 ops 16 > 24404 HEADER Cycle 598 tail 598:024432 len 224 ops 5 > 24406 HEADER Cycle 598 tail 598:024436 len 224 ops 5 > 24408 HEADER Cycle 598 tail 598:024438 len 5712 ops 20 > 24421 HEADER Cycle 598 tail 598:024440 len 224 ops 5 > 24423 HEADER Cycle 598 tail 598:024453 len 224 ops 5 > 24425 HEADER Cycle 598 tail 598:024455 len 6352 ops 20 > 24439 HEADER Cycle 598 tail 598:024457 len 224 ops 5 > 24441 HEADER Cycle 598 tail 598:024471 len 224 ops 5 > 24443 HEADER Cycle 598 tail 598:024473 len 5072 ops 20 > 24454 HEADER Cycle 598 tail 598:024475 len 224 ops 5 > 24456 HEADER Cycle 598 tail 598:024486 len 224 ops 5 > 24458 HEADER Cycle 598 tail 598:024488 len 4072 ops 16 > 24467 HEADER Cycle 598 tail 598:024490 len 224 ops 5 > 24469 HEADER Cycle 598 tail 598:024499 len 224 ops 5 > 24471 HEADER Cycle 598 tail 598:024501 len 1896 ops 16 > 24476 HEADER Cycle 598 tail 598:024503 len 224 ops 5 > 24478 HEADER Cycle 598 tail 598:024508 len 224 ops 5 > 24480 HEADER Cycle 598 tail 598:024510 len 5584 ops 20 > 24492 HEADER Cycle 598 tail 598:024512 len 224 ops 5 > 24494 HEADER Cycle 598 tail 598:024524 len 224 ops 5 > 24496 HEADER Cycle 598 tail 598:024526 len 2280 ops 16 > 24502 HEADER Cycle 598 tail 598:024528 len 224 ops 5 > 24504 HEADER Cycle 598 tail 598:024534 len 224 ops 5 > 24506 HEADER Cycle 598 tail 598:024536 len 2408 ops 16 > 24512 HEADER Cycle 598 tail 598:024538 len 224 ops 5 > 24514 HEADER Cycle 598 tail 598:024544 len 2280 ops 16 > 24520 HEADER Cycle 598 tail 598:024546 len 224 ops 5 > 24522 HEADER Cycle 598 tail 598:024552 len 224 ops 5 > 24524 HEADER Cycle 598 tail 598:024554 len 2280 ops 16 > 24530 HEADER Cycle 598 tail 598:024556 len 224 ops 5 > 24532 HEADER Cycle 598 tail 598:024562 len 224 ops 5 > 24534 HEADER Cycle 598 tail 598:024564 len 2408 ops 16 > 24540 HEADER Cycle 598 tail 598:024566 len 224 ops 5 > 24542 HEADER Cycle 598 tail 598:024572 len 224 ops 5 > 24544 HEADER Cycle 598 tail 598:024574 len 2280 ops 16 > 24550 HEADER Cycle 598 tail 598:024576 len 224 ops 5 > 24552 HEADER Cycle 598 tail 598:024582 len 224 ops 5 > 24554 HEADER Cycle 598 tail 598:024584 len 2280 ops 16 > 24560 HEADER Cycle 598 tail 598:024586 len 224 ops 5 > 24562 HEADER Cycle 598 tail 598:024592 len 224 ops 5 > 24564 HEADER Cycle 598 tail 598:024594 len 2280 ops 16 > 24570 HEADER Cycle 598 tail 598:024596 len 224 ops 5 > 24572 HEADER Cycle 598 tail 598:024602 len 224 ops 5 > 24574 HEADER Cycle 598 tail 598:024604 len 2280 ops 16 > 24580 HEADER Cycle 598 tail 598:024606 len 224 ops 5 > 24582 HEADER Cycle 598 tail 598:024612 len 224 ops 5 > 24584 HEADER Cycle 598 tail 598:024614 len 2408 ops 16 > 24590 HEADER Cycle 598 tail 598:024616 len 224 ops 5 > 24592 HEADER Cycle 598 tail 598:024622 len 2408 ops 16 > 24598 HEADER Cycle 598 tail 598:024624 len 224 ops 5 > 24600 HEADER Cycle 598 tail 598:024630 len 224 ops 5 > 24602 HEADER Cycle 598 tail 598:024632 len 2408 ops 16 > 24608 HEADER Cycle 598 tail 598:024634 len 224 ops 5 > 24610 HEADER Cycle 598 tail 598:024640 len 2408 ops 16 > 24616 HEADER Cycle 598 tail 598:024642 len 224 ops 5 > 24618 HEADER Cycle 598 tail 598:024648 len 224 ops 5 > 24620 HEADER Cycle 598 tail 598:024650 len 2408 ops 16 > 24626 HEADER Cycle 598 tail 598:024652 len 224 ops 5 > 24628 HEADER Cycle 598 tail 598:024658 len 224 ops 5 > 24630 HEADER Cycle 598 tail 598:024660 len 2408 ops 16 > 24636 HEADER Cycle 598 tail 598:024662 len 224 ops 5 > 24638 HEADER Cycle 598 tail 598:024668 len 224 ops 5 > 24640 HEADER Cycle 598 tail 598:024670 len 2408 ops 16 > 24646 HEADER Cycle 598 tail 598:024672 len 224 ops 5 > 24648 HEADER Cycle 598 tail 598:024678 len 2408 ops 16 > 24654 HEADER Cycle 598 tail 598:024680 len 224 ops 5 > 24656 HEADER Cycle 598 tail 598:024686 len 224 ops 5 > 24658 HEADER Cycle 598 tail 598:024688 len 2408 ops 16 > 24664 HEADER Cycle 598 tail 598:024690 len 224 ops 5 > 24666 HEADER Cycle 598 tail 598:024696 len 2408 ops 16 > 24672 HEADER Cycle 598 tail 598:024698 len 224 ops 5 > 24674 HEADER Cycle 598 tail 598:024704 len 224 ops 5 > 24676 HEADER Cycle 598 tail 598:024706 len 2536 ops 16 > 24682 HEADER Cycle 598 tail 598:024708 len 224 ops 5 > 24684 HEADER Cycle 598 tail 598:024714 len 224 ops 5 > 24686 HEADER Cycle 598 tail 598:024716 len 5072 ops 32 > 24697 HEADER Cycle 598 tail 598:024718 len 224 ops 5 > 24699 HEADER Cycle 598 tail 598:024729 len 224 ops 5 > 24701 HEADER Cycle 598 tail 598:024731 len 10784 ops 64 > 24724 HEADER Cycle 598 tail 598:024733 len 224 ops 5 > 24726 HEADER Cycle 598 tail 598:024756 len 224 ops 5 > 24728 HEADER Cycle 598 tail 598:024758 len 7608 ops 48 > 24744 HEADER Cycle 598 tail 598:024760 len 224 ops 5 > 24746 HEADER Cycle 598 tail 598:024776 len 224 ops 5 > 24748 HEADER Cycle 598 tail 598:024778 len 10144 ops 64 > 24769 HEADER Cycle 598 tail 598:024780 len 224 ops 5 > 24771 HEADER Cycle 598 tail 598:024801 len 224 ops 5 > 24773 HEADER Cycle 598 tail 598:024803 len 5584 ops 32 > 24785 HEADER Cycle 598 tail 598:024805 len 224 ops 5 > 24787 HEADER Cycle 598 tail 598:024817 len 224 ops 5 > 24789 HEADER Cycle 598 tail 598:024819 len 10656 ops 64 > 24811 HEADER Cycle 598 tail 598:024821 len 224 ops 5 > 24813 HEADER Cycle 598 tail 598:024843 len 224 ops 5 > 24815 HEADER Cycle 598 tail 598:024845 len 17264 ops 96 > 24850 HEADER Cycle 598 tail 598:024847 len 224 ops 5 > 24852 HEADER Cycle 598 tail 598:024882 len 224 ops 5 > 24854 HEADER Cycle 598 tail 598:024884 len 2408 ops 16 > 24860 HEADER Cycle 598 tail 598:024886 len 224 ops 5 > 24862 HEADER Cycle 598 tail 598:024892 len 224 ops 5 > 24864 HEADER Cycle 598 tail 598:024894 len 2920 ops 16 > 24871 HEADER Cycle 598 tail 598:024896 len 224 ops 5 > 24873 HEADER Cycle 598 tail 598:024903 len 224 ops 5 > 24875 HEADER Cycle 598 tail 598:024905 len 2280 ops 16 > 24881 HEADER Cycle 598 tail 598:024907 len 224 ops 5 > 24883 HEADER Cycle 598 tail 598:024913 len 224 ops 5 > 24885 HEADER Cycle 598 tail 598:024915 len 2920 ops 16 > 24892 HEADER Cycle 598 tail 598:024917 len 224 ops 5 > 24894 HEADER Cycle 598 tail 598:024924 len 224 ops 5 > 24896 HEADER Cycle 598 tail 598:024926 len 2536 ops 16 > 24902 HEADER Cycle 598 tail 598:024928 len 224 ops 5 > 24904 HEADER Cycle 598 tail 598:024934 len 224 ops 5 > 24906 HEADER Cycle 598 tail 598:024936 len 2792 ops 16 > 24913 HEADER Cycle 598 tail 598:024938 len 224 ops 5 > 24915 HEADER Cycle 598 tail 598:024945 len 224 ops 5 > 24917 HEADER Cycle 598 tail 598:024947 len 2536 ops 16 > 24923 HEADER Cycle 598 tail 598:024949 len 224 ops 5 > 24925 HEADER Cycle 598 tail 598:024955 len 224 ops 5 > 24927 HEADER Cycle 598 tail 598:024957 len 2408 ops 16 > 24933 HEADER Cycle 598 tail 598:024959 len 224 ops 5 > 24935 HEADER Cycle 598 tail 598:024965 len 224 ops 5 > 24937 HEADER Cycle 598 tail 598:024967 len 3048 ops 16 > 24944 HEADER Cycle 598 tail 598:024969 len 224 ops 5 > 24946 HEADER Cycle 598 tail 598:024976 len 224 ops 5 > 24948 HEADER Cycle 598 tail 598:024978 len 2664 ops 16 > 24955 HEADER Cycle 598 tail 598:024980 len 224 ops 5 > 24957 HEADER Cycle 598 tail 598:024987 len 224 ops 5 > 24959 HEADER Cycle 598 tail 598:024989 len 2280 ops 16 > 24965 HEADER Cycle 598 tail 598:024991 len 224 ops 5 > 24967 HEADER Cycle 598 tail 598:024997 len 224 ops 5 > 24969 HEADER Cycle 598 tail 598:024999 len 2792 ops 16 > 24976 HEADER Cycle 598 tail 598:025001 len 224 ops 5 > 24978 HEADER Cycle 598 tail 598:025008 len 224 ops 5 > 24980 HEADER Cycle 598 tail 598:025010 len 2408 ops 16 > 24986 HEADER Cycle 598 tail 598:025012 len 224 ops 5 > 24988 HEADER Cycle 598 tail 598:025018 len 224 ops 5 > 24990 HEADER Cycle 598 tail 598:025020 len 3176 ops 16 > 24998 HEADER Cycle 598 tail 598:025022 len 224 ops 5 > 25000 HEADER Cycle 598 tail 598:025030 len 224 ops 5 > 25002 HEADER Cycle 598 tail 598:025032 len 2920 ops 16 > 25009 HEADER Cycle 598 tail 598:025034 len 224 ops 5 > 25011 HEADER Cycle 598 tail 598:025041 len 224 ops 5 > 25013 HEADER Cycle 598 tail 598:025043 len 3048 ops 16 > 25020 HEADER Cycle 598 tail 598:025045 len 224 ops 5 > 25022 HEADER Cycle 598 tail 598:025052 len 224 ops 5 > 25024 HEADER Cycle 598 tail 598:025054 len 5840 ops 32 > 25037 HEADER Cycle 598 tail 598:025056 len 224 ops 5 > 25039 HEADER Cycle 598 tail 598:025069 len 224 ops 5 > 25041 HEADER Cycle 598 tail 598:025071 len 8132 ops 19 > 25058 HEADER Cycle 598 tail 598:025073 len 224 ops 5 > 25060 HEADER Cycle 598 tail 598:025090 len 224 ops 5 > 25062 HEADER Cycle 598 tail 598:025092 len 996 ops 14 > 25065 HEADER Cycle 598 tail 598:025094 len 224 ops 5 > 25067 HEADER Cycle 598 tail 598:025097 len 224 ops 5 > 25069 HEADER Cycle 598 tail 598:025099 len 996 ops 14 > 25072 HEADER Cycle 598 tail 598:025101 len 224 ops 5 > 25074 HEADER Cycle 598 tail 598:025104 len 224 ops 5 > 25076 HEADER Cycle 598 tail 598:025106 len 996 ops 14 > 25079 HEADER Cycle 598 tail 598:025108 len 224 ops 5 > 25081 HEADER Cycle 598 tail 598:025111 len 224 ops 5 > 25083 HEADER Cycle 598 tail 598:025113 len 996 ops 14 > 25086 HEADER Cycle 598 tail 598:025115 len 224 ops 5 > 25088 HEADER Cycle 598 tail 598:025118 len 224 ops 5 > 25090 HEADER Cycle 598 tail 598:025120 len 996 ops 14 > 25093 HEADER Cycle 598 tail 598:025122 len 224 ops 5 > 25095 HEADER Cycle 598 tail 598:025125 len 224 ops 5 > 25097 HEADER Cycle 598 tail 598:025127 len 996 ops 14 > 25100 HEADER Cycle 598 tail 598:025129 len 224 ops 5 > 25102 HEADER Cycle 598 tail 598:025132 len 224 ops 5 > 25104 HEADER Cycle 598 tail 598:025134 len 996 ops 14 > 25107 HEADER Cycle 598 tail 598:025136 len 224 ops 5 > 25109 HEADER Cycle 598 tail 598:025139 len 224 ops 5 > 25111 HEADER Cycle 598 tail 598:025141 len 996 ops 14 > 25114 HEADER Cycle 598 tail 598:025143 len 224 ops 5 > 25116 HEADER Cycle 598 tail 598:025146 len 224 ops 5 > 25118 HEADER Cycle 598 tail 598:025148 len 996 ops 14 > 25121 HEADER Cycle 598 tail 598:025150 len 224 ops 5 > 25123 HEADER Cycle 598 tail 598:025153 len 224 ops 5 > 25125 HEADER Cycle 598 tail 598:025155 len 996 ops 14 > 25128 HEADER Cycle 598 tail 598:025157 len 224 ops 5 > 25130 HEADER Cycle 598 tail 598:025160 len 224 ops 5 > 25132 HEADER Cycle 598 tail 598:025162 len 996 ops 14 > 25135 HEADER Cycle 598 tail 598:025164 len 224 ops 5 > 25137 HEADER Cycle 598 tail 598:025167 len 224 ops 5 > 25139 HEADER Cycle 598 tail 598:025169 len 996 ops 14 > 25142 HEADER Cycle 598 tail 598:025171 len 224 ops 5 > 25144 HEADER Cycle 598 tail 598:025174 len 224 ops 5 > 25146 HEADER Cycle 598 tail 598:025176 len 996 ops 14 > 25149 HEADER Cycle 598 tail 598:025178 len 224 ops 5 > 25151 HEADER Cycle 598 tail 598:025181 len 224 ops 5 > 25153 HEADER Cycle 598 tail 598:025183 len 996 ops 14 > 25156 HEADER Cycle 598 tail 598:025185 len 224 ops 5 > 25158 HEADER Cycle 598 tail 598:025188 len 224 ops 5 > 25160 HEADER Cycle 598 tail 598:025190 len 996 ops 14 > 25163 HEADER Cycle 598 tail 598:025192 len 224 ops 5 > 25165 HEADER Cycle 598 tail 598:025195 len 224 ops 5 > 25167 HEADER Cycle 598 tail 598:025197 len 996 ops 14 > 25170 HEADER Cycle 598 tail 598:025199 len 224 ops 5 > 25172 HEADER Cycle 598 tail 598:025202 len 224 ops 5 > 25174 HEADER Cycle 598 tail 598:025204 len 996 ops 14 > 25177 HEADER Cycle 598 tail 598:025206 len 224 ops 5 > 25179 HEADER Cycle 598 tail 598:025209 len 224 ops 5 > 25181 HEADER Cycle 598 tail 598:025211 len 996 ops 14 > 25184 HEADER Cycle 598 tail 598:025213 len 224 ops 5 > 25186 HEADER Cycle 598 tail 598:025216 len 224 ops 5 > 25188 HEADER Cycle 598 tail 598:025218 len 996 ops 14 > 25191 HEADER Cycle 598 tail 598:025220 len 224 ops 5 > 25193 HEADER Cycle 598 tail 598:025223 len 224 ops 5 > 25195 HEADER Cycle 598 tail 598:025225 len 996 ops 14 > 25198 HEADER Cycle 598 tail 598:025227 len 224 ops 5 > 25200 HEADER Cycle 598 tail 598:025230 len 224 ops 5 > 25202 HEADER Cycle 598 tail 598:025232 len 996 ops 14 > 25205 HEADER Cycle 598 tail 598:025234 len 224 ops 5 > 25207 HEADER Cycle 598 tail 598:025237 len 224 ops 5 > 25209 HEADER Cycle 598 tail 598:025239 len 996 ops 14 > 25212 HEADER Cycle 598 tail 598:025241 len 224 ops 5 > 25214 HEADER Cycle 598 tail 598:025244 len 224 ops 5 > 25216 HEADER Cycle 598 tail 598:025246 len 996 ops 14 > 25219 HEADER Cycle 598 tail 598:025248 len 224 ops 5 > 25221 HEADER Cycle 598 tail 598:025251 len 224 ops 5 > 25223 HEADER Cycle 598 tail 598:025253 len 996 ops 14 > 25226 HEADER Cycle 598 tail 598:025255 len 224 ops 5 > 25228 HEADER Cycle 598 tail 598:025258 len 224 ops 5 > 25230 HEADER Cycle 598 tail 598:025260 len 996 ops 14 > 25233 HEADER Cycle 598 tail 598:025262 len 224 ops 5 > 25235 HEADER Cycle 598 tail 598:025265 len 224 ops 5 > 25237 HEADER Cycle 598 tail 598:025267 len 996 ops 14 > 25240 HEADER Cycle 598 tail 598:025269 len 224 ops 5 > 25242 HEADER Cycle 598 tail 598:025272 len 224 ops 5 > 25244 HEADER Cycle 598 tail 598:025274 len 996 ops 14 > 25247 HEADER Cycle 598 tail 598:025276 len 224 ops 5 > 25249 HEADER Cycle 598 tail 598:025279 len 224 ops 5 > 25251 HEADER Cycle 598 tail 598:025281 len 996 ops 14 > 25254 HEADER Cycle 598 tail 598:025283 len 224 ops 5 > 25256 HEADER Cycle 598 tail 598:025286 len 224 ops 5 > 25258 HEADER Cycle 598 tail 598:025288 len 996 ops 14 > 25261 HEADER Cycle 598 tail 598:025290 len 224 ops 5 > 25263 HEADER Cycle 598 tail 598:025293 len 224 ops 5 > 25265 HEADER Cycle 598 tail 598:025295 len 996 ops 14 > 25268 HEADER Cycle 598 tail 598:025297 len 224 ops 5 > 25270 HEADER Cycle 598 tail 598:025300 len 224 ops 5 > 25272 HEADER Cycle 598 tail 598:025302 len 996 ops 14 > 25275 HEADER Cycle 598 tail 598:025304 len 224 ops 5 > 25277 HEADER Cycle 598 tail 598:025307 len 224 ops 5 > 25279 HEADER Cycle 598 tail 598:025309 len 996 ops 14 > 25282 HEADER Cycle 598 tail 598:025311 len 224 ops 5 > 25284 HEADER Cycle 598 tail 598:025314 len 224 ops 5 > 25286 HEADER Cycle 598 tail 598:025316 len 996 ops 14 > 25289 HEADER Cycle 598 tail 598:025318 len 224 ops 5 > 25291 HEADER Cycle 598 tail 598:025321 len 224 ops 5 > 25293 HEADER Cycle 598 tail 598:025323 len 996 ops 14 > 25296 HEADER Cycle 598 tail 598:025325 len 224 ops 5 > 25298 HEADER Cycle 598 tail 598:025328 len 224 ops 5 > 25300 HEADER Cycle 598 tail 598:025330 len 996 ops 14 > 25303 HEADER Cycle 598 tail 598:025332 len 224 ops 5 > 25305 HEADER Cycle 598 tail 598:025335 len 224 ops 5 > 25307 HEADER Cycle 598 tail 598:025337 len 996 ops 14 > 25310 HEADER Cycle 598 tail 598:025339 len 224 ops 5 > 25312 HEADER Cycle 598 tail 598:025342 len 224 ops 5 > 25314 HEADER Cycle 598 tail 598:025344 len 996 ops 14 > 25317 HEADER Cycle 598 tail 598:025346 len 224 ops 5 > 25319 HEADER Cycle 598 tail 598:025349 len 224 ops 5 > 25321 HEADER Cycle 598 tail 598:025351 len 996 ops 14 > 25324 HEADER Cycle 598 tail 598:025353 len 224 ops 5 > 25326 HEADER Cycle 598 tail 598:025356 len 224 ops 5 > 25328 HEADER Cycle 598 tail 598:025358 len 996 ops 14 > 25331 HEADER Cycle 598 tail 598:025360 len 224 ops 5 > 25333 HEADER Cycle 598 tail 598:025363 len 224 ops 5 > 25335 HEADER Cycle 598 tail 598:025365 len 996 ops 14 > 25338 HEADER Cycle 598 tail 598:025367 len 224 ops 5 > 25340 HEADER Cycle 598 tail 598:025370 len 224 ops 5 > 25342 HEADER Cycle 598 tail 598:025372 len 996 ops 14 > 25345 HEADER Cycle 598 tail 598:025374 len 224 ops 5 > 25347 HEADER Cycle 598 tail 598:025377 len 224 ops 5 > 25349 HEADER Cycle 598 tail 598:025379 len 996 ops 14 > 25352 HEADER Cycle 598 tail 598:025381 len 224 ops 5 > 25354 HEADER Cycle 598 tail 598:025384 len 224 ops 5 > 25356 HEADER Cycle 598 tail 598:025386 len 996 ops 14 > 25359 HEADER Cycle 598 tail 598:025388 len 224 ops 5 > 25361 HEADER Cycle 598 tail 598:025391 len 224 ops 5 > 25363 HEADER Cycle 598 tail 598:025393 len 996 ops 14 > 25366 HEADER Cycle 598 tail 598:025395 len 224 ops 5 > 25368 HEADER Cycle 598 tail 598:025398 len 224 ops 5 > 25370 HEADER Cycle 598 tail 598:025400 len 996 ops 14 > 25373 HEADER Cycle 598 tail 598:025402 len 224 ops 5 > 25375 HEADER Cycle 598 tail 598:025405 len 224 ops 5 > 25377 HEADER Cycle 598 tail 598:025407 len 996 ops 14 > 25380 HEADER Cycle 598 tail 598:025409 len 224 ops 5 > 25382 HEADER Cycle 598 tail 598:025412 len 224 ops 5 > 25384 HEADER Cycle 598 tail 598:025414 len 996 ops 14 > 25387 HEADER Cycle 598 tail 598:025416 len 224 ops 5 > 25389 HEADER Cycle 598 tail 598:025419 len 224 ops 5 > 25391 HEADER Cycle 598 tail 598:025421 len 996 ops 14 > 25394 HEADER Cycle 598 tail 598:025423 len 224 ops 5 > 25396 HEADER Cycle 598 tail 598:025426 len 224 ops 5 > 25398 HEADER Cycle 598 tail 598:025428 len 996 ops 14 > 25401 HEADER Cycle 598 tail 598:025430 len 224 ops 5 > 25403 HEADER Cycle 598 tail 598:025433 len 224 ops 5 > [00000 - 25405] Cycle 0x00000256 New Cycle 0x00000255 > 25420 HEADER Cycle 597 tail 597:025329 len 32256 ops 133 > 25484 HEADER Cycle 597 tail 597:025329 len 32256 ops 112 > 25548 HEADER Cycle 597 tail 597:025329 len 32256 ops 101 > 25612 HEADER Cycle 597 tail 597:025329 len 32256 ops 97 > 25676 HEADER Cycle 597 tail 597:025329 len 32256 ops 78 > 25740 HEADER Cycle 597 tail 597:025329 len 32256 ops 122 > 25804 HEADER Cycle 597 tail 597:025329 len 32256 ops 123 > 25868 HEADER Cycle 597 tail 597:025388 len 32256 ops 64 > 25932 HEADER Cycle 597 tail 597:025388 len 32256 ops 74 > 25996 HEADER Cycle 597 tail 597:025388 len 32256 ops 157 > 26060 HEADER Cycle 597 tail 597:025388 len 32252 ops 138 > 26124 HEADER Cycle 597 tail 597:025388 len 32256 ops 103 > 26188 HEADER Cycle 597 tail 597:025388 len 32236 ops 195 > 26252 HEADER Cycle 597 tail 597:025388 len 32256 ops 122 > 26316 HEADER Cycle 597 tail 597:025388 len 32256 ops 83 > 26380 HEADER Cycle 597 tail 597:025388 len 32256 ops 121 > 26444 HEADER Cycle 597 tail 597:025388 len 17784 ops 52 > 26480 HEADER Cycle 597 tail 597:025388 len 32256 ops 186 > 26544 HEADER Cycle 597 tail 597:025388 len 32256 ops 143 > 26608 HEADER Cycle 597 tail 597:025388 len 32256 ops 107 > 26672 HEADER Cycle 597 tail 597:025388 len 32256 ops 101 > 26736 HEADER Cycle 597 tail 597:025388 len 32256 ops 110 > 26800 HEADER Cycle 597 tail 597:025388 len 32256 ops 107 > 26864 HEADER Cycle 597 tail 597:025388 len 32256 ops 110 > 26928 HEADER Cycle 597 tail 597:025388 len 32256 ops 115 > 26992 HEADER Cycle 597 tail 597:025388 len 32256 ops 138 > 27056 HEADER Cycle 597 tail 597:025388 len 32256 ops 92 > 27120 HEADER Cycle 597 tail 597:025388 len 300 ops 4 > 27122 HEADER Cycle 597 tail 597:027088 len 32256 ops 160 > 27186 HEADER Cycle 597 tail 597:027088 len 32256 ops 166 > 27250 HEADER Cycle 597 tail 597:027088 len 32256 ops 158 > 27314 HEADER Cycle 597 tail 597:027088 len 32256 ops 98 > 27378 HEADER Cycle 597 tail 597:027154 len 32256 ops 123 > 27442 HEADER Cycle 597 tail 597:027154 len 32256 ops 171 > 27506 HEADER Cycle 597 tail 597:027154 len 32256 ops 106 > 27570 HEADER Cycle 597 tail 597:027154 len 32256 ops 105 > 27634 HEADER Cycle 597 tail 597:027154 len 11628 ops 27 > 27658 HEADER Cycle 597 tail 597:027666 len 32256 ops 112 > 27722 HEADER Cycle 597 tail 597:027666 len 32256 ops 145 > 27786 HEADER Cycle 597 tail 597:027666 len 32256 ops 93 > 27850 HEADER Cycle 597 tail 597:027666 len 32256 ops 81 > 27914 HEADER Cycle 597 tail 597:027666 len 32256 ops 88 > 27978 HEADER Cycle 597 tail 597:027666 len 32256 ops 96 > 28042 HEADER Cycle 597 tail 597:027666 len 32256 ops 128 > 28106 HEADER Cycle 597 tail 597:027666 len 32256 ops 106 > 28170 HEADER Cycle 597 tail 597:027690 len 32256 ops 81 > 28234 HEADER Cycle 597 tail 597:027690 len 32256 ops 95 > 28298 HEADER Cycle 597 tail 597:027690 len 32248 ops 108 > 28362 HEADER Cycle 597 tail 597:027690 len 32256 ops 158 > 28426 HEADER Cycle 597 tail 597:027690 len 32256 ops 128 > 28490 HEADER Cycle 597 tail 597:027690 len 32244 ops 151 > 28554 HEADER Cycle 597 tail 597:027690 len 32256 ops 142 > 28618 HEADER Cycle 597 tail 597:027690 len 32256 ops 131 > 28682 HEADER Cycle 597 tail 597:027690 len 32256 ops 87 > 28746 HEADER Cycle 597 tail 597:027690 len 32256 ops 77 > 28810 HEADER Cycle 597 tail 597:027690 len 32256 ops 83 > 28874 HEADER Cycle 597 tail 597:027690 len 32256 ops 96 > 28938 HEADER Cycle 597 tail 597:027690 len 32256 ops 61 > 29002 HEADER Cycle 597 tail 597:027690 len 32256 ops 81 > 29066 HEADER Cycle 597 tail 597:027690 len 32256 ops 82 > 29130 HEADER Cycle 597 tail 597:027690 len 32256 ops 67 > 29194 HEADER Cycle 597 tail 597:027690 len 30676 ops 99 > 29255 HEADER Cycle 597 tail 597:029226 len 32256 ops 118 > 29319 HEADER Cycle 597 tail 597:029226 len 32256 ops 127 > 29383 HEADER Cycle 597 tail 597:029226 len 32256 ops 151 > 29447 HEADER Cycle 597 tail 597:029287 len 32244 ops 115 > 29511 HEADER Cycle 597 tail 597:029287 len 32256 ops 86 > 29575 HEADER Cycle 597 tail 597:029287 len 32256 ops 98 > 29639 HEADER Cycle 597 tail 597:029287 len 32256 ops 110 > 29703 HEADER Cycle 597 tail 597:029287 len 32256 ops 159 > 29767 HEADER Cycle 597 tail 597:029287 len 32256 ops 138 > 29831 HEADER Cycle 597 tail 597:029287 len 32256 ops 149 > 29895 HEADER Cycle 597 tail 597:029287 len 32256 ops 99 > 29959 HEADER Cycle 597 tail 597:029287 len 32256 ops 98 > 30023 HEADER Cycle 597 tail 597:029287 len 32256 ops 85 > 30087 HEADER Cycle 597 tail 597:029287 len 32256 ops 73 > 30151 HEADER Cycle 597 tail 597:029287 len 32256 ops 83 > 30215 HEADER Cycle 597 tail 597:029287 len 32256 ops 129 > 30279 HEADER Cycle 597 tail 597:029287 len 32256 ops 98 > 30343 HEADER Cycle 597 tail 597:029287 len 32256 ops 209 > 30407 HEADER Cycle 597 tail 597:029287 len 17304 ops 100 > 30442 HEADER Cycle 597 tail 597:029287 len 32256 ops 129 > 30506 HEADER Cycle 597 tail 597:029287 len 32256 ops 139 > 30570 HEADER Cycle 597 tail 597:029287 len 14436 ops 53 > 30600 HEADER Cycle 597 tail 597:030474 len 32256 ops 110 > 30664 HEADER Cycle 597 tail 597:030474 len 32256 ops 113 > 30728 HEADER Cycle 597 tail 597:030474 len 32256 ops 135 > 30792 HEADER Cycle 597 tail 597:030474 len 32256 ops 129 > 30856 HEADER Cycle 597 tail 597:030474 len 32256 ops 123 > 30920 HEADER Cycle 597 tail 597:030474 len 32256 ops 83 > 30984 HEADER Cycle 597 tail 597:030474 len 32256 ops 105 > 31048 HEADER Cycle 597 tail 597:030474 len 32256 ops 90 > 31112 HEADER Cycle 597 tail 597:030474 len 32256 ops 87 > 31176 HEADER Cycle 597 tail 597:030696 len 22356 ops 48 > 31221 HEADER Cycle 597 tail 597:031208 len 32256 ops 99 > 31285 HEADER Cycle 597 tail 597:031208 len 32256 ops 97 > 31349 HEADER Cycle 597 tail 597:031208 len 32256 ops 105 > 31413 HEADER Cycle 597 tail 597:031208 len 32256 ops 116 > 31477 HEADER Cycle 597 tail 597:031208 len 32256 ops 118 > 31541 HEADER Cycle 597 tail 597:031208 len 32256 ops 111 > 31605 HEADER Cycle 597 tail 597:031253 len 32256 ops 144 > 31669 HEADER Cycle 597 tail 597:031253 len 32256 ops 115 > 31733 HEADER Cycle 597 tail 597:031253 len 32256 ops 121 > 31797 HEADER Cycle 597 tail 597:031253 len 32256 ops 105 > 31861 HEADER Cycle 597 tail 597:031253 len 32256 ops 85 > 31925 HEADER Cycle 597 tail 597:031253 len 32256 ops 106 > 31989 HEADER Cycle 597 tail 597:031253 len 32256 ops 151 > 32053 HEADER Cycle 597 tail 597:031253 len 32256 ops 106 > 32117 HEADER Cycle 597 tail 597:031253 len 32256 ops 124 > 32181 HEADER Cycle 597 tail 597:031253 len 32256 ops 91 > 32245 HEADER Cycle 597 tail 597:031253 len 32256 ops 120 > 32309 HEADER Cycle 597 tail 597:031253 len 32256 ops 179 > 32373 HEADER Cycle 597 tail 597:031253 len 32256 ops 103 > 32437 HEADER Cycle 597 tail 597:031253 len 32256 ops 63 > 32501 HEADER Cycle 597 tail 597:031253 len 32256 ops 63 > 32565 HEADER Cycle 597 tail 597:031253 len 32256 ops 77 > 32629 HEADER Cycle 597 tail 597:031253 len 32256 ops 73 > 32693 HEADER Cycle 597 tail 597:031253 len 32256 ops 100 > 32757 HEADER Cycle 597 tail 597:031253 len 32256 ops 70 > 32821 HEADER Cycle 597 tail 597:031253 len 32256 ops 81 > 32885 HEADER Cycle 597 tail 597:031253 len 32256 ops 87 > 32949 HEADER Cycle 597 tail 597:031253 len 32256 ops 104 > 33013 HEADER Cycle 597 tail 597:031253 len 1384 ops 4 > 33017 HEADER Cycle 597 tail 597:032981 len 32256 ops 89 > 33081 HEADER Cycle 597 tail 597:032981 len 32256 ops 120 > 33145 HEADER Cycle 597 tail 597:032981 len 32256 ops 103 > 33209 HEADER Cycle 597 tail 597:032981 len 32256 ops 125 > 33273 HEADER Cycle 597 tail 597:033049 len 32256 ops 131 > 33337 HEADER Cycle 597 tail 597:033049 len 32256 ops 136 > 33401 HEADER Cycle 597 tail 597:033049 len 32256 ops 138 > 33465 HEADER Cycle 597 tail 597:033049 len 32256 ops 150 > 33529 HEADER Cycle 597 tail 597:033049 len 32256 ops 98 > 33593 HEADER Cycle 597 tail 597:033049 len 23320 ops 94 > 33640 HEADER Cycle 597 tail 597:033625 len 32256 ops 100 > 33704 HEADER Cycle 597 tail 597:033625 len 32256 ops 98 > 33768 HEADER Cycle 597 tail 597:033625 len 32256 ops 131 > 33832 HEADER Cycle 597 tail 597:033625 len 32256 ops 137 > 33896 HEADER Cycle 597 tail 597:033625 len 32256 ops 145 > 33960 HEADER Cycle 597 tail 597:033625 len 32256 ops 114 > 34024 HEADER Cycle 597 tail 597:033625 len 32256 ops 132 > 34088 HEADER Cycle 597 tail 597:033625 len 32256 ops 119 > 34152 HEADER Cycle 597 tail 597:033672 len 21060 ops 119 > 34195 HEADER Cycle 597 tail 597:034184 len 32256 ops 125 > 34259 HEADER Cycle 597 tail 597:034184 len 32256 ops 127 > 34323 HEADER Cycle 597 tail 597:034184 len 32256 ops 68 > 34387 HEADER Cycle 597 tail 597:034184 len 32256 ops 79 > 34451 HEADER Cycle 597 tail 597:034184 len 32256 ops 101 > 34515 HEADER Cycle 597 tail 597:034184 len 32256 ops 100 > 34579 HEADER Cycle 597 tail 597:034184 len 32256 ops 115 > 34643 HEADER Cycle 597 tail 597:034184 len 32256 ops 148 > 34707 HEADER Cycle 597 tail 597:034227 len 32256 ops 147 > 34771 HEADER Cycle 597 tail 597:034227 len 32256 ops 139 > 34835 HEADER Cycle 597 tail 597:034227 len 32256 ops 125 > 34899 HEADER Cycle 597 tail 597:034227 len 32256 ops 138 > 34963 HEADER Cycle 597 tail 597:034227 len 32256 ops 82 > 35027 HEADER Cycle 597 tail 597:034227 len 32256 ops 68 > 35091 HEADER Cycle 597 tail 597:034227 len 32256 ops 73 > 35155 HEADER Cycle 597 tail 597:034227 len 32256 ops 96 > 35219 HEADER Cycle 597 tail 597:034227 len 1848 ops 4 > 35224 HEADER Cycle 597 tail 597:035251 len 32256 ops 114 > 35288 HEADER Cycle 597 tail 597:035251 len 32256 ops 122 > 35352 HEADER Cycle 597 tail 597:035251 len 32256 ops 86 > 35416 HEADER Cycle 597 tail 597:035251 len 32256 ops 85 > 35480 HEADER Cycle 597 tail 597:035251 len 32256 ops 71 > 35544 HEADER Cycle 597 tail 597:035251 len 32256 ops 84 > 35608 HEADER Cycle 597 tail 597:035251 len 32256 ops 152 > 35672 HEADER Cycle 597 tail 597:035256 len 24944 ops 91 > 35722 HEADER Cycle 597 tail 597:035704 len 32256 ops 195 > 35786 HEADER Cycle 597 tail 597:035704 len 32256 ops 91 > 35850 HEADER Cycle 597 tail 597:035704 len 32256 ops 79 > 35914 HEADER Cycle 597 tail 597:035704 len 32256 ops 112 > 35978 HEADER Cycle 597 tail 597:035704 len 32256 ops 133 > 36042 HEADER Cycle 597 tail 597:035754 len 32256 ops 83 > 36106 HEADER Cycle 597 tail 597:035754 len 32256 ops 68 > 36170 HEADER Cycle 597 tail 597:035754 len 32256 ops 85 > 36234 HEADER Cycle 597 tail 597:035754 len 32256 ops 120 > 36298 HEADER Cycle 597 tail 597:035754 len 32256 ops 81 > 36362 HEADER Cycle 597 tail 597:035754 len 32244 ops 106 > 36426 HEADER Cycle 597 tail 597:035754 len 32256 ops 89 > 36490 HEADER Cycle 597 tail 597:035754 len 32256 ops 77 > 36554 HEADER Cycle 597 tail 597:035754 len 32256 ops 95 > 36618 HEADER Cycle 597 tail 597:035754 len 32256 ops 107 > 36682 HEADER Cycle 597 tail 597:035754 len 32256 ops 107 > 36746 HEADER Cycle 597 tail 597:035754 len 32248 ops 100 > 36810 HEADER Cycle 597 tail 597:035754 len 17772 ops 66 > 36846 HEADER Cycle 597 tail 597:036842 len 224 ops 5 > 36848 HEADER Cycle 597 tail 597:036878 len 224 ops 5 > 36850 HEADER Cycle 597 tail 597:036880 len 32256 ops 73 > 36914 HEADER Cycle 597 tail 597:036880 len 32256 ops 134 > 36978 HEADER Cycle 597 tail 597:036880 len 32256 ops 131 > 37042 HEADER Cycle 597 tail 597:036880 len 32256 ops 91 > 37106 HEADER Cycle 597 tail 597:036880 len 32256 ops 139 > 37170 HEADER Cycle 597 tail 597:036880 len 32256 ops 124 > 37234 HEADER Cycle 597 tail 597:036880 len 32256 ops 174 > 37298 HEADER Cycle 597 tail 597:036880 len 32256 ops 92 > 37362 HEADER Cycle 597 tail 597:036882 len 32256 ops 117 > 37426 HEADER Cycle 597 tail 597:036946 len 32256 ops 104 > 37490 HEADER Cycle 597 tail 597:036946 len 32244 ops 84 > 37554 HEADER Cycle 597 tail 597:036946 len 32256 ops 71 > 37618 HEADER Cycle 597 tail 597:036946 len 32256 ops 173 > 37682 HEADER Cycle 597 tail 597:036946 len 32244 ops 87 > 37746 HEADER Cycle 597 tail 597:036946 len 32256 ops 83 > 37810 HEADER Cycle 597 tail 597:036946 len 32256 ops 93 > 37874 HEADER Cycle 597 tail 597:036946 len 32256 ops 134 > 37938 HEADER Cycle 597 tail 597:036946 len 32252 ops 110 > 38002 HEADER Cycle 597 tail 597:036946 len 32248 ops 155 > 38066 HEADER Cycle 597 tail 597:036946 len 32252 ops 123 > 38130 HEADER Cycle 597 tail 597:036946 len 32256 ops 78 > 38194 HEADER Cycle 597 tail 597:036946 len 32256 ops 60 > 38258 HEADER Cycle 597 tail 597:036946 len 32256 ops 78 > 38322 HEADER Cycle 597 tail 597:036946 len 32256 ops 75 > 38386 HEADER Cycle 597 tail 597:036946 len 32256 ops 60 > 38450 HEADER Cycle 597 tail 597:036946 len 32256 ops 122 > 38514 HEADER Cycle 597 tail 597:036946 len 32256 ops 123 > 38578 HEADER Cycle 597 tail 597:036946 len 32256 ops 112 > 38642 HEADER Cycle 597 tail 597:036946 len 32256 ops 133 > 38706 HEADER Cycle 597 tail 597:036946 len 32256 ops 156 > 38770 HEADER Cycle 597 tail 597:036946 len 32256 ops 101 > 38834 HEADER Cycle 597 tail 597:036946 len 32256 ops 145 > [25405 - 38888] Cycle 0x00000255 New Cycle 0x00000000 > root@quartz:~ # > -=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Well, that confirms why it won't replay. There shouldn't be a cycle# change from 597 to zero. This actually shows the cycle#s at the log record headers (not all the sector cycle#s). At the end we are writing out full iclog buffers of 32k each. Hence the length of 32256 and 64 BBs (32k) between the headers. Now at the end, we would expect... 38834 .. 38834+64=38898 of cycle#s of 597 for that log record. But at 38889 it goes to zero cycle#. So that log record is corrupted at around 54 BBs (27K into the 32K). And then for the last (38920-38888 = 32) BBs (16K) of the log we don't find a log record header. I would expect the log head to be at the cycle# change from 598->597. > 25398 HEADER Cycle 598 tail 598:025428 len 996 ops 14 > 25401 HEADER Cycle 598 tail 598:025430 len 224 ops 5 > 25403 HEADER Cycle 598 tail 598:025433 len 224 ops 5 <--- head > [00000 - 25405] Cycle 0x00000256 New Cycle 0x00000255 > 25420 HEADER Cycle 597 tail 597:025329 len 32256 ops 133 > 25484 HEADER Cycle 597 tail 597:025329 len 32256 ops 112 > 25548 HEADER Cycle 597 tail 597:025329 len 32256 ops 101 ie. the last LR written at 598:25403. I was surprised to see the tail at the time at 598:25433, as that makes the tail into the future. That looks weird to me. Or perhaps I'm missing something. If there's corruption that was not between the tail to the head, then it could be a goer I guess but one would wonder about corruption beyond the end of the log too. But the tail looks weird. OOI, can you save the log, compress it and send it to me. $ xfs_logprint -C savedlog /dev/sdb $ gzip savedlog etc.. --Tim From owner-xfs@oss.sgi.com Wed Dec 19 20:58:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 20:58: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=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBK4vuhW029367 for ; Wed, 19 Dec 2007 20:58:03 -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 PAA22986; Thu, 20 Dec 2007 15:58:04 +1100 Message-ID: <4769F71C.3090802@sgi.com> Date: Thu, 20 Dec 2007 16:01:16 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-dev , xfs-oss Subject: Re: [review please] Re: Important regression with XFS update for 2.6.24-rc6 References: <20071218112804.GA3069@localhost.localdomain> <20071218122445.GJ4396912@sgi.com> <877ijckrco.fsf@free.fr> <20071218151946.GQ4396912@sgi.com> <20071219104544.GC4612@sgi.com> <20071220015641.GM4612@sgi.com> In-Reply-To: <20071220015641.GM4612@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5185/Wed Dec 19 16:56:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14034 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 Looks good. --Tim David Chinner wrote: > This has run through several iterations of xfsqa now, and it > fixes the reported problem, so can I get a review? > > Cheers, > > Dave. > > On Wed, Dec 19, 2007 at 09:45:44PM +1100, David Chinner wrote: >> On Wed, Dec 19, 2007 at 02:19:47AM +1100, David Chinner wrote: >>> On Tue, Dec 18, 2007 at 03:30:31PM +0100, Damien Wyart wrote: >>>> * David Chinner [071218 13:24]: >>>>> Ok. I haven't noticed anything wrong with directories up to about >>>>> 250,000 files in the last few days. The ls -l I just did on >>>>> a directory with 15000 entries (btree format) used about 5MB of RAM. >>>>> extent format directories appear to work fine as well (tested 500 >>>>> entries). >>>> Ok, nice to know the problem is not so frequent. >>> ..... >>> >>>> I have put the files at http://damien.wyart.free.fr/xfs/ >>>> >>>> strace_xfs_problem.1.gz and strace_xfs_problem.2.gz have been created >>>> with the problematic kernel, and are quite bigger than >>>> strace_xfs_problem.normal.gz, which has been created with the vanilla >>>> rc5-git5. There is also xfs_info. >>> Looks like several getdents() through the directory the getdents() >>> call starts outputting the first files again. It gets to a certain >>> point and always goes back to the beginning. However, it appears to >>> get to the end eventually (without ever getting past the bad offset). >> UML and a bunch of printk's to the rescue. >> >> So we went back to double buffering, which then screwed up the d_off >> of the dirents. I changed the temporary dirents to point to the current >> offset so that filldir got what it expected when filling the user buffer. >> >> Except it appears that it I didn't to initialise the current >> offset for the first dirent read from the temporary buffer so filldir >> occasionally got an uninitialised offset. Can someone pass me a >> brown paper bag, please? >> >> In my local testing, more often than not, that uninitialised offset >> reads as zero which is where the looping comes from. Sometimes it >> points off into wacko-land, which is probably how we eventually get >> the looping terminating before you run out of memory. >> >> That also explains why we haven't seen it - it requires the user buffer >> to fill on the first entry of a backing buffer and so it is largely >> dependent on the pattern of name lengths, page size and filesystem >> block size aligning just right to trigger the problem. >> >> Can you test this patch, Damien? >> >> Cheers, >> >> Dave. >> -- >> Dave Chinner >> Principal Engineer >> SGI Australian Software Group >> >> --- >> fs/xfs/linux-2.6/xfs_file.c | 1 + >> 1 file changed, 1 insertion(+) >> >> Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c >> =================================================================== >> --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2007-12-19 00:26:40.000000000 +1100 >> +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c 2007-12-19 21:26:38.701143555 +1100 >> @@ -348,6 +348,7 @@ xfs_file_readdir( >> >> size = buf.used; >> de = (struct hack_dirent *)buf.dirent; >> + curr_offset = de->offset /* & 0x7fffffff */; >> while (size > 0) { >> if (filldir(dirent, de->name, de->namlen, >> curr_offset & 0x7fffffff, > From owner-xfs@oss.sgi.com Wed Dec 19 21:04:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 21:04: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=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBK54cfU029931 for ; Wed, 19 Dec 2007 21:04:39 -0800 X-ASG-Debug-ID: 1198127088-0f88015f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from email.msoe.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CF7EB4A3182 for ; Wed, 19 Dec 2007 21:04:48 -0800 (PST) Received: from email.msoe.edu (email.msoe.edu [155.92.194.61]) by cuda.sgi.com with ESMTP id FnMKjXEew4HLglGF for ; Wed, 19 Dec 2007 21:04:48 -0800 (PST) Received: from localhost ([155.92.193.21]) by email.msoe.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Dec 2007 23:04:45 -0600 Date: Wed, 19 Dec 2007 23:04:45 -0600 From: "Jonathan C. Detert" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount prob: "log inconsistent or not a log" Subject: Re: mount prob: "log inconsistent or not a log" Message-ID: <20071220050445.GA3212@msoe.edu> References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011601.GU19770@msoe.edu> <4769F343.9040405@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4769F343.9040405@sgi.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 20 Dec 2007 05:04:45.0727 (UTC) FILETIME=[D6A642F0:01C842C5] X-Barracuda-Connect: email.msoe.edu[155.92.194.61] X-Barracuda-Start-Time: 1198127090 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37129 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5185/Wed Dec 19 16:56:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14035 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jonathan.Detert@msoe.edu Precedence: bulk X-list: xfs * Timothy Shimmin [071219 22:43]: > Jonathan C. Detert wrote: > >* Timothy Shimmin [071219 18:53]: > >>Hi Jonathan, -- snip -- > >-- snip -- > > > >>An "xfs_logprint -d /dev/sdb" will show what the cycle#s are > >>and where the log records are. It might give an idea of the > >>extent of the corruption. > > > >Ok. It doesn't enlighten me, but hopefully you or others can take time > >to see it, and maybe it will enlighten you. Here it is: > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >root@quartz:~ # xfs_logprint -d /dev/sdb > xfs_logprint.out > >xfs_logprint: > > data device: 0x810 > > log device: 0x810 daddr: 39859232 length: 38920 > > > >[00000 - 00000] Cycle 0xffffffff New Cycle 0x00000256 > > 12 HEADER Cycle 598 tail 598:000010 len 224 ops 5 -- snip -- > > 38770 HEADER Cycle 597 tail 597:036946 len 32256 ops 101 > > 38834 HEADER Cycle 597 tail 597:036946 len 32256 ops 145 > >[25405 - 38888] Cycle 0x00000255 New Cycle 0x00000000 > >root@quartz:~ # > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Well, that confirms why it won't replay. > There shouldn't be a cycle# change from 597 to zero. > This actually shows the cycle#s at the log record headers > (not all the sector cycle#s). > > At the end we are writing out full iclog buffers of 32k each. > Hence the length of 32256 and 64 BBs (32k) between the headers. > > Now at the end, we would expect... > 38834 .. 38834+64=38898 of cycle#s of 597 for that log record. > But at 38889 it goes to zero cycle#. > So that log record is corrupted at around 54 BBs (27K into the 32K). > > And then for the last (38920-38888 = 32) BBs (16K) of the > log we don't find a log record header. > > I would expect the log head to be at the cycle# change from 598->597. > > > 25398 HEADER Cycle 598 tail 598:025428 len 996 ops 14 > > 25401 HEADER Cycle 598 tail 598:025430 len 224 ops 5 > > 25403 HEADER Cycle 598 tail 598:025433 len 224 ops 5 <--- head > > [00000 - 25405] Cycle 0x00000256 New Cycle 0x00000255 > > 25420 HEADER Cycle 597 tail 597:025329 len 32256 ops 133 > > 25484 HEADER Cycle 597 tail 597:025329 len 32256 ops 112 > > 25548 HEADER Cycle 597 tail 597:025329 len 32256 ops 101 > > ie. the last LR written at 598:25403. > I was surprised to see the tail at the time at 598:25433, > as that makes the tail into the future. > That looks weird to me. Or perhaps I'm missing something. I appreciate your analysis. I'm barely able to track with you, though, so I can't say as to whether you're missing anything. > If there's corruption that was not between the tail to the head, > then it could be a goer I guess but one would wonder about corruption what do you mean by 'goer' - hardware failure? > beyond the end of the log too. But the tail looks weird. > > OOI, can you save the log, compress it and send it to me. yes; will send it off-list, as it's still 2 MB after compression. -- Jon Detert IT Systems Administrator, Milwaukee School of Engineering 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A. -- Never do anything against conscience, even if the state demands it. From owner-xfs@oss.sgi.com Wed Dec 19 21:33:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 21:33:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBK5X6w1031849 for ; Wed, 19 Dec 2007 21:33:12 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA23795; Thu, 20 Dec 2007 16:33:15 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 8F50C58C4C0F; Thu, 20 Dec 2007 16:33:15 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 974905 - Initialise current offset in xfs_file_readdir correctly Message-Id: <20071220053315.8F50C58C4C0F@chook.melbourne.sgi.com> Date: Thu, 20 Dec 2007 16:33:15 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5186/Wed Dec 19 19:38:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14036 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 Initialise current offset in xfs_file_readdir correctly After reading the directory contents into the temporary buffer, we grab each dirent and pass it to filldir witht eh current offset of the dirent. The current offset was not being set for the first dirent in the temporary buffer, which coul dresult in bad offsets being set in the f_pos field result in looping and duplicate entries being returned from readdir. Date: Thu Dec 20 16:32:49 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30282a fs/xfs/linux-2.6/xfs_file.c - 1.161 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.161&r2=text&tr2=1.160&f=h - Initialise the curr_offset correctly for the first dirent in each temp buffer during readdir. From owner-xfs@oss.sgi.com Wed Dec 19 21:42:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 19 Dec 2007 21:42:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBK5gCK9032630 for ; Wed, 19 Dec 2007 21:42:14 -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 QAA23931; Thu, 20 Dec 2007 16:42:20 +1100 Message-ID: <476A017D.2020106@sgi.com> Date: Thu, 20 Dec 2007 16:45:33 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Jonathan C. Detert" CC: xfs@oss.sgi.com Subject: Re: mount prob: "log inconsistent or not a log" References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011601.GU19770@msoe.edu> <4769F343.9040405@sgi.com> <20071220050445.GA3212@msoe.edu> In-Reply-To: <20071220050445.GA3212@msoe.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5186/Wed Dec 19 19:38:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14037 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 Jonathan C. Detert wrote: > >> If there's corruption that was not between the tail to the head, >> then it could be a goer I guess but one would wonder about corruption > > what do you mean by 'goer' - hardware failure? > I was just thinking that if there was corruption just confined to the log but not in the interval between the tail and head then I can't see why theoretically the log can't be replayed. The replay of the log is done from the tail to the head - the other log data is mostly irrelevant in this case AFAICT (I think the failure came with code which is trying to deal with the case with a new filesystem where part of the log is not written to yet so has zero cycle#s - but here we have wrapped 598 times or whatever it was). --Tim From owner-xfs@oss.sgi.com Thu Dec 20 09:55:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 09:55:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBKHtXK6025250 for ; Thu, 20 Dec 2007 09:55:37 -0800 X-ASG-Debug-ID: 1198173345-441100b40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from email.msoe.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 240FCB85A25 for ; Thu, 20 Dec 2007 09:55:45 -0800 (PST) Received: from email.msoe.edu (email.msoe.edu [155.92.194.61]) by cuda.sgi.com with ESMTP id KUc5pDG9OE8kxbuT for ; Thu, 20 Dec 2007 09:55:45 -0800 (PST) Received: from localhost ([155.92.193.21]) by email.msoe.edu with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Dec 2007 11:55:12 -0600 Date: Thu, 20 Dec 2007 11:55:12 -0600 From: "Jonathan C. Detert" To: David Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount prob: "log inconsistent or not a log" Subject: Re: mount prob: "log inconsistent or not a log" Message-ID: <20071220175512.GA6023@msoe.edu> References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011848.GV19770@msoe.edu> <20071220015425.GL4612@sgi.com> <20071220024453.GX19770@msoe.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071220024453.GX19770@msoe.edu> User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 20 Dec 2007 17:55:13.0033 (UTC) FILETIME=[78455F90:01C84331] X-Barracuda-Connect: email.msoe.edu[155.92.194.61] X-Barracuda-Start-Time: 1198173346 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37179 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5191/Thu Dec 20 08:37:36 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14038 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jonathan.Detert@msoe.edu Precedence: bulk X-list: xfs * Jonathan C. Detert [071219 20:44]: > * David Chinner [071219 19:59]: > > On Wed, Dec 19, 2007 at 07:18:48PM -0600, Jonathan C. Detert wrote: > > > * Timothy Shimmin [071219 18:53]: > > > > Hi Jonathan, > > -- snip -- > > > > > Jonathan.Detert@msoe.edu wrote: > > > > >This is what /var/log/messages has to say about the mount attempt: > > > > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS mounting filesystem sdb > > > > >Dec 19 17:42:30 quartz kernel: [ 9701.960000] XFS: Log inconsistent or not > > > > >a log (last==0, first!=1) > > > > > > --snip -- > > > > > > > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > > > > > > Every 512 bytes of the log is stamped with the cycle#. > > > > The cycle# is effectively the number of times the log has wrapped > > > > > > -- snip -- > > > > > > > An "xfs_logprint -d /dev/sdb" will show what the cycle#s are > > > > and where the log records are. It might give an idea of the > > > > extent of the corruption. > > > > > > Something occurred to me to point out: the snapshot from yesterday has > > > the same problem. How can that be? Is is possible that the log has > > > been hosed for some time, and that the problem only reared its head now > > > because I had to remount? I.e. is it possible for an xfs fs to be > > > mounted and used, even while the log is messed up? > > > > No, it should not. I just want to clarify - I mean to ask: Is it possible that an xfs filesystem which is in use by an o.s., last mounted by the o.s. months ago, could have a corrupted log, and yet keep functioning until such time as a remount of it is attempted? I.e. if a log gets corrupted while the f.s. is in use, will anyone notice, until such time as an attempt to remount the f.s. is made? I don't mean to ask: Is it possible to mount an xfs fs whose log is corrupted? Thanks -- Jon Detert IT Systems Administrator, Milwaukee School of Engineering 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A. -- Half a truth is often a great lie. From owner-xfs@oss.sgi.com Thu Dec 20 11:53:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 11:54: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=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBKJrqlg031174 for ; Thu, 20 Dec 2007 11:53:59 -0800 X-ASG-Debug-ID: 1198180444-441b01ca0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from email.msoe.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CA655B8D19A for ; Thu, 20 Dec 2007 11:54:05 -0800 (PST) Received: from email.msoe.edu (email.msoe.edu [155.92.194.61]) by cuda.sgi.com with ESMTP id LHcFtCS2ls8DtpYt for ; Thu, 20 Dec 2007 11:54:05 -0800 (PST) Received: from localhost ([155.92.193.21]) by email.msoe.edu with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Dec 2007 13:54:02 -0600 Date: Thu, 20 Dec 2007 13:54:02 -0600 From: "Jonathan C. Detert" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount prob: "log inconsistent or not a log" Subject: Re: mount prob: "log inconsistent or not a log" Message-ID: <20071220195402.GC6476@msoe.edu> References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011601.GU19770@msoe.edu> <4769F343.9040405@sgi.com> <20071220050445.GA3212@msoe.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071220050445.GA3212@msoe.edu> User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 20 Dec 2007 19:54:02.0561 (UTC) FILETIME=[11CD0310:01C84342] X-Barracuda-Connect: email.msoe.edu[155.92.194.61] X-Barracuda-Start-Time: 1198180445 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37187 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5194/Thu Dec 20 10:31:08 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14039 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jonathan.Detert@msoe.edu Precedence: bulk X-list: xfs * Jonathan C. Detert [071219 23:04]: > * Timothy Shimmin [071219 22:43]: > > Jonathan C. Detert wrote: > > >* Timothy Shimmin [071219 18:53]: > > >>Hi Jonathan, > > -- snip -- > > > >-- snip -- > > > > > >>An "xfs_logprint -d /dev/sdb" will show what the cycle#s are > > >>and where the log records are. It might give an idea of the > > >>extent of the corruption. > > > > > >Ok. It doesn't enlighten me, but hopefully you or others can take time > > >to see it, and maybe it will enlighten you. Here it is: > > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > >root@quartz:~ # xfs_logprint -d /dev/sdb > xfs_logprint.out > > >xfs_logprint: > > > data device: 0x810 > > > log device: 0x810 daddr: 39859232 length: 38920 > > > > > >[00000 - 00000] Cycle 0xffffffff New Cycle 0x00000256 > > > 12 HEADER Cycle 598 tail 598:000010 len 224 ops 5 > > -- snip -- > > > > 38770 HEADER Cycle 597 tail 597:036946 len 32256 ops 101 > > > 38834 HEADER Cycle 597 tail 597:036946 len 32256 ops 145 > > >[25405 - 38888] Cycle 0x00000255 New Cycle 0x00000000 > > >root@quartz:~ # > > >-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > Well, that confirms why it won't replay. > > There shouldn't be a cycle# change from 597 to zero. > > This actually shows the cycle#s at the log record headers > > (not all the sector cycle#s). > > > > At the end we are writing out full iclog buffers of 32k each. > > Hence the length of 32256 and 64 BBs (32k) between the headers. > > > > Now at the end, we would expect... > > 38834 .. 38834+64=38898 of cycle#s of 597 for that log record. > > But at 38889 it goes to zero cycle#. > > So that log record is corrupted at around 54 BBs (27K into the 32K). > > > > And then for the last (38920-38888 = 32) BBs (16K) of the > > log we don't find a log record header. > > > > I would expect the log head to be at the cycle# change from 598->597. > > > > > 25398 HEADER Cycle 598 tail 598:025428 len 996 ops 14 > > > 25401 HEADER Cycle 598 tail 598:025430 len 224 ops 5 > > > 25403 HEADER Cycle 598 tail 598:025433 len 224 ops 5 <--- head > > > [00000 - 25405] Cycle 0x00000256 New Cycle 0x00000255 > > > 25420 HEADER Cycle 597 tail 597:025329 len 32256 ops 133 > > > 25484 HEADER Cycle 597 tail 597:025329 len 32256 ops 112 > > > 25548 HEADER Cycle 597 tail 597:025329 len 32256 ops 101 > > > > ie. the last LR written at 598:25403. > > I was surprised to see the tail at the time at 598:25433, > > as that makes the tail into the future. > > That looks weird to me. Or perhaps I'm missing something. > > If there's corruption that was not between the tail to the head, > > then it could be a goer I guess but one would wonder about corruption > > beyond the end of the log too. But the tail looks weird. Another question: do you think it's worth me trying an xfs_repair with the -L flag: -L Force Log Zeroing. Forces xfs_repair to zero the log even if it is dirty (contains metadata changes). When using this option the filesystem will likely appear to be corrupt, and can cause the loss of user files and/or data. Another observation: if/when I do an fdisk on /dev/sdb, I see this warning message: Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) I never put a paritition table on this disk, so I don't know if that warning is really a concern or not. -- Jon Detert IT Systems Administrator, Milwaukee School of Engineering 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A. -- Never do anything against conscience, even if the state demands it. From owner-xfs@oss.sgi.com Thu Dec 20 16:43:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 16:43:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBL0gtIl023228 for ; Thu, 20 Dec 2007 16:42:59 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28241; Fri, 21 Dec 2007 11:42:59 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 8C12858C4C0F; Fri, 21 Dec 2007 11:42:59 +1100 (EST) Date: Fri, 21 Dec 2007 11:42:59 +1100 To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.24-rc6 User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20071221004259.8C12858C4C0F@chook.melbourne.sgi.com> From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/5195/Thu Dec 20 11:25:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14040 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/linux-2.6/xfs_file.c | 1 + fs/xfs/linux-2.6/xfs_iops.c | 4 +--- 2 files changed, 2 insertions(+), 3 deletions(-) through these commits: commit 4743e0ec1217fd00f57461ebdd7979d31af18700 Author: Lachlan McIlroy Date: Fri Dec 21 11:00:23 2007 +1100 [XFS] Initialise current offset in xfs_file_readdir correctly After reading the directory contents into the temporary buffer, we grab each dirent and pass it to filldir witht eh current offset of the dirent. The current offset was not being set for the first dirent in the temporary buffer, which coul dresult in bad offsets being set in the f_pos field result in looping and duplicate entries being returned from readdir. SGI-PV: 974905 SGI-Modid: xfs-linux-melb:xfs-kern:30282a Signed-off-by: David Chinner Signed-off-by: Tim Shimmin Signed-off-by: Lachlan McIlroy commit bad60fdd14df32459e31cc75ab681e4458bf25cf Author: Christoph Hellwig Date: Fri Dec 21 10:58:56 2007 +1100 [XFS] Fix mknod regression This was broken by my '[XFS] simplify xfs_create/mknod/symlink prototype', which assigned the re-shuffled ondisk dev_t back to the rdev variable in xfs_vn_mknod. Because of that i_rdev is set to the ondisk dev_t instead of the linux dev_t later down the function. Fortunately the fix for it is trivial: we can just remove the assignment because xfs_revalidate_inode has done the proper job before unlocking the inode. SGI-PV: 974873 SGI-Modid: xfs-linux-melb:xfs-kern:30273a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy From owner-xfs@oss.sgi.com Thu Dec 20 16:44:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 16:44:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBL0iHPZ023336 for ; Thu, 20 Dec 2007 16:44:21 -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 LAA28283; Fri, 21 Dec 2007 11:44:22 +1100 Message-ID: <476B0D29.4050504@sgi.com> Date: Fri, 21 Dec 2007 11:47:37 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Jonathan C. Detert" CC: David Chinner , xfs@oss.sgi.com Subject: Re: mount prob: "log inconsistent or not a log" References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011848.GV19770@msoe.edu> <20071220015425.GL4612@sgi.com> <20071220024453.GX19770@msoe.edu> <20071220175512.GA6023@msoe.edu> In-Reply-To: <20071220175512.GA6023@msoe.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5195/Thu Dec 20 11:25:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14041 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 Jonathan C. Detert wrote: > > I just want to clarify - I mean to ask: > > Is it possible that an xfs filesystem which is in use by an o.s., > last mounted by the o.s. months ago, could have a corrupted log, and > yet keep functioning until such time as a remount of it is attempted? > Yes. The log is read on every mount. I don't believe we read it otherwise. On a mount we look for the log head and an unmount record etc. to decide whether to do a replay or not. So it could be corrupted and we would not know and we don't really care until the next mount. However, if we are modifying metadata in the filesystem (with some exceptions) then we will be continuing to write to the log and we will continue to wrap the log. And hence if someone corrupted the log at a point in the past, we may very well be able to overwrite the log and effectively lose that corruption. Do you understand the basic idea? We just write to the log while the file-system is mounted and we are writing to the filesystem (particularly changing metadata); and we read from the log during (just prior) mounting of the filesystem. > I.e. if a log gets corrupted while the f.s. is in use, will anyone > notice, until such time as an attempt to remount the f.s. is made? No I don't think anyone will notice. No-one has cause to read it, so noone cares. If you unmount it cleanly. Run repair on it before mounting it again. Then repair may find corruption when it tries to find the log head etc... to work out if the log is clean or not. i.e. in this case repair will try to read the log before you've tried to do a mount. --Tim From owner-xfs@oss.sgi.com Thu Dec 20 17:55:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 17:55:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBL1tMdT027100 for ; Thu, 20 Dec 2007 17:55:25 -0800 X-ASG-Debug-ID: 1198202135-7fb401e70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from email.msoe.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B911AB8F2AC for ; Thu, 20 Dec 2007 17:55:35 -0800 (PST) Received: from email.msoe.edu (email.msoe.edu [155.92.194.61]) by cuda.sgi.com with ESMTP id n83GoDDegsoLHZFv for ; Thu, 20 Dec 2007 17:55:35 -0800 (PST) Received: from localhost ([155.92.193.21]) by email.msoe.edu with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Dec 2007 19:55:33 -0600 Date: Thu, 20 Dec 2007 19:55:33 -0600 From: "Jonathan C. Detert" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount prob: "log inconsistent or not a log" Subject: Re: mount prob: "log inconsistent or not a log" Message-ID: <20071221015533.GH6476@msoe.edu> References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011848.GV19770@msoe.edu> <20071220015425.GL4612@sgi.com> <20071220024453.GX19770@msoe.edu> <20071220175512.GA6023@msoe.edu> <476B0D29.4050504@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476B0D29.4050504@sgi.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 21 Dec 2007 01:55:33.0874 (UTC) FILETIME=[92D4B520:01C84374] X-Barracuda-Connect: email.msoe.edu[155.92.194.61] X-Barracuda-Start-Time: 1198202135 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37211 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5197/Thu Dec 20 16:32:01 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14042 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jonathan.Detert@msoe.edu Precedence: bulk X-list: xfs * Timothy Shimmin [071220 18:49]: > Jonathan C. Detert wrote: > > > >I just want to clarify - I mean to ask: > > > > Is it possible that an xfs filesystem which is in use by an o.s., > > last mounted by the o.s. months ago, could have a corrupted log, and > > yet keep functioning until such time as a remount of it is attempted? > > > Yes. > The log is read on every mount. I don't believe we read it otherwise. > On a mount we look for the log head and an unmount record etc. to decide > whether to do a replay or not. > So it could be corrupted and we would not know and we don't really care > until the next mount. > However, if we are modifying metadata in the filesystem (with some > exceptions) > then we will be continuing to write to the log and we will continue to > wrap the log. And hence if someone corrupted the log at a point in the past, > we may very well be able to overwrite the log and effectively lose that > corruption. > > Do you understand the basic idea? I think so. > We just write to the log while the file-system is mounted and we are writing > to the filesystem (particularly changing metadata); and > we read from the log during (just prior) mounting of the filesystem. > > > I.e. if a log gets corrupted while the f.s. is in use, will anyone > > notice, until such time as an attempt to remount the f.s. is made? > No I don't think anyone will notice. > No-one has cause to read it, so noone cares. > > If you unmount it cleanly. Run repair on it before mounting it again. > Then repair may find corruption when it tries to find the log head etc... > to work out if the log is clean or not. > i.e. in this case repair will try to read the log before you've tried > to do a mount. So, how do you recover from a situation like i have, namely: 1) the xfs file system is not currently mounted 2) an attempt to mount the xfs fs fails, complaining about log being inconsistent or not a log You say noone cares if the log is corrupt, but it seems to be a fatal problem if you want to mount the fs. Bottom line: how do you recover when trying to remount an xfs fs whose log happens to be corrupt? -- Jon Detert IT Systems Administrator, Milwaukee School of Engineering 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A. -- "Solitary trees, if they grow at all, grow strong." ~ Winston Churchill From owner-xfs@oss.sgi.com Thu Dec 20 18:01:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 18:01: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=3.2 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, J_CHICKENPOX_15,J_CHICKENPOX_45,J_CHICKENPOX_52,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBL20xuJ027609 for ; Thu, 20 Dec 2007 18:01:01 -0800 X-ASG-Debug-ID: 1198202469-536c010c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sc3app27.rit.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7584CB8F306 for ; Thu, 20 Dec 2007 18:01:09 -0800 (PST) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by cuda.sgi.com with ESMTP id DHS7pFKAWusnfcPV for ; Thu, 20 Dec 2007 18:01:09 -0800 (PST) Received: from cias-jpspgd-macbook.jayps.home (cpe-72-230-182-205.rochester.res.rr.com [72.230.182.205]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPSA id <0JTD00953MXVW8@smtp-server.rit.edu> for xfs@oss.sgi.com; Thu, 20 Dec 2007 21:01:09 -0500 (EST) Date: Thu, 20 Dec 2007 21:01:06 -0500 From: Jay Sullivan X-ASG-Orig-Subj: Re: xfs_force_shutdown called from file fs/xfs/xfs_trans_buf.c Subject: Re: xfs_force_shutdown called from file fs/xfs/xfs_trans_buf.c In-reply-to: To: xfs@oss.sgi.com Cc: Jay Sullivan Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.915) X-RIT-Received-From: 72.230.182.205 jpspgd@smtp-server.rit.edu References: X-Barracuda-Connect: sc3app27.rit.edu[129.21.35.56] X-Barracuda-Start-Time: 1198202470 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37211 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5197/Thu Dec 20 16:32:01 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 14522 X-archive-position: 14043 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpspgd@rit.edu Precedence: bulk X-list: xfs I'm still seeing problems. =( Most recently I have copied all of the data off of the suspect XFS volume onto another fresh XFS volume. A few days later I saw the same messages show up in dmesg. I haven't had a catastrophic failure that makes the kernel remount the FS RO, but I don't want to wait for that to happen. Today I upgraded to the latest stable kernel in Gentoo (2.6.23-r3) and I'm still on xfsprogs 2.9.4, also the latest stable release. A few hours after rebooting to load the new kernel, I saw the following in dmesg: #################### attempt to access beyond end of device dm-0: rw=0, want=68609558288793608, limit=8178892800 I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xf3c0079e000000 ("xfs_trans_read_buf") error 5 buf count 4096 attempt to access beyond end of device dm-0: rw=0, want=68609558288793608, limit=8178892800 I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xf3c0079e000000 ("xfs_trans_read_buf") error 5 buf count 4096 attempt to access beyond end of device dm-0: rw=0, want=68609558288793608, limit=8178892800 I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xf3c0079e000000 ("xfs_trans_read_buf") error 5 buf count 4096 attempt to access beyond end of device dm-0: rw=0, want=68609558288793608, limit=8178892800 I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xf3c0079e000000 ("xfs_trans_read_buf") error 5 buf count 4096 ################### These are the same types of messages (trying to access a block that is WAAAY outside of the range of my drives) that I was seeing before the last time my FS got remounted read-only by the colonel. Any ideas? What other information can I gather that would help with troubleshooting? Here are some more specifics: This is a Dell PowerEdge 1850 with a FusionMPT/LSI fibre channel card. The XFS volume is a 3.9TB logical volume in LVM. The volume group is spread across LUNs of a Apple XServe RAIDs which are connected o'er FC to our fabric. I just swapped FC switches (to a different brand even) and the problem was showing before and after the switch switch, so that's not it. I have also swapped FC cards, upgraded FC card firmware, updated BIOSs, etc.. This server sees heavy NFS (v3) and samba (currently 3.0.24 until the current regression bug is squashed and stable) traffic. 'Heavy traffic' means it usually sees 200-300Mbps throughput 24/7, although sometimes more. Far-fetched: Is there any way that a particular file on my FS, when accessed, is causing the problem? I have a very similar system (Dell PE 2650, same FC card, same type of RAID, same SFP cables, same GPT scheme, same kernel) but instead with an ext3 (full journal) FS in a 5.[something]TB logical volume (LVM) with no problems. Oh, and it sees system load values in the mid-20s just about all day. Grasping at straws. I need XFS to work because we'll soon be requiring seriously large filesystems with non-sucky extended attribute and ACL support. Plus it's fast and I like it. Can the XFS community help? I don't want to have to turn to that guy that allegedly killed his wife. =P ~Jay On Nov 14, 2007, at 10:05 AM, Jay Sullivan wrote: > Of course this had to happen one more time before my scheduled > maintenance window... Anyways, here's all of the good stuff I > collected. Can anyone make sense of it? Oh, and I upgraded to > xfsprogs > 2.9.4 last week, so all output you see is with that version. > > Thanks! > > ################### > > dmesg output > > ################### > > XFS internal error XFS_WANT_CORRUPTED_GOTO at line 4533 of file > fs/xfs/xfs_bmap.c. Caller 0xc028c5a2 > [] xfs_bmap_read_extents+0x3bd/0x498 > [] xfs_iread_extents+0x74/0xe1 > [] xfs_iext_realloc_direct+0xa4/0xe7 > [] xfs_iext_add+0x138/0x272 > [] xfs_iread_extents+0x74/0xe1 > [] xfs_bmapi+0x1ca/0x173f > [] elv_rb_add+0x6f/0x88 > [] as_update_rq+0x32/0x72 > [] as_add_request+0x76/0xa4 > [] elv_insert+0xd5/0x142 > [] __make_request+0xc8/0x305 > [] generic_make_request+0x122/0x1d9 > [] __map_bio+0x33/0xa9 > [] __clone_and_map+0xda/0x34c > [] mempool_alloc+0x2a/0xdb > [] xfs_ilock+0x58/0xa0 > [] xfs_iomap+0x216/0x4b7 > [] __xfs_get_blocks+0x6b/0x226 > [] radix_tree_node_alloc+0x16/0x57 > [] radix_tree_insert+0xb0/0x126 > [] xfs_get_blocks+0x28/0x2d > [] block_read_full_page+0x192/0x346 > [] xfs_get_blocks+0x0/0x2d > [] xfs_iget+0x145/0x150 > [] do_mpage_readpage+0x530/0x621 > [] xfs_iunlock+0x43/0x84 > [] xfs_vget+0xe1/0xf2 > [] find_exported_dentry+0x71/0x4b6 > [] __do_page_cache_readahead+0x88/0x153 > [] mpage_readpage+0x4b/0x5e > [] xfs_get_blocks+0x0/0x2d > [] blockable_page_cache_readahead+0x4d/0xb9 > [] page_cache_readahead+0x174/0x1a3 > [] find_get_page+0x18/0x3a > [] do_generic_mapping_read+0x1b5/0x535 > [] __capable+0x8/0x1b > [] generic_file_sendfile+0x68/0x83 > [] nfsd_read_actor+0x0/0x10f > [] xfs_sendfile+0x94/0x164 > [] nfsd_read_actor+0x0/0x10f > [] nfsd_permission+0x6e/0x103 > [] xfs_file_sendfile+0x4c/0x5c > [] nfsd_read_actor+0x0/0x10f > [] nfsd_vfs_read+0x344/0x361 > [] nfsd_read_actor+0x0/0x10f > [] nfsd_read+0xd8/0xf9 > [] nfsd3_proc_read+0xb0/0x174 > [] nfs3svc_decode_readargs+0x0/0xf7 > [] nfsd_dispatch+0x8a/0x1f5 > [] svcauth_unix_set_client+0x11d/0x175 > [] svc_process+0x4fd/0x681 > [] nfsd+0x163/0x273 > [] nfsd+0x0/0x273 > [] kernel_thread_helper+0x7/0x10 > ======================= > attempt to access beyond end of device > dm-1: rw=0, want=6763361770196172808, limit=7759462400 > I/O error in filesystem ("dm-1") meta-data dev dm-1 block > 0x5ddc49b238000000 ("xfs_trans_read_buf") error 5 buf count 4096 > xfs_force_shutdown(dm-1,0x1) called from line 415 of file > fs/xfs/xfs_trans_buf.c. Return address = 0xc02baa25 > Filesystem "dm-1": I/O Error Detected. Shutting down filesystem: dm-1 > Please umount the filesystem, and rectify the problem(s) > > > ####################### > > At this point I umount'ed and mount'ed the FS several times, but > xfs_repair still told me to use -L... Any ideas? > > ####################### > > server-files ~ # umount /mnt/san/ > server-files ~ # mount /mnt/san/ > server-files ~ # umount /mnt/san/ > server-files ~ # xfs_repair > /dev/server-files-sanvg01/server-files-sanlv01 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > ERROR: The filesystem has valuable metadata changes in a log which > needs > to > be replayed. Mount the filesystem to replay the log, and unmount it > before > re-running xfs_repair. If you are unable to mount the filesystem, > then > use > the -L option to destroy the log and attempt a repair. > Note that destroying the log may cause corruption -- please attempt a > mount > of the filesystem before doing this. > server-files ~ # xfs_repair -L > /dev/server-files-sanvg01/server-files-sanlv01 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > ALERT: The filesystem has valuable metadata changes in a log which is > being > destroyed because the -L option was used. > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > 4002: Badness in key lookup (length) > bp=(bno 2561904, len 16384 bytes) key=(bno 2561904, len 8192 bytes) > 8003: Badness in key lookup (length) > bp=(bno 0, len 512 bytes) key=(bno 0, len 4096 bytes) > bad bmap btree ptr 0x5f808b0400000000 in ino 5123809 > bad data fork in inode 5123809 > cleared inode 5123809 > bad magic # 0x58465342 in inode 7480148 (data fork) bmbt block 0 > bad data fork in inode 7480148 > cleared inode 7480148 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - 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 > entry "Fuller_RotoscopeCorrected.mov" at block 0 offset 184 in > directory > inode 8992373 references free inode 7480148 > clearing inode number in entry at offset 184... > Phase 5 - rebuild AG headers and trees... > - reset superblock... > 4000: Badness in key lookup (length) > bp=(bno 0, len 4096 bytes) key=(bno 0, len 512 bytes) > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - traversing filesystem ... > bad hash table for directory inode 8992373 (no data entry): rebuilding > rebuilding directory inode 8992373 > 4000: Badness in key lookup (length) > bp=(bno 0, len 4096 bytes) key=(bno 0, len 512 bytes) > 4000: Badness in key lookup (length) > bp=(bno 0, len 4096 bytes) key=(bno 0, len 512 bytes) > - traversal finished ... > - moving disconnected inodes to lost+found ... > Phase 7 - verify and correct link counts... > 4000: Badness in key lookup (length) > bp=(bno 0, len 4096 bytes) key=(bno 0, len 512 bytes) > done > server-files ~ # mount /mnt/san > server-files ~ # umount /mnt/san > server-files ~ # xfs_repair -L > /dev/server-files-sanvg01/server-files-sanlv01 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > > server-files ~ # xfs_repair > /dev/server-files-sanvg01/server-files-sanlv01 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > XFS: totally zeroed log > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - 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 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - traversing filesystem ... > - traversal finished ... > - moving disconnected inodes to lost+found ... > Phase 7 - verify and correct link counts... > done > > ################ > > So that's it for now. Next week I'll be rsyncing all of the data > off of > this volume to another array. I still want to know what's happening, > though... *pout* > > Anyways, thanks a lot for everyone's help. > > ~Jay > > > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf > Of Jay Sullivan > Sent: Friday, November 02, 2007 10:49 AM > To: xfs@oss.sgi.com > Subject: RE: xfs_force_shutdown called from file fs/xfs/ > xfs_trans_buf.c > > What can I say about Murphy and his silly laws? I just had a drive > fail > on my array. I wonder if this is the root of my problems... Yay > parity. > > ~Jay > > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf > Of Jay Sullivan > Sent: Friday, November 02, 2007 10:00 AM > To: xfs@oss.sgi.com > Subject: RE: xfs_force_shutdown called from file fs/xfs/ > xfs_trans_buf.c > > I lost the xfs_repair output on an xterm with only four lines of > scrollback... I'll definitely be more careful to preserve more > 'evidence' next time. =( "Pics or it didn't happen", right? > > I just upgraded xfsprogs and will scan the disk during my next > scheduled > downtime (probably in about 2 weeks). I'm tempted to just wipe the > volume and start over: I have enough 'spare' space lying around to > copy > everything out to a fresh XFS volume. > > Regarding "areca": I'm using hardware RAID built into Apple XServe > RAIDs o'er LSI FC929X cards. > > Someone else offered the likely explanation that the btree is > corrupted. > Isn't this something xfs_repair should be able to fix? Would it be > easier, safer, and faster to move the data to a new volume (and > restore > corrupted files if/as I find them from backup)? We're talking about > just less than 4TB of data which used to take about 6 hours to fsck > (one > pass) with ext3. Restoring the whole shebang from backups would > probably take the better part of 12 years (waiting for compression, > resetting ACLs, etc.)... > > FWIW, another (way less important,) much busier and significantly > larger > logical volume on the same array has been totally fine. Murphy--go > figure. > > Thanks! > > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sandeen.net] > Sent: Thursday, November 01, 2007 10:30 PM > To: Jay Sullivan > Cc: xfs@oss.sgi.com > Subject: Re: xfs_force_shutdown called from file fs/xfs/ > xfs_trans_buf.c > > Jay Sullivan wrote: >> Good eye: it wasn't mountable, thus the -L flag. No recent >> (unplanned) power outages. The machine and the array that holds the >> disks are both on serious batteries/UPS and the array's cache >> batteries are in good health. > > Did you have the xfs_repair output to see what it found? You might > also > grab the very latest xfsprogs (2.9.4) in case it's catching more > cases. > > I hate it when people suggest running memtest86, but I might do that > anyway. :) > > What controller are you using? If you say "areca" I might be on to > something with some other bugs I've seen... > > -Eric > > > > -- Jay Sullivan PC Systems Administrator College of Imaging Arts and Sciences Rochester Institute of Technology 7A-1320 :: 585.475.4688 -- Privacy at RIT: http://www.rit.edu/privacy/ -- [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Dec 20 21:07:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 21:07: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.9 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, J_CHICKENPOX_33,J_CHICKENPOX_43,J_CHICKENPOX_45,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBL578Gk007072 for ; Thu, 20 Dec 2007 21:07:12 -0800 X-ASG-Debug-ID: 1198213636-2b0002d20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E53CC4AAE90 for ; Thu, 20 Dec 2007 21:07:16 -0800 (PST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by cuda.sgi.com with ESMTP id wF1gsU4RYu4uXcyL for ; Thu, 20 Dec 2007 21:07:16 -0800 (PST) Received: by rv-out-0910.google.com with SMTP id k20so114342rvb.32 for ; Thu, 20 Dec 2007 21:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=+gpsjdz5nzY3VNpF5GsvlnD97JFsVrxFDdmsmOTE+0U=; b=ZGHf1aIVvLB5BfTv+Y9QdTtLFFuo4eNazGBp+GMAguilz12F8tNDgwk9jsCtnZ/Fdc4RMp5VDowEYWAbWxukdDLO1C7d7hht0TEg7qq0lNRDn0PQQDiVZqctZTeb+bqynX+ZyGpFsYdAeLGIvOkwtEaVor89fYBijiddWC2bIBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gcVjFdOUVYnzESMW1moVfRabuEYaBEOaujSs3QKIKmrQ67JCvulU3wUmpNi5beKcQ7OUxX+vBh5oc4sM/X/HsSuT66CPFBBkvl5dTUcaqo1ECTe9XjuP9byViy82XLIZ+U27fynnmaLpcuVUYNrD6w27/gjiKfW8I5VacttsUWY= Received: by 10.142.49.4 with SMTP id w4mr458574wfw.185.1198213634586; Thu, 20 Dec 2007 21:07:14 -0800 (PST) Received: by 10.142.217.12 with HTTP; Thu, 20 Dec 2007 21:07:14 -0800 (PST) Message-ID: Date: Fri, 21 Dec 2007 13:07:14 +0800 From: "Changliang Chen" To: "David Chinner" X-ASG-Orig-Subj: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Subject: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Cc: "Eric Sandeen" , "Alex Madarasz" , xfs@oss.sgi.com In-Reply-To: <20071216233127.GY4612@sgi.com> MIME-Version: 1.0 References: <1197653927.3841.1226620089@webmail.messagingengine.com> <4764AB08.7040608@sandeen.net> <20071216233127.GY4612@sgi.com> X-Barracuda-Connect: rv-out-0910.google.com[209.85.198.191] X-Barracuda-Start-Time: 1198213639 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0154 1.0000 -1.9208 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37224 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5199/Thu Dec 20 18:57:19 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2210 X-archive-position: 14044 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hqucocl@gmail.com Precedence: bulk X-list: xfs Hi We have use xfs for storage's filesystem which has reach 4T per node.inour mkfs option,we always use agsize= 4g.Is this any problem, and any suggest? By the way,how many agcounts the [new] mkfs defaults make? 2007/12/17, David Chinner : > > On Sat, Dec 15, 2007 at 10:35:20PM -0600, Eric Sandeen wrote: > > Alex Madarasz wrote: > > > We're building a new Fedora 8.0.1 Linux system to stream data from a > > > 250Msps ADC to disk, and want to start tuning the system configuration > > > for maximum XFS write performance. To date, without any significant > > > effort at tuning our Fedora 7 dev system, we're seeing 250MBps write > > > with 8-bit samples and ~ 300MBps write with 16-bit samples. We want to > > > push the tuning as far as we can go with this architecture before we > > > start looking at other hardware options. Looking at various other > > > tuning pages on the Web finds few that are interested in maxing out > > > sequential writes to very large arrays while using SAS HW RAID with > big > > > fast SAS drives too. > > > > ... > > > > > XFS Tuning Options? > > > > > > - HW RAID0: > > > - Array/logical disk HW RAID stripe size? > > > > At any rate you'll want to match xfs's geometry with the raid geometry. > > > > > - Cache enabled (some reports that cache s/b turned off?)? > > > > If it's battery-backed cache, leave it on, and disable barriers in xfs > > (it's a mount option) > > > > > - xfs mkfs / mount options? > > > > David mentioned these before as a generic place to start: > > > > # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 > > > > # mount -o logbsize=256k > > > > and that those would be upcoming new defaults for mkfs. > > > > 4 ags may not be what you want for a ~2T filesystem. > > Right - the 4 AG tuning is effectively for single disk configurations to > limit parallelism and therefore keep seeks between AGs down. When you > have multiple disks, the [new] mkfs defaults should be just fine (i.e. > just drop the agcount suggestion). > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > > -- Best Regards [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Dec 20 22:22:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 22:22:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBL6MC1m010772 for ; Thu, 20 Dec 2007 22:22:15 -0800 X-ASG-Debug-ID: 1198218144-334400090000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E34D34AB255 for ; Thu, 20 Dec 2007 22:22:25 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id yFQkxshXKRSF8KEV for ; Thu, 20 Dec 2007 22:22:25 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBL6MIF3023416 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 Dec 2007 07:22:19 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBL6MIGH023414 for xfs@oss.sgi.com; Fri, 21 Dec 2007 07:22:18 +0100 Date: Fri, 21 Dec 2007 07:22:18 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 3/4] stop re-checking permissions in xfs_swapext Subject: [PATCH 3/4] stop re-checking permissions in xfs_swapext Message-ID: <20071221062218.GC23180@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1198218145 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37230 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5203/Thu Dec 20 20:10:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14047 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs xfs_swapext should simplify check if we have a writeable file descriptor instead of re-checking the permissions using xfs_iaccess. Add an additional check to refuse O_APPEND file descriptors because swapext is not an append-only write operation. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_dfrag.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dfrag.c 2007-12-19 16:57:18.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_dfrag.c 2007-12-19 16:57:29.000000000 +0100 @@ -74,12 +74,23 @@ xfs_swapext( goto out_free_sxp; } + if (!(file->f_mode & FMODE_WRITE) || (file->f_flags & O_APPEND)) { + error = XFS_ERROR(EBADF); + goto out_put_file; + } + target_file = fget((int)sxp->sx_fdtmp); if (!target_file) { error = XFS_ERROR(EINVAL); goto out_put_file; } + if (!(target_file->f_mode & FMODE_WRITE) || + (target_file->f_flags & O_APPEND)) { + error = XFS_ERROR(EBADF); + goto out_put_target_file; + } + ip = XFS_I(file->f_path.dentry->d_inode); tip = XFS_I(target_file->f_path.dentry->d_inode); @@ -154,15 +165,6 @@ xfs_swap_extents( xfs_lock_inodes(ips, 2, 0, lock_flags); locked = 1; - /* Check permissions */ - error = xfs_iaccess(ip, S_IWUSR, NULL); - if (error) - goto error0; - - error = xfs_iaccess(tip, S_IWUSR, NULL); - if (error) - goto error0; - /* Verify that both files have the same format */ if ((ip->i_d.di_mode & S_IFMT) != (tip->i_d.di_mode & S_IFMT)) { error = XFS_ERROR(EINVAL); From owner-xfs@oss.sgi.com Thu Dec 20 22:21:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 22:22:02 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBL6Lv2h010721 for ; Thu, 20 Dec 2007 22:21:58 -0800 X-ASG-Debug-ID: 1198218128-71be00520000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 20E00B91473 for ; Thu, 20 Dec 2007 22:22:08 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id PJ5N4d0wgGQMn9Ze for ; Thu, 20 Dec 2007 22:22:08 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBL6M2F3023387 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 Dec 2007 07:22:02 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBL6M2fB023385 for xfs@oss.sgi.com; Fri, 21 Dec 2007 07:22:02 +0100 Date: Fri, 21 Dec 2007 07:22:02 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/4] remove permission check from xfs_change_file_space Subject: [PATCH 1/4] remove permission check from xfs_change_file_space Message-ID: <20071221062202.GA23180@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1198218130 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37229 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5203/Thu Dec 20 20:10:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14045 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Both callers of xfs_change_file_space alreaedy do the file->f_mode & FMODE_WRITE check to ensure we have a file descriptor that has been opened for write mode, so there is no need to re-check that with xfs_iaccess. Especially as the later might wrongly deny it for corner cases like file descriptor passing through unix domain sockets. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-12-19 16:07:57.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-12-19 16:08:19.000000000 +0100 @@ -4311,21 +4311,9 @@ xfs_change_file_space( xfs_itrace_entry(ip); - /* - * must be a regular file and have write permission - */ if (!S_ISREG(ip->i_d.di_mode)) return XFS_ERROR(EINVAL); - xfs_ilock(ip, XFS_ILOCK_SHARED); - - if ((error = xfs_iaccess(ip, S_IWUSR, credp))) { - xfs_iunlock(ip, XFS_ILOCK_SHARED); - return error; - } - - xfs_iunlock(ip, XFS_ILOCK_SHARED); - switch (bf->l_whence) { case 0: /*SEEK_SET*/ break; From owner-xfs@oss.sgi.com Thu Dec 20 22:22:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 22:22:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBL6MKlH010826 for ; Thu, 20 Dec 2007 22:22:23 -0800 X-ASG-Debug-ID: 1198218152-2b03037e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5C1C24AB255 for ; Thu, 20 Dec 2007 22:22:32 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id RPWXjb3RAQh8wlye for ; Thu, 20 Dec 2007 22:22:32 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBL6MQF3023430 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 Dec 2007 07:22:27 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBL6MQXD023428 for xfs@oss.sgi.com; Fri, 21 Dec 2007 07:22:26 +0100 Date: Fri, 21 Dec 2007 07:22:26 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 4/4] use generic_permission Subject: [PATCH 4/4] use generic_permission Message-ID: <20071221062226.GD23180@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1198218153 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37230 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5203/Thu Dec 20 20:10:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14048 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Now that all direct caller of xfs_iaccess are gone we can kill xfs_iaccess and xfs_access and just use generic_permission with a check_acl callback. This is required for the per-mount read-only patchset in -mm to work properly with XFS. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2007-12-19 16:55:36.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2007-12-19 16:57:33.000000000 +0100 @@ -3583,69 +3583,6 @@ xfs_iflush_all( XFS_MOUNT_IUNLOCK(mp); } -/* - * xfs_iaccess: check accessibility of inode for mode. - */ -int -xfs_iaccess( - xfs_inode_t *ip, - mode_t mode, - cred_t *cr) -{ - int error; - mode_t orgmode = mode; - struct inode *inode = vn_to_inode(XFS_ITOV(ip)); - - if (mode & S_IWUSR) { - umode_t imode = inode->i_mode; - - if (IS_RDONLY(inode) && - (S_ISREG(imode) || S_ISDIR(imode) || S_ISLNK(imode))) - return XFS_ERROR(EROFS); - - if (IS_IMMUTABLE(inode)) - return XFS_ERROR(EACCES); - } - - /* - * If there's an Access Control List it's used instead of - * the mode bits. - */ - if ((error = _ACL_XFS_IACCESS(ip, mode, cr)) != -1) - return error ? XFS_ERROR(error) : 0; - - if (current_fsuid(cr) != ip->i_d.di_uid) { - mode >>= 3; - if (!in_group_p((gid_t)ip->i_d.di_gid)) - mode >>= 3; - } - - /* - * If the DACs are ok we don't need any capability check. - */ - if ((ip->i_d.di_mode & mode) == mode) - return 0; - /* - * Read/write DACs are always overridable. - * Executable DACs are overridable if at least one exec bit is set. - */ - if (!(orgmode & S_IXUSR) || - (inode->i_mode & S_IXUGO) || S_ISDIR(inode->i_mode)) - if (capable_cred(cr, CAP_DAC_OVERRIDE)) - return 0; - - if ((orgmode == S_IRUSR) || - (S_ISDIR(inode->i_mode) && (!(orgmode & S_IWUSR)))) { - if (capable_cred(cr, CAP_DAC_READ_SEARCH)) - return 0; -#ifdef NOISE - cmn_err(CE_NOTE, "Ick: mode=%o, orgmode=%o", mode, orgmode); -#endif /* NOISE */ - return XFS_ERROR(EACCES); - } - return XFS_ERROR(EACCES); -} - #ifdef XFS_ILOCK_TRACE ktrace_t *xfs_ilock_trace_buf; Index: linux-2.6-xfs/fs/xfs/xfs_inode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h 2007-12-19 16:55:36.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_inode.h 2007-12-19 16:57:33.000000000 +0100 @@ -550,7 +550,6 @@ void xfs_iunpin(xfs_inode_t *); int xfs_iextents_copy(xfs_inode_t *, xfs_bmbt_rec_t *, int); int xfs_iflush(xfs_inode_t *, uint); void xfs_iflush_all(struct xfs_mount *); -int xfs_iaccess(xfs_inode_t *, mode_t, cred_t *); void xfs_ichgtime(xfs_inode_t *, int); xfs_fsize_t xfs_file_last_byte(xfs_inode_t *); void xfs_lock_inodes(xfs_inode_t **, int, int, uint); Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-12-19 16:55:36.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-12-19 16:57:33.000000000 +0100 @@ -898,27 +898,6 @@ xfs_setattr( return code; } - -/* - * xfs_access - * Null conversion from vnode mode bits to inode mode bits, as in efs. - */ -int -xfs_access( - xfs_inode_t *ip, - int mode, - cred_t *credp) -{ - int error; - - xfs_itrace_entry(ip); - xfs_ilock(ip, XFS_ILOCK_SHARED); - error = xfs_iaccess(ip, mode, credp); - xfs_iunlock(ip, XFS_ILOCK_SHARED); - return error; -} - - /* * The maximum pathlen is 1024 bytes. Since the minimum file system * blocksize is 512 bytes, we can get a max of 2 extents back from Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-12-19 16:55:36.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-12-19 16:59:11.000000000 +0100 @@ -555,12 +555,31 @@ xfs_vn_put_link( #ifdef CONFIG_XFS_POSIX_ACL STATIC int +xfs_check_acl( + struct inode *inode, + int mask) +{ + struct xfs_inode *ip = XFS_I(inode); + int error; + + xfs_itrace_entry(ip); + + if (XFS_IFORK_Q(ip)) { + error = xfs_acl_iaccess(ip, mask, NULL); + if (error != -1) + return -error; + } + + return -EAGAIN; +} + +STATIC int xfs_vn_permission( - struct inode *inode, - int mode, - struct nameidata *nd) + struct inode *inode, + int mask, + struct nameidata *nd) { - return -xfs_access(XFS_I(inode), mode << 6, NULL); + return generic_permission(inode, mask, xfs_check_acl); } #else #define xfs_vn_permission NULL Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-19 16:55:36.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-19 16:57:33.000000000 +0100 @@ -225,7 +225,6 @@ EXPORT_SYMBOL(xfs_fs_cmn_err); EXPORT_SYMBOL(xfs_highbit32); EXPORT_SYMBOL(xfs_highbit64); EXPORT_SYMBOL(xfs_idestroy); -EXPORT_SYMBOL(xfs_iaccess); EXPORT_SYMBOL(xfs_iextract); EXPORT_SYMBOL(xfs_iext_add); EXPORT_SYMBOL(xfs_iext_destroy); Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2007-12-19 16:55:36.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2007-12-19 16:57:33.000000000 +0100 @@ -392,32 +392,6 @@ xfs_acl_allow_set( } /* - * The access control process to determine the access permission: - * if uid == file owner id, use the file owner bits. - * if gid == file owner group id, use the file group bits. - * scan ACL for a matching user or group, and use matched entry - * permission. Use total permissions of all matching group entries, - * until all acl entries are exhausted. The final permission produced - * by matching acl entry or entries needs to be & with group permission. - * if not owner, owning group, or matching entry in ACL, use file - * other bits. - */ -STATIC int -xfs_acl_capability_check( - mode_t mode, - cred_t *cr) -{ - if ((mode & ACL_READ) && !capable_cred(cr, CAP_DAC_READ_SEARCH)) - return EACCES; - if ((mode & ACL_WRITE) && !capable_cred(cr, CAP_DAC_OVERRIDE)) - return EACCES; - if ((mode & ACL_EXECUTE) && !capable_cred(cr, CAP_DAC_OVERRIDE)) - return EACCES; - - return 0; -} - -/* * Note: cr is only used here for the capability check if the ACL test fails. * It is not used to find out the credentials uid or groups etc, as was * done in IRIX. It is assumed that the uid and groups for the current @@ -438,7 +412,6 @@ xfs_acl_access( matched.ae_tag = 0; /* Invalid type */ matched.ae_perm = 0; - md >>= 6; /* Normalize the bits for comparison */ for (i = 0; i < fap->acl_cnt; i++) { /* @@ -520,7 +493,8 @@ xfs_acl_access( break; } - return xfs_acl_capability_check(md, cr); + /* EACCES tells generic_permission to check for capability overrides */ + return EACCES; } EXPORT_SYMBOL(xfs_acl_access); Index: linux-2.6-xfs/fs/xfs/xfs_acl.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.h 2007-12-19 16:55:36.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_acl.h 2007-12-19 16:57:33.000000000 +0100 @@ -75,7 +75,6 @@ extern int xfs_acl_vremove(bhv_vnode_t * #define _ACL_GET_DEFAULT(pv,pd) (xfs_acl_vtoacl(pv,NULL,pd) == 0) #define _ACL_ACCESS_EXISTS xfs_acl_vhasacl_access #define _ACL_DEFAULT_EXISTS xfs_acl_vhasacl_default -#define _ACL_XFS_IACCESS(i,m,c) (XFS_IFORK_Q(i) ? xfs_acl_iaccess(i,m,c) : -1) #define _ACL_ALLOC(a) ((a) = kmem_zone_alloc(xfs_acl_zone, KM_SLEEP)) #define _ACL_FREE(a) ((a)? kmem_zone_free(xfs_acl_zone, (a)):(void)0) @@ -95,7 +94,6 @@ extern int xfs_acl_vremove(bhv_vnode_t * #define _ACL_GET_DEFAULT(pv,pd) (0) #define _ACL_ACCESS_EXISTS (NULL) #define _ACL_DEFAULT_EXISTS (NULL) -#define _ACL_XFS_IACCESS(i,m,c) (-1) #endif #endif /* __XFS_ACL_H__ */ Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.h 2007-12-19 16:55:36.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.h 2007-12-19 16:57:33.000000000 +0100 @@ -18,7 +18,6 @@ int xfs_open(struct xfs_inode *ip); int xfs_getattr(struct xfs_inode *ip, struct bhv_vattr *vap, int flags); int xfs_setattr(struct xfs_inode *ip, struct bhv_vattr *vap, int flags, struct cred *credp); -int xfs_access(struct xfs_inode *ip, int mode, struct cred *credp); int xfs_readlink(struct xfs_inode *ip, char *link); int xfs_fsync(struct xfs_inode *ip, int flag, xfs_off_t start, xfs_off_t stop); From owner-xfs@oss.sgi.com Thu Dec 20 22:22:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 22:22:12 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBL6M50a010742 for ; Thu, 20 Dec 2007 22:22:07 -0800 X-ASG-Debug-ID: 1198218137-71b800460000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0681FB9147A for ; Thu, 20 Dec 2007 22:22:18 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 6WoJoNioQiGwF7ZM for ; Thu, 20 Dec 2007 22:22:18 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBL6MDF3023402 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 Dec 2007 07:22:13 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBL6MD63023400 for xfs@oss.sgi.com; Fri, 21 Dec 2007 07:22:13 +0100 Date: Fri, 21 Dec 2007 07:22:13 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/4] clean up xfs_swapext Subject: [PATCH 2/4] clean up xfs_swapext Message-ID: <20071221062213.GB23180@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1198218139 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37229 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5203/Thu Dec 20 20:10:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14046 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs - stop using vnodes - use proper multiple label goto unwinding - give the struct file * variables saner names Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_dfrag.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dfrag.c 2007-12-19 16:14:39.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_dfrag.c 2007-12-19 16:29:58.000000000 +0100 @@ -52,76 +52,61 @@ xfs_swapext( xfs_swapext_t __user *sxu) { xfs_swapext_t *sxp; - xfs_inode_t *ip=NULL, *tip=NULL; - xfs_mount_t *mp; - struct file *fp = NULL, *tfp = NULL; - bhv_vnode_t *vp, *tvp; + xfs_inode_t *ip, *tip; + struct file *file, *target_file; int error = 0; sxp = kmem_alloc(sizeof(xfs_swapext_t), KM_MAYFAIL); if (!sxp) { error = XFS_ERROR(ENOMEM); - goto error0; + goto out; } if (copy_from_user(sxp, sxu, sizeof(xfs_swapext_t))) { error = XFS_ERROR(EFAULT); - goto error0; + goto out_free_sxp; } /* Pull information for the target fd */ - if (((fp = fget((int)sxp->sx_fdtarget)) == NULL) || - ((vp = vn_from_inode(fp->f_path.dentry->d_inode)) == NULL)) { + file = fget((int)sxp->sx_fdtarget); + if (!file) { error = XFS_ERROR(EINVAL); - goto error0; - } - - ip = xfs_vtoi(vp); - if (ip == NULL) { - error = XFS_ERROR(EBADF); - goto error0; + goto out_free_sxp; } - if (((tfp = fget((int)sxp->sx_fdtmp)) == NULL) || - ((tvp = vn_from_inode(tfp->f_path.dentry->d_inode)) == NULL)) { + target_file = fget((int)sxp->sx_fdtmp); + if (!target_file) { error = XFS_ERROR(EINVAL); - goto error0; + goto out_put_file; } - tip = xfs_vtoi(tvp); - if (tip == NULL) { - error = XFS_ERROR(EBADF); - goto error0; - } + ip = XFS_I(file->f_path.dentry->d_inode); + tip = XFS_I(target_file->f_path.dentry->d_inode); if (ip->i_mount != tip->i_mount) { - error = XFS_ERROR(EINVAL); - goto error0; + error = XFS_ERROR(EINVAL); + goto out_put_target_file; } if (ip->i_ino == tip->i_ino) { - error = XFS_ERROR(EINVAL); - goto error0; + error = XFS_ERROR(EINVAL); + goto out_put_target_file; } - mp = ip->i_mount; - - if (XFS_FORCED_SHUTDOWN(mp)) { - error = XFS_ERROR(EIO); - goto error0; + if (XFS_FORCED_SHUTDOWN(ip->i_mount)) { + error = XFS_ERROR(EIO); + goto out_put_target_file; } error = xfs_swap_extents(ip, tip, sxp); - error0: - if (fp != NULL) - fput(fp); - if (tfp != NULL) - fput(tfp); - - if (sxp != NULL) - kmem_free(sxp, sizeof(xfs_swapext_t)); - + out_put_target_file: + fput(target_file); + out_put_file: + fput(file); + out_free_sxp: + kmem_free(sxp, sizeof(xfs_swapext_t)); + out: return error; } From owner-xfs@oss.sgi.com Thu Dec 20 22:36:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 22:37:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBL6aucJ012515 for ; Thu, 20 Dec 2007 22:36:58 -0800 X-ASG-Debug-ID: 1198219028-71b800690000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BE404B917C4 for ; Thu, 20 Dec 2007 22:37:09 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id ja1wGnxrZOxlf5po for ; Thu, 20 Dec 2007 22:37:09 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBL6b3F3023790 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 Dec 2007 07:37:03 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBL6b3RS023788 for xfs@oss.sgi.com; Fri, 21 Dec 2007 07:37:03 +0100 Date: Fri, 21 Dec 2007 07:37:03 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] dmapi: kill last 2.4 compat leftovers Subject: Re: [PATCH] dmapi: kill last 2.4 compat leftovers Message-ID: <20071221063703.GA23706@lst.de> References: <20071130093909.GB2949@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071130093909.GB2949@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1198219029 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37231 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5203/Thu Dec 20 20:10:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14049 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Any reason this didn't get in yet? On Fri, Nov 30, 2007 at 10:39:09AM +0100, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/dmapi/dmapi_register.c > =================================================================== > --- linux-2.6-xfs.orig/fs/dmapi/dmapi_register.c 2007-09-29 11:49:22.000000000 +0200 > +++ linux-2.6-xfs/fs/dmapi/dmapi_register.c 2007-09-29 11:49:39.000000000 +0200 > @@ -34,10 +34,8 @@ > #include > #include > #include > -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) > #include > #include > -#endif > #include > #include > #include > @@ -1520,33 +1518,6 @@ dm_getall_disp( > return(error); > } > > -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) > -#define d_alloc_anon dmapi_alloc_anon > -static struct dentry * > -d_alloc_anon(struct inode *inode) > -{ > - struct dentry *dentry; > - > - spin_lock(&dcache_lock); > - list_for_each_entry(dentry, &inode->i_dentry, d_alias) { > - if (!(dentry->d_flags & DCACHE_NFSD_DISCONNECTED)) > - goto found; > - } > - spin_unlock(&dcache_lock); > - > - dentry = d_alloc_root(inode); > - if (likely(dentry != NULL)) > - dentry->d_flags |= DCACHE_NFSD_DISCONNECTED; > - return dentry; > - found: > - dget_locked(dentry); > - dentry->d_vfs_flags |= DCACHE_REFERENCED; > - spin_unlock(&dcache_lock); > - iput(inode); > - return dentry; > -} > -#endif > - > int > dm_open_by_handle_rvp( > unsigned int fd, > Index: linux-2.6-xfs/fs/dmapi/dmapi_sysent.c > =================================================================== > --- linux-2.6-xfs.orig/fs/dmapi/dmapi_sysent.c 2007-09-29 11:49:42.000000000 +0200 > +++ linux-2.6-xfs/fs/dmapi/dmapi_sysent.c 2007-09-29 11:49:57.000000000 +0200 > @@ -706,14 +706,6 @@ dmapi_init_procfs(int dmapi_minor) > entry = create_proc_read_entry( DMAPI_DBG_PROCFS "/summary", > 0, NULL, dmapi_summary, NULL); > entry->owner = THIS_MODULE; > - > -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) > - entry = proc_mknod( DMAPI_PROCFS, S_IFCHR | S_IRUSR | S_IWUSR, > - NULL, mk_kdev(MISC_MAJOR,dmapi_minor)); > - if( entry == NULL ) > - return; > - entry->owner = THIS_MODULE; > -#endif > #endif > } > > @@ -722,9 +714,6 @@ static void __exit > dmapi_cleanup_procfs(void) > { > #ifdef CONFIG_PROC_FS > -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) > - remove_proc_entry( DMAPI_PROCFS, NULL); > -#endif > remove_proc_entry( DMAPI_DBG_PROCFS "/summary", NULL); > remove_proc_entry( DMAPI_DBG_PROCFS "/fsreg", NULL); > remove_proc_entry( DMAPI_DBG_PROCFS "/sessions", NULL); ---end quoted text--- From owner-xfs@oss.sgi.com Thu Dec 20 22:37:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 20 Dec 2007 22:37:17 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBL6bBYj012560 for ; Thu, 20 Dec 2007 22:37: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 RAA06872; Fri, 21 Dec 2007 17:37:19 +1100 Message-ID: <476B5FE4.9030405@sgi.com> Date: Fri, 21 Dec 2007 17:40:36 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Jonathan C. Detert" CC: xfs@oss.sgi.com Subject: Re: mount prob: "log inconsistent or not a log" References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011848.GV19770@msoe.edu> <20071220015425.GL4612@sgi.com> <20071220024453.GX19770@msoe.edu> <20071220175512.GA6023@msoe.edu> <476B0D29.4050504@sgi.com> <20071221015533.GH6476@msoe.edu> In-Reply-To: <20071221015533.GH6476@msoe.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5203/Thu Dec 20 20:10:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14050 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 Jonathan C. Detert wrote: > * Timothy Shimmin [071220 18:49]: >> Jonathan C. Detert wrote: >>> I just want to clarify - I mean to ask: >>> >>> Is it possible that an xfs filesystem which is in use by an o.s., >>> last mounted by the o.s. months ago, could have a corrupted log, and >>> yet keep functioning until such time as a remount of it is attempted? >>> >> Yes. >> The log is read on every mount. I don't believe we read it otherwise. >> On a mount we look for the log head and an unmount record etc. to decide >> whether to do a replay or not. >> So it could be corrupted and we would not know and we don't really care >> until the next mount. >> However, if we are modifying metadata in the filesystem (with some >> exceptions) >> then we will be continuing to write to the log and we will continue to >> wrap the log. And hence if someone corrupted the log at a point in the past, >> we may very well be able to overwrite the log and effectively lose that >> corruption. >> >> Do you understand the basic idea? > > I think so. > >> We just write to the log while the file-system is mounted and we are writing >> to the filesystem (particularly changing metadata); and >> we read from the log during (just prior) mounting of the filesystem. >> >>> I.e. if a log gets corrupted while the f.s. is in use, will anyone >>> notice, until such time as an attempt to remount the f.s. is made? >> No I don't think anyone will notice. >> No-one has cause to read it, so noone cares. >> >> If you unmount it cleanly. Run repair on it before mounting it again. >> Then repair may find corruption when it tries to find the log head etc... >> to work out if the log is clean or not. >> i.e. in this case repair will try to read the log before you've tried >> to do a mount. > > So, how do you recover from a situation like i have, namely: > > 1) the xfs file system is not currently mounted > 2) an attempt to mount the xfs fs fails, complaining about log being > inconsistent or not a log > > You say noone cares if the log is corrupt, but it seems to be a > fatal problem if you want to mount the fs. > Noone cares until you need to read it and it is still corrupt and then you care when you want to mount it. So yes, you care ;-) > Bottom line: how do you recover when trying to remount an xfs fs whose > log happens to be corrupt? Without doing anything fancy, you are stuffed. You need to clear the log and repair it using "xfs_repair -L" (the -L will zero the log and for linux write a log record in there). I was wondering that if only the end of the log was corrupted and that was not between the tail and the head, then one could write 0x00000255 (597 dec) at the start of each sector (which is the previous cycle#) where the corruption is. Then the recovery code would likely think that this was old data as it has the old cycle# (and hence ignore it). However, it is xmas breakup day and I'm too tired to try it out at the moment. :) Was thinking of something like: xfs_io -c 'pwrite -b 512 -S 0x00000255 38889s 31s' sdb-xfs-log.fixup But that's not right. Sorry. And then I'm still not convinced about the tail numbers in many of the log records (particularly the head) anyway. --Tim From owner-xfs@oss.sgi.com Fri Dec 21 15:19:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 21 Dec 2007 15:19:36 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBLNJTdI023431 for ; Fri, 21 Dec 2007 15:19:31 -0800 X-ASG-Debug-ID: 1198279182-3348021c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from email.msoe.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 975D6B9ECEE for ; Fri, 21 Dec 2007 15:19:42 -0800 (PST) Received: from email.msoe.edu (email.msoe.edu [155.92.194.61]) by cuda.sgi.com with ESMTP id 1H6NXAudqByDye68 for ; Fri, 21 Dec 2007 15:19:42 -0800 (PST) Received: from localhost ([155.92.193.21]) by email.msoe.edu with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Dec 2007 17:19:09 -0600 Date: Fri, 21 Dec 2007 17:19:09 -0600 From: "Jonathan C. Detert" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount prob: "log inconsistent or not a log" Subject: Re: mount prob: "log inconsistent or not a log" Message-ID: <20071221231909.GE4723@msoe.edu> References: <20071220000144.GQ19770@msoe.edu> <4769BD13.5040303@sgi.com> <20071220011848.GV19770@msoe.edu> <20071220015425.GL4612@sgi.com> <20071220024453.GX19770@msoe.edu> <20071220175512.GA6023@msoe.edu> <476B0D29.4050504@sgi.com> <20071221015533.GH6476@msoe.edu> <476B5FE4.9030405@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476B5FE4.9030405@sgi.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 21 Dec 2007 23:19:09.0237 (UTC) FILETIME=[E3907E50:01C84427] X-Barracuda-Connect: email.msoe.edu[155.92.194.61] X-Barracuda-Start-Time: 1198279182 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37297 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5211/Fri Dec 21 11:05:46 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14051 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jonathan.Detert@msoe.edu Precedence: bulk X-list: xfs * Timothy Shimmin [071221 00:38]: > Jonathan C. Detert wrote: > >* Timothy Shimmin [071220 18:49]: > >>Jonathan C. Detert wrote: > >>>I just want to clarify - I mean to ask: > >>> > >>> Is it possible that an xfs filesystem which is in use by an o.s., > >>> last mounted by the o.s. months ago, could have a corrupted log, and > >>> yet keep functioning until such time as a remount of it is attempted? > >>> > >>Yes. > >>The log is read on every mount. I don't believe we read it otherwise. > >>On a mount we look for the log head and an unmount record etc. to decide > >>whether to do a replay or not. > >>So it could be corrupted and we would not know and we don't really care > >>until the next mount. -- snip -- > >>If you unmount it cleanly. Run repair on it before mounting it again. > >>Then repair may find corruption when it tries to find the log head etc... > >>to work out if the log is clean or not. > >>i.e. in this case repair will try to read the log before you've tried > >>to do a mount. > > > >So, how do you recover from a situation like i have, namely: > > > >1) the xfs file system is not currently mounted > >2) an attempt to mount the xfs fs fails, complaining about log being > > inconsistent or not a log -- snip -- > Without doing anything fancy, you are stuffed. > You need to clear the log and repair it using "xfs_repair -L" > (the -L will zero the log and for linux write a log record in there). > > I was wondering that if only the end of the log was corrupted and that > was not between the tail and the head, then one could write > 0x00000255 (597 dec) at the start of each sector (which is the previous > cycle#) where the corruption is. > Then the recovery code would likely think that this was old > data as it has the old cycle# (and hence ignore it). > However, it is xmas breakup day and I'm too tired to try it out > at the moment. :) Merry Christmas, and have a good rest > Was thinking of something like: > xfs_io -c 'pwrite -b 512 -S 0x00000255 38889s 31s' sdb-xfs-log.fixup > But that's not right. Sorry. > And then I'm still not convinced about the tail numbers in many > of the log records (particularly the head) anyway. I have nothing to lose at this point. If you work out a best guess sometime before January 5th, I will try it. If it works, there would be much rejoicing around here. Thanks for all your help so far. -- Jon Detert IT Systems Administrator, Milwaukee School of Engineering 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A. -- Linus Torvalds doesn't die, he simply returns zero. From owner-xfs@oss.sgi.com Wed Dec 26 07:59:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Dec 2007 07:59:22 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_34, J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBQFxCIt015455 for ; Wed, 26 Dec 2007 07:59:13 -0800 X-ASG-Debug-ID: 1198684765-65e4000b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 55E061196BAE for ; Wed, 26 Dec 2007 07:59:25 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 1vti4vScDJ7G1P4w for ; Wed, 26 Dec 2007 07:59:25 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBQFmvF3003553 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Dec 2007 16:48:57 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBQFmvOd003551; Wed, 26 Dec 2007 16:48:57 +0100 Date: Wed, 26 Dec 2007 16:48:57 +0100 From: Christoph Hellwig To: jailbird@alcatraz.fdf.net Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] xfs: fix unaligned access in readdir Subject: [PATCH] xfs: fix unaligned access in readdir Message-ID: <20071226154857.GA3472@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1198684766 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37733 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5260/Wed Dec 26 06:19:24 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14052 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs This patch should fix the issue seen on Alpha with unaligned accesses in the new readdir code. By aligning each dirent to sizeof(u64) we'll avoid unaligned accesses. To make doubly sure we're not hitting problems also rearrange struct hack_dirent to avoid holes. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_file.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_file.c 2007-12-26 15:35:33.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_file.c 2007-12-26 15:40:14.000000000 +0100 @@ -262,9 +262,9 @@ xfs_file_readdir( #else struct hack_dirent { - int namlen; - loff_t offset; u64 ino; + loff_t offset; + int namlen; unsigned int d_type; char name[]; }; @@ -286,8 +286,10 @@ xfs_hack_filldir( { struct hack_callback *buf = __buf; struct hack_dirent *de = (struct hack_dirent *)(buf->dirent + buf->used); + unsigned int reclen; - if (buf->used + sizeof(struct hack_dirent) + namlen > buf->len) + reclen = ALIGN(sizeof(struct hack_dirent) + namlen, sizeof(u64)); + if (buf->used + reclen > buf->len) return -EINVAL; de->namlen = namlen; @@ -295,7 +297,7 @@ xfs_hack_filldir( de->ino = ino; de->d_type = d_type; memcpy(de->name, name, namlen); - buf->used += sizeof(struct hack_dirent) + namlen; + buf->used += reclen; return 0; } @@ -335,7 +337,8 @@ xfs_file_readdir( offset = filp->f_pos; while (!eof) { - int reclen; + unsigned int reclen; + start_offset = offset; buf.used = 0; @@ -356,7 +359,8 @@ xfs_file_readdir( goto done; } - reclen = sizeof(struct hack_dirent) + de->namlen; + reclen = ALIGN(sizeof(struct hack_dirent) + de->namlen, + sizeof(u64)); size -= reclen; de = (struct hack_dirent *)((char *)de + reclen); curr_offset = de->offset /* & 0x7fffffff */; From owner-xfs@oss.sgi.com Wed Dec 26 14:19:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 26 Dec 2007 14:19: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.4 required=5.0 tests=BAYES_00,J_CHICKENPOX_34, J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBQMJT9V014841 for ; Wed, 26 Dec 2007 14:19:32 -0800 X-ASG-Debug-ID: 1198707581-44a800100000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mta11.adelphia.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 07AA4BB8B12 for ; Wed, 26 Dec 2007 14:19:41 -0800 (PST) Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by cuda.sgi.com with ESMTP id DR1CIf10Uu5EBXMH for ; Wed, 26 Dec 2007 14:19:41 -0800 (PST) Received: from bobdole.fdf.net ([76.185.82.89]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20071226221940.UQZR29909.mta11.adelphia.net@bobdole.fdf.net>; Wed, 26 Dec 2007 17:19:40 -0500 Received: from [192.168.2.2] (relativity.wireless.alcatraz.fdf.net [192.168.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bobdole.fdf.net (Postfix) with ESMTP id 63D76B30D; Wed, 26 Dec 2007 16:19:39 -0600 (CST) Message-ID: <4772D373.6020906@alcatraz.fdf.net> Date: Wed, 26 Dec 2007 16:19:31 -0600 From: Dustin Marquess Organization: Alcatraz Island Security Consulting User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.12pre) Gecko/20071210 SeaMonkey/1.1.8pre MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: fix unaligned access in readdir Subject: Re: [PATCH] xfs: fix unaligned access in readdir References: <20071226154857.GA3472@lst.de> In-Reply-To: <20071226154857.GA3472@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mta11.adelphia.net[68.168.78.205] X-Barracuda-Start-Time: 1198707584 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37751 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5263/Wed Dec 26 12:47:53 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14053 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jailbird@alcatraz.fdf.net Precedence: bulk X-list: xfs This patch does indeed fix the problem. Thanks! -Dustin Christoph Hellwig wrote: > This patch should fix the issue seen on Alpha with unaligned accesses > in the new readdir code. By aligning each dirent to sizeof(u64) we'll > avoid unaligned accesses. To make doubly sure we're not hitting > problems also rearrange struct hack_dirent to avoid holes. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_file.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_file.c 2007-12-26 15:35:33.000000000 +0100 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_file.c 2007-12-26 15:40:14.000000000 +0100 > @@ -262,9 +262,9 @@ xfs_file_readdir( > #else > > struct hack_dirent { > - int namlen; > - loff_t offset; > u64 ino; > + loff_t offset; > + int namlen; > unsigned int d_type; > char name[]; > }; > @@ -286,8 +286,10 @@ xfs_hack_filldir( > { > struct hack_callback *buf = __buf; > struct hack_dirent *de = (struct hack_dirent *)(buf->dirent + buf->used); > + unsigned int reclen; > > - if (buf->used + sizeof(struct hack_dirent) + namlen > buf->len) > + reclen = ALIGN(sizeof(struct hack_dirent) + namlen, sizeof(u64)); > + if (buf->used + reclen > buf->len) > return -EINVAL; > > de->namlen = namlen; > @@ -295,7 +297,7 @@ xfs_hack_filldir( > de->ino = ino; > de->d_type = d_type; > memcpy(de->name, name, namlen); > - buf->used += sizeof(struct hack_dirent) + namlen; > + buf->used += reclen; > return 0; > } > > @@ -335,7 +337,8 @@ xfs_file_readdir( > offset = filp->f_pos; > > while (!eof) { > - int reclen; > + unsigned int reclen; > + > start_offset = offset; > > buf.used = 0; > @@ -356,7 +359,8 @@ xfs_file_readdir( > goto done; > } > > - reclen = sizeof(struct hack_dirent) + de->namlen; > + reclen = ALIGN(sizeof(struct hack_dirent) + de->namlen, > + sizeof(u64)); > size -= reclen; > de = (struct hack_dirent *)((char *)de + reclen); > curr_offset = de->offset /* & 0x7fffffff */; > From owner-xfs@oss.sgi.com Fri Dec 28 04:25:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 28 Dec 2007 04:25: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=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBSCPgaS009048 for ; Fri, 28 Dec 2007 04:25:43 -0800 X-ASG-Debug-ID: 1198844755-6ede02aa0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from py-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 95A4E4C53AC for ; Fri, 28 Dec 2007 04:25:56 -0800 (PST) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by cuda.sgi.com with ESMTP id XaeQirToOK4HjNDa for ; Fri, 28 Dec 2007 04:25:56 -0800 (PST) Received: by py-out-1112.google.com with SMTP id u77so6349208pyb.3 for ; Fri, 28 Dec 2007 04:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=THqYpzCweauMv4Dyqxrfx4lXdfPROQvniYsJiKcPwkQ=; b=OhiW7hRymKTvxKGEGJvALsgYgewveITAs87Rm+xadp+WrsNTwARbtyOXssJAnkbr70GAuUJm9rj+myUHOSMP+lTgk/EhZ25SHmpaZz1Vj97BVD0wAp0jn/PKK0Rn3FNk8ExGG6AdANEnYI6MiosUFKo9oKemdOtkNZMVWV7ZVfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=Pk0jkALtvyOIdvM3dnY7nO4dwdPMlgPbirczjccaVVimV08HNNShIBFd4jVXz4k/P/KhpXTWmukEVFnJcWDtknESxDSw43ly3mjpBDonHqH2Fhp4gcXJxFeR2HU8Vpbp2qIvY0/qyrTAwpiHuCk2p0AFDuwIo0gR8JxdWXxzTF8= Received: by 10.64.91.15 with SMTP id o15mr17803788qbb.57.1198844320426; Fri, 28 Dec 2007 04:18:40 -0800 (PST) Received: by 10.65.96.5 with HTTP; Fri, 28 Dec 2007 04:18:40 -0800 (PST) Message-ID: <3b8ebef50712280418l663cafadm80f884f43dfd3a15@mail.gmail.com> Date: Fri, 28 Dec 2007 10:18:40 -0200 From: "Nelzinho Rocha" To: xfs@oss.sgi.com X-ASG-Orig-Subj: how remove project quota Subject: how remove project quota MIME-Version: 1.0 X-Barracuda-Connect: py-out-1112.google.com[64.233.166.181] X-Barracuda-Start-Time: 1198844756 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5116 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.37904 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5273/Fri Dec 28 02:09:15 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 209 X-archive-position: 14054 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tecnhouse@gmail.com Precedence: bulk X-list: xfs Hello, how remove a project quota? Would be sufficient remove project quota the files /etc/projid and /etc/projects? Or have to do something else? Best regards, []'s [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Dec 30 15:04:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Dec 2007 15:04: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=-0.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBUN4OF4013831 for ; Sun, 30 Dec 2007 15:04:25 -0800 X-ASG-Debug-ID: 1199055873-156702390000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9F883BD24D0 for ; Sun, 30 Dec 2007 15:04:34 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id 0TYnHHVlXxaSOzDu for ; Sun, 30 Dec 2007 15:04:34 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 10C671C00023A; Sun, 30 Dec 2007 18:04:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 0AB414019521; Sun, 30 Dec 2007 18:04:33 -0500 (EST) Date: Sun, 30 Dec 2007 18:04:32 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: xfs@oss.sgi.com cc: linux-raid@vger.kernel.org, Alan Piszcz X-ASG-Orig-Subj: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. Subject: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1199055878 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38119 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5298/Sun Dec 30 12:16:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14055 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Dave's original e-mail: > # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 > # mount -o logbsize=256k > And if you don't care about filsystem corruption on power loss: > # mount -o logbsize=256k,nobarrier > Those mkfs values (except for log size) will be hte defaults in the next > release of xfsprogs. > Cheers, > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group --------- I used his mkfs.xfs options verbatim but I use my own mount options: noatime,nodiratime,logbufs=8,logbsize=26214 Here are the results, the results of 3 bonnie++ averaged together for each test: http://home.comcast.net/~jpiszcz/xfs1/result.html Thanks Dave, this looks nice--the more optimizations the better! ----------- I also find it rather pecuilar that in some of my (other) benchmarks my RAID 5 is just as fast as RAID 0 for extracting large files (uncompressed) files: RAID 5 (1024k CHUNK) 26.95user 6.72system 0:37.89elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k0inputs+0outputs (6major+526minor)pagefaults 0swaps Compare with RAID 0 for the same operation: (as with RAID5, it appears 256k-1024k..2048k possibly) is the sweet spot. Why does mdadm still use 64k for the default chunk size? And another quick question, would there be any benefit to use (if it were possible) a block size of > 4096 bytes with XFS (I assume only IA64/similar arch can support it), e.g. x86_64 cannot because the page_size is 4096. [ 8265.407137] XFS: only pagesize (4096) or less will currently work. The speeds: extract speed with 4 chunk: 27.30user 10.51system 0:55.87elapsed 67%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps 27.39user 10.38system 0:56.98elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps 27.31user 10.56system 0:57.70elapsed 65%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps extract speed with 8 chunk: 27.09user 9.27system 0:54.60elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+525minor)pagefaults 0swaps 27.23user 8.91system 0:54.38elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+527minor)pagefaults 0swaps 27.19user 8.98system 0:54.68elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps extract speed with 16 chunk: 27.12user 7.24system 0:51.12elapsed 67%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps 27.13user 7.12system 0:50.58elapsed 67%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps 27.11user 7.18system 0:50.56elapsed 67%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+527minor)pagefaults 0swaps extract speed with 32 chunk: 27.15user 6.52system 0:48.06elapsed 70%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+527minor)pagefaults 0swaps 27.24user 6.38system 0:49.10elapsed 68%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps 27.11user 6.46system 0:47.56elapsed 70%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps extract speed with 64 chunk: 27.15user 5.94system 0:45.13elapsed 73%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+525minor)pagefaults 0swaps 27.17user 5.94system 0:44.82elapsed 73%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+527minor)pagefaults 0swaps 27.02user 6.12system 0:44.61elapsed 74%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+525minor)pagefaults 0swaps extract speed with 128 chunk: 26.98user 5.78system 0:40.48elapsed 80%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+525minor)pagefaults 0swaps 27.05user 5.73system 0:40.30elapsed 81%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps 27.11user 5.68system 0:40.59elapsed 80%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps extract speed with 256 chunk: 27.10user 5.60system 0:36.47elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+525minor)pagefaults 0swaps 27.03user 5.67system 0:36.18elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps 27.17user 5.50system 0:37.38elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps extract speed with 512 chunk: 27.06user 5.54system 0:36.58elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+524minor)pagefaults 0swaps 27.03user 5.59system 0:36.31elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+525minor)pagefaults 0swaps 27.06user 5.58system 0:36.42elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps extract speed with 1024 chunk: 26.92user 5.69system 0:36.51elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+525minor)pagefaults 0swaps 27.18user 5.43system 0:36.39elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps 27.04user 5.60system 0:36.27elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps extract speed with 2048 chunk: 26.97user 5.63system 0:36.99elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+525minor)pagefaults 0swaps 26.98user 5.62system 0:36.90elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+527minor)pagefaults 0swaps 27.15user 5.44system 0:37.06elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps extract speed with 4096 chunk: 27.11user 5.54system 0:38.96elapsed 83%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps 27.09user 5.55system 0:38.85elapsed 84%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+527minor)pagefaults 0swaps 27.12user 5.52system 0:38.80elapsed 84%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps extract speed with 8192 chunk: 27.04user 5.57system 0:43.54elapsed 74%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps 27.15user 5.49system 0:43.52elapsed 75%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps 27.11user 5.52system 0:43.66elapsed 74%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+528minor)pagefaults 0swaps extract speed with 16384 chunk: 27.25user 5.45system 0:52.18elapsed 62%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+526minor)pagefaults 0swaps 27.18user 5.52system 0:52.54elapsed 62%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+527minor)pagefaults 0swaps 27.17user 5.50system 0:51.38elapsed 63%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (6major+525minor)pagefaults 0swaps Justin. From owner-xfs@oss.sgi.com Sun Dec 30 15:39:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Dec 2007 15:39:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBUNdapB015821 for ; Sun, 30 Dec 2007 15:39:38 -0800 X-ASG-Debug-ID: 1199057989-608c00b10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E4F17BD25F4 for ; Sun, 30 Dec 2007 15:39:49 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by cuda.sgi.com with ESMTP id 7tAZKtzv8tNwzLa2 for ; Sun, 30 Dec 2007 15:39:49 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so7799713waf.18 for ; Sun, 30 Dec 2007 15:39:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hzhA+E5PyWT+9Ftk5ZI5E2Oulltbi6JXykazfGk3zQI=; b=pdnpfIFvzK6jt1gW5MWTdLwOyuDwZWC+yK0DcuNIAjAGAmLZH696wH+joTd/vVNaNrueVMfOilY3SsfJLoClykyHlOS+llYAq48aLmO0pue3S4tmGo/YA8fm0HTtUXxiJCwZNARbGbcfHwITdBJj7YY+C5KNeuDjWuSTMY05RtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=wuBLB912kZYCiI15DFXjdfgy1wVtwK5X4i8MqCT0jKRXp1G6LGNCI0G10+UMcphbGuDkglI1hjfUJ61cGrVThftaW2qGkvZrRUldZZI03XfrFlGJ1Fpy3pkOchkhHilRcKxKOM38WM8ZqppfbSC1Hbn9nPXNpGHhozX/1u2Dr8E= Received: by 10.114.81.1 with SMTP id e1mr8684666wab.11.1199057594082; Sun, 30 Dec 2007 15:33:14 -0800 (PST) Received: by 10.114.255.19 with HTTP; Sun, 30 Dec 2007 15:33:14 -0800 (PST) Message-ID: <5d96567b0712301533v3a7fcfd1pfce02563526a39bf@mail.gmail.com> Date: Mon, 31 Dec 2007 01:33:14 +0200 From: Raz To: "Justin Piszcz" X-ASG-Orig-Subj: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. Subject: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. Cc: xfs@oss.sgi.com, linux-raid@vger.kernel.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.180] X-Barracuda-Start-Time: 1199057989 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38123 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5302/Sun Dec 30 14:58:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14056 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs what is nobarrier ? On 12/31/07, Justin Piszcz wrote: > Dave's original e-mail: > > > # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 > > # mount -o logbsize=256k > > > And if you don't care about filsystem corruption on power loss: > > > # mount -o logbsize=256k,nobarrier > > > Those mkfs values (except for log size) will be hte defaults in the next > > release of xfsprogs. > > > Cheers, > > > Dave. > > -- > > Dave Chinner > > Principal Engineer > > SGI Australian Software Group > > --------- > > I used his mkfs.xfs options verbatim but I use my own mount options: > noatime,nodiratime,logbufs=8,logbsize=26214 > > Here are the results, the results of 3 bonnie++ averaged together for each > test: > http://home.comcast.net/~jpiszcz/xfs1/result.html > > Thanks Dave, this looks nice--the more optimizations the better! > > ----------- > > I also find it rather pecuilar that in some of my (other) benchmarks my > RAID 5 is just as fast as RAID 0 for extracting large files (uncompressed) > files: > > RAID 5 (1024k CHUNK) > 26.95user 6.72system 0:37.89elapsed 88%CPU (0avgtext+0avgdata > 0maxresident)k0inputs+0outputs (6major+526minor)pagefaults 0swaps > > Compare with RAID 0 for the same operation: > > (as with RAID5, it appears 256k-1024k..2048k possibly) is the sweet spot. > > Why does mdadm still use 64k for the default chunk size? > > And another quick question, would there be any benefit to use (if it were > possible) a block size of > 4096 bytes with XFS (I assume only > IA64/similar arch can support it), e.g. x86_64 cannot because the > page_size is 4096. > > [ 8265.407137] XFS: only pagesize (4096) or less will currently work. > > The speeds: > > extract speed with 4 chunk: > 27.30user 10.51system 0:55.87elapsed 67%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > 27.39user 10.38system 0:56.98elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > 27.31user 10.56system 0:57.70elapsed 65%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > extract speed with 8 chunk: > 27.09user 9.27system 0:54.60elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+525minor)pagefaults 0swaps > 27.23user 8.91system 0:54.38elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+527minor)pagefaults 0swaps > 27.19user 8.98system 0:54.68elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > extract speed with 16 chunk: > 27.12user 7.24system 0:51.12elapsed 67%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > 27.13user 7.12system 0:50.58elapsed 67%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > 27.11user 7.18system 0:50.56elapsed 67%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+527minor)pagefaults 0swaps > extract speed with 32 chunk: > 27.15user 6.52system 0:48.06elapsed 70%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+527minor)pagefaults 0swaps > 27.24user 6.38system 0:49.10elapsed 68%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > 27.11user 6.46system 0:47.56elapsed 70%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > extract speed with 64 chunk: > 27.15user 5.94system 0:45.13elapsed 73%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+525minor)pagefaults 0swaps > 27.17user 5.94system 0:44.82elapsed 73%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+527minor)pagefaults 0swaps > 27.02user 6.12system 0:44.61elapsed 74%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+525minor)pagefaults 0swaps > extract speed with 128 chunk: > 26.98user 5.78system 0:40.48elapsed 80%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+525minor)pagefaults 0swaps > 27.05user 5.73system 0:40.30elapsed 81%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > 27.11user 5.68system 0:40.59elapsed 80%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > extract speed with 256 chunk: > 27.10user 5.60system 0:36.47elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+525minor)pagefaults 0swaps > 27.03user 5.67system 0:36.18elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > 27.17user 5.50system 0:37.38elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > extract speed with 512 chunk: > 27.06user 5.54system 0:36.58elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+524minor)pagefaults 0swaps > 27.03user 5.59system 0:36.31elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+525minor)pagefaults 0swaps > 27.06user 5.58system 0:36.42elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > extract speed with 1024 chunk: > 26.92user 5.69system 0:36.51elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+525minor)pagefaults 0swaps > 27.18user 5.43system 0:36.39elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > 27.04user 5.60system 0:36.27elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > extract speed with 2048 chunk: > 26.97user 5.63system 0:36.99elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+525minor)pagefaults 0swaps > 26.98user 5.62system 0:36.90elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+527minor)pagefaults 0swaps > 27.15user 5.44system 0:37.06elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > extract speed with 4096 chunk: > 27.11user 5.54system 0:38.96elapsed 83%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > 27.09user 5.55system 0:38.85elapsed 84%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+527minor)pagefaults 0swaps > 27.12user 5.52system 0:38.80elapsed 84%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > extract speed with 8192 chunk: > 27.04user 5.57system 0:43.54elapsed 74%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > 27.15user 5.49system 0:43.52elapsed 75%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > 27.11user 5.52system 0:43.66elapsed 74%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+528minor)pagefaults 0swaps > extract speed with 16384 chunk: > 27.25user 5.45system 0:52.18elapsed 62%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+526minor)pagefaults 0swaps > 27.18user 5.52system 0:52.54elapsed 62%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+527minor)pagefaults 0swaps > 27.17user 5.50system 0:51.38elapsed 63%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (6major+525minor)pagefaults 0swaps > > Justin. > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Raz From owner-xfs@oss.sgi.com Sun Dec 30 15:44:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 30 Dec 2007 15:44:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBUNi5RP016359 for ; Sun, 30 Dec 2007 15:44:14 -0800 X-ASG-Debug-ID: 1199058257-083f00d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-out.m-online.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EF9F34CDC83 for ; Sun, 30 Dec 2007 15:44:17 -0800 (PST) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by cuda.sgi.com with ESMTP id Yn82c8cO85EUxWtU for ; Sun, 30 Dec 2007 15:44:17 -0800 (PST) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 2CFFB227973; Mon, 31 Dec 2007 00:46:01 +0100 (CET) X-Auth-Info: AsP+iNiOv2ieTUb/6ZYqdSKcvwS79HUYAzEUr39WOIA= X-Auth-Info: AsP+iNiOv2ieTUb/6ZYqdSKcvwS79HUYAzEUr39WOIA= X-Auth-Info: AsP+iNiOv2ieTUb/6ZYqdSKcvwS79HUYAzEUr39WOIA= X-Auth-Info: AsP+iNiOv2ieTUb/6ZYqdSKcvwS79HUYAzEUr39WOIA= Received: from mail.denx.de (p5B0DEBCA.dip.t-dialin.net [91.13.235.202]) by smtp-auth.mnet-online.de (Postfix) with ESMTP id CAB4990264; Mon, 31 Dec 2007 00:44:15 +0100 (CET) Received: from gemini.denx.de (gemini.denx.de [10.0.0.2]) by mail.denx.de (Postfix) with ESMTP id 4EB166D00A5; Mon, 31 Dec 2007 00:44:15 +0100 (CET) Received: from gemini.denx.de (localhost.localdomain [127.0.0.1]) by gemini.denx.de (Postfix) with ESMTP id 1E11B24755; Mon, 31 Dec 2007 00:44:15 +0100 (CET) To: Raz cc: "Justin Piszcz" , xfs@oss.sgi.com, linux-raid@vger.kernel.org From: Wolfgang Denk X-ASG-Orig-Subj: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. Subject: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit In-reply-to: Your message of "Mon, 31 Dec 2007 01:33:14 +0200." <5d96567b0712301533v3a7fcfd1pfce02563526a39bf@mail.gmail.com> Date: Mon, 31 Dec 2007 00:44:15 +0100 Message-Id: <20071230234415.1E11B24755@gemini.denx.de> X-Barracuda-Connect: mail-out.m-online.net[212.18.0.9] X-Barracuda-Start-Time: 1199058259 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38122 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5302/Sun Dec 30 14:58:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14057 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wd@denx.de Precedence: bulk X-list: xfs In message <5d96567b0712301533v3a7fcfd1pfce02563526a39bf@mail.gmail.com> you wrote: > what is nobarrier ? ... > > > # mount -o logbsize=256k,nobarrier See http://oss.sgi.com/projects/xfs/faq.html Q: How can I address the problem with the write cache? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de One of the advantages of being a captain is being able to ask for ad- vice without necessarily having to take it. -- Kirk, "Dagger of the Mind", stardate 2715.2 From owner-xfs@oss.sgi.com Mon Dec 31 02:16:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 02:16: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=4.9 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVAGXmT008675 for ; Mon, 31 Dec 2007 02:16:35 -0800 X-ASG-Debug-ID: 1199096205-05d6008f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CF23A2C01B0 for ; Mon, 31 Dec 2007 02:16:45 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by cuda.sgi.com with ESMTP id ssXu665mvHyM5Xxp for ; Mon, 31 Dec 2007 02:16:45 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so8134817waf.18 for ; Mon, 31 Dec 2007 02:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=s75N3JeQRC4uwOszLgCQpm87eFGGvfJCCoDl2T0e508=; b=TjTCmgArfeADiL33w6ABduvhL1JPo5Hnsq4qFb1tVQc6uz5thp+rN6thI4xZWqkkPZ93gW9kYOB9/ZKqXau/mY7dxg8cazLRJDgO+yqx86PkIYtRaxalbXUl55vNqsocmwLKgmAaA5k36jAZIwQbJrh4E9y6Z8acdyQ4V2rrCAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=PKAlq0v5/Hr6u4Ibd+FrarxA+305N9nrrnW3LTcKeczVkWaL8etTRKKNe/s3A7eILZ79sqIdDO55KA+aPxgGN6YexMhtOPTWVpjQ4uY9VQbvQ8SkOE6mOuQK79Pc4CvyRjaIauZtfsK7GrYOOm898M2SlsJHouJCc1Fz2UxDSyM= Received: by 10.114.192.1 with SMTP id p1mr12831246waf.47.1199095776049; Mon, 31 Dec 2007 02:09:36 -0800 (PST) Received: by 10.114.39.9 with HTTP; Mon, 31 Dec 2007 02:09:36 -0800 (PST) Message-ID: Date: Mon, 31 Dec 2007 02:09:36 -0800 From: "Aaron Blew" To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair gone wrong Subject: xfs_repair gone wrong MIME-Version: 1.0 X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.182] X-Barracuda-Start-Time: 1199096207 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.38 X-Barracuda-Spam-Status: No, SCORE=-1.38 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_00_10, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38164 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.64 HTML_00_10 BODY: Message is 0% to 10% HTML 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5307/Sun Dec 30 18:25:49 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 850 X-archive-position: 14058 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aaronblew@gmail.com Precedence: bulk X-list: xfs After a recent Debian dist-upgrade on my home server, I finally rebooted the machine to take advantage of the new kernel that had been installed. Unfortunately upon reboot, my first md array wasn't coming online successfully. I finally rebuilt the md array and got LVM back online (the VG and single LV are comprised of two 3 disk software RAID-5 arrays, md0 and md1), the filesystem wouldn't mount, much to my dismay. xfs_check seemed to segfault, so I ended up running xfs_repair without the -n option (OOPS), which made all sorts of changes to the filesystem, leaving me with 18GB of my original 650GB dataset (1.2TB filesystem). I'm willing to bet the majority of my data is still there, but is there a tool to crawl the device looking for files/data? Any ideas would be appreciated! Thanks much, -Aaron [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Dec 31 07:01:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 07:01: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVF1VVo000837 for ; Mon, 31 Dec 2007 07:01:32 -0800 X-ASG-Debug-ID: 1199113298-70e7005e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gaimboi.tmr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1DFF5BD40C3 for ; Mon, 31 Dec 2007 07:01:41 -0800 (PST) Received: from gaimboi.tmr.com (mail.tmr.com [64.65.253.246]) by cuda.sgi.com with ESMTP id gJqrHtWb8I2qtaXt for ; Mon, 31 Dec 2007 07:01:41 -0800 (PST) Received: from [127.0.0.1] (gaimboi.tmr.com [127.0.0.1]) by gaimboi.tmr.com (8.12.8/8.12.8) with ESMTP id lBVFMrPO003106; Mon, 31 Dec 2007 10:22:54 -0500 Message-ID: <4779094D.8050002@tmr.com> Date: Mon, 31 Dec 2007 10:22:53 -0500 From: Bill Davidsen Organization: TMR Associates Inc, Schenectady NY User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061105 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Justin Piszcz CC: xfs@oss.sgi.com, linux-raid@vger.kernel.org, Alan Piszcz X-ASG-Orig-Subj: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. Subject: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail.tmr.com[64.65.253.246] X-Barracuda-Start-Time: 1199113306 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38181 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5308/Mon Dec 31 03:23:14 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14059 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: xfs Justin Piszcz wrote: > Dave's original e-mail: > >> # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d >> agcount=4 >> # mount -o logbsize=256k > >> And if you don't care about filsystem corruption on power loss: > >> # mount -o logbsize=256k,nobarrier > >> Those mkfs values (except for log size) will be hte defaults in the next >> release of xfsprogs. > >> Cheers, > >> Dave. >> -- >> Dave Chinner >> Principal Engineer >> SGI Australian Software Group > > --------- > > I used his mkfs.xfs options verbatim but I use my own mount options: > noatime,nodiratime,logbufs=8,logbsize=26214 > > Here are the results, the results of 3 bonnie++ averaged together for > each test: > http://home.comcast.net/~jpiszcz/xfs1/result.html > > Thanks Dave, this looks nice--the more optimizations the better! > > ----------- > > I also find it rather pecuilar that in some of my (other) benchmarks > my RAID 5 is just as fast as RAID 0 for extracting large files > (uncompressed) files: > > RAID 5 (1024k CHUNK) > 26.95user 6.72system 0:37.89elapsed 88%CPU (0avgtext+0avgdata > 0maxresident)k0inputs+0outputs (6major+526minor)pagefaults 0swaps > > Compare with RAID 0 for the same operation: > > (as with RAID5, it appears 256k-1024k..2048k possibly) is the sweet spot. > > Why does mdadm still use 64k for the default chunk size? Write performance with small files, I would think. There is some information in old posts, but I don't seem to find them as quickly as I would like. > > And another quick question, would there be any benefit to use (if it > were possible) a block size of > 4096 bytes with XFS (I assume only > IA64/similar arch can support it), e.g. x86_64 cannot because the > page_size is 4096. > > [ 8265.407137] XFS: only pagesize (4096) or less will currently work. -- Bill Davidsen "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark From owner-xfs@oss.sgi.com Mon Dec 31 08:26:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 08:26:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_20, DATE_IN_PAST_12_24 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVGQ0UJ009940 for ; Mon, 31 Dec 2007 08:26:01 -0800 X-ASG-Debug-ID: 1199118375-70e901310000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pan.gwi.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BBB94121FDE4 for ; Mon, 31 Dec 2007 08:26:15 -0800 (PST) Received: from pan.gwi.net (pan.gwi.net [207.5.128.165]) by cuda.sgi.com with ESMTP id 6kIRp3CBaedjcxwC for ; Mon, 31 Dec 2007 08:26:15 -0800 (PST) Received: from strange.home.langhorst.com (bb-66-55-211-238.gwi.net [66.55.211.238]) by pan.gwi.net (8.13.1/8.13.1) with ESMTP id lBVGQD6p037192 for ; Mon, 31 Dec 2007 11:26:14 -0500 (EST) (envelope-from brad@langhorst.com) Received: from up.home.langhorst.com ([192.168.10.13]) by strange.home.langhorst.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J9NSv-00084V-KJ for xfs@oss.sgi.com; Mon, 31 Dec 2007 11:26:13 -0500 X-ASG-Orig-Subj: raid 10 su, sw settings Subject: raid 10 su, sw settings From: Brad Langhorst To: xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 Date: Sun, 30 Dec 2007 19:00:39 -0500 Message-Id: <1199059239.13944.65.camel@up> Mime-Version: 1.0 X-Mailer: Evolution 2.21.4 X-Barracuda-Connect: pan.gwi.net[207.5.128.165] X-Barracuda-Start-Time: 1199118375 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0013 1.0000 -2.0127 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.13 X-Barracuda-Spam-Status: No, SCORE=-1.13 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=DATE_IN_PAST_12_24 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38187 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.88 DATE_IN_PAST_12_24 Date: is 12 to 24 hours before Received: date X-Virus-Scanned: ClamAV 0.91.2/5310/Mon Dec 31 05:06:43 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id lBVGQ2UJ009942 X-archive-position: 14060 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brad@langhorst.com Precedence: bulk X-list: xfs I have this system - 3ware 9650 controller - 4 disk raid 10 - 64k stripe size - this is a vmware host, so lots of r/w on a few big files. I'm not entirely satisfied with its performance. Typical blocks/sec from iostat during large file movements is about 100M/s read and 80M/s write. When I set this up, I did not fully understand all the details... so I want to check a few things. - is the partition aligned correctly? i fear not... /dev/sda1 * 1 24 192748+ 83 Linux /dev/sda2 25 19449 156031312+ 83 Linux Is this where I'm losing performance? - What should the sunit and swidth settings be during mount? I guess with raid 10 the width is 2 so... sunit = 128 (64k/512) and swidth = 256 (2*64k/512) Or maybe I should use width 1 ?  Remounting (mount -o remount) with these options does not lead to a noticeable change in performance. Must I recreate the fs or unmount and remount? Here's the output of xfsinfo in case it's relevant. xfs_info / meta-data=/dev/sda2 isize=256 agcount=16, agsize=2437989 blks = sectsz=512 attr=0 data = bsize=4096 blocks=39007824, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=19046, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 From owner-xfs@oss.sgi.com Mon Dec 31 09:04:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 09:04:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVH4Y5T012775 for ; Mon, 31 Dec 2007 09:04:38 -0800 X-ASG-Debug-ID: 1199120688-0e9702730000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0D9334D089C for ; Mon, 31 Dec 2007 09:04:48 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id V5wV2w73jDTznD8i for ; Mon, 31 Dec 2007 09:04:48 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 0A0501C00023C; Mon, 31 Dec 2007 12:04:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 04F194019521; Mon, 31 Dec 2007 12:04:17 -0500 (EST) Date: Mon, 31 Dec 2007 12:04:17 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Brad Langhorst cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: raid 10 su, sw settings Subject: Re: raid 10 su, sw settings In-Reply-To: <1199059239.13944.65.camel@up> Message-ID: References: <1199059239.13944.65.camel@up> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-731421917-1199120657=:23402" X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1199120689 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38190 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5310/Mon Dec 31 05:06:43 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14061 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-731421917-1199120657=:23402 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 30 Dec 2007, Brad Langhorst wrote: > I have this system > - 3ware 9650 controller > - 4 disk raid 10 > - 64k stripe size > - this is a vmware host, so lots of r/w on a few big files. > > I'm not entirely satisfied with its performance. > > Typical blocks/sec from iostat during large file movements is about > 100M/s read and 80M/s write. > > When I set this up, I did not fully understand all the details... so I > want to check a few things. > > - is the partition aligned correctly? i fear not... > /dev/sda1 * 1 24 192748+ 83 Linux > /dev/sda2 25 19449 156031312+ 83 Linux > > Is this where I'm losing performance? > > - What should the sunit and swidth settings be during mount? > I guess with raid 10 the width is 2 so... > sunit =3D 128 (64k/512) and swidth =3D 256 (2*64k/512) > > Or maybe I should use width 1 ? > =FF=FF > Remounting (mount -o remount) with these options does not lead > to a noticeable change in performance. Must I recreate the fs or > unmount and remount? > > Here's the output of xfsinfo in case it's relevant. > > xfs_info / > meta-data=3D/dev/sda2 isize=3D256 agcount=3D16, agsize=3D= 2437989 > blks > =3D sectsz=3D512 attr=3D0 > data =3D bsize=3D4096 blocks=3D39007824, > imaxpct=3D25 > =3D sunit=3D0 swidth=3D0 blks, unwritt= en=3D1 > naming =3Dversion 2 bsize=3D4096 > log =3Dinternal bsize=3D4096 blocks=3D19046, version= =3D1 > =3D sectsz=3D512 sunit=3D0 blks > realtime =3Dnone extsz=3D65536 blocks=3D0, rtextents= =3D0 > > > > > > > > #1 What type of performance do you expect with a 4-disk raid10? #2 You should be able to umount/mount with the new sizes, although I have= =20 not tested it myself b/c I typically use sw raid here (sunit/etc is=20 optimized for sw raid). Justin. ---1463747160-731421917-1199120657=:23402-- From owner-xfs@oss.sgi.com Mon Dec 31 10:00:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 10:00:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_42 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVI08X6017087 for ; Mon, 31 Dec 2007 10:00:11 -0800 X-ASG-Debug-ID: 1199124017-3ff100600000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from AUSEXCH1.greshamstorage.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6187D4D0A5C for ; Mon, 31 Dec 2007 10:00:17 -0800 (PST) Received: from AUSEXCH1.greshamstorage.com (license.greshamstorage.com [12.166.178.178]) by cuda.sgi.com with ESMTP id 1n6EvDSe9i2MSsDF for ; Mon, 31 Dec 2007 10:00:17 -0800 (PST) Received: from [192.245.184.83] ([192.245.184.83]) by AUSEXCH1.greshamstorage.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Dec 2007 12:00:16 -0600 Message-ID: <47792E2F.1090906@greshamstorage.com> Date: Mon, 31 Dec 2007 12:00:15 -0600 From: Kipp Aldrich Reply-To: kippa@greshamstorage.com Organization: Gresham Enterprise Storage User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: O_DIRECT and bigphysarea Subject: O_DIRECT and bigphysarea Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Dec 2007 18:00:16.0180 (UTC) FILETIME=[FF812F40:01C84BD6] X-Barracuda-Connect: license.greshamstorage.com[12.166.178.178] X-Barracuda-Start-Time: 1199124023 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38194 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5311/Mon Dec 31 09:05:08 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14062 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kippa@greshamstorage.com Precedence: bulk X-list: xfs Is it possible to read/write an xfs file opened with O_DIRECT to a buffer obtained via bigphysarea? I have tried this and get "Bad Address" errors. Buffers obtained via regular alloc methods work fine. The bigphysarea buffers are correctly mmap'ed into user space, and show in /proc//maps. So, the question is can I do xfs O_DIRECT on reads/writes to bigphysarea buffers? Thanks. I am running 2.6 (2.6.21-rc3, from sgi cvs). Kipp -- Kipp A. Aldrich From owner-xfs@oss.sgi.com Mon Dec 31 10:43:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 10:43:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVIh0Ge019802 for ; Mon, 31 Dec 2007 10:43:03 -0800 X-ASG-Debug-ID: 1199126592-2b8600c30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pan.gwi.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C5F82BD4C5F for ; Mon, 31 Dec 2007 10:43:12 -0800 (PST) Received: from pan.gwi.net (pan.gwi.net [207.5.128.165]) by cuda.sgi.com with ESMTP id cGkteSbyWZ7drKPQ for ; Mon, 31 Dec 2007 10:43:12 -0800 (PST) Received: from strange.home.langhorst.com (bb-66-55-211-238.gwi.net [66.55.211.238]) by pan.gwi.net (8.13.1/8.13.1) with ESMTP id lBVIh251066767; Mon, 31 Dec 2007 13:43:02 -0500 (EST) (envelope-from brad@langhorst.com) Received: from up.home.langhorst.com ([192.168.10.13]) by strange.home.langhorst.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J9PbK-0004Sp-34; Mon, 31 Dec 2007 13:43:02 -0500 X-ASG-Orig-Subj: Re: raid 10 su, sw settings Subject: Re: raid 10 su, sw settings From: Brad Langhorst To: Justin Piszcz Cc: xfs@oss.sgi.com In-Reply-To: References: <1199059239.13944.65.camel@up> Content-Type: text/plain Date: Mon, 31 Dec 2007 13:43:06 -0500 Message-Id: <1199126586.3437.10.camel@up> Mime-Version: 1.0 X-Mailer: Evolution 2.21.4 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: pan.gwi.net[207.5.128.165] X-Barracuda-Start-Time: 1199126595 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38197 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5311/Mon Dec 31 09:05:08 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14063 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brad@langhorst.com Precedence: bulk X-list: xfs On Mon, 2007-12-31 at 12:04 -0500, Justin Piszcz wrote: > > > > Typical blocks/sec from iostat during large file movements is about > > 100M/s read and 80M/s write. > > > > #1 What type of performance do you expect with a 4-disk raid10? Are you saying that i should not expect more? I expect about 70% better performance, since I think a single disk should be able to do 100M/s. Maybe this is unreasonable? > #2 You should be able to umount/mount with the new sizes, although I have > not tested it myself b/c I typically use sw raid here (sunit/etc is > optimized for sw raid). I am able to do the remount, but it seems to have had no impact. I don't know why but I see 3 possibilities: - Perhaps because su/sw settings don't matter very much. - maybe it didn't take effect (rebooting this system is not a preferred option) - maybe it doesn't matter if the partition layout is not optimized. Brad From owner-xfs@oss.sgi.com Mon Dec 31 11:07:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 11:07:57 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVJ7iUu021562 for ; Mon, 31 Dec 2007 11:07:53 -0800 X-ASG-Debug-ID: 1199128079-05e000450000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 92CE44D10DA for ; Mon, 31 Dec 2007 11:07:59 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id Dv27Uq4qQ2kJ6RBz for ; Mon, 31 Dec 2007 11:07:59 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id C24731C00023B; Mon, 31 Dec 2007 14:07:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id BEC164019521; Mon, 31 Dec 2007 14:07:27 -0500 (EST) Date: Mon, 31 Dec 2007 14:07:27 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Brad Langhorst cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: raid 10 su, sw settings Subject: Re: raid 10 su, sw settings In-Reply-To: <1199126586.3437.10.camel@up> Message-ID: References: <1199059239.13944.65.camel@up> <1199126586.3437.10.camel@up> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1199128079 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38198 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5311/Mon Dec 31 09:05:08 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14064 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Mon, 31 Dec 2007, Brad Langhorst wrote: > > On Mon, 2007-12-31 at 12:04 -0500, Justin Piszcz wrote: > >>> >>> Typical blocks/sec from iostat during large file movements is about >>> 100M/s read and 80M/s write. >>> >> >> #1 What type of performance do you expect with a 4-disk raid10? > > Are you saying that i should not expect more? > I expect about 70% better performance, since I think a single disk > should be able to do 100M/s. Maybe this is unreasonable? A single disk may do 90MiB/s burst but not sustained for read or write, at least not cheap SATA disks and when you get toward the middle part of the disk the speed wil drop off significantly. 100MiB/s read and 80MiB/s write for RAID10 sounds about right to me. Maybe someone else on the list with a similar configuration can chime in with their benchmarks. > > >> #2 You should be able to umount/mount with the new sizes, although I have >> not tested it myself b/c I typically use sw raid here (sunit/etc is >> optimized for sw raid). > I am able to do the remount, but it seems to have had no impact. > I don't know why but I see 3 possibilities: > - Perhaps because su/sw settings don't matter very much. > - maybe it didn't take effect (rebooting this system is not a preferred > option) > - maybe it doesn't matter if the partition layout is not optimized. > > Brad > > From owner-xfs@oss.sgi.com Mon Dec 31 11:43:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 11:43:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_41 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVJhH42024164 for ; Mon, 31 Dec 2007 11:43:21 -0800 X-ASG-Debug-ID: 1199130211-1cc300340000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.mnsu.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 28427BD4E4B for ; Mon, 31 Dec 2007 11:43:31 -0800 (PST) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by cuda.sgi.com with ESMTP id sG7HvO1OP40ZnWdW for ; Mon, 31 Dec 2007 11:43:31 -0800 (PST) Received: from [134.29.32.1] (j3gum-3.ITS.MNSU.EDU [134.29.32.1]) by mail.mnsu.edu (8.13.7/8.13.7) with ESMTP id lBVJhU3r011864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 31 Dec 2007 13:43:30 -0600 Message-ID: <4779466E.40104@mnsu.edu> Date: Mon, 31 Dec 2007 13:43:42 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: [Fwd: linux-image-2.6.18-5-amd64 with 32bit userspace: xfs_fsr fails because ioctl32(xfs_fsr:15013): Unknown cmd] Subject: [Fwd: linux-image-2.6.18-5-amd64 with 32bit userspace: xfs_fsr fails because ioctl32(xfs_fsr:15013): Unknown cmd] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: Mail.MNSU.EDU[134.29.1.12] X-Barracuda-Start-Time: 1199130212 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38201 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M BODY: Custom Rule 7568M X-Virus-Scanned: ClamAV 0.91.2/5311/Mon Dec 31 09:05:08 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14065 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: xfs I just wanted to let you folks at sgi.com know I've recently sent this bug report to the Debian folks about their kernel. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458467 Sincerely, Jeffrey Hundstad -------- Original Message -------- Subject: linux-image-2.6.18-5-amd64 with 32bit userspace: xfs_fsr fails because ioctl32(xfs_fsr:15013): Unknown cmd Date: Mon, 31 Dec 2007 12:02:31 -0600 From: Jeffrey Hundstad To: Debian Bug Tracking System Package: linux-image-2.6.18-5-amd64 Version: 2.6.18.dfsg.1-17 Severity: normal The command xfs_fsr from package (xfsdump) which is used to defragment xfs filesystems fails to defragment the filesystem. Instead it errors with the following message indicating: ioctl32(xfs_fsr:15013): Unknown cmd fd(3) cmd(c01c5868){00} arg(ffa48c0c) on / The userspace is 32 bit. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages linux-image-2.6.18-5-amd64 depends on: ii cor 5.97-5.3 The GNU core utilities ii deb 1.5.11etch1 Debian configuration management sy ii e2f 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 ext2 file system utilities and lib ii ini 0.85h tools for generating an initramfs ii mod 3.3-pre4-2 tools for managing Linux kernel mo linux-image-2.6.18-5-amd64 recommends no packages. -- debconf information: * linux-image-2.6.18-5-amd64/postinst/create-kimage-link-2.6.18-5-amd64: false shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-5-amd64/postinst/old-system-map-link-2.6.18-5-amd64: true linux-image-2.6.18-5-amd64/preinst/initrd-2.6.18-5-amd64: linux-image-2.6.18-5-amd64/preinst/elilo-initrd-2.6.18-5-amd64: true linux-image-2.6.18-5-amd64/postinst/depmod-error-2.6.18-5-amd64: false linux-image-2.6.18-5-amd64/preinst/bootloader-initrd-2.6.18-5-amd64: true * linux-image-2.6.18-5-amd64/preinst/already-running-this-2.6.18-5-amd64: linux-image-2.6.18-5-amd64/prerm/removing-running-kernel-2.6.18-5-amd64: true * linux-image-2.6.18-5-amd64/preinst/lilo-initrd-2.6.18-5-amd64: false linux-image-2.6.18-5-amd64/preinst/abort-overwrite-2.6.18-5-amd64: linux-image-2.6.18-5-amd64/preinst/failed-to-move-modules-2.6.18-5-amd64: linux-image-2.6.18-5-amd64/prerm/would-invalidate-boot-loader-2.6.18-5-amd64: true linux-image-2.6.18-5-amd64/postinst/bootloader-error-2.6.18-5-amd64: linux-image-2.6.18-5-amd64/postinst/old-initrd-link-2.6.18-5-amd64: true linux-image-2.6.18-5-amd64/preinst/overwriting-modules-2.6.18-5-amd64: true linux-image-2.6.18-5-amd64/postinst/old-dir-initrd-link-2.6.18-5-amd64: true linux-image-2.6.18-5-amd64/preinst/lilo-has-ramdisk: linux-image-2.6.18-5-amd64/postinst/depmod-error-initrd-2.6.18-5-amd64: false linux-image-2.6.18-5-amd64/postinst/bootloader-test-error-2.6.18-5-amd64: linux-image-2.6.18-5-amd64/postinst/kimage-is-a-directory: linux-image-2.6.18-5-amd64/preinst/abort-install-2.6.18-5-amd64: From owner-xfs@oss.sgi.com Mon Dec 31 12:23:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 12:23:36 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVKNSKn031513 for ; Mon, 31 Dec 2007 12:23:32 -0800 X-ASG-Debug-ID: 1199132622-1cc3007a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 418AFBD5220 for ; Mon, 31 Dec 2007 12:23:42 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by cuda.sgi.com with ESMTP id QQ6xyGA2QuTdTWJn for ; Mon, 31 Dec 2007 12:23:42 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so2884370fga.8 for ; Mon, 31 Dec 2007 12:23:41 -0800 (PST) Received: by 10.86.62.3 with SMTP id k3mr12587963fga.15.1199132237428; Mon, 31 Dec 2007 12:17:17 -0800 (PST) Received: from teal.hq.k1024.org ( [84.75.114.75]) by mx.google.com with ESMTPS id 4sm10341485fge.8.2007.12.31.12.17.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Dec 2007 12:17:16 -0800 (PST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id C8CBA40A537; Mon, 31 Dec 2007 21:17:12 +0100 (CET) Date: Mon, 31 Dec 2007 21:17:12 +0100 From: Iustin Pop To: Justin Piszcz Cc: Brad Langhorst , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: raid 10 su, sw settings Subject: Re: raid 10 su, sw settings Message-ID: <20071231201712.GA3679@teal.hq.k1024.org> Mail-Followup-To: Justin Piszcz , Brad Langhorst , xfs@oss.sgi.com References: <1199059239.13944.65.camel@up> <1199126586.3437.10.camel@up> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.154] X-Barracuda-Start-Time: 1199132623 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38203 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5311/Mon Dec 31 09:05:08 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14066 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Mon, Dec 31, 2007 at 02:07:27PM -0500, Justin Piszcz wrote: > > > On Mon, 31 Dec 2007, Brad Langhorst wrote: > >> >> On Mon, 2007-12-31 at 12:04 -0500, Justin Piszcz wrote: >> >>>> >>>> Typical blocks/sec from iostat during large file movements is about >>>> 100M/s read and 80M/s write. >>>> >>> >>> #1 What type of performance do you expect with a 4-disk raid10? >> >> Are you saying that i should not expect more? >> I expect about 70% better performance, since I think a single disk >> should be able to do 100M/s. Maybe this is unreasonable? > A single disk may do 90MiB/s burst but not sustained for read or write, at > least not cheap SATA disks and when you get toward the middle part of the > disk the speed wil drop off significantly. 100MiB/s read and 80MiB/s write > for RAID10 sounds about right to me. Maybe someone else on the list with a > similar configuration can chime in with their benchmarks. I agree about the disk speed - 100MiB/s for SATA drives is a little bit too much to expect. And certainly, *only* in purely single-reader or single-writer sequential workloads. I have the same config - 4 drive hw raid10 on 9650. A recent zcav log shows read speeds start at around 140MiB/s and decrease toward 75MiB/s. Since this is zcav from the bonie++ package, it doesn't take into account any filesystem or partitioning overhead. regards, iustin From owner-xfs@oss.sgi.com Mon Dec 31 12:54:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 12:55:02 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVKsrHq001538 for ; Mon, 31 Dec 2007 12:54:55 -0800 X-ASG-Debug-ID: 1199134504-7acb00e40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pan.gwi.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C58F7BD557D for ; Mon, 31 Dec 2007 12:55:04 -0800 (PST) Received: from pan.gwi.net (pan.gwi.net [207.5.128.165]) by cuda.sgi.com with ESMTP id 9P3enyayhKV7rXok for ; Mon, 31 Dec 2007 12:55:04 -0800 (PST) Received: from strange.home.langhorst.com (bb-66-55-211-238.gwi.net [66.55.211.238]) by pan.gwi.net (8.13.1/8.13.1) with ESMTP id lBVKsvbY092771; Mon, 31 Dec 2007 15:55:02 -0500 (EST) (envelope-from brad@langhorst.com) Received: from up.home.langhorst.com ([192.168.10.13]) by strange.home.langhorst.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J9Rex-0000dY-WF; Mon, 31 Dec 2007 15:54:56 -0500 X-ASG-Orig-Subj: Re: raid 10 su, sw settings Subject: Re: raid 10 su, sw settings From: Brad Langhorst To: Iustin Pop Cc: xfs@oss.sgi.com In-Reply-To: <20071231201712.GA3679@teal.hq.k1024.org> References: <1199059239.13944.65.camel@up> <1199126586.3437.10.camel@up> <20071231201712.GA3679@teal.hq.k1024.org> Content-Type: text/plain Date: Mon, 31 Dec 2007 15:55:01 -0500 Message-Id: <1199134501.3437.21.camel@up> Mime-Version: 1.0 X-Mailer: Evolution 2.21.4 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: pan.gwi.net[207.5.128.165] X-Barracuda-Start-Time: 1199134508 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38205 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5311/Mon Dec 31 09:05:08 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14067 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brad@langhorst.com Precedence: bulk X-list: xfs On Mon, 2007-12-31 at 21:17 +0100, Iustin Pop wrote: > On Mon, Dec 31, 2007 at 02:07:27PM -0500, Justin Piszcz wrote: > > On Mon, 31 Dec 2007, Brad Langhorst wrote: > >> On Mon, 2007-12-31 at 12:04 -0500, Justin Piszcz wrote: > >> > >>>> > >>>> Typical blocks/sec from iostat during large file movements is about > >>>> 100M/s read and 80M/s write. > >>>> > >>> > >>> #1 What type of performance do you expect with a 4-disk raid10? > >> > >> Are you saying that i should not expect more? > >> I expect about 70% better performance, since I think a single disk > >> should be able to do 100M/s. Maybe this is unreasonable? > > A single disk may do 90MiB/s burst but not sustained for read or write, at > > least not cheap SATA disks and when you get toward the middle part of the > > disk the speed wil drop off significantly. 100MiB/s read and 80MiB/s write > > for RAID10 sounds about right to me. Maybe someone else on the list with a > > similar configuration can chime in with their benchmarks. > > I agree about the disk speed - 100MiB/s for SATA drives is a little bit > too much to expect. And certainly, *only* in purely single-reader or > single-writer sequential workloads. > > I have the same config - 4 drive hw raid10 on 9650. A recent zcav log > shows read speeds start at around 140MiB/s and decrease toward 75MiB/s. > Since this is zcav from the bonie++ package, it doesn't take into > account any filesystem or partitioning overhead. I guess I should re-adjust my expectations Any opinions on the partition layout? Did you go to special effort to layout your partitions on the stripe boundaries (actually i don't really understand this fully yet). From owner-xfs@oss.sgi.com Mon Dec 31 13:49:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 13:49:20 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVLn7wR005718 for ; Mon, 31 Dec 2007 13:49:15 -0800 X-ASG-Debug-ID: 1199137761-0a09017a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 15B4F4D183C for ; Mon, 31 Dec 2007 13:49:21 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by cuda.sgi.com with ESMTP id bDNpehV7nq9Opqk8 for ; Mon, 31 Dec 2007 13:49:21 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so2899521fga.8 for ; Mon, 31 Dec 2007 13:49:19 -0800 (PST) Received: by 10.86.80.5 with SMTP id d5mr12647208fgb.20.1199137346224; Mon, 31 Dec 2007 13:42:26 -0800 (PST) Received: from teal.hq.k1024.org ( [84.75.114.75]) by mx.google.com with ESMTPS id l12sm10367552fgb.9.2007.12.31.13.42.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Dec 2007 13:42:25 -0800 (PST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 2661640A537; Mon, 31 Dec 2007 22:42:23 +0100 (CET) Date: Mon, 31 Dec 2007 22:42:23 +0100 From: Iustin Pop To: Brad Langhorst Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: raid 10 su, sw settings Subject: Re: raid 10 su, sw settings Message-ID: <20071231214223.GB3679@teal.hq.k1024.org> Mail-Followup-To: Brad Langhorst , xfs@oss.sgi.com References: <1199059239.13944.65.camel@up> <1199126586.3437.10.camel@up> <20071231201712.GA3679@teal.hq.k1024.org> <1199134501.3437.21.camel@up> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1199134501.3437.21.camel@up> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.158] X-Barracuda-Start-Time: 1199137762 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38210 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5313/Mon Dec 31 12:52:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14068 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Mon, Dec 31, 2007 at 03:55:01PM -0500, Brad Langhorst wrote: > Any opinions on the partition layout? Did you go to special effort to > layout your partitions on the stripe boundaries (actually i don't really > understand this fully yet). So instead of the usual 255 heads, 63 cylinders fake geometry that is not a multiple of anything, I setup 16h/16c geometry that gives a nice power-of-two multiplier so all partitions *should* be aligned at a nice multiple of any size you choose; fdisk -l on the drive reports units of 128k. I have to say that the performance of the filesystem (XFS) on that raid10 is satisfactory and about what I expected. Certainly ~50MiB/s write while doing ~50MiB/s reads (for a combined, not purely sequential throughput of ~100MiB/s) is enough for my needs. regards, iustin From owner-xfs@oss.sgi.com Mon Dec 31 14:53:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 14:54:03 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBVMrtXB010740 for ; Mon, 31 Dec 2007 14:53:58 -0800 X-ASG-Debug-ID: 1199141649-2b8602760000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pan.gwi.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 88BB0BD5B5A for ; Mon, 31 Dec 2007 14:54:10 -0800 (PST) Received: from pan.gwi.net (pan.gwi.net [207.5.128.165]) by cuda.sgi.com with ESMTP id Ib3kUI3Kfs5n4tN5 for ; Mon, 31 Dec 2007 14:54:10 -0800 (PST) Received: from strange.home.langhorst.com (bb-66-55-211-238.gwi.net [66.55.211.238]) by pan.gwi.net (8.13.1/8.13.1) with ESMTP id lBVMs1U3012788; Mon, 31 Dec 2007 17:54:07 -0500 (EST) (envelope-from brad@langhorst.com) Received: from up.home.langhorst.com ([192.168.10.13]) by strange.home.langhorst.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J9TWB-0004u0-6x; Mon, 31 Dec 2007 17:53:59 -0500 X-ASG-Orig-Subj: Re: raid 10 su, sw settings Subject: Re: raid 10 su, sw settings From: Brad Langhorst To: Iustin Pop , xfs@oss.sgi.com In-Reply-To: <20071231214223.GB3679@teal.hq.k1024.org> References: <1199059239.13944.65.camel@up> <1199126586.3437.10.camel@up> <20071231201712.GA3679@teal.hq.k1024.org> <1199134501.3437.21.camel@up> <20071231214223.GB3679@teal.hq.k1024.org> Content-Type: text/plain Date: Mon, 31 Dec 2007 17:54:04 -0500 Message-Id: <1199141644.3437.24.camel@up> Mime-Version: 1.0 X-Mailer: Evolution 2.21.4 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: pan.gwi.net[207.5.128.165] X-Barracuda-Start-Time: 1199141650 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38213 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5313/Mon Dec 31 12:52:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14069 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brad@langhorst.com Precedence: bulk X-list: xfs On Mon, 2007-12-31 at 22:42 +0100, Iustin Pop wrote: > On Mon, Dec 31, 2007 at 03:55:01PM -0500, Brad Langhorst wrote: > > Any opinions on the partition layout? Did you go to special effort to > > layout your partitions on the stripe boundaries (actually i don't really > > understand this fully yet). > > So instead of the usual 255 heads, 63 cylinders fake geometry that is > not a multiple of anything, I setup 16h/16c geometry that gives a nice > power-of-two multiplier so all partitions *should* be aligned at a nice > multiple of any size you choose; fdisk -l on the drive reports units of > 128k. Sorry to be thick... i don't understand this. Do you configure the raid controller with these settings? or is this an fdisk option? thanks! brad From owner-xfs@oss.sgi.com Mon Dec 31 17:16:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Dec 2007 17:16: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=-0.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m011Gevs024341 for ; Mon, 31 Dec 2007 17:16:46 -0800 X-ASG-Debug-ID: 1199150213-367a00340000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 36DD34D1FA9 for ; Mon, 31 Dec 2007 17:16:53 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by cuda.sgi.com with ESMTP id GVEBcxRyMAyjcZnw for ; Mon, 31 Dec 2007 17:16:53 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so2937048fga.8 for ; Mon, 31 Dec 2007 17:16:52 -0800 (PST) Received: by 10.86.65.11 with SMTP id n11mr4032249fga.4.1199146507609; Mon, 31 Dec 2007 16:15:07 -0800 (PST) Received: from teal.hq.k1024.org ( [84.75.114.75]) by mx.google.com with ESMTPS id 4sm10447000fge.8.2007.12.31.16.15.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Dec 2007 16:15:06 -0800 (PST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 063F040A861; Tue, 1 Jan 2008 01:15:04 +0100 (CET) Date: Tue, 1 Jan 2008 01:15:04 +0100 From: Iustin Pop To: Brad Langhorst Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: raid 10 su, sw settings Subject: Re: raid 10 su, sw settings Message-ID: <20080101001504.GA12559@teal.hq.k1024.org> Mail-Followup-To: Brad Langhorst , xfs@oss.sgi.com References: <1199059239.13944.65.camel@up> <1199126586.3437.10.camel@up> <20071231201712.GA3679@teal.hq.k1024.org> <1199134501.3437.21.camel@up> <20071231214223.GB3679@teal.hq.k1024.org> <1199141644.3437.24.camel@up> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1199141644.3437.24.camel@up> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.158] X-Barracuda-Start-Time: 1199150215 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38224 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5322/Mon Dec 31 17:04:42 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14070 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Mon, Dec 31, 2007 at 05:54:04PM -0500, Brad Langhorst wrote: > > On Mon, 2007-12-31 at 22:42 +0100, Iustin Pop wrote: > > On Mon, Dec 31, 2007 at 03:55:01PM -0500, Brad Langhorst wrote: > > > Any opinions on the partition layout? Did you go to special effort to > > > layout your partitions on the stripe boundaries (actually i don't really > > > understand this fully yet). > > > > So instead of the usual 255 heads, 63 cylinders fake geometry that is > > not a multiple of anything, I setup 16h/16c geometry that gives a nice > > power-of-two multiplier so all partitions *should* be aligned at a nice > > multiple of any size you choose; fdisk -l on the drive reports units of > > 128k. > Sorry to be thick... i don't understand this. > Do you configure the raid controller with these settings? or is this an > fdisk option? Note: I'm not even sure it matters, or if I did it right :) It's an fdisk option. For example, "fdisk -H 16 -S 16 /dev/sdX". Also, happy new year! iustin