From owner-linux-xfs@oss.sgi.com Wed Jun 1 07:08:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 07:08:47 -0700 (PDT) Received: from relay01.uchicago.edu (relay01.uchicago.edu [128.135.12.136]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51E8fXq013774 for ; Wed, 1 Jun 2005 07:08:42 -0700 Received: from [128.135.92.53] (moviemac.bsd.uchicago.edu [128.135.92.53]) by relay01.uchicago.edu (8.12.10/8.12.9) with ESMTP id j51E7hKx001424; Wed, 1 Jun 2005 09:07:43 -0500 (CDT) In-Reply-To: <325673.f49b164f31c289627bd3b6908b08b9e3.ANY@taniwha.stupidest.org> References: <9c4afc4cfd08b8eb6fa84f701c776c5c@uchicago.edu> <325673.f49b164f31c289627bd3b6908b08b9e3.ANY@taniwha.stupidest.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2c5f2f842bf892c64cdfc446bbbc3920@uchicago.edu> Content-Transfer-Encoding: 7bit Cc: linux-xfs@oss.sgi.com From: Xander Meadow Subject: Re: getting data from a corrupted file system Date: Wed, 1 Jun 2005 09:07:43 -0500 To: Chris Wedgwood X-Mailer: Apple Mail (2.622) X-archive-position: 5350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xmeadow@uchicago.edu Precedence: bulk X-list: linux-xfs > I've done a bit of this from time to time. It depends how stuck you > are and how much effort you want to spend as to whether this is worth > your while. Well as my personal time is worth nearly nothing I'm willing to try a bunch of stuff to get this back, so any and all suggestions you have I'll be willing to try. > As I said on the list, try xfs_repair and make sure it has enough > memory. Make sure you have a recent xfs_repair too. I'm pretty sure we have a recent version of xfs_repair because the tech guy at consensys sent me a xfs_repair update, and then he modified that version so that it would skip an Assertion error that was causing xfs_repair to stop. > how much memory does the system have? have you tried making sure > there is enough swap? from /proc/meminfo: total: used: free: shared: buffers: cached: Mem: 3962441728 919121920 3043319808 0 63930368 361832448 Swap: 2138537984 0 2138537984 MemTotal: 3869572 kB MemFree: 2971992 kB ... SwapTotal: 2088416 kB SwapFree: 2088416 kB It seems like this should be enough memory if everything is running okay, right? >> What I'm wondering is, is there any way for me to get my data back? > > probably --- i just wonder how much memory xfs_repair is trying to use > Is there a way I can find this out and reply back to you? Thanks so much for all your help, I'll take any and all advice at this point. >Xander From owner-linux-xfs@oss.sgi.com Wed Jun 1 07:11:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 07:11:58 -0700 (PDT) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51EBqXq014189 for ; Wed, 1 Jun 2005 07:11:53 -0700 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id j51EAvGm026104 for ; Wed, 1 Jun 2005 10:10:57 -0400 (EDT) Date: Wed, 1 Jun 2005 10:10:57 -0400 (EDT) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: reserved blocks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Hi, Is there any way to specify reserved blocks under XFS? I mean similarly to ext2/ext3, where one was able to specify that e.g. only 95% can be used, 5% is reserved for the root. It seems to me that this option is not available with XFS, and probably there is a reason for it. Cheers Gaspar From owner-linux-xfs@oss.sgi.com Wed Jun 1 11:06:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 11:06:39 -0700 (PDT) Received: from web32509.mail.mud.yahoo.com (web32509.mail.mud.yahoo.com [68.142.207.219]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j51I6YXq030973 for ; Wed, 1 Jun 2005 11:06:34 -0700 Received: (qmail 68935 invoked by uid 60001); 1 Jun 2005 18:05:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ATkGNrAv/rOyupdm8YtGpqlKemQhaStWQa9Uah82K/l78MmaV9eUD4uGFRAKjW8KIZXnOIJrnCMnXopUsQGg7fLOtXrDDLg9eA1KeGags6tZM/73tujT/AptYPAsuAZxjCmPWTAsftlqLZblfg395M++2lV+2ioiAiHw8+dOci0= ; Message-ID: <20050601180538.68933.qmail@web32509.mail.mud.yahoo.com> Received: from [216.52.22.7] by web32509.mail.mud.yahoo.com via HTTP; Wed, 01 Jun 2005 11:05:38 PDT Date: Wed, 1 Jun 2005 11:05:38 -0700 (PDT) From: Ravi Wijayaratne Subject: XFS file system crash with SUSE SLES 8 To: suse-sles-e@suse.com, linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 5352 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: linux-xfs Hi all We are running Suse SLES8 2.4.21-138 kernel with XFS 1.3. We see the following XFS crash in our syslog. kernel: xfs_inotobp: xfs_imap() returned an error 22 on lvm(58,0). Returning error. kernel: xfs_iunlink_remove: xfs_inotobp() returned an error 22 on lvm(58,0). Returning error. kernel: xfs_inactive:^Ixfs_ifree() returned an error = 22 on lvm(58,0) kernel: xfs_force_shutdown(lvm(58,0),0x1) called from line 1866 of file xfs_vnodeops.c. Return address = 0xc020941b kernel: Filesystem "lvm(58,0)": I/O Error Detected. Shutting down filesystem: lvm(58,0) kernel: Please umount the filesystem, and rectify the problem(s) Here are the steps we used to reproduce the problem. 1. Creare 3 RAID 5 sets. 2. Group these 3 RAID sets to one large physical volume 3. Create an XFS file system on it 4. Run dbench -c ./client.txt 64 5. Within 10 minutes the file system crashes. Having dropped in to KDB I see that the problem occur in xfs_iunlink_remove() I think it is expected that the unlinked inode number be either in the agi->agi_unlinked[..] array or if not xfs_dinode_t->di_next_unlinked list ( first item has the refernce fro, agi_unlinked array). How ever in this case the xfs_dinode_t->di_nlink is 0 and the agi_unlinked array is filled up with 0xFFFFFFFF or I gather NULLAGINO. The agi seem to be sensible judging from the Magic number. So it seem that some inode got escaped from the unlink process. How that would happen is beyond me. Any insights would be very helpful. The problem seem to be very similar to http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 Thanks in advance. Ravi ------------------------------ Ravi Wijayaratne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-linux-xfs@oss.sgi.com Wed Jun 1 16:16:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 16:16:03 -0700 (PDT) Received: from sbapexch02.ad.corp.expertcity.com (68-111-37-8.corp.expertcity.com [68.111.37.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51NG0Xq021719 for ; Wed, 1 Jun 2005 16:16:00 -0700 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: False No space left on device error Date: Wed, 1 Jun 2005 16:15:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: False No space left on device error Thread-Index: AcVm/9Q7onQP+h+HQmOLepnj73meFA== From: "Michael Ramsey" To: Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 744 X-archive-position: 5353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Ramsey@citrix.com Precedence: bulk X-list: linux-xfs logfs2.nyc#uname -a Linux logfs2.nyc 2.6.11-1.27_FC3smp #1 SMP Tue May 17 20:38:05 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux logfs2.nyc#df -h /dev/mapper/raidvol-vol1 9.0T 7.1T 2.0T 79% /u01 logfs2.nyc#rpm -qa |grep xfs xfsprogs-2.6.13-2 logfs2.nyc#df -i /dev/mapper/raidvol-vol1 8236943008 3834112 8233108896 1% /u01 logfs2.nyc#cd /u01 logfs2.nyc#rm a rm: remove regular empty file `a'? y logfs2.nyc#touch a logfs2.nyc#touch b touch: cannot touch `b': No space left on device logfs2.nyc#rm a rm: remove regular empty file `a'? y logfs2.nyc#touch b logfs2.nyc#touch a touch: cannot touch `a': No space left on device Logfs2.nyc#mount /dev/mapper/raidvol-vol1 on /u01 type xfs (rw) Michael Ramsey [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Jun 1 16:36:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 16:36:46 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51NahXq026691 for ; Wed, 1 Jun 2005 16:36:43 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j521MXf1003788 for ; Wed, 1 Jun 2005 18:22:33 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j51NZgad60126335; Wed, 1 Jun 2005 16:35:43 -0700 (PDT) Message-ID: <429E4650.7070404@sgi.com> Date: Wed, 01 Jun 2005 18:35:44 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Chris Wedgwood Subject: Re: out of the tree compilation and 4KSTACKS References: <20050531074820.GM8770@neu.nirvana> <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> <20050531215402.GE23991@neu.nirvana> In-Reply-To: <20050531215402.GE23991@neu.nirvana> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Axel Thimm wrote: > On Tue, May 31, 2005 at 02:28:23PM -0700, Chris Wedgwood wrote: > >>On Tue, May 31, 2005 at 09:48:20AM +0200, Axel Thimm wrote: >> >> >>>is it possible to add xfs support to a 2.6.9 kernel (e.g. the RHEL4 >>>kernel) as an external kernel module? >> >>yes > > > Hm, any pointers to "how"? ;) > I've been looking at doing just this; I have a patch that lets xfs build as an out-of-tree 2.6 module. I'll send it to you off list, ok? The tricky part is getting all the xfs config options communicated to the xfs build. Ultimately it'd be nice to have a src.rpm like those on livna.org & other place that can easily be rebuilt against various kernels, maybe with xfs config options as --defines to the build.... >>>Would that make sense w/ 4KSTACKS? >> >>it does but it won't give you 8K stacks, the stack size is a property >>of the kernel and modules will inherit this > > > Sure, that's clear. What I mean is: If you turn on xfs in RHEL4's > kernel is it considered safe with 4KSTACKS? If not, that would make > the whole point of building the kernel modules out of the tree > meaningless. > > lkml and this list sometimes consider NFS & XFS a dangerous > combination stackwise. Urban legend or is there truth to it? with 4kstacks, any layering of xfs over/under other systems has the potential for danger. There are probably still a couple things we could do to reduce some of the individual large-stack functions, too. Do you have x86_64 support planned? Stack shouldn't be quite such a big issue there. -Eric From owner-linux-xfs@oss.sgi.com Wed Jun 1 16:40:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 16:40:06 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51Ne2Xq027182 for ; Wed, 1 Jun 2005 16:40:03 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j521Pqlq004250 for ; Wed, 1 Jun 2005 18:25:52 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j51Nd4ad51419641; Wed, 1 Jun 2005 16:39:05 -0700 (PDT) Message-ID: <429E471A.8050601@sgi.com> Date: Wed, 01 Jun 2005 18:39:06 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Ramsey CC: linux-xfs@oss.sgi.com Subject: Re: False No space left on device error References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs My best guess is that this is the inode32 allocator running out of < 2T blocks to allocate inodes... I'd have to think about how to prove this theory. -Eric Michael Ramsey wrote: > logfs2.nyc#uname -a > Linux logfs2.nyc 2.6.11-1.27_FC3smp #1 SMP Tue May 17 > 20:38:05 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux > > logfs2.nyc#df -h > /dev/mapper/raidvol-vol1 9.0T 7.1T 2.0T 79% /u01 > > logfs2.nyc#rpm -qa |grep xfs > xfsprogs-2.6.13-2 > > logfs2.nyc#df -i > /dev/mapper/raidvol-vol1 8236943008 3834112 8233108896 > 1% /u01 > > logfs2.nyc#cd /u01 > logfs2.nyc#rm a > rm: remove regular empty file `a'? y > logfs2.nyc#touch a > logfs2.nyc#touch b > touch: cannot touch `b': No space left on device > logfs2.nyc#rm a > rm: remove regular empty file `a'? y > logfs2.nyc#touch b > logfs2.nyc#touch a > touch: cannot touch `a': No space left on device > > Logfs2.nyc#mount > /dev/mapper/raidvol-vol1 on /u01 type xfs (rw) > > > Michael Ramsey > > > > > [[HTML alternate version deleted]] > From owner-linux-xfs@oss.sgi.com Wed Jun 1 16:40:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 16:40:31 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51NeRXq027397 for ; Wed, 1 Jun 2005 16:40:28 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j521QHpg004341 for ; Wed, 1 Jun 2005 18:26:17 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j51NdSad60046484; Wed, 1 Jun 2005 16:39:30 -0700 (PDT) Message-ID: <429E4732.50802@sgi.com> Date: Wed, 01 Jun 2005 18:39:30 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gbakos@cfa.harvard.edu CC: linux-xfs@oss.sgi.com Subject: Re: reserved blocks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Gaspar Bakos wrote: > Hi, > > Is there any way to specify reserved blocks under XFS? > > I mean similarly to ext2/ext3, where one was able to specify that e.g. > only 95% can be used, 5% is reserved for the root. > > It seems to me that this option is not available with XFS, and probably > there is a reason for it. It is not available, because it was never written, I think. :) -Eric From owner-linux-xfs@oss.sgi.com Wed Jun 1 16:40:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 16:40:46 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51NebXq027536 for ; Wed, 1 Jun 2005 16:40:37 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.4/8.13.4/Debian-1) with ESMTP id j51MZnMx018460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2005 17:35:50 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.4/8.13.4/Submit) with ESMTP id j51MZnXe018457; Wed, 1 Jun 2005 17:35:49 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Wed, 1 Jun 2005 17:35:49 -0500 (EST) From: Net Llama! To: Michael Ramsey cc: linux-xfs@oss.sgi.com Subject: Re: False No space left on device error In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Wed, 01 Jun 2005 17:35:50 -0500 Received-SPF: pass (mail.linux-sxs.org: domain of netllama@linux-sxs.org designates 127.0.0.1 as permitted sender) receiver=mail.linux-sxs.org; client-ip=127.0.0.1; helo=mail.linux-sxs.org; envelope-from=netllama@linux-sxs.org; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; X-archive-position: 5357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Have you run xfs_repair on this partition? On Wed, 1 Jun 2005, Michael Ramsey wrote: > logfs2.nyc#uname -a > Linux logfs2.nyc 2.6.11-1.27_FC3smp #1 SMP Tue May 17 > 20:38:05 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux > > logfs2.nyc#df -h > /dev/mapper/raidvol-vol1 9.0T 7.1T 2.0T 79% /u01 > > logfs2.nyc#rpm -qa |grep xfs > xfsprogs-2.6.13-2 > > logfs2.nyc#df -i > /dev/mapper/raidvol-vol1 8236943008 3834112 8233108896 > 1% /u01 > > logfs2.nyc#cd /u01 > logfs2.nyc#rm a > rm: remove regular empty file `a'? y > logfs2.nyc#touch a > logfs2.nyc#touch b > touch: cannot touch `b': No space left on device > logfs2.nyc#rm a > rm: remove regular empty file `a'? y > logfs2.nyc#touch b > logfs2.nyc#touch a > touch: cannot touch `a': No space left on device > > Logfs2.nyc#mount > /dev/mapper/raidvol-vol1 on /u01 type xfs (rw) > > > Michael Ramsey > > > > > [[HTML alternate version deleted]] > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Wed Jun 1 16:43:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 16:43:31 -0700 (PDT) Received: from sbapexch02.ad.corp.expertcity.com (68-111-37-8.corp.expertcity.com [68.111.37.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51NhRXq028416 for ; Wed, 1 Jun 2005 16:43:27 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: False No space left on device error Date: Wed, 1 Jun 2005 16:43:05 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: False No space left on device error Thread-Index: AcVnA0J7funfyhvgTySyHcM6ZWP1bwAACzdA From: "Michael Ramsey" To: "Net Llama!" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j51NhRXq028418 X-archive-position: 5358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Ramsey@citrix.com Precedence: bulk X-list: linux-xfs Yes. The error returns. Could this be a 8K stack issue under Fedora x86_64? Michael Ramsey -----Original Message----- From: Net Llama! [mailto:netllama@linux-sxs.org] Sent: Wednesday, June 01, 2005 3:36 PM To: Michael Ramsey Cc: linux-xfs@oss.sgi.com Subject: Re: False No space left on device error Have you run xfs_repair on this partition? On Wed, 1 Jun 2005, Michael Ramsey wrote: > logfs2.nyc#uname -a > Linux logfs2.nyc 2.6.11-1.27_FC3smp #1 SMP Tue May 17 > 20:38:05 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux > > logfs2.nyc#df -h > /dev/mapper/raidvol-vol1 9.0T 7.1T 2.0T 79% /u01 > > logfs2.nyc#rpm -qa |grep xfs > xfsprogs-2.6.13-2 > > logfs2.nyc#df -i > /dev/mapper/raidvol-vol1 8236943008 3834112 8233108896 1% /u01 > > logfs2.nyc#cd /u01 > logfs2.nyc#rm a > rm: remove regular empty file `a'? y > logfs2.nyc#touch a > logfs2.nyc#touch b > touch: cannot touch `b': No space left on device logfs2.nyc#rm a > rm: remove regular empty file `a'? y > logfs2.nyc#touch b > logfs2.nyc#touch a > touch: cannot touch `a': No space left on device > > Logfs2.nyc#mount > /dev/mapper/raidvol-vol1 on /u01 type xfs (rw) > > > Michael Ramsey > > > > > [[HTML alternate version deleted]] > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Wed Jun 1 16:45:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 16:45:48 -0700 (PDT) Received: from sbapexch02.ad.corp.expertcity.com (68-111-37-8.corp.expertcity.com [68.111.37.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51NjjXq028974 for ; Wed, 1 Jun 2005 16:45:45 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: False No space left on device error Date: Wed, 1 Jun 2005 16:45:26 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: False No space left on device error Thread-Index: AcVnAzGVoxBqtJ9/S8C+TdksODBrpwAAJf+g From: "Michael Ramsey" To: "Eric Sandeen" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j51NjjXq028976 X-archive-position: 5359 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Ramsey@citrix.com Precedence: bulk X-list: linux-xfs Even under the x86_64 kernel? Michael Ramsey -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Wednesday, June 01, 2005 4:39 PM To: Michael Ramsey Cc: linux-xfs@oss.sgi.com Subject: Re: False No space left on device error My best guess is that this is the inode32 allocator running out of < 2T blocks to allocate inodes... I'd have to think about how to prove this theory. -Eric Michael Ramsey wrote: > logfs2.nyc#uname -a > Linux logfs2.nyc 2.6.11-1.27_FC3smp #1 SMP Tue May 17 > 20:38:05 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux > > logfs2.nyc#df -h > /dev/mapper/raidvol-vol1 9.0T 7.1T 2.0T 79% /u01 > > logfs2.nyc#rpm -qa |grep xfs > xfsprogs-2.6.13-2 > > logfs2.nyc#df -i > /dev/mapper/raidvol-vol1 8236943008 3834112 8233108896 1% /u01 > > logfs2.nyc#cd /u01 > logfs2.nyc#rm a > rm: remove regular empty file `a'? y > logfs2.nyc#touch a > logfs2.nyc#touch b > touch: cannot touch `b': No space left on device logfs2.nyc#rm a > rm: remove regular empty file `a'? y > logfs2.nyc#touch b > logfs2.nyc#touch a > touch: cannot touch `a': No space left on device > > Logfs2.nyc#mount > /dev/mapper/raidvol-vol1 on /u01 type xfs (rw) > > > Michael Ramsey > > > > > [[HTML alternate version deleted]] > From owner-linux-xfs@oss.sgi.com Wed Jun 1 16:58:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 16:59:00 -0700 (PDT) Received: from junior.physik.fu-berlin.de (junior.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51NwsXq029991 for ; Wed, 1 Jun 2005 16:58:57 -0700 Received: from p54bd5c61.dip.t-dialin.net ([84.189.92.97] helo=puariko.homeip.net) by mail.atrpms.net with esmtps (TLSv1:AES256-SHA:256) (/C=DE/ST=Berlin/L=Berlin/O=nirvana)(verified=1) (Exim 4.51) id 1Ddd5p-00022K-IO; Thu, 02 Jun 2005 01:57:57 +0200 Received: (from thimm@localhost) by neu.nirvana (8.13.1/8.12.11/Submit) id j51Nviir019776; Thu, 2 Jun 2005 01:57:44 +0200 Date: Thu, 2 Jun 2005 01:57:43 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: Re: out of the tree compilation and 4KSTACKS Message-ID: <20050601235743.GB15449@neu.nirvana> Reply-To: linux-xfs@oss.sgi.com References: <20050531074820.GM8770@neu.nirvana> <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> <20050531215402.GE23991@neu.nirvana> <429E4650.7070404@sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline In-Reply-To: <429E4650.7070404@sgi.com> User-Agent: Mutt/1.4.2i X-HELO-Warning: Remote host 84.189.92.97 (p54bd5c61.dip.t-dialin.net) incorrectly presented itself as puariko.homeip.net X-Scanned: No viruses found. X-Scan-Signature: 6b039af5f0abeb93bf4ceeec8d48d017 X-archive-position: 5360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 01, 2005 at 06:35:44PM -0500, Eric Sandeen wrote: > Axel Thimm wrote: > >On Tue, May 31, 2005 at 02:28:23PM -0700, Chris Wedgwood wrote: > > > >>On Tue, May 31, 2005 at 09:48:20AM +0200, Axel Thimm wrote: > >> > >> > >>>is it possible to add xfs support to a 2.6.9 kernel (e.g. the RHEL4 > >>>kernel) as an external kernel module? > >> > >>yes > > > > > >Hm, any pointers to "how"? ;) > > >=20 > I've been looking at doing just this; I have a patch that lets xfs build= =20 > as an out-of-tree 2.6 module. I'll send it to you off list, ok? The=20 > tricky part is getting all the xfs config options communicated to the=20 > xfs build. Ultimately it'd be nice to have a src.rpm like those on=20 > livna.org & other place that can easily be rebuilt against various=20 > kernels, maybe with xfs config options as --defines to the build.... Why not have an xfs.config file as part of the src.rpms instead (that is cated to the .config file of the kernel built against)? People seem to hate --defines. :) And if one wants to change the config he can install the src.rpm, edit the config and rpmbuild -ba the specfile. > >>>Would that make sense w/ 4KSTACKS? > >> > >>it does but it won't give you 8K stacks, the stack size is a property > >>of the kernel and modules will inherit this > > > > > >Sure, that's clear. What I mean is: If you turn on xfs in RHEL4's > >kernel is it considered safe with 4KSTACKS? If not, that would make > >the whole point of building the kernel modules out of the tree > >meaningless. > > > >lkml and this list sometimes consider NFS & XFS a dangerous > >combination stackwise. Urban legend or is there truth to it? >=20 > with 4kstacks, any layering of xfs over/under other systems has the=20 > potential for danger. There are probably still a couple things we could= =20 > do to reduce some of the individual large-stack functions, too. That would be nice. The idea is to have the kmdl to plug into standard RHEL kernels, and to not constrain the system to not use NFS, LVM etc. > Do you have x86_64 support planned? Stack shouldn't be quite such a big= =20 > issue there. x86_64 is supported at ATrpms at the same level as i386 archs, but the requests hadn't been x86_64 specific, I think all were for i386 until now. I'd prefer a solution that works on both platforms (and even ppc as this is the next arch to include at ATrpms :). --=20 Axel.Thimm at ATrpms.net --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnkt3QBVS1GOamfERAo4gAJ4m9dwDqqwmM42EjyqmkZ9lQxyRZACfdabi 5O/5A+iqesekNhSEhOZpxms= =8rWg -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- From owner-linux-xfs@oss.sgi.com Wed Jun 1 19:20:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 19:20:41 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j522KcXq003956 for ; Wed, 1 Jun 2005 19:20:38 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5246SnT002466 for ; Wed, 1 Jun 2005 21:06:28 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j522Jead60156362; Wed, 1 Jun 2005 19:19:41 -0700 (PDT) Message-ID: <429E6CBF.6070701@sgi.com> Date: Wed, 01 Jun 2005 21:19:43 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Ramsey CC: linux-xfs@oss.sgi.com Subject: Re: False No space left on device error References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5361 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Michael Ramsey wrote: > Even under the x86_64 kernel? even that kernel uses 32 bit inodes by default... 64-bit inodes -should- be safe on x86_64; an interesting test would be to mount with the inode64 option & see if you can create another inode. Caveat, though - I can't say 64-bit inodes on x86_64 have had much/any testing... -Eric > Michael Ramsey > > > > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Wednesday, June 01, 2005 4:39 PM > To: Michael Ramsey > Cc: linux-xfs@oss.sgi.com > Subject: Re: False No space left on device error > > My best guess is that this is the inode32 allocator > running out of < 2T blocks to allocate inodes... I'd have > to think about how to prove this theory. > > -Eric > > Michael Ramsey wrote: > >>logfs2.nyc#uname -a >>Linux logfs2.nyc 2.6.11-1.27_FC3smp #1 SMP Tue May 17 >>20:38:05 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux >> >>logfs2.nyc#df -h >>/dev/mapper/raidvol-vol1 9.0T 7.1T 2.0T 79% /u01 >> >>logfs2.nyc#rpm -qa |grep xfs >>xfsprogs-2.6.13-2 >> >>logfs2.nyc#df -i >>/dev/mapper/raidvol-vol1 8236943008 3834112 8233108896 > > 1% /u01 > >>logfs2.nyc#cd /u01 >>logfs2.nyc#rm a >>rm: remove regular empty file `a'? y >>logfs2.nyc#touch a >>logfs2.nyc#touch b >>touch: cannot touch `b': No space left on device > > logfs2.nyc#rm a > >>rm: remove regular empty file `a'? y >>logfs2.nyc#touch b >>logfs2.nyc#touch a >>touch: cannot touch `a': No space left on device >> >>Logfs2.nyc#mount >>/dev/mapper/raidvol-vol1 on /u01 type xfs (rw) >> >> >>Michael Ramsey >> >> >> >> >>[[HTML alternate version deleted]] >> > > From owner-linux-xfs@oss.sgi.com Wed Jun 1 19:54:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 19:54:58 -0700 (PDT) Received: from sbapexch02.ad.corp.expertcity.com (68-111-37-8.corp.expertcity.com [68.111.37.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j522srXq005472 for ; Wed, 1 Jun 2005 19:54:53 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: False No space left on device error Date: Wed, 1 Jun 2005 19:54:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: False No space left on device error Thread-Index: AcVnGaFkPbev0klyQc+Br48pCEGsXgABEIfQ From: "Michael Ramsey" To: "Eric Sandeen" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j522ssXq005474 X-archive-position: 5362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Ramsey@citrix.com Precedence: bulk X-list: linux-xfs logfs2.nyc#mount /dev/mapper/raidvol-vol1 on /u01 type xfs (rw,inode64) logfs2.nyc#touch a logfs2.nyc#touch b logfs2.nyc#touch c logfs2.nyc#touch d Well looks like the initial test worked... What to do what to do... QA perhaps? I will run some tests and see if I lose any data... Will xfs_recover work with 64 bit inodes? Michael Ramsey -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Wednesday, June 01, 2005 7:20 PM To: Michael Ramsey Cc: linux-xfs@oss.sgi.com Subject: Re: False No space left on device error Michael Ramsey wrote: > Even under the x86_64 kernel? even that kernel uses 32 bit inodes by default... 64-bit inodes -should- be safe on x86_64; an interesting test would be to mount with the inode64 option & see if you can create another inode. Caveat, though - I can't say 64-bit inodes on x86_64 have had much/any testing... -Eric > Michael Ramsey > > > > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Wednesday, June 01, 2005 4:39 PM > To: Michael Ramsey > Cc: linux-xfs@oss.sgi.com > Subject: Re: False No space left on device error > > My best guess is that this is the inode32 allocator running out of < > 2T blocks to allocate inodes... I'd have to think about how to prove > this theory. > > -Eric > > Michael Ramsey wrote: > >>logfs2.nyc#uname -a >>Linux logfs2.nyc 2.6.11-1.27_FC3smp #1 SMP Tue May 17 >>20:38:05 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux >> >>logfs2.nyc#df -h >>/dev/mapper/raidvol-vol1 9.0T 7.1T 2.0T 79% /u01 >> >>logfs2.nyc#rpm -qa |grep xfs >>xfsprogs-2.6.13-2 >> >>logfs2.nyc#df -i >>/dev/mapper/raidvol-vol1 8236943008 3834112 8233108896 > > 1% /u01 > >>logfs2.nyc#cd /u01 >>logfs2.nyc#rm a >>rm: remove regular empty file `a'? y >>logfs2.nyc#touch a >>logfs2.nyc#touch b >>touch: cannot touch `b': No space left on device > > logfs2.nyc#rm a > >>rm: remove regular empty file `a'? y >>logfs2.nyc#touch b >>logfs2.nyc#touch a >>touch: cannot touch `a': No space left on device >> >>Logfs2.nyc#mount >>/dev/mapper/raidvol-vol1 on /u01 type xfs (rw) >> >> >>Michael Ramsey >> >> >> >> >>[[HTML alternate version deleted]] >> > > From owner-linux-xfs@oss.sgi.com Wed Jun 1 20:43:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 20:43:14 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j523hBXq010937 for ; Wed, 1 Jun 2005 20:43:11 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j525T0Na017355 for ; Wed, 1 Jun 2005 22:29:00 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j523fBad60181922; Wed, 1 Jun 2005 20:41:12 -0700 (PDT) Message-ID: <429E7FDA.7070307@sgi.com> Date: Wed, 01 Jun 2005 22:41:14 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Ramsey CC: linux-xfs@oss.sgi.com Subject: Re: False No space left on device error References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5363 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Michael Ramsey wrote: > logfs2.nyc#mount > /dev/mapper/raidvol-vol1 on /u01 type xfs (rw,inode64) > > logfs2.nyc#touch a > logfs2.nyc#touch b > logfs2.nyc#touch c > logfs2.nyc#touch d > > Well looks like the initial test worked... great, I thought that was probably it. > What to do > what to do... QA perhaps? > > I will run some tests and see if I lose any data... you can use the undocumented/unsupported/non-production "ino64" option to force all inodes into 64-bit range, and test them on a (smaller) scratch fs. I expect that it'll be fine but testing is good. > Will xfs_recover work with 64 bit inodes? all the xfs tools should be fine w/ 64-bit inodes on a 64-bit system. (Hm, but opteron is tricky, were they built as 64-bit?) -Eric > Michael Ramsey > > From owner-linux-xfs@oss.sgi.com Wed Jun 1 20:50:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jun 2005 20:50:18 -0700 (PDT) Received: from bruce.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j523oCXq011517 for ; Wed, 1 Jun 2005 20:50:12 -0700 Received: by bruce.melbourne.sgi.com (Postfix, from userid 38403) id 1379659A52; Thu, 2 Jun 2005 13:37:40 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfstests Message-Id: <20050602033740.1379659A52@bruce.melbourne.sgi.com> Date: Thu, 2 Jun 2005 13:37:40 +1000 (EST) From: fsgqa@bruce.melbourne.sgi.com (FSG QA) X-archive-position: 5364 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Add three additional quota tests - 106/107/108. Date: Thu Jun 2 13:48:44 AEST 2005 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22775a xfstests/106 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/106 xfstests/106.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/106.out xfstests/107 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/107 xfstests/107.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/107.out xfstests/108 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/108 xfstests/108.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/108.out xfstests/common.quota - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/common.quota.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h xfstests/group - 1.75 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/group.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h From owner-linux-xfs@oss.sgi.com Thu Jun 2 02:08:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 02:08:09 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5297xXq031063 for ; Thu, 2 Jun 2005 02:07:59 -0700 Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j5296fPA096758; Thu, 2 Jun 2005 05:06:41 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 251A5529BBC; Thu, 2 Jun 2005 02:06:41 -0700 (PDT) Date: Thu, 2 Jun 2005 02:06:41 -0700 From: Chris Wedgwood To: Robin Humble Cc: linux-xfs@oss.sgi.com, Wayne Steenburg , sonny@burdell.org Subject: Re: XFS module for RHEL4 Message-ID: <620614.d53037961dceb73fbe2a31af34e1bb64.ANY@taniwha.stupidest.org> References: <1117576633.5018.12.camel@FC3Work> <20050601035347.GB20301@kevlar.burdell.org> <20050601061802.GB7359@lemming.cita.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601061802.GB7359@lemming.cita.utoronto.ca> X-archive-position: 5365 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Wed, Jun 01, 2005 at 02:18:02AM -0400, Robin Humble wrote: > if you want 8k stacks as well (highly recommended for servers) then > unfortunately it's not quite that simple. you need to stop some of > the RedHat patches being applied RH is aware of this and the next release will correct this > as (for some unknown and possibly insane reason) RedHat removed the > 8k stack option entirely... I wasn't aware of that. I'll ask next time I remember. > OTOH, I run fc3 at home with the default kernel (4k stacks) and XFS > and it's very stable. So for simple workloads and setups 4k stacks > are usually fine. XFS on most IDE/SCSI drives with RAID, dm, LVM, etc. should be OK. From owner-linux-xfs@oss.sgi.com Thu Jun 2 02:21:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 02:21:36 -0700 (PDT) Received: from kevlar.burdell.org (66-23-228-155.clients.speedfactory.net [66.23.228.155]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j529LXXq031899 for ; Thu, 2 Jun 2005 02:21:33 -0700 Received: by kevlar.burdell.org (Postfix, from userid 1189) id 7172566C82; Thu, 2 Jun 2005 04:57:03 -0400 (EDT) Date: Thu, 2 Jun 2005 04:57:03 -0400 From: Sonny Rao To: Chris Wedgwood Cc: Robin Humble , linux-xfs@oss.sgi.com, Wayne Steenburg Subject: Re: XFS module for RHEL4 Message-ID: <20050602085703.GA20593@kevlar.burdell.org> References: <1117576633.5018.12.camel@FC3Work> <20050601035347.GB20301@kevlar.burdell.org> <20050601061802.GB7359@lemming.cita.utoronto.ca> <620614.d53037961dceb73fbe2a31af34e1bb64.ANY@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <620614.d53037961dceb73fbe2a31af34e1bb64.ANY@taniwha.stupidest.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 5366 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sonny@burdell.org Precedence: bulk X-list: linux-xfs On Thu, Jun 02, 2005 at 02:06:41AM -0700, Chris Wedgwood wrote: > > OTOH, I run fc3 at home with the default kernel (4k stacks) and XFS > > and it's very stable. So for simple workloads and setups 4k stacks > > are usually fine. > > XFS on most IDE/SCSI drives with RAID, dm, LVM, etc. should be OK. > Is it just when you have XFS + LVM + NFS that the stack problems show up the most? I've used XFS + NFS on a 4k-stack kernel w/out any problems. Sonny From owner-linux-xfs@oss.sgi.com Thu Jun 2 02:29:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 02:29:51 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j529TmXq032409 for ; Thu, 2 Jun 2005 02:29:48 -0700 Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j529SiPA152410; Thu, 2 Jun 2005 05:28:47 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 56833529BBC; Thu, 2 Jun 2005 02:28:44 -0700 (PDT) Date: Thu, 2 Jun 2005 02:28:44 -0700 From: Chris Wedgwood To: Sonny Rao Cc: Robin Humble , linux-xfs@oss.sgi.com, Wayne Steenburg Subject: Re: XFS module for RHEL4 Message-ID: <910319.0b209f40c6a01d757bbb332879c42ead.IBX@taniwha.stupidest.org> References: <1117576633.5018.12.camel@FC3Work> <20050601035347.GB20301@kevlar.burdell.org> <20050601061802.GB7359@lemming.cita.utoronto.ca> <620614.d53037961dceb73fbe2a31af34e1bb64.ANY@taniwha.stupidest.org> <20050602085703.GA20593@kevlar.burdell.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050602085703.GA20593@kevlar.burdell.org> X-archive-position: 5367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Jun 02, 2005 at 04:57:03AM -0400, Sonny Rao wrote: > Is it just when you have XFS + LVM + NFS that the stack problems > show up the most? I've used XFS + NFS on a 4k-stack kernel w/out > any problems. the more things "in the chain" (stacked as it were) the more likely problems will occur. how bad each component is and how many are needed i'm not sure. From owner-linux-xfs@oss.sgi.com Thu Jun 2 05:53:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 05:53:26 -0700 (PDT) Received: from flyingAngel.upjs.sk (gw.hotelstep.cz [194.213.195.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52CrJXq013846 for ; Thu, 2 Jun 2005 05:53:22 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 8666510015E; Thu, 2 Jun 2005 14:52:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 851FF180122; Thu, 2 Jun 2005 14:52:07 +0200 (CEST) Date: Thu, 2 Jun 2005 14:52:07 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: False No space left on device error In-Reply-To: <429E7FDA.7070307@sgi.com> Message-ID: References: <429E7FDA.7070307@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs On Wed, 1 Jun 2005, Eric Sandeen wrote: Hi. > you can use the undocumented/unsupported/non-production "ino64" option to > force all inodes into 64-bit range, and test them on a (smaller) scratch fs. > I expect that it'll be fine but testing is good. Can you explain difference between ino64 and inode64 options? Comments in source says: "ino64" /* force inodes into 64-bit range */ "inode64" /* inodes can be allocated anywhere */ Is it possible to explain it little bit more? There is no info in xfs.txt. Thanks. Jan -- From owner-linux-xfs@oss.sgi.com Thu Jun 2 06:20:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 06:20:17 -0700 (PDT) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52DKDXq017473 for ; Thu, 2 Jun 2005 06:20:13 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Jun 2005 06:19:16 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Jun 2005 06:19:16 -0700 Message-ID: <429F0753.5010403@xfs.org> Date: Thu, 02 Jun 2005 08:19:15 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jan Derfinak CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: False No space left on device error References: <429E7FDA.7070307@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2005 13:19:16.0626 (UTC) FILETIME=[AD4CE720:01C56775] X-archive-position: 5370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs ino64 is a test option, it deliberately adds a large number to inode values so that it is possible to test that the inode handling is 64 bit clean without buying a few Tbytes of disk (which would have been very expensive when the code was written). It should not be used outside of testing. inode64 is a hack to force xfs to keep inodes down in the start of the filesystem where the inode numbers (which are disk addresses really) do not overflow 32 bits. This is for systems which cannot cope with larger inodes. There are also 3rd party backup applications which barf on large inode numbers, networker was the one I remember. Steve Jan Derfinak wrote: > On Wed, 1 Jun 2005, Eric Sandeen wrote: > > Hi. > > >>you can use the undocumented/unsupported/non-production "ino64" option to >>force all inodes into 64-bit range, and test them on a (smaller) scratch fs. >>I expect that it'll be fine but testing is good. > > > Can you explain difference between ino64 and inode64 options? > Comments in source says: > "ino64" /* force inodes into 64-bit range */ > "inode64" /* inodes can be allocated anywhere */ > > Is it possible to explain it little bit more? There is no info in xfs.txt. > > Thanks. > > Jan > From owner-linux-xfs@oss.sgi.com Thu Jun 2 06:27:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 06:28:00 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52DRrXq017996 for ; Thu, 2 Jun 2005 06:27:53 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j52DQuxT011669 for ; Thu, 2 Jun 2005 08:26:56 -0500 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j52DQsad60308987; Thu, 2 Jun 2005 06:26:55 -0700 (PDT) Message-ID: <429F091E.6090105@sgi.com> Date: Thu, 02 Jun 2005 08:26:54 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jan Derfinak CC: linux-xfs@oss.sgi.com Subject: Re: False No space left on device error References: <429E7FDA.7070307@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5371 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Jan Derfinak wrote: > On Wed, 1 Jun 2005, Eric Sandeen wrote: > > Hi. > > >>you can use the undocumented/unsupported/non-production "ino64" option to >>force all inodes into 64-bit range, and test them on a (smaller) scratch fs. >>I expect that it'll be fine but testing is good. > > > Can you explain difference between ino64 and inode64 options? > Comments in source says: > "ino64" /* force inodes into 64-bit range */ > "inode64" /* inodes can be allocated anywhere */ > > Is it possible to explain it little bit more? There is no info in xfs.txt. i don't know why inode64 is missing. ino64 is testing only; it artificially forces ALL inodes into 64 bits. inode64 is for production on 64-bit boxs; it -allows- inodes to grow into 64 bits. -Eric > Thanks. > > Jan > From owner-linux-xfs@oss.sgi.com Thu Jun 2 06:30:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 06:30:08 -0700 (PDT) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52DU5Xq018457 for ; Thu, 2 Jun 2005 06:30:05 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Jun 2005 06:29:08 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Jun 2005 06:29:08 -0700 Message-ID: <429F09A3.2040507@xfs.org> Date: Thu, 02 Jun 2005 08:29:07 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jan Derfinak CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: False No space left on device error References: <429E7FDA.7070307@sgi.com> <429F0753.5010403@xfs.org> In-Reply-To: <429F0753.5010403@xfs.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2005 13:29:08.0707 (UTC) FILETIME=[0E354B30:01C56777] X-archive-position: 5372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Steve Lord wrote: > > ino64 is a test option, it deliberately adds a large number to > inode values so that it is possible to test that the inode handling > is 64 bit clean without buying a few Tbytes of disk (which would > have been very expensive when the code was written). It should > not be used outside of testing. > > inode64 is a hack to force xfs to keep inodes down in the start of > the filesystem where the inode numbers (which are disk addresses > really) do not overflow 32 bits. This is for systems which cannot > cope with larger inodes. There are also 3rd party backup > applications which barf on large inode numbers, networker was > the one I remember. OK, got that backwards, inode64 says do not keep them in 32 bits, inode32 says keep them in 32 bits. > > Steve From owner-linux-xfs@oss.sgi.com Thu Jun 2 06:31:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 06:31:43 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52DVdXq018863 for ; Thu, 2 Jun 2005 06:31:39 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j52FHVFx011000 for ; Thu, 2 Jun 2005 08:17:32 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j52DUdad60280100; Thu, 2 Jun 2005 06:30:40 -0700 (PDT) Message-ID: <429F09FF.1080506@sgi.com> Date: Thu, 02 Jun 2005 08:30:39 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: Jan Derfinak , linux-xfs@oss.sgi.com Subject: Re: False No space left on device error References: <429E7FDA.7070307@sgi.com> <429F0753.5010403@xfs.org> In-Reply-To: <429F0753.5010403@xfs.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5373 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Steve Lord wrote: > > ino64 is a test option, it deliberately adds a large number to > inode values so that it is possible to test that the inode handling > is 64 bit clean without buying a few Tbytes of disk (which would > have been very expensive when the code was written). It should > not be used outside of testing. > > inode64 is a hack to force xfs to keep inodes down in the start of > the filesystem where the inode numbers (which are disk addresses > really) do not overflow 32 bits. This is for systems which cannot > cope with larger inodes. There are also 3rd party backup > applications which barf on large inode numbers, networker was > the one I remember. well, the inode64 option itself is the -inverse- of the hack, actually, right. Default XFS inode allocation changed a few years ago, to force inodes into the low 32-bit range. THAT was the mild hack, and the inode64 option was added to again allow XFS to work as originally designed, allocating inodes anywhere on the filesystem on systems which could handle 64-bit inodes. -Eric > Steve From owner-linux-xfs@oss.sgi.com Thu Jun 2 07:26:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 07:26:52 -0700 (PDT) Received: from kevlar.burdell.org (66-23-228-155.clients.speedfactory.net [66.23.228.155]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52EQmXq022869 for ; Thu, 2 Jun 2005 07:26:48 -0700 Received: by kevlar.burdell.org (Postfix, from userid 1189) id C32A266C82; Thu, 2 Jun 2005 10:02:18 -0400 (EDT) Date: Thu, 2 Jun 2005 10:02:18 -0400 From: Sonny Rao To: Wayne Steenburg Cc: linux-xfs@oss.sgi.com Subject: Re: XFS module for RHEL4 Message-ID: <20050602140218.GA24138@kevlar.burdell.org> References: <1117576633.5018.12.camel@FC3Work> <20050601035347.GB20301@kevlar.burdell.org> <1117711504.5018.3.camel@FC3Work> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117711504.5018.3.camel@FC3Work> User-Agent: Mutt/1.4.2.1i X-archive-position: 5374 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sonny@burdell.org Precedence: bulk X-list: linux-xfs On Thu, Jun 02, 2005 at 07:25:04AM -0400, Wayne Steenburg wrote: > On Tue, 2005-05-31 at 23:53 -0400, Sonny Rao wrote: > > On Tue, May 31, 2005 at 05:57:13PM -0400, Wayne Steenburg wrote: > > > How would one go about compiling the XFS modules for the stock RHEL4 > > > kernel? Redhat decided not to include it for whatever reason. > > > > > > > More precisely, RedHat decided it couldn't support any filesystem > > other than Ext3 (hint, if you paid for RHEL 4 and want XFS, you could > > complai^H^H^H^H ask RedHat to reevaluate their choices of supported > > filesystems) > > > > On to the (possibly) useful portion of this post, > > > > You need to get the kernel source RPM and use the rpmbuild command to > > setup the kernel tree appropriately.. I believe the command is > > "rpmbuild -bp" for "prep" which means untar and apply patches in > > RPM-speak. This will put the kernel tree in the "BUILD" directory > > where you can then go in and theoretically change whatever kernel > > options you want and rebuild. If you want the module to load into the > > supplied kernel, you should start with their config file and just > > build the XFS module. There could be other steps I'm missing (like > > adding the proper extraversion junk to the Makefile, possibly) because > > I haven't had the misfortune of doing this in a while, but that should > > get you started. > > > > And don't forget to let them hear your opinion on this subject :-) > > > > Sonny > > > Thanks for your response Sonny (and Robin too) I'm not sure how to build > just the XFS module, using RPM. I did find elsewhere a reference to > using kbuild (ie. make -C path/to/kernel/src M=$PWD modules). Ill > probably just try that route unless you could explain how to build just > that module. Thanks again. You can build just the XFS modules from the top-level directory like this: make SUBDIRS=fs/xfs modules Sonny From owner-linux-xfs@oss.sgi.com Thu Jun 2 11:32:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 11:32:19 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52IWCXq009844 for ; Thu, 2 Jun 2005 11:32:12 -0700 Received: from dibbler.crodrigues.org (c-66-30-114-143.hsd1.ma.comcast.net[66.30.114.143]) by comcast.net (sccrmhc11) with ESMTP id <2005060218311401100mgpr7e>; Thu, 2 Jun 2005 18:31:14 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by dibbler.crodrigues.org (8.13.3/8.13.1) with ESMTP id j52IVSeQ080663 for ; Thu, 2 Jun 2005 14:31:28 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.3/8.13.1/Submit) id j52IVSvC080659 for linux-xfs@oss.sgi.com; Thu, 2 Jun 2005 14:31:28 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 2 Jun 2005 14:31:27 -0400 From: Craig Rodrigues To: linux-xfs@oss.sgi.com Subject: New XFS for FreeBSD project web page Message-ID: <20050602183127.GA73568@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 5376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rodrigc@crodrigues.org Precedence: bulk X-list: linux-xfs Content-Length: 720 Lines: 23 Hi, I would like to announce the new project web page for the XFS for FreeBSD project: http://people.freebsd.org/~rodrigc/xfs/ We made a snapshot release available on March 22. Progress is slow, because we have been distracted by other things (i.e. real life). I have two questions. Can you put a link to our web site off of your XFS for Linux project page, since our project is derived from your sources? Of course, SGI would have no relation to this project, and the link would just be there for informational purposes for interested users. Also, are you planning to release a newer xfsprogs snapshot at any time? I am creating a FreeBSD port of xfsprogs. -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs@oss.sgi.com Thu Jun 2 11:45:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 11:45:17 -0700 (PDT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52IjEXq011044 for ; Thu, 2 Jun 2005 11:45:14 -0700 Received: from pimout3-ext.prodigy.net (pimout3-int.prodigy.net [207.115.4.218]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j52Ii5Cg012783 for ; Thu, 2 Jun 2005 14:44:06 -0400 X-ORBL: [63.202.173.158] Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j52IiFIJ214610; Thu, 2 Jun 2005 14:44:15 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 650F1529BBC; Thu, 2 Jun 2005 11:44:15 -0700 (PDT) Date: Thu, 2 Jun 2005 11:44:15 -0700 From: Chris Wedgwood To: Eric Sandeen Cc: Jan Derfinak , linux-xfs@oss.sgi.com Subject: Re: False No space left on device error Message-ID: <598937.75f59e30faa49a9d1a48e7ee592eae21.ANY@taniwha.stupidest.org> References: <429E7FDA.7070307@sgi.com> <429F091E.6090105@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429F091E.6090105@sgi.com> X-archive-position: 5377 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 172 Lines: 7 On Thu, Jun 02, 2005 at 08:26:54AM -0500, Eric Sandeen wrote: > ino64 is testing only; it artificially forces ALL inodes into 64 > bits. maybe s/ino64/force_no64/ then? From owner-linux-xfs@oss.sgi.com Thu Jun 2 12:08:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 12:08:49 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52J8jXq012928 for ; Thu, 2 Jun 2005 12:08:46 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j52KsfCN009356 for ; Thu, 2 Jun 2005 13:54:41 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j52J7lR09392967; Thu, 2 Jun 2005 14:07:47 -0500 (CDT) Message-ID: <429F5902.8000302@sgi.com> Date: Thu, 02 Jun 2005 14:07:46 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: Jan Derfinak , linux-xfs@oss.sgi.com Subject: Re: False No space left on device error References: <429E7FDA.7070307@sgi.com> <429F091E.6090105@sgi.com> <598937.75f59e30faa49a9d1a48e7ee592eae21.ANY@taniwha.stupidest.org> In-Reply-To: <598937.75f59e30faa49a9d1a48e7ee592eae21.ANY@taniwha.stupidest.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5378 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 470 Lines: 17 Chris Wedgwood wrote: > On Thu, Jun 02, 2005 at 08:26:54AM -0500, Eric Sandeen wrote: > > >>ino64 is testing only; it artificially forces ALL inodes into 64 >>bits. > > > maybe s/ino64/force_no64/ then? ah, ino64 has the weight of history behind it now. :) I agree it's not obvious. But then it's not a documented/supported option anyway. Until I let the cat out of the bag on the list, you'd have to read the source to find out about it anyway! :) -Eric From owner-linux-xfs@oss.sgi.com Thu Jun 2 17:54:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 17:54:13 -0700 (PDT) Received: from bruce.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j530s8Xq020071 for ; Thu, 2 Jun 2005 17:54:09 -0700 Received: by bruce.melbourne.sgi.com (Postfix, from userid 38403) id 349DF59A52; Fri, 3 Jun 2005 10:31:23 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfstests Message-Id: <20050603003123.349DF59A52@bruce.melbourne.sgi.com> Date: Fri, 3 Jun 2005 10:31:23 +1000 (EST) From: fsgqa@bruce.melbourne.sgi.com (FSG QA) X-archive-position: 5379 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 725 Lines: 18 Fix .full file overwrite in test 106, enable project quota QA in 108. Date: Fri Jun 3 10:52:58 AEST 2005 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22787a xfstests/106 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/106.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfstests/108 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/108.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfstests/108.out - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/108.out.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs@oss.sgi.com Thu Jun 2 18:46:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 18:46:56 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j531knXq024154 for ; Thu, 2 Jun 2005 18:46:50 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA06035; Fri, 3 Jun 2005 11:45:49 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j531jmkt1789428; Fri, 3 Jun 2005 11:45:49 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j531drph001270; Fri, 3 Jun 2005 11:39:53 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j531doM0001268; Fri, 3 Jun 2005 11:39:50 +1000 Date: Fri, 3 Jun 2005 11:39:50 +1000 From: Nathan Scott To: Ravi Wijayaratne Cc: suse-sles-e@suse.com, linux-xfs@oss.sgi.com Subject: Re: XFS file system crash with SUSE SLES 8 Message-ID: <20050603013950.GC1021@frodo> References: <20050601180538.68933.qmail@web32509.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601180538.68933.qmail@web32509.mail.mud.yahoo.com> User-Agent: Mutt/1.5.3i X-archive-position: 5380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 582 Lines: 20 On Wed, Jun 01, 2005 at 11:05:38AM -0700, Ravi Wijayaratne wrote: > Hi all Hi there, > We are running Suse SLES8 2.4.21-138 kernel with XFS 1.3. > We see the following XFS crash in our syslog. This is resolved in more recent kernels, your options would be to move up to SLES9 or to attempt to backport current XFS CVS code to SLES8 kernels. SLES8 precedes SGIs direct involvement with XFS on SLES, so I'm not sure what shape that code base is in (but I would imagine it wont have been getting all of the fixes that are merged in the current SLES9 series). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 2 18:48:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 18:48:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j531mRXq024539 for ; Thu, 2 Jun 2005 18:48:32 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA06069; Fri, 3 Jun 2005 11:47:28 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j531lRkt1789864; Fri, 3 Jun 2005 11:47:28 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j531fWph001313; Fri, 3 Jun 2005 11:41:32 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j531fU9h001311; Fri, 3 Jun 2005 11:41:30 +1000 Date: Fri, 3 Jun 2005 11:41:30 +1000 From: Nathan Scott To: Deanan Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel bug on SLES 9 Message-ID: <20050603014130.GD1021@frodo> References: <42657615.9090404@tippett.com> <428F72EF.1060302@delusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428F72EF.1060302@delusion.com> User-Agent: Mutt/1.5.3i X-archive-position: 5381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 571 Lines: 18 On Sat, May 21, 2005 at 10:42:07AM -0700, Deanan wrote: > Has anyone seen the error below before? > > I was basically writing about 60G sequentially in 16mb files and it > occured a few times at about 55Gb into the write. > The system is SLES 9 x86-64 with 2G of ram. The filesystem was made > using the defaults > on top of an md raid 0 of 3 disks (chunk size 512). This is resolved in more recent SLES9 versions. I can't remember off the top of my head when it was fixed though - it'll be either in SP1 already, or in SP2 when that releases. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 2 19:09:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 19:09:30 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5329NXq025618 for ; Thu, 2 Jun 2005 19:09:26 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06429; Fri, 3 Jun 2005 12:08:22 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5328Lkt1788961; Fri, 3 Jun 2005 12:08:22 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j5322Qph001370; Fri, 3 Jun 2005 12:02:26 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j5322OPq001368; Fri, 3 Jun 2005 12:02:24 +1000 Date: Fri, 3 Jun 2005 12:02:24 +1000 From: Nathan Scott To: James Chapman Cc: linux-xfs@oss.sgi.com Subject: Re: Files >4GB in XFS realtime partition Message-ID: <20050603020224.GE1021@frodo> References: <428B4CC0.70702@katalix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428B4CC0.70702@katalix.com> User-Agent: Mutt/1.5.3i X-archive-position: 5382 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1293 Lines: 43 On Wed, May 18, 2005 at 03:10:08PM +0100, James Chapman wrote: > I'm seeing corrupt data when trying to read/write files >4GB in a > realtime partition. Are there any known bugs in this area? Corruption > only occurs when the file grows larger than 4GB. No problems are seen > when using non-realtime XFS partitions. > > Kernel: 2.4.29 > Arch: MIPS Hmm, I can't reproduce this on i386 with a current (CVS) kernel, both buffered and direct realtime IO looks OK at offsets larger than 4GB. Does this sequence fail for you too?... [root@bruce xfstests]# xfs_io -Rf /mnt/xfs0/realtime xfs_io> pwrite 5g 4k wrote 4096/4096 bytes at offset 5368709120 4 KiB, 1 ops; 0.0000 sec (15.024 MiB/sec and 3846.1538 ops/sec) xfs_io> quit [root@bruce xfstests]# od -x /mnt/xfs0/realtime 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 50000000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 50000010000 bruce xfs-cmds/xfstests# xfs_io -Rdf /mnt/xfs0/realtime-direct xfs_io> pwrite 5g 4k wrote 4096/4096 bytes at offset 5368709120 4 KiB, 1 ops; 0.0000 sec (208.965 KiB/sec and 52.2411 ops/sec) xfs_io> q bruce xfs-cmds/xfstests# od -x /mnt/xfs0/realtime-direct 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 50000000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 50000010000 cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 2 19:50:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 19:50:17 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j532oBXq028589 for ; Thu, 2 Jun 2005 19:50:12 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA07183; Fri, 3 Jun 2005 12:49:10 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j532nAkt1790533; Fri, 3 Jun 2005 12:49:10 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j532hEph001483; Fri, 3 Jun 2005 12:43:14 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j532hC88001481; Fri, 3 Jun 2005 12:43:12 +1000 Date: Fri, 3 Jun 2005 12:43:12 +1000 From: Nathan Scott To: Craig Rodrigues Cc: linux-xfs@oss.sgi.com Subject: Re: New XFS for FreeBSD project web page Message-ID: <20050603024312.GF1021@frodo> References: <20050602183127.GA73568@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050602183127.GA73568@crodrigues.org> User-Agent: Mutt/1.5.3i X-archive-position: 5383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 784 Lines: 24 Hi Craig, On Thu, Jun 02, 2005 at 02:31:27PM -0400, Craig Rodrigues wrote: > I have two questions. Can you put a link to our web site > off of your XFS for Linux project page, since our project is derived > from your sources? Should be fine, there'll be caveats that its not an SGI project, not SGI supported, etc, etc, but sounds like thats OK with you. > Also, are you planning to release a newer xfsprogs snapshot at any time? > I am creating a FreeBSD port of xfsprogs. There's been changes merged into xfsprogs for a long time to build on FreeBSD. The CVS xfs-cmds tree is always the best place to get current xfsprogs code, rather than the snapshots - if CVS doesn't build atm, just send a patch over and should be no trouble for us to merge it in. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 2 20:39:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 20:39:27 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j533dLXq002993 for ; Thu, 2 Jun 2005 20:39:22 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA08066; Fri, 3 Jun 2005 13:38:20 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 880844822C04; Fri, 3 Jun 2005 13:39:04 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 937235 - mkfs vs MD0/1 Message-Id: <20050603033904.880844822C04@chook.melbourne.sgi.com> Date: Fri, 3 Jun 2005 13:39:04 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 485 Lines: 14 Do not do stripe alignment in mkfs for raid0/1 MD devices. Date: Fri Jun 3 13:36:04 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: hch@asg.melbourne.sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22794a xfsprogs/libdisk/md.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libdisk/md.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h From owner-linux-xfs@oss.sgi.com Thu Jun 2 21:17:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 21:17:06 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j534GxXq004937 for ; Thu, 2 Jun 2005 21:17:00 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08835 for ; Fri, 3 Jun 2005 14:16:00 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 958EC4822C04; Fri, 3 Jun 2005 14:16:46 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 932952 - xfsprogs-2.6.30 Message-Id: <20050603041646.958EC4822C04@chook.melbourne.sgi.com> Date: Fri, 3 Jun 2005 14:16:46 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3460 Lines: 82 Add a man page for xfs_quota utility. Date: Fri Jun 3 14:07:38 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22797a xfsprogs/man/man8/xfs_quota.8 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_quota.8 Fix xfs_quota bugs found by QA tests, and add some options to assist testing. Date: Fri Jun 3 14:09:21 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: fsgqa The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22798a xfsprogs/quota/edit.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/edit.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsprogs/quota/free.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/free.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfsprogs/quota/quot.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/quot.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsprogs/quota/quota.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/quota.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsprogs/quota/quota.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/quota.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsprogs/quota/report.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/report.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Add O_NONBLOCK option to xfs_io open command. Date: Fri Jun 3 14:11:00 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22799a xfsprogs/io/open.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/open.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsprogs/io/init.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/init.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/io/file.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/file.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h xfsprogs/io/io.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/io.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h Bump xfsprogs version number for recent changes, switch xfs_quota on in the build. Date: Fri Jun 3 14:15:21 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22800a xfsprogs/Makefile - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/Makefile.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h xfsprogs/VERSION - 1.124 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h xfsprogs/doc/CHANGES - 1.168 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.168&r2=text&tr2=1.167&f=h xfsprogs/debian/changelog - 1.113 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h From owner-linux-xfs@oss.sgi.com Thu Jun 2 22:14:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 22:14:48 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j535EgXq008578 for ; Thu, 2 Jun 2005 22:14:43 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA10077; Fri, 3 Jun 2005 15:13:40 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 9A6B84822C04; Fri, 3 Jun 2005 15:14:25 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 932952 - project quota Message-Id: <20050603051425.9A6B84822C04@chook.melbourne.sgi.com> Date: Fri, 3 Jun 2005 15:14:25 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5386 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3360 Lines: 54 Add support for project quota, based on Dan Knappes earlier work. Date: Fri Jun 3 15:13:11 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dknappe@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22805a xfsidbg.c - 1.274 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.274&r2=text&tr2=1.273&f=h xfs_buf_item.h - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.h.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h xfs_vnodeops.c - 1.644 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.644&r2=text&tr2=1.643&f=h xfs_log_recover.c - 1.296 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.296&r2=text&tr2=1.295&f=h xfs_vfsops.c - 1.467 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.467&r2=text&tr2=1.466&f=h xfs_mount.h - 1.200 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.200&r2=text&tr2=1.199&f=h xfs_utils.c - 1.66 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.c.diff?r1=text&tr1=1.66&r2=text&tr2=1.65&f=h xfs_quota.h - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_quota.h.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h xfs_trans_buf.c - 1.120 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_buf.c.diff?r1=text&tr1=1.120&r2=text&tr2=1.119&f=h quota/xfs_trans_dquot.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_trans_dquot.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h quota/xfs_quota_priv.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_quota_priv.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h quota/xfs_qm_bhv.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_bhv.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h quota/xfs_qm_syscalls.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h quota/xfs_dquot.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h quota/xfs_dquot.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h quota/xfs_qm.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h quota/xfs_qm.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h linux-2.6/xfs_linux.h - 1.128 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.128&r2=text&tr2=1.127&f=h linux-2.6/xfs_super.c - 1.333 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.333&r2=text&tr2=1.332&f=h linux-2.4/xfs_linux.h - 1.139 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.139&r2=text&tr2=1.138&f=h linux-2.4/xfs_super.c - 1.305 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.305&r2=text&tr2=1.304&f=h From owner-linux-xfs@oss.sgi.com Thu Jun 2 22:20:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 22:21:01 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j535KsXq009867 for ; Thu, 2 Jun 2005 22:20:55 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA10291; Fri, 3 Jun 2005 15:19:51 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 120104822C04; Fri, 3 Jun 2005 15:20:38 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 932952 - project quota inheritance Message-Id: <20050603052038.120104822C04@chook.melbourne.sgi.com> Date: Fri, 3 Jun 2005 15:20:38 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 754 Lines: 18 Add support for project quota inheritance, a merge of Glens changes. Useful for tracking resources (used space/inodes) within a directory tree or groups of directory trees identified by a common project ID. Date: Fri Jun 3 15:17:31 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: overby,nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22806a xfs_vnodeops.c - 1.645 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.645&r2=text&tr2=1.644&f=h xfs_inode.c - 1.415 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.415&r2=text&tr2=1.414&f=h From owner-linux-xfs@oss.sgi.com Thu Jun 2 22:39:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 22:39:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j535dbXq010711 for ; Thu, 2 Jun 2005 22:39:38 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA10684; Fri, 3 Jun 2005 15:38:34 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 488334822C04; Fri, 3 Jun 2005 15:39:20 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 932952 - split patches Message-Id: <20050603053920.488334822C04@chook.melbourne.sgi.com> Date: Fri, 3 Jun 2005 15:39:20 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 848 Lines: 22 Date: Fri Jun 3 15:37:08 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: Jan Kara The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: 2.6.x-xfs-melb:linux:22808a split-patches/pquota-enable - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/pquota-enable - Extend quota interfaces to allow project quota for XFS. split-patches/quotactl-update - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/quotactl-update - Import the quotactl reorganisation that Jan and I did recently. split-patches/series - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - Add in couple of quota patches for mainline. From owner-linux-xfs@oss.sgi.com Thu Jun 2 23:23:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jun 2005 23:23:25 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j536NDXq015065 for ; Thu, 2 Jun 2005 23:23:14 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA11551 for ; Fri, 3 Jun 2005 16:22:14 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 314F349AC12F; Fri, 3 Jun 2005 16:22:59 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - merge up to 2.4.31 Message-Id: <20050603062259.314F349AC12F@chook.melbourne.sgi.com> Date: Fri, 3 Jun 2005 16:22:59 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 8434 Lines: 114 Date: Fri Jun 3 16:21:53 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: marcelo.tosatti@cyclades.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.4.x-xfs-melb Modid: 2.4.x-xfs-melb:linux:22815a MAINTAINERS - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/MAINTAINERS.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h Makefile - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Makefile.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/i386/kernel/mtrr.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/mtrr.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/i386/kernel/pci-irq.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/pci-irq.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/i386/mm/pageattr.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/mm/pageattr.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ia64/lib/swiotlb.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ia64/lib/swiotlb.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/kernel/time.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc/kernel/time.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/x86_64/kernel/e820.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/kernel/e820.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/x86_64/kernel/mtrr.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/kernel/mtrr.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/x86_64/kernel/pci-gart.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/kernel/pci-gart.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/x86_64/kernel/pci-pc.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/kernel/pci-pc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/x86_64/kernel/process.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/kernel/process.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/x86_64/kernel/setup64.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/kernel/setup64.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/x86_64/kernel/smp.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/kernel/smp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/x86_64/mm/pageattr.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/mm/pageattr.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/block/cciss.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/block/cciss.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/block/floppy.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/block/floppy.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/block/loop.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/block/loop.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/moxa.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/moxa.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/random.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/random.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/i2c/i2c-core.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/i2c/i2c-core.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/bonding/bond_main.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/bonding/bond_main.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/pcnet32.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/pcnet32.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/tg3.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/tg3.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/net/tg3.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/tg3.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/usb/serial/io_edgeport.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/serial/io_edgeport.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/serial/pl2303.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/serial/pl2303.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/serial/visor.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/serial/visor.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/serial/visor.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/serial/visor.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/video/fbmem.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/video/fbmem.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/binfmt_elf.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/binfmt_elf.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h fs/jfs/super.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/jfs/super.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-x86_64/mmu_context.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-x86_64/mmu_context.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-x86_64/unistd.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-x86_64/unistd.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/i2c.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/i2c.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/linux/pci_ids.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/pci_ids.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h lib/rwsem-spinlock.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/lib/rwsem-spinlock.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h lib/rwsem.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/lib/rwsem.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h mm/filemap.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/filemap.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/core/rtnetlink.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/core/rtnetlink.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/ipvs/ip_vs_ctl.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/ipvs/ip_vs_ctl.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/ipvs/ip_vs_sched.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/ipvs/ip_vs_sched.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/ipvs/ip_vs_sync.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/ipvs/ip_vs_sync.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/ipv4/tcp_input.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/tcp_input.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/netlink/af_netlink.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/netlink/af_netlink.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h split-patches/rwsem-backport - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/rwsem-backport.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h split-patches/dmapi-enable - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/dmapi-enable.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h split-patches/downgrade_write-backport - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/downgrade_write-backport.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/sata_sil.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_sil.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/sata_svw.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_svw.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/libata-scsi.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/libata-scsi.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/ahci.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/ahci.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h From owner-linux-xfs@oss.sgi.com Fri Jun 3 01:11:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 01:11:23 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j538BJXq024541 for ; Fri, 3 Jun 2005 01:11:19 -0700 Received: from pimout1-ext.prodigy.net (pimout1-int.prodigy.net [207.115.5.65]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j538ATKh027979 for ; Fri, 3 Jun 2005 04:10:30 -0400 X-ORBL: [63.202.173.158] Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j538A9sk107380; Fri, 3 Jun 2005 04:10:14 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 2EC9E529BBC; Fri, 3 Jun 2005 01:10:08 -0700 (PDT) Date: Fri, 3 Jun 2005 01:10:08 -0700 From: Chris Wedgwood To: Robin Humble Cc: linux-xfs@oss.sgi.com, Axel Thimm Subject: Re: out of the tree compilation and 4KSTACKS Message-ID: <395268.61e8aecb7bfdbc2323c32f7a33aa3e8d.ANY@taniwha.stupidest.org> References: <20050531074820.GM8770@neu.nirvana> <462608.672469a40d5f4a17f7b1f43a4517535a.ANY@taniwha.stupidest.org> <20050531215402.GE23991@neu.nirvana> <477395.f3b7fdadc14ce50b8c44d1f319df1ab6.IBX@taniwha.stupidest.org> <20050601034202.GA31105@neu.nirvana> <20050601040009.GA11354@taniwha.stupidest.org> <20050601060509.GA7359@lemming.cita.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601060509.GA7359@lemming.cita.utoronto.ca> X-archive-position: 5390 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 312 Lines: 9 On Wed, Jun 01, 2005 at 02:05:09AM -0400, Robin Humble wrote: > I think RedHat are mistaken. > http://oss.sgi.com/archives/linux-xfs/2005-03/msg00189.html I'm pretty sure they will argue that for what most of their customers do ext3 is as faster and somewhat leaner and more reliable than the alternatives. From owner-linux-xfs@oss.sgi.com Fri Jun 3 01:30:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 01:30:44 -0700 (PDT) Received: from pantene.yandex.ru (pantene.yandex.ru [213.180.200.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j538UeXq025585 for ; Fri, 3 Jun 2005 01:30:41 -0700 Received: from YAMAIL (pantene.yandex.ru) by mail.yandex.ru id ; Fri, 3 Jun 2005 12:29:28 +0400 Date: Fri, 3 Jun 2005 12:29:28 +0400 (MSD) From: "Arthur" Message-Id: <42A014E8.000008.28676@pantene.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] To: linux-xfs@oss.sgi.com Subject: XFS w/RT Reply-To: tubaranja@yandex.ru X-Source-Ip: 193.109.128.36 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-archive-position: 5391 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tubaranja@yandex.ru Precedence: bulk X-list: linux-xfs Content-Length: 466 Lines: 6 Hello! This message about the realtime feature. Now there is a question about to include it in the kernel of one distribution (CRUX). Me interests opinion of developers. How you think, how much it's stable at present? How often there are problems with it and what character of this problems? Somebody spent tests on latency with inclusion of this opportunity and without it? If yes, can will show me links to results of tests? In advance thanks. -- ------ Arthur From owner-linux-xfs@oss.sgi.com Fri Jun 3 04:49:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 04:49:39 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53BnZXq006176 for ; Fri, 3 Jun 2005 04:49:36 -0700 Received: from host217-37-158-154.in-addr.btopenworld.com ([217.37.158.154] helo=[192.168.27.54]) by s14.s14avahost.net with esmtpa (Exim 4.44) id 1DeAf9-0002O1-TM; Fri, 03 Jun 2005 06:48:32 -0500 Message-ID: <42A0438E.1070202@katalix.com> Date: Fri, 03 Jun 2005 12:48:30 +0100 From: James Chapman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com, sandeen@sgi.com Subject: Re: Files >4GB in XFS realtime partition References: <428B4CC0.70702@katalix.com> <20050603020224.GE1021@frodo> In-Reply-To: <20050603020224.GE1021@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: jchapman@katalix.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 5392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: linux-xfs Content-Length: 1574 Lines: 53 Hi Nathan, Eric Sandeen asked me to reproduce this on an x86 but I've been unable to find time to do so yet. I'll get back to you as soon as I can. I'll try to test with a 2.4.29 kernel. /james Nathan Scott wrote: > On Wed, May 18, 2005 at 03:10:08PM +0100, James Chapman wrote: > >>I'm seeing corrupt data when trying to read/write files >4GB in a >>realtime partition. Are there any known bugs in this area? Corruption >>only occurs when the file grows larger than 4GB. No problems are seen >>when using non-realtime XFS partitions. >> >>Kernel: 2.4.29 >>Arch: MIPS > > > Hmm, I can't reproduce this on i386 with a current (CVS) kernel, > both buffered and direct realtime IO looks OK at offsets larger > than 4GB. Does this sequence fail for you too?... > > [root@bruce xfstests]# xfs_io -Rf /mnt/xfs0/realtime > xfs_io> pwrite 5g 4k > wrote 4096/4096 bytes at offset 5368709120 > 4 KiB, 1 ops; 0.0000 sec (15.024 MiB/sec and 3846.1538 ops/sec) > xfs_io> quit > > [root@bruce xfstests]# od -x /mnt/xfs0/realtime > 0000000 0000 0000 0000 0000 0000 0000 0000 0000 > * > 50000000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd > * > 50000010000 > > bruce xfs-cmds/xfstests# xfs_io -Rdf /mnt/xfs0/realtime-direct > xfs_io> pwrite 5g 4k > wrote 4096/4096 bytes at offset 5368709120 > 4 KiB, 1 ops; 0.0000 sec (208.965 KiB/sec and 52.2411 ops/sec) > xfs_io> q > bruce xfs-cmds/xfstests# od -x /mnt/xfs0/realtime-direct > 0000000 0000 0000 0000 0000 0000 0000 0000 0000 > * > 50000000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd > * > 50000010000 > > cheers. > From owner-linux-xfs@oss.sgi.com Fri Jun 3 05:14:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 05:14:15 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53CEBXq007767 for ; Fri, 3 Jun 2005 05:14:12 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j53E0DHN022062 for ; Fri, 3 Jun 2005 07:00:13 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j53CDCad54448706; Fri, 3 Jun 2005 05:13:12 -0700 (PDT) Message-ID: <42A04958.40909@sgi.com> Date: Fri, 03 Jun 2005 07:13:12 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Chapman CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: Files >4GB in XFS realtime partition References: <428B4CC0.70702@katalix.com> <20050603020224.GE1021@frodo> <42A0438E.1070202@katalix.com> In-Reply-To: <42A0438E.1070202@katalix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 449 Lines: 16 James Chapman wrote: > Hi Nathan, > > Eric Sandeen asked me to reproduce this on an x86 but I've been unable > to find time to do so yet. I'll get back to you as soon as I can. I'll > try to test with a 2.4.29 kernel. > > /james > James, testing Nathan's case with xfs_io on your normal arch would be good too, and more useful at this point. If that fails, I wonder how hard it would be for you to take ulibc out of the equation... -Eric From owner-linux-xfs@oss.sgi.com Fri Jun 3 05:56:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 05:56:06 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53Cu0Xq010060 for ; Fri, 3 Jun 2005 05:56:00 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j53Ct2xT019980 for ; Fri, 3 Jun 2005 07:55:02 -0500 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j53Ct0ad60590144; Fri, 3 Jun 2005 05:55:01 -0700 (PDT) Message-ID: <42A05324.5010201@sgi.com> Date: Fri, 03 Jun 2005 07:55:00 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tubaranja@yandex.ru CC: linux-xfs@oss.sgi.com Subject: Re: XFS w/RT References: <42A014E8.000008.28676@pantene.yandex.ru> In-Reply-To: <42A014E8.000008.28676@pantene.yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5394 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1054 Lines: 22 Arthur wrote: > Hello! > This message about the realtime feature. Now there is a question about to include it in the kernel of one distribution (CRUX). Me interests opinion of developers. How you think, how much it's stable at present? How often there are problems with it and what character of this problems? Somebody spent tests on latency with inclusion of this opportunity and without it? If yes, can will show me links to results of tests? In advance thanks. Realtime should be in decent shape but it's not heavily tested. That's why it's still under CONFIG_EXPERIMENTAL And FWIW, it's not 'realtime' in a strict sense, but the allocator is more deterministic than standard. It also allocates larger chunks at a time. I'm not aware of any published analysis of latency. Very few users/applications have a need for this option, to tell you the truth. But in some cases it can be good; direct IO media streaming might be one case. You might ask James Chapman why they chose to use it in their embedded system, for starters. :) -Eric From owner-linux-xfs@oss.sgi.com Fri Jun 3 06:51:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 06:51:12 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53Dp6Xq018964 for ; Fri, 3 Jun 2005 06:51:06 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id 846151621A8 for ; Fri, 3 Jun 2005 15:50:01 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07169-08 for ; Fri, 3 Jun 2005 15:49:56 +0200 (CEST) Received: from [192.9.209.64] (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 193851621A5 for ; Fri, 3 Jun 2005 15:49:56 +0200 (CEST) Message-ID: <42A05FD8.8070809@opticalart.de> Date: Fri, 03 Jun 2005 15:49:12 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS List Subject: xfs_repair Err 990 Content-Type: multipart/mixed; boundary="------------020202090307000202040900" X-archive-position: 5395 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 9743 Lines: 232 This is a multi-part message in MIME format. --------------020202090307000202040900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi! Filesystem is 950GB XFS partition on an external Fibre-Channel Array. xfs_progs is version 2.6.25. System is running gentoo linux with a vanilla 2.6.8.1 kernel. The system crashed due to a power-failure. I ran into the infamous err 990 during xfs_repair: ... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 corrupt dinode 2537480171, extent total = 1, nblocks = 0. Unmount and run xfs_repair. fatal error -- couldn't map inode 2537480171, err = 990 and stops there. The filesystem is mounting fine after the half finished run of xfs_repair, but accesses going to that inode (or others not repaired) make it barf (see attached dmesg.txt). Anything I can do to fix this via xfs_db? Like hiding that part from the users until I have a chance to do the xfs_dump+mkfs.xfs+xfs_restore routine? Thanks. Cheers, Frank... -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a DI Supervisor http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 --------------020202090307000202040900 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" [] xfs_iformat+0x2b5/0x5c2 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iget_core+0x101/0x6ce [] iget_locked+0xbc/0xfd [] xfs_iget+0x157/0x189 [] xfs_dir_lookup_int+0xb4/0x12b [] xfs_lookup+0x50/0x88 [] linvfs_lookup+0x67/0x9f [] real_lookup+0xe1/0x104 [] do_lookup+0x96/0xa1 [] link_path_walk+0x811/0xfdf [] path_lookup+0xad/0x1d2 [] __user_walk+0x49/0x7b [] linvfs_readdir+0x202/0x23b [] vfs_lstat+0x1c/0x58 [] update_atime+0x92/0xd5 [] sys_lstat64+0x1b/0x39 [] vfs_readdir+0xb4/0xb6 [] filldir64+0x0/0xeb [] sys_getdents64+0xa1/0xab [] filldir64+0x0/0xeb [] syscall_call+0x7/0xb Filesystem "sdc1": corrupt dinode 763502840, extent total = 1, nblocks = 0. Unmount and run xfs_repair. 0x0: 49 4e 81 b6 01 02 00 01 00 00 03 e9 00 00 00 64 Filesystem "sdc1": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0264b3a [] xfs_iformat+0x2b5/0x5c2 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iget_core+0x101/0x6ce [] iget_locked+0xbc/0xfd [] xfs_iget+0x157/0x189 [] xfs_dir_lookup_int+0xb4/0x12b [] xfs_lookup+0x50/0x88 [] linvfs_lookup+0x67/0x9f [] real_lookup+0xe1/0x104 [] do_lookup+0x96/0xa1 [] link_path_walk+0x811/0xfdf [] path_lookup+0xad/0x1d2 [] __user_walk+0x49/0x7b [] vfs_lstat+0x1c/0x58 [] sys_lstat64+0x1b/0x39 [] syscall_call+0x7/0xb Filesystem "sdc1": corrupt dinode 3629094670, extent total = 1, nblocks = 0. Unmount and run xfs_repair. 0x0: 49 4e 81 b6 01 02 00 01 00 00 03 e9 00 00 00 64 Filesystem "sdc1": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0264b3a [] xfs_iformat+0x2b5/0x5c2 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iget_core+0x101/0x6ce [] iget_locked+0xbc/0xfd [] xfs_iget+0x157/0x189 [] xfs_dir_lookup_int+0xb4/0x12b [] xfs_lookup+0x50/0x88 [] linvfs_lookup+0x67/0x9f [] real_lookup+0xe1/0x104 [] do_lookup+0x96/0xa1 [] link_path_walk+0x811/0xfdf [] do_anonymous_page+0x130/0x1b7 [] path_lookup+0xad/0x1d2 [] __user_walk+0x49/0x7b [] vfs_lstat+0x1c/0x58 [] sys_lstat64+0x1b/0x39 [] do_page_fault+0x0/0x56f [] error_code+0x2d/0x38 [] syscall_call+0x7/0xb Filesystem "sdc1": corrupt dinode 2537480171, extent total = 1, nblocks = 0. Unmount and run xfs_repair. 0x0: 49 4e 41 ed 01 02 00 02 00 00 03 e9 00 00 00 64 Filesystem "sdc1": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0264b3a [] xfs_iformat+0x2b5/0x5c2 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iget_core+0x101/0x6ce [] iget_locked+0xbc/0xfd [] xfs_iget+0x157/0x189 [] xfs_dir_lookup_int+0xb4/0x12b [] xfs_lookup+0x50/0x88 [] linvfs_lookup+0x67/0x9f [] real_lookup+0xe1/0x104 [] do_lookup+0x96/0xa1 [] link_path_walk+0x811/0xfdf [] path_lookup+0xad/0x1d2 [] __user_walk+0x49/0x7b [] linvfs_readdir+0x202/0x23b [] vfs_lstat+0x1c/0x58 [] sys_lstat64+0x1b/0x39 [] vfs_readdir+0xb4/0xb6 [] update_process_times+0x45/0x51 [] smp_apic_timer_interrupt+0xe6/0x14e [] syscall_call+0x7/0xb Filesystem "sdc1": corrupt dinode 3611258870, extent total = 1, nblocks = 0. Unmount and run xfs_repair. 0x0: 49 4e 81 ed 01 02 00 01 00 00 00 00 00 00 00 00 Filesystem "sdc1": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0264b3a [] xfs_iformat+0x2b5/0x5c2 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iget_core+0x101/0x6ce [] iget_locked+0xbc/0xfd [] xfs_iget+0x157/0x189 [] xfs_dir_lookup_int+0xb4/0x12b [] xfs_lookup+0x50/0x88 [] linvfs_lookup+0x67/0x9f [] real_lookup+0xe1/0x104 [] do_lookup+0x96/0xa1 [] link_path_walk+0x811/0xfdf [] path_lookup+0xad/0x1d2 [] __user_walk+0x49/0x7b [] vfs_lstat+0x1c/0x58 [] sys_lstat64+0x1b/0x39 [] syscall_call+0x7/0xb Filesystem "sdc1": corrupt dinode 2403297492, extent total = 1, nblocks = 0. Unmount and run xfs_repair. 0x0: 49 4e 41 ed 01 02 00 02 00 00 03 e9 00 00 00 64 Filesystem "sdc1": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0264b3a [] xfs_iformat+0x2b5/0x5c2 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iget_core+0x101/0x6ce [] iget_locked+0xbc/0xfd [] xfs_iget+0x157/0x189 [] xfs_dir_lookup_int+0xb4/0x12b [] xfs_lookup+0x50/0x88 [] linvfs_lookup+0x67/0x9f [] real_lookup+0xe1/0x104 [] do_lookup+0x96/0xa1 [] link_path_walk+0x811/0xfdf [] vsprintf+0x27/0x2b [] copy_to_user+0x52/0x62 [] path_lookup+0xad/0x1d2 [] __user_walk+0x49/0x7b [] vfs_stat+0x1f/0x5b [] sys_stat64+0x1b/0x39 [] math_state_restore+0x28/0x42 [] syscall_call+0x7/0xb Filesystem "sdc1": corrupt dinode 2403297492, extent total = 1, nblocks = 0. Unmount and run xfs_repair. 0x0: 49 4e 41 ed 01 02 00 02 00 00 03 e9 00 00 00 64 Filesystem "sdc1": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0264b3a [] xfs_iformat+0x2b5/0x5c2 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iget_core+0x101/0x6ce [] iget_locked+0xbc/0xfd [] xfs_iget+0x157/0x189 [] xfs_dir_lookup_int+0xb4/0x12b [] xfs_lookup+0x50/0x88 [] linvfs_lookup+0x67/0x9f [] real_lookup+0xe1/0x104 [] do_lookup+0x96/0xa1 [] link_path_walk+0x811/0xfdf [] xfs_dir2_put_dirent64_direct+0x0/0x96 [] path_lookup+0xad/0x1d2 [] __user_walk+0x49/0x7b [] vfs_stat+0x1f/0x5b [] sys_stat64+0x1b/0x39 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller 0xc0229136 [] xfs_free_ag_extent+0x454/0x78a [] xfs_free_extent+0x100/0x125 [] xfs_free_extent+0x100/0x125 [] kmem_zone_alloc+0x50/0x96 [] xfs_trans_get_efd+0x38/0x46 [] xfs_bmap_finish+0x13e/0x1d2 [] xfs_itruncate_finish+0x22a/0x452 [] xfs_inactive+0x504/0x558 [] vn_rele+0xfd/0x119 [] linvfs_clear_inode+0x18/0x30 [] clear_inode+0x9b/0xa7 [] generic_delete_inode+0x10a/0x13c [] iput+0x62/0x7c [] sys_unlink+0x13a/0x172 [] sys_getdents64+0xa1/0xab [] filldir64+0x0/0xeb [] syscall_call+0x7/0xb xfs_force_shutdown(sdc1,0x8) called from line 4049 of file fs/xfs/xfs_bmap.c. Return address = 0xc0293420 Filesystem "sdc1": Corruption of in-memory data detected. Shutting down filesystem: sdc1 Please umount the filesystem, and rectify the problem(s) --------------020202090307000202040900-- From owner-linux-xfs@oss.sgi.com Fri Jun 3 09:16:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 09:16:36 -0700 (PDT) Received: from jaguar.mkp.net (vanessarodrigues.com [192.139.46.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GGVXq030502 for ; Fri, 3 Jun 2005 09:16:31 -0700 Received: from wilson.lab.mkp.net (groovelator.mkp.net [209.217.122.111]) by jaguar.mkp.net (Postfix) with ESMTP id 8259D286CB0; Fri, 3 Jun 2005 12:15:31 -0400 (EDT) Received: by wilson.lab.mkp.net (Postfix, from userid 1654) id D4871204037; Fri, 3 Jun 2005 12:15:31 -0400 (EDT) To: nathans@sgi.com (Nathan Scott) Cc: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: Re: TAKE 937235 - mkfs vs MD0/1 From: "Martin K. Petersen" Organization: mkp.net References: <20050603033904.880844822C04@chook.melbourne.sgi.com> Date: Fri, 03 Jun 2005 12:15:31 -0400 In-Reply-To: <20050603033904.880844822C04@chook.melbourne.sgi.com> (Nathan Scott's message of "Fri, 3 Jun 2005 13:39:04 +1000 (EST)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5396 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mkp@mkp.net Precedence: bulk X-list: linux-xfs Content-Length: 221 Lines: 11 >>>>> "Nathan" == Nathan Scott writes: Nathan, Nathan> Do not do stripe alignment in mkfs for raid0/1 MD devices. RAID1 I can understand. But why RAID0? -- Martin K. Petersen http://mkp.net/ From owner-linux-xfs@oss.sgi.com Fri Jun 3 09:59:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 09:59:14 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GxBXq005579 for ; Fri, 3 Jun 2005 09:59:11 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j53IjDoL024939 for ; Fri, 3 Jun 2005 11:45:14 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j53GvB0F16267254; Fri, 3 Jun 2005 11:57:12 -0500 (CDT) Message-ID: <42A08BE7.8080405@sgi.com> Date: Fri, 03 Jun 2005 11:57:11 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank Hellmann CC: XFS List Subject: Re: xfs_repair Err 990 References: <42A05FD8.8070809@opticalart.de> In-Reply-To: <42A05FD8.8070809@opticalart.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5397 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 420 Lines: 12 Frank Hellmann wrote: > corrupt dinode 2537480171, extent total = 1, nblocks = 0. Unmount and run xfs_repair. > Anything I can do to fix this via xfs_db? Like hiding that part from the > users until I have a chance to do the xfs_dump+mkfs.xfs+xfs_restore > routine? I've fixed this sort of thing before by using db to set both extents and nblocks to 0 for that inode, and re-running repair. I think. :) -Eric From owner-linux-xfs@oss.sgi.com Fri Jun 3 09:59:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 09:59:44 -0700 (PDT) Received: from topalm2.dionis.local (82.211.131.6.planetsky.com [82.211.131.6] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GxZXq005709 for ; Fri, 3 Jun 2005 09:59:38 -0700 Received: from [10.0.0.99] (helo=[10.0.0.99]) by topalm2.dionis.local with esmtp (Exim 3.35 #1 (Debian)) id 1DeFV7-00033r-00 for ; Fri, 03 Jun 2005 20:58:29 +0400 Message-ID: <42A08C35.9080402@yandex.ru> Date: Fri, 03 Jun 2005 20:58:29 +0400 From: Ed User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: right su and sw values for raid 10 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: spied@yandex.ru Precedence: bulk X-list: linux-xfs Content-Length: 98 Lines: 3 can you help me select right su and sw parameters for hardware raid 10 (4 disks, 128kb stripe)? From owner-linux-xfs@oss.sgi.com Fri Jun 3 12:26:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 12:26:20 -0700 (PDT) Received: from topalm2.dionis.local (82.211.131.6.planetsky.com [82.211.131.6] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53JQDXq022677 for ; Fri, 3 Jun 2005 12:26:17 -0700 Received: from [10.0.0.99] (helo=[10.0.0.99]) by topalm2.dionis.local with esmtp (Exim 3.35 #1 (Debian)) id 1DeHn1-0007m9-00 for ; Fri, 03 Jun 2005 23:25:07 +0400 Message-ID: <42A0AE93.6010001@yandex.ru> Date: Fri, 03 Jun 2005 23:25:07 +0400 From: Ed User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: why is log version=1 default? Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5399 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: spied@yandex.ru Precedence: bulk X-list: linux-xfs Content-Length: 48 Lines: 2 exist any reason do not use version=2 for log? From owner-linux-xfs@oss.sgi.com Fri Jun 3 15:24:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 15:24:44 -0700 (PDT) Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53MOdXq013187 for ; Fri, 3 Jun 2005 15:24:39 -0700 Received: from pacbell.net (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA21112 for ; Fri, 3 Jun 2005 15:23:39 -0700 Message-ID: <42A0D86B.5070502@pacbell.net> Date: Fri, 03 Jun 2005 15:23:39 -0700 From: Kenneth Sumrall User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: "LEAFN node level is 1..." warning and suspicious circumstances. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5400 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksumrall@pacbell.net Precedence: bulk X-list: linux-xfs Content-Length: 3664 Lines: 95 At work, we have a huge 5.6 Tb SCSI RAID, hooked up to a SuperMicro 6012P-6 1U server, which NFS exports the RAID to over 100 machines. The entire RAID is configured as a single XFS filesystem. Because the RAID is over 2 Tb, and the SCSI implementation in the RAID doesn't support the newer READ16/WRITE16 SCSI commands, the RAID unit has set the sector size to 2048 bytes. Also, because the partition tables seem to assume a sector size of 512 bytes, we are running XFS directly on the block device /dev/sdc, _NOT_ /dev/scd1. We are runing on a Suse 9.2 system, with a 2.6.11.7 kernel. Anyhow, we have been having some hang (not panic) issues with the SuperMicro, and just to make sure it wasn't an XFS problem we decided to check the XFS filesystem for errors. We first ran xfs_check, but it immediately gives an "out of memory" error. What are my options for fixing this? We added oodles of swap space, and made sure ulimit was set to unlimited data and stack space. Since xfs_check is just a shell script wrapper around xfs_db, we can't run that either. :-( So, we next ran xfs_repair -n, and it reported the following errors: Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 LEAFN node level is 1 inode 1074431615 bno = 8388608 LEAFN node level is 1 inode 1074431632 bno = 8388608 - agno = 2 LEAFN node level is 1 inode 2148178682 bno = 8388608 LEAFN node level is 1 inode 2148183066 bno = 8388608 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - process newly discovered inodes... and it repeated the LEAFN warnings again in Phase 4. A quick check of xfs_repair source shows that xfs_repair only reports this situation, but does nothing about it. However, we unmounted the filesystem, and ran xfs_repair in full repair mode, just in case, and hoping that Phase 5 (which is skipped in -n mode) would fix the problem, but it doesn't. So, I checked the xfs mailing list archives, and this has been mentioned a few times before, but no definate answers were given. However, I did notice that in EVERY ONE of the instances where this message was printed, the bno was equal to 8388608. Here is a link to the xfs mailing list archives that shows the 6 messages that contain the LEAFN error message: Decimal 8388608 equals hex 0x800000. This seems very suspicious. Is this a real problem, or just a mild annoyance? BTW, we were able to get rid of the error message using "find . -inum ..." to find the offending files. They were all directories. We then moved them aside, created new directories, mv the contents into the new directory, and deleted the old directory. Oh, just in case anyone was wondering xfs_repair took about 45 minutes on our 5.6 Tb RAID which is 81% full, and running "find . -inum ..." took about 50 minutes. Many thanks in advance for any help or insight. Ken Sumrall ksumrall@pacbell.net From owner-linux-xfs@oss.sgi.com Fri Jun 3 19:48:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jun 2005 19:48:52 -0700 (PDT) Received: from ISP2.conwaycorp.net (isp2.conwaycorp.net [24.144.4.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j542mnXq005216 for ; Fri, 3 Jun 2005 19:48:49 -0700 Received: (qmail 10428 invoked by uid 8009); 4 Jun 2005 02:47:50 -0000 Received: from 24.144.34.225 by ISP2 (envelope-from , uid 89) with qmail-scanner-1.23 (clamdscan: 0.75.1. Clear:RC:1(24.144.34.225):. Processed in 0.074691 secs); 04 Jun 2005 02:47:50 -0000 Received: from dhcp34-225.cable.conwaycorp.net (HELO ?192.168.1.100?) (rob.benton@24.144.34.225) by ISP2.conwaycorp.net with SMTP; 4 Jun 2005 02:47:50 -0000 Message-ID: <42A12598.8010007@conwaycorp.net> Date: Fri, 03 Jun 2005 22:52:56 -0500 From: Rob Benton User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_repair fatal error 990 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rob.benton@conwaycorp.net Precedence: bulk X-list: linux-xfs Content-Length: 3285 Lines: 89 Hey guys I could use some help here. I know there's probably a way to fix this but I don't know what it is. I am running Debian testing with a linux 2.6.9 kernel. Last night some strange behavior started and I noticed messages from the kernel and xfs. So I did a reboot with a Knoppix CD I had and tried xfs_repair. After that I tried xfs_check. These were version 2.6.28 by the way. =========================================================================== root@ttyp0[knoppix]# xfs_repair /dev/hdb2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 correcting nblocks for inode 109931154, was 0 - counted 1 - agno = 14 correcting nblocks for inode 120423310, was 0 - counted 12 - agno = 15 correcting nblocks for inode 128288145, was 0 - counted 1 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 data fork in regular inode 109931154 claims used block 7613136 correcting nblocks for inode 109931154, was 1 - counted 0 - agno = 14 data fork in regular inode 120423310 claims used block 8137424 correcting nblocks for inode 120423310, was 12 - counted 0 - agno = 15 data fork in regular inode 128288145 claims used block 273104 correcting nblocks for inode 128288145, was 1 - counted 0 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... corrupt dinode 109931154, extent total = 1, nblocks = 0. Unmount and run xfs_repair. fatal error -- couldn't map inode 109931154, err = 990 root@0[knoppix]# xfs_check /dev/hdb2 bad nblocks 0 for inode 109931154, counted 1 bad nblocks 0 for inode 120423310, counted 12 bad nblocks 0 for inode 128288145, counted 1 =========================================================================== From owner-linux-xfs@oss.sgi.com Sat Jun 4 09:36:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 04 Jun 2005 09:36:52 -0700 (PDT) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j54GamXq028214 for ; Sat, 4 Jun 2005 09:36:48 -0700 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id j54GZm2V025464 for ; Sat, 4 Jun 2005 12:35:48 -0400 (EDT) Date: Sat, 4 Jun 2005 12:35:48 -0400 (EDT) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: kswapd causing giant load Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 1169 Lines: 33 Hi, I encounter a giant load (up to 10.0) when I copy files, either from a remote server to the local machine, or even locally. Because I use XFS filesystem, I decided to forward my email to the XFS list; maybe anyone has a clue. The setup is: OS: Redhat FC3 with 2.6.11-1.14_FC3smp (redhat distro) kernel, XFS filesystem HW: Dual opteron 2.0GHz on Tyan motherboard, 4Gb RAM The partition i am using is: 2.1Tb hardware RAID-5 unit served by 3ware controller (8 x 300Gb) OR 300Gb simple SATA disk, also served by a 3ware controller. I have no clue where to start combatting this problem. - Kernel specific? - Due to improper setup of the 3ware controllers? - XFS filesystem specific? 10715 hatuser 15 0 35432 2792 2020 R 28.3 0.1 1:45.06 sshd 10724 hatuser 16 0 17504 11m 664 R 8.3 0.3 0:33.56 rsync 175 root 15 0 0 0 0 S 19.7 0.0 136:25.58 kswapd0 172 root 15 0 0 0 0 S 0.3 0.0 1:23.59 pdflush 174 root 15 0 0 0 0 S 0.3 0.0 99:18.93 kswapd1 Before I start extensive experimenting, maybe someone knows right away what causes high loads due to "kswapd* and pdflush". Cheers Gaspar From owner-linux-xfs@oss.sgi.com Sat Jun 4 10:44:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 04 Jun 2005 10:44:08 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j54Hi0Xq031496 for ; Sat, 4 Jun 2005 10:44:01 -0700 Received: from quatar.cs.tu-berlin.de [130.149.17.111] (helo=quatar) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwh2-1Decfi2yPn-0003G7; Sat, 04 Jun 2005 19:42:58 +0200 Date: Sat, 4 Jun 2005 19:42:53 +0200 (MEST) From: Udo Wolter X-X-Sender: uwp@quatar Reply-To: uwp@dicke-aersche.de To: linux-xfs@oss.sgi.com Subject: Re: XFS & cryptoloop problems Message-ID: X-message-flag: Microsoft & Outlook wegwerfen - Linux nehmen ! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Provags-ID: kundenserver.de abuse@kundenserver.de login:3106c298ae0df7732ff6407e2ab764cf X-archive-position: 5403 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: uwp@dicke-aersche.de Precedence: bulk X-list: linux-xfs Content-Length: 670 Lines: 17 Ok, I now can tell it, it's not the crypto part that has these problems. After copying the data to an unencrypted disk the partition couldn't be mounted too. A xfs_repair solved the problem but I think anyway that the code shouldn't give oops and the mount command shouldn't end with a seg fault. It's clearly a problem in the XFS code (at least in kernel 2.6.11.6 & 2.6.11.10). Mermgfurt, Udo P.S.: BTW, the xfs_repair even worked at the encrypted partition... -- Udo Wolter | /"\ email: uwp@dicke-aersche.de | \ / ASCII RIBBON CAMPAIGN www: www.dicke-aersche.de | X AGAINST HTML MAIL dark: heaven@lutz-ziffer.de | / \ From owner-linux-xfs@oss.sgi.com Sat Jun 4 22:36:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 04 Jun 2005 22:36:25 -0700 (PDT) Received: from hotmail.com (bay106-f9.bay106.hotmail.com [65.54.161.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j555aJXq003691 for ; Sat, 4 Jun 2005 22:36:20 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 4 Jun 2005 22:35:19 -0700 Message-ID: Received: from 65.54.161.203 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 05 Jun 2005 05:35:19 GMT X-Originating-IP: [65.54.161.203] X-Originating-Email: [s_wendy_cheng@hotmail.com] X-Sender: s_wendy_cheng@hotmail.com In-Reply-To: From: "Wendy Cheng" To: gbakos@cfa.harvard.edu, linux-xfs@oss.sgi.com Subject: RE: kswapd causing giant load Date: Sun, 05 Jun 2005 05:35:19 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 05 Jun 2005 05:35:19.0928 (UTC) FILETIME=[5C931F80:01C56990] X-archive-position: 5405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: s_wendy_cheng@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1994 Lines: 57 Would you be able to recreate this problem away from 3ware controller and/or non-RAID-5 setting ? Check out: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121434, comment #263 - more specifically (cut and paste the relevant info): "Different kernels might tweak different parameters that will affect RAID-5 operations on 3Ware Escalade 7000/8000 series controllers. Finding a good set (3Ware's site has excellent recommendations) and putting those in your /etc/rc.d/rc.local or similar is _crucial_ for a production server to minimize any change in defaults with any new kernel." -- Wendy ----Original Message Follows---- From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: kswapd causing giant load Date: Sat, 4 Jun 2005 12:35:48 -0400 (EDT) Hi, I encounter a giant load (up to 10.0) when I copy files, either from a remote server to the local machine, or even locally. Because I use XFS filesystem, I decided to forward my email to the XFS list; maybe anyone has a clue. The setup is: OS: Redhat FC3 with 2.6.11-1.14_FC3smp (redhat distro) kernel, XFS filesystem HW: Dual opteron 2.0GHz on Tyan motherboard, 4Gb RAM The partition i am using is: 2.1Tb hardware RAID-5 unit served by 3ware controller (8 x 300Gb) OR 300Gb simple SATA disk, also served by a 3ware controller. I have no clue where to start combatting this problem. - Kernel specific? - Due to improper setup of the 3ware controllers? - XFS filesystem specific? 10715 hatuser 15 0 35432 2792 2020 R 28.3 0.1 1:45.06 sshd 10724 hatuser 16 0 17504 11m 664 R 8.3 0.3 0:33.56 rsync 175 root 15 0 0 0 0 S 19.7 0.0 136:25.58 kswapd0 172 root 15 0 0 0 0 S 0.3 0.0 1:23.59 pdflush 174 root 15 0 0 0 0 S 0.3 0.0 99:18.93 kswapd1 Before I start extensive experimenting, maybe someone knows right away what causes high loads due to "kswapd* and pdflush". Cheers Gaspar From owner-linux-xfs@oss.sgi.com Sun Jun 5 17:15:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 17:16:00 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j560FsXq022154 for ; Sun, 5 Jun 2005 17:15:55 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA09545; Mon, 6 Jun 2005 10:14:42 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j560Egkt1850469; Mon, 6 Jun 2005 10:14:42 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j560EeJt1853266; Mon, 6 Jun 2005 10:14:40 +1000 (EST) Date: Mon, 6 Jun 2005 10:14:40 +1000 From: Nathan Scott To: "Martin K. Petersen" Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 937235 - mkfs vs MD0/1 Message-ID: <20050606101439.C1876379@wobbly.melbourne.sgi.com> References: <20050603033904.880844822C04@chook.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mkp@mkp.net on Fri, Jun 03, 2005 at 12:15:31PM -0400 X-archive-position: 5406 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 752 Lines: 26 On Fri, Jun 03, 2005 at 12:15:31PM -0400, Martin K. Petersen wrote: > >>>>> "Nathan" == Nathan Scott writes: Hey Martin, > Nathan> Do not do stripe alignment in mkfs for raid0/1 MD devices. > > RAID1 I can understand. In hindsight and after reading the docs, I'm no longer convinced (of my last change, I mean). Both RAID0 and 1 use chunksizes we should be aligning to... > But why RAID0? I was led to think this was a linear array, rather than a stripe. What I really wanted to catch was the linear case, theres no point aligning that to anything. Looks like there's several other RAID types we need to consider nowadays too from looking through a 2.6 include/linux/raid/md_k.h and drivers/md/Kconfig. thanks! -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jun 5 18:14:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 18:14:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j561ECXq025262 for ; Sun, 5 Jun 2005 18:14:17 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10910 for ; Mon, 6 Jun 2005 11:13:09 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id E20B149AC12F; Mon, 6 Jun 2005 11:14:28 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - man pages Message-Id: <20050606011428.E20B149AC12F@chook.melbourne.sgi.com> Date: Mon, 6 Jun 2005 11:14:28 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 637 Lines: 16 Minor man page corrections, patch botch on xfs_quota.8. Date: Mon Jun 6 11:12:46 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22818a xfsprogs/man/man8/xfs_db.8 - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_db.8.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/man/man8/xfs_quota.8 - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_quota.8.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs@oss.sgi.com Sun Jun 5 19:11:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 19:12:00 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j562BtXq029518 for ; Sun, 5 Jun 2005 19:11:56 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12058; Mon, 6 Jun 2005 12:10:49 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 9970249AC12F; Mon, 6 Jun 2005 12:12:09 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 937235 - MD vs mkfs Message-Id: <20050606021209.9970249AC12F@chook.melbourne.sgi.com> Date: Mon, 6 Jun 2005 12:12:09 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 511 Lines: 15 Fixup that last fix attempting to not align on linear MD arrays; also added in RAID4/6/10 support. Date: Mon Jun 6 12:10:21 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: dgc@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22819a xfsprogs/libdisk/md.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libdisk/md.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h From owner-linux-xfs@oss.sgi.com Sun Jun 5 19:22:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 19:22:19 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j562MDXq030299 for ; Sun, 5 Jun 2005 19:22:14 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12268; Mon, 6 Jun 2005 12:21:08 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 20D5A49AC12F; Mon, 6 Jun 2005 12:22:28 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 937341 - update kernel docs Message-Id: <20050606022228.20D5A49AC12F@chook.melbourne.sgi.com> Date: Mon, 6 Jun 2005 12:22:28 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 657 Lines: 16 Update documentation on XFS sysctls and mount options. Date: Mon Jun 6 12:20:25 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: dgc@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: 2.6.x-xfs-melb:linux:22820a Documentation/filesystems/xfs.txt - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/filesystems/xfs.txt.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h split-patches/docs-update - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/docs-update.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h From owner-linux-xfs@oss.sgi.com Sun Jun 5 19:30:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 19:30:46 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j562UcXq031035 for ; Sun, 5 Jun 2005 19:30:41 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12411; Mon, 6 Jun 2005 12:29:33 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4222349AC12F; Mon, 6 Jun 2005 12:30:54 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 937341 - update docs, 2.4 kernels Message-Id: <20050606023054.4222349AC12F@chook.melbourne.sgi.com> Date: Mon, 6 Jun 2005 12:30:54 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 659 Lines: 16 Update documentation on XFS sysctls and mount options. Date: Mon Jun 6 12:29:09 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: dgc@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.4.x-xfs-melb Modid: 2.4.x-xfs-melb:linux:22822a Documentation/filesystems/xfs.txt - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/filesystems/xfs.txt.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h split-patches/docs-update2 - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/docs-update2.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h From owner-linux-xfs@oss.sgi.com Sun Jun 5 19:49:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 19:49:58 -0700 (PDT) Received: from 163.com ([220.181.31.173]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j562nrXq032091 for ; Sun, 5 Jun 2005 19:49:54 -0700 Message-Id: <200506060249.j562nrXq032091@oss.sgi.com> Received: from jcy (unknown [218.79.127.163]) by smtp11 (Coremail) with SMTP id ZkCOL4m5o0KEi_EA.1 for ; Mon, 06 Jun 2005 10:48:48 +0800 (CST) X-Originating-IP: [218.79.127.163] Date: Mon, 6 Jun 2005 10:48:45 +0800 From: "Jacky Kim" To: "linux-xfs" Subject: XFS Use% mismatch! X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-archive-position: 5412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jcy_2008@163.com Precedence: bulk X-list: linux-xfs Content-Length: 1323 Lines: 45 I use the follow XFS cmd_tars under kernel 2.6.7: acl-2.2.27.src.tar.gz attr-2.4.19.src.tar.gz xfsprogs-2.6.25.src.tar.gz dmapi-2.2.1.src.tar.gz xfsdump-2.2.25.src.tar.gz # uname -a Linux fc2 2.6.7 #1 Mon Dec 27 10:44:16 CST 2004 i686 GNU/Linux # cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid5] md0 : active raid5 sdd[4] sdc[3] sdb[2] sda[1] 732595392 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU] # mount /dev/md/0 on /vol type xfs (rw,noatime,nodiratime,nouuid,usrquota) After some days, I found some mismatch ploblem: # df -h Filesystem Size Used Avail Use% Mounted on /dev/md/0 699G 93G 607G 14% /vol ~~~ ~~~ # df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/md/0 732595328 487 732594841 1% /vol ~~~ ~~~ But when I remount it, and it seems ok: # df -h Filesystem Size Used Avail Use% Mounted on /dev/md/0 699G 2.0M 699G 1% /vol ~~~ ~~~ # df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/md/0 732595328 8 732595320 1% /vol ~~~ ~~~ Best Regards! Jacky Kim . From owner-linux-xfs@oss.sgi.com Sun Jun 5 20:46:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 20:46:58 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j563krXq006451 for ; Sun, 5 Jun 2005 20:46:54 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA13958; Mon, 6 Jun 2005 13:45:46 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id C18B949AC130; Mon, 6 Jun 2005 13:47:06 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 915018 - force large sectors for MD RAID5 Message-Id: <20050606034706.C18B949AC130@chook.melbourne.sgi.com> Date: Mon, 6 Jun 2005 13:47:06 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1802 Lines: 32 Extend get_subvol_wrapper with another parameter which tells whether or not to equate sectors&blocks for this device. Use it in mkfs for RAID4/5/6. Date: Mon Jun 6 13:44:56 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: sandeen@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22829a xfsprogs/mkfs/xfs_mkfs.c - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h xfsprogs/libdisk/md.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libdisk/md.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/libdisk/drivers.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libdisk/drivers.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/libdisk/xvm.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libdisk/xvm.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/libdisk/lvm.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libdisk/lvm.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/include/volume.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/volume.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/libdisk/evms.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libdisk/evms.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h xfsprogs/libdisk/drivers.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libdisk/drivers.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsprogs/libdisk/dm.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libdisk/dm.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h From owner-linux-xfs@oss.sgi.com Sun Jun 5 21:51:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 21:51:21 -0700 (PDT) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j564pEXq012590 for ; Sun, 5 Jun 2005 21:51:15 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j564oAfE1978799; Mon, 6 Jun 2005 14:50:10 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j564o7xB1307647; Mon, 6 Jun 2005 14:50:07 +1000 (AEST) Date: Mon, 6 Jun 2005 14:50:06 +1000 From: Tim Shimmin To: Jacky Kim Cc: linux-xfs Subject: Re: XFS Use% mismatch! Message-ID: <20050606145006.O1319708@boing.melbourne.sgi.com> References: <200506060249.j562nrXq032091@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200506060249.j562nrXq032091@oss.sgi.com>; from jcy_2008@163.com on Mon, Jun 06, 2005 at 10:48:45AM +0800 X-archive-position: 5414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1399 Lines: 39 Hi Jacky, On Mon, Jun 06, 2005 at 10:48:45AM +0800, Jacky Kim wrote: > > After some days, I found some mismatch ploblem: > > # df -h > Filesystem Size Used Avail Use% Mounted on > /dev/md/0 699G 93G 607G 14% /vol > ~~~ ~~~ > # df -i > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/md/0 732595328 487 732594841 1% /vol > ~~~ ~~~ > But when I remount it, and it seems ok: > > # df -h > Filesystem Size Used Avail Use% Mounted on > /dev/md/0 699G 2.0M 699G 1% /vol > ~~~ ~~~ > # df -i > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/md/0 732595328 8 732595320 1% /vol > ~~~ ~~~ > I not 100% certain what you are saying :) If you are saying that the %Used is not matching with what is used/total-number then I can't quite see that. This is done by df(1) code and looking at df code on IRIX (assume it's pretty similar to Linux) it does value*100/total and then takes the ceiling of that value (rounds up to next integer). (ie. if 0 < x <= 1, now matter how small it will report 1%.) e.g. 93*100/699 = 13.3%; ceil(13.3) = 14% 487*100/732595328 = 0.000006; ceil(0.000006) = 1% --Tim From owner-linux-xfs@oss.sgi.com Sun Jun 5 22:11:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 22:11:10 -0700 (PDT) Received: from 163.com ([220.181.31.173]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j565B7Xq014185 for ; Sun, 5 Jun 2005 22:11:08 -0700 Message-Id: <200506060511.j565B7Xq014185@oss.sgi.com> Received: from jcy (unknown [218.79.127.163]) by smtp11 (Coremail) with SMTP id TUCIiqjao0IIA5gA.1 for ; Mon, 06 Jun 2005 13:10:08 +0800 (CST) X-Originating-IP: [218.79.127.163] Date: Mon, 6 Jun 2005 13:10:01 +0800 From: "Jacky Kim" To: "Tim Shimmin" Cc: "linux-xfs" Subject: Re: XFS Use% mismatch! X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-archive-position: 5415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jcy_2008@163.com Precedence: bulk X-list: linux-xfs Content-Length: 1115 Lines: 36 >> After some days, I found some mismatch ploblem: >> >> # df -h >> Filesystem Size Used Avail Use% Mounted on >> /dev/md/0 699G 93G 607G 14% /vol ~~~ ~~~ It says that 93G(14%) is used, but actually about 1M is used: # du --max-depth=1 -m /vol 0 /vol/backup 0 /vol/database 1 /vol >> But when I remount it, and it seems ok: >> >> # df -h >> Filesystem Size Used Avail Use% Mounted on >> /dev/md/0 699G 2.0M 699G 1% /vol ~~~ ~~~ >> > >I not 100% certain what you are saying :) >If you are saying that the %Used is not matching with what >is used/total-number then I can't quite see that. >This is done by df(1) code and looking at df code on IRIX (assume it's >pretty similar to Linux) it does value*100/total and then takes the >ceiling of that value (rounds up to next integer). >(ie. if 0 < x <= 1, now matter how small it will report 1%.) > >e.g. 93*100/699 = 13.3%; ceil(13.3) = 14% > 487*100/732595328 = 0.000006; ceil(0.000006) = 1% > >--Tim > From owner-linux-xfs@oss.sgi.com Sun Jun 5 22:11:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 22:11:56 -0700 (PDT) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j565BoXq014398 for ; Sun, 5 Jun 2005 22:11:51 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j565AlfE1817475; Mon, 6 Jun 2005 15:10:48 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j565Aj501977805; Mon, 6 Jun 2005 15:10:45 +1000 (AEST) Date: Mon, 6 Jun 2005 15:10:45 +1000 From: Tim Shimmin To: Ed Cc: linux-xfs@oss.sgi.com Subject: Re: why is log version=1 default? Message-ID: <20050606151045.P1319708@boing.melbourne.sgi.com> References: <42A0AE93.6010001@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <42A0AE93.6010001@yandex.ru>; from spied@yandex.ru on Fri, Jun 03, 2005 at 11:25:07PM +0400 X-archive-position: 5416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 567 Lines: 19 Hi Ed, On Fri, Jun 03, 2005 at 11:25:07PM +0400, Ed wrote: > exist any reason do not use version=2 for log? > I don't think so. The only problem would be if you wanted to mount the filesystem using a linux kernel predating around June 2002 and/or mounting on an IRIX kernel prior to 6.5.26. It would/should refuse to mount the filesystem for those older kernels (which don't know about v2 logs). (Although this could probably be worked around by zeroing the log and resetting the appropriate superblock flag bit - using xfs_db or xfs_chver on IRIX). --Tim From owner-linux-xfs@oss.sgi.com Sun Jun 5 22:22:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 22:22:58 -0700 (PDT) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j565MrXq015349 for ; Sun, 5 Jun 2005 22:22:54 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j565LnfE1979737; Mon, 6 Jun 2005 15:21:49 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j565Lk4g1691604; Mon, 6 Jun 2005 15:21:46 +1000 (AEST) Date: Mon, 6 Jun 2005 15:21:46 +1000 From: Tim Shimmin To: Jacky Kim Cc: Tim Shimmin , linux-xfs Subject: Re: XFS Use% mismatch! Message-ID: <20050606152146.Q1319708@boing.melbourne.sgi.com> References: <200506060511.j565B7Xq014185@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200506060511.j565B7Xq014185@oss.sgi.com>; from jcy_2008@163.com on Mon, Jun 06, 2005 at 01:10:01PM +0800 X-archive-position: 5417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1431 Lines: 40 On Mon, Jun 06, 2005 at 01:10:01PM +0800, Jacky Kim wrote: > >> After some days, I found some mismatch ploblem: > >> > >> # df -h > >> Filesystem Size Used Avail Use% Mounted on > >> /dev/md/0 699G 93G 607G 14% /vol > ~~~ ~~~ > It says that 93G(14%) is used, but actually about 1M is used: > # du --max-depth=1 -m /vol > 0 /vol/backup > 0 /vol/database > 1 /vol > > >> But when I remount it, and it seems ok: > >> > >> # df -h > >> Filesystem Size Used Avail Use% Mounted on > >> /dev/md/0 699G 2.0M 699G 1% /vol > ~~~ ~~~ Sorry, I thought you were comparing the tilde underlined fields. You're saying it looks like the counters for space and inodes are not being properly updated until you remount. Okay, not so good :( > >> > > > >I not 100% certain what you are saying :) > >If you are saying that the %Used is not matching with what > >is used/total-number then I can't quite see that. > >This is done by df(1) code and looking at df code on IRIX (assume it's > >pretty similar to Linux) it does value*100/total and then takes the > >ceiling of that value (rounds up to next integer). > >(ie. if 0 < x <= 1, now matter how small it will report 1%.) > >e.g. 93*100/699 = 13.3%; ceil(13.3) = 14% > > 487*100/732595328 = 0.000006; ceil(0.000006) = 1% > >--Tim > > From owner-linux-xfs@oss.sgi.com Sun Jun 5 23:28:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jun 2005 23:29:00 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j566StXq019736 for ; Sun, 5 Jun 2005 23:28:56 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA16927; Mon, 6 Jun 2005 16:27:48 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j566RkXf158616; Mon, 6 Jun 2005 16:27:47 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j566RijL151319; Mon, 6 Jun 2005 16:27:44 +1000 (EST) Date: Mon, 6 Jun 2005 16:27:44 +1000 From: Dave Chinner To: Jacky Kim Cc: linux-xfs Subject: Re: XFS Use% mismatch! Message-ID: <20050606162744.C19332@melbourne.sgi.com> References: <200506060511.j565B7Xq014185@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200506060511.j565B7Xq014185@oss.sgi.com>; from jcy_2008@163.com on Mon, Jun 06, 2005 at 01:10:01PM +0800 X-archive-position: 5418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1060 Lines: 33 On Mon, Jun 06, 2005 at 01:10:01PM +0800, Jacky Kim wrote: > >> After some days, I found some mismatch ploblem: > >> > >> # df -h > >> Filesystem Size Used Avail Use% Mounted on > >> /dev/md/0 699G 93G 607G 14% /vol > ~~~ ~~~ > It says that 93G(14%) is used, but actually about 1M is used: > # du --max-depth=1 -m /vol > 0 /vol/backup > 0 /vol/database > 1 /vol What you are probably seeing here is unlinked but still referenced files. The space is not freed until the inode is completely unlinked from the filesystem, and this occurs when the final reference to the inode goes away. Seeing as the inode has been unlinked from the directory, a filesystem traversal such as find or du will not find the inode and so it will not show up as used space in such a scan. You can probably use fuser or lsof to see if there are any userspace processes still holding reference to the files. Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Mon Jun 6 05:48:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jun 2005 05:48:17 -0700 (PDT) Received: from lucifer.czad.org (lucifer.czad.org [80.55.246.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j56Cm9Xq023259 for ; Mon, 6 Jun 2005 05:48:10 -0700 Received: (qmail 19561 invoked by uid 1000); 6 Jun 2005 12:47:03 -0000 Subject: XFS oops, kernel 2.4.30 w/grsecurity From: Marek Materzok Reply-To: tilk@lucifer.czad.org To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 06 Jun 2005 14:47:02 +0200 Message-Id: <1118062022.6266.19.camel@lucifer.czad.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-archive-position: 5419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tilk@lucifer.czad.org Precedence: bulk X-list: linux-xfs Content-Length: 3041 Lines: 41 A following error happened on my server today: Jun 6 11:40:08 lucifer kernel: Filesystem "ide0(3,6)": XFS internal error xfs_btree_check_lblock at line 222 of file xfs_btree.c. Caller 0xc01ed58d Jun 6 11:40:08 lucifer kernel: c9871750 c01efc41 c0374857 00000001 d71ffc00 c037484b 000000de c01ed58d Jun 6 11:40:08 lucifer kernel: c8bd4f80 d76b2940 00ca1740 00000000 00000008 00000000 c987178c cf416124 Jun 6 11:40:08 lucifer kernel: 00000000 e8421900 d0df8000 c01ed58d cf416124 d0df8000 00000000 d7e66d40 Jun 6 11:40:08 lucifer kernel: Call Trace: [xfs_btree_check_lblock+97/416] [xfs_bmbt_rshift+253/1584] [xfs_bmbt_rshift+253/1584] [kmem_zone_zalloc+53/95] [xfs_buf_item_init+85/192] Jun 6 11:40:08 lucifer kernel: [xfs_bmbt_insrec+1072/1552] [xfs_btree_check_lblock+155/416] [xfs_bmbt_lookup+1191/1296] [xfs_bmbt_insert+109/320] [xfs_bmap_add_extent_delay_real+4261/5440] [xfs_trans_mod_dquot_byino+272/288] Jun 6 11:40:08 lucifer kernel: [xfs_trans_mod_dquot+58/304] [xfs_bmap_add_extent+829/1104] [kmem_zone_zalloc+53/95] [xfs_bmapi+1706/5584] [xfs_bmap_do_search_extents+248/1056] [xfs_bmap_search_extents+107/272] Jun 6 11:40:08 lucifer kernel: [xfs_log_reserve+191/208] [xfs_iomap_write_allocate+698/1392] [xfs_iunlock+62/128] [xfs_iomap+987/1344] [xfs_map_blocks+88/144] [xfs_page_state_convert+1208/1600] Jun 6 11:40:08 lucifer kernel: [create_buffers+107/224] [linvfs_writepage+126/304] [fsync_buffers_list+290/384] [__block_commit_write+128/192] [generic_osync_inode+143/176] [do_generic_file_write+875/1056] Jun 6 11:40:08 lucifer kernel: [xfs_write+684/2432] [do_generic_file_read+494/1120] [update_atime+108/112] [linvfs_write+245/400] [do_readv_writev+451/560] [linvfs_write+0/400] Jun 6 11:40:09 lucifer kernel: [sys_writev+90/128] [system_call+51/64] Jun 6 11:40:09 lucifer kernel: xfs_force_shutdown(ide0(3,6),0x8) called from line 1091 of file xfs_trans.c. Return address = 0xc023aa4b Jun 6 11:40:09 lucifer kernel: Filesystem "ide0(3,6)": Corruption of in-memory data detected. Shutting down filesystem: ide0(3,6) Jun 6 11:40:09 lucifer kernel: Please umount the filesystem, and rectify the problem(s) Then, the /home partition (/dev/hda6) was disabled, and every access to it ended with EIO. A reboot fixed the problem - the filesystem was rebuilt and mounted correctly. Nothing like this happened ever to my XFS filesystems. My kernel is: Linux version 2.4.30-tilk1 (tilk@lucifer.czad.org) (gcc version 3.3.4 (Debian 1:3.3.4-3)) #1 sob kwi 9 12:54:22 CEST 2005 Patches applied are: grsecurity 2.1.5, lm_sensors 2.8.8, XFS ACL. -- _____ _ _ _ |_ _(_) | |__ | Marek "Tilk" Materzok -- tilk@lucifer.czad.org | | | | | | / / | http://tilk.czad.org/ -- GPG #F8C12ABE | |_| |_|_|_\_\ | "How can you challenge a perfect, immortal machine?" | -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS d- s: a--- C++ UL+++$ P-- L+++$ E- W++ N+ o? K? w--- O? M? V? PS+ PE- Y+ PGP+ !t 5? X R* tv b+ DI+ D G e h! !r y- ------END GEEK CODE BLOCK------ From owner-linux-xfs@oss.sgi.com Mon Jun 6 16:20:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jun 2005 16:20:33 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j56NKPXq016536 for ; Mon, 6 Jun 2005 16:20:26 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07315; Tue, 7 Jun 2005 09:19:19 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 17FFF49AC130; Tue, 7 Jun 2005 09:20:50 +1000 (EST) To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE 907752 - attr Message-Id: <20050606232050.17FFF49AC130@chook.melbourne.sgi.com> Date: Tue, 7 Jun 2005 09:20:50 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5420 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1090 Lines: 23 Reduce verbosity when copying attributes between files. Patch from AndreasG. Date: Tue Jun 7 09:18:38 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/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:22833a attr/VERSION - 1.53 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/VERSION.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h attr/doc/CHANGES - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h attr/debian/changelog - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/debian/changelog.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h attr/libattr/attr_copy_fd.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libattr/attr_copy_fd.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h attr/libattr/attr_copy_file.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libattr/attr_copy_file.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h From owner-linux-xfs@oss.sgi.com Mon Jun 6 23:40:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jun 2005 23:40:51 -0700 (PDT) Received: from topalm2.dionis.local (82.211.131.6.planetsky.com [82.211.131.6] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j576egXq021415 for ; Mon, 6 Jun 2005 23:40:45 -0700 Received: from [10.0.0.99] (helo=[10.0.0.99]) by topalm2.dionis.local with esmtp (Exim 3.35 #1 (Debian)) id 1DfXkK-00075Z-00; Tue, 07 Jun 2005 10:39:32 +0400 Message-ID: <42A54124.4060007@yandex.ru> Date: Tue, 07 Jun 2005 10:39:32 +0400 From: Ed User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: nathans@sgi.com Subject: Re: right su and sw values for raid 10 References: <42A08C35.9080402@yandex.ru> In-Reply-To: <42A08C35.9080402@yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: spied@yandex.ru Precedence: bulk X-list: linux-xfs Content-Length: 285 Lines: 10 Ed wrote: > can you help me select right su and sw parameters for hardware raid 10 > (4 disks, 128kb stripe)? i found this message: "TAKE 937235 - mkfs vs MD0/1". it's right don't use sunit and swidth for raid 10? From owner-linux-xfs@oss.sgi.com Tue Jun 7 07:41:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jun 2005 07:41:40 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j57EfYXq002380 for ; Tue, 7 Jun 2005 07:41:34 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j57GS6XB021247 for ; Tue, 7 Jun 2005 09:28:07 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j57EdUR09711530; Tue, 7 Jun 2005 09:39:30 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DffEn-000094-00; Tue, 07 Jun 2005 09:39:29 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 928382 - add XFS_INOBT_IS_FREE_DISK Message-Id: From: Christoph Hellwig Date: Tue, 07 Jun 2005 09:39:29 -0500 X-archive-position: 5422 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 758 Lines: 20 Date: Tue Jun 7 07:39:14 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:193778a fs/xfs/xfs_macros.c - 1.57 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_macros.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h - add a variant of XFS_INOBT_IS_FREE that works with on disk structures fs/xfs/xfs_ialloc_btree.h - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h - add a variant of XFS_INOBT_IS_FREE that works with on disk structures needed for xfsprogs and we want to keep this header in sync From owner-linux-xfs@oss.sgi.com Tue Jun 7 07:57:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jun 2005 07:57:32 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j57EvSXq004998 for ; Tue, 7 Jun 2005 07:57:28 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j57EuNxT030990 for ; Tue, 7 Jun 2005 09:56:23 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j57EuM0F16503892; Tue, 7 Jun 2005 09:56:22 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DffV7-0002ad-00; Tue, 07 Jun 2005 09:56:21 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 928382 - resync endianess handling in xfsprogs with the kernel Message-Id: From: Christoph Hellwig Date: Tue, 07 Jun 2005 09:56:21 -0500 X-archive-position: 5423 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1828 Lines: 31 Date: Tue Jun 7 07:56:07 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:193780a xfsprogs/db/frag.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/frag.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/db/check.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/check.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfsprogs/include/libxfs.h - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h xfsprogs/include/xfs_ialloc_btree.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_ialloc_btree.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/repair/phase7.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase7.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/repair/incore.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/incore.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/repair/scan.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/scan.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/libxfs/xfs_ialloc.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_ialloc.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h xfsprogs/libxfs/xfs.h - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs.h.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h xfsprogs/libxfs/xfs_bmap_btree.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_bmap_btree.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h From owner-linux-xfs@oss.sgi.com Tue Jun 7 07:57:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jun 2005 07:57:39 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j57EvaXq005053 for ; Tue, 7 Jun 2005 07:57:36 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j57Gi8ot028230 for ; Tue, 7 Jun 2005 09:44:09 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j57EuWR09710606 for ; Tue, 7 Jun 2005 09:56:32 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j57EuVaV44569433; Tue, 7 Jun 2005 09:56:31 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j57EuVgc020281; Tue, 7 Jun 2005 09:56:31 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j57EuVqN020279; Tue, 7 Jun 2005 09:56:31 -0500 Date: Tue, 7 Jun 2005 09:56:31 -0500 From: Eric Sandeen Message-Id: <200506071456.j57EuVqN020279@penguin.americas.sgi.com> To: sgi.bugs.xfs@fido.engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 937447 - minor warning cleanup X-archive-position: 5424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 520 Lines: 17 Fix warning on 2.4: feed likely() and int, not a pointer Date: Tue Jun 7 07:56:07 PDT 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:193781a linux-2.4/xfs_buf.c - 1.206 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.c.diff?r1=text&tr1=1.206&r2=text&tr2=1.205&f=h - Fix warning: feed likely() and int, not a pointer From owner-linux-xfs@oss.sgi.com Tue Jun 7 17:18:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jun 2005 17:18:22 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j580IGXq010548 for ; Tue, 7 Jun 2005 17:18:17 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10948; Wed, 8 Jun 2005 10:17:06 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j580H6kt1936343; Wed, 8 Jun 2005 10:17:06 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j580H3OJ1936172; Wed, 8 Jun 2005 10:17:03 +1000 (EST) Date: Wed, 8 Jun 2005 10:17:03 +1000 From: Nathan Scott To: Ed Cc: linux-xfs@oss.sgi.com Subject: Re: right su and sw values for raid 10 Message-ID: <20050608101703.B1931184@wobbly.melbourne.sgi.com> References: <42A08C35.9080402@yandex.ru> <42A54124.4060007@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <42A54124.4060007@yandex.ru>; from spied@yandex.ru on Tue, Jun 07, 2005 at 10:39:32AM +0400 X-archive-position: 5426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 560 Lines: 20 On Tue, Jun 07, 2005 at 10:39:32AM +0400, Ed wrote: > Ed wrote: > > > can you help me select right su and sw parameters for hardware raid 10 > > (4 disks, 128kb stripe)? > > > i found this message: "TAKE 937235 - mkfs vs MD0/1". > it's right don't use sunit and swidth for raid 10? No. Look thru the CVS code in xfsprogs/libdisk/md.c -- you should be able to figure out the right thing for your setup from that. If you're keen, and your RAID device driver exports its geometry, you could add some new libdisk code for your device. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jun 7 21:47:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jun 2005 21:47:45 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j584leXq000834 for ; Tue, 7 Jun 2005 21:47:41 -0700 Received: from pimout1-ext.prodigy.net (pimout1-int.prodigy.net [207.115.5.65]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j584kkKd020083 for ; Wed, 8 Jun 2005 00:46:46 -0400 X-ORBL: [63.202.173.158] Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j584kYsk128210; Wed, 8 Jun 2005 00:46:34 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 170FD528F22; Tue, 7 Jun 2005 21:46:34 -0700 (PDT) Date: Tue, 7 Jun 2005 21:46:34 -0700 From: Chris Wedgwood To: Tim Shimmin Cc: Ed , linux-xfs@oss.sgi.com Subject: Re: why is log version=1 default? Message-ID: <003874.f47b8d00f0d0e5163b2a498c9a81b182.ANY@taniwha.stupidest.org> References: <42A0AE93.6010001@yandex.ru> <20050606151045.P1319708@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050606151045.P1319708@boing.melbourne.sgi.com> X-archive-position: 5428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 281 Lines: 8 On Mon, Jun 06, 2005 at 03:10:45PM +1000, Tim Shimmin wrote: > The only problem would be if you wanted to mount the filesystem > using a linux kernel predating around June 2002 and/or mounting on > an IRIX kernel prior to 6.5.26. Does IRIX 6.5.26 support v2 directories anyway? From owner-linux-xfs@oss.sgi.com Tue Jun 7 23:42:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jun 2005 23:42:24 -0700 (PDT) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j586gJXq008796 for ; Tue, 7 Jun 2005 23:42:20 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j586fBfE2040747; Wed, 8 Jun 2005 16:41:12 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j586f8Hl1432437; Wed, 8 Jun 2005 16:41:08 +1000 (AEST) Date: Wed, 8 Jun 2005 16:41:07 +1000 From: Tim Shimmin To: Chris Wedgwood Cc: Tim Shimmin , Ed , linux-xfs@oss.sgi.com Subject: Re: why is log version=1 default? Message-ID: <20050608164107.C1319708@boing.melbourne.sgi.com> References: <42A0AE93.6010001@yandex.ru> <20050606151045.P1319708@boing.melbourne.sgi.com> <003874.f47b8d00f0d0e5163b2a498c9a81b182.ANY@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <003874.f47b8d00f0d0e5163b2a498c9a81b182.ANY@taniwha.stupidest.org>; from cw@f00f.org on Tue, Jun 07, 2005 at 09:46:34PM -0700 X-archive-position: 5429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 583 Lines: 20 Hi Chris, On Tue, Jun 07, 2005 at 09:46:34PM -0700, Chris Wedgwood wrote: > On Mon, Jun 06, 2005 at 03:10:45PM +1000, Tim Shimmin wrote: > > > The only problem would be if you wanted to mount the filesystem > > using a linux kernel predating around June 2002 and/or mounting on > > an IRIX kernel prior to 6.5.26. > > Does IRIX 6.5.26 support v2 directories anyway? > I'm a bit confused by the question - are you confusing v2 directories with v2 logs perhaps? v2 directories went in around IRIX 6.5.5mf and became the default in 6.5.14mf. v2 logs went into IRIX 6.5.26. --Tim From owner-linux-xfs@oss.sgi.com Wed Jun 8 03:12:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jun 2005 03:12:38 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j58ACYXq004733 for ; Wed, 8 Jun 2005 03:12:34 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j58BxCYH011533 for ; Wed, 8 Jun 2005 04:59:13 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j58ABS0F16555950; Wed, 8 Jun 2005 05:11:28 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DfxWz-00005T-00; Wed, 08 Jun 2005 05:11:29 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 936977 - quiesce the filesystem proper when freezing Message-Id: From: Christoph Hellwig Date: Wed, 08 Jun 2005 05:11:29 -0500 X-archive-position: 5430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1191 Lines: 26 Date: Wed Jun 8 03:10:57 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:193840a fs/xfs/xfs_vfsops.c - 1.468 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.468&r2=text&tr2=1.467&f=h - add a new xfs_quiesce_fs helper, used by remount read-only and freeze fs/xfs/linux-2.4/xfs_vfs.h - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.h.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h fs/xfs/linux-2.6/xfs_vfs.h - 1.51 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h - add SYNC_QUIESCE flag fs/xfs/linux-2.4/xfs_super.c - 1.306 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.306&r2=text&tr2=1.305&f=h fs/xfs/linux-2.6/xfs_super.c - 1.334 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.334&r2=text&tr2=1.333&f=h - call VFS_SYNC(..., SYNC_QUIESCE, ...) in the freeze path From owner-linux-xfs@oss.sgi.com Wed Jun 8 07:36:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jun 2005 07:36:20 -0700 (PDT) Received: from ausmail2.core.coremetrics.com (app.clientdynamics.net [66.45.103.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j58EaFXq021441 for ; Wed, 8 Jun 2005 07:36:15 -0700 Received: by ausmail2.core.coremetrics.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jun 2005 09:32:03 -0500 Message-ID: From: "Harris, Jeff" To: linux-xfs@oss.sgi.com Subject: Help! Issue with growing an XFS filesystem, bootblock is now miss ing... Date: Wed, 8 Jun 2005 09:32:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 5431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: JHarris@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1472 Lines: 57 Hello all, we were trying to grow a 61gb Filesystem to 230gb and ran into a bad issue. I expanded the storage on the backend, made sure Linux could see it, and then ran my fdisk. I deleted the partition, did NOT write the changes, and then made the larger partition over it, making sure to use the whole disk including the 1st sector. After writing out our changes, it appears to have corrupted our Filesystem bootblock. It will not recognize that there is an XFS Filesystem there, even though when I cat the device I definitely see data. Xfs_repair complains about the lack of a primary superblock, and goes on to find secondary superblocks, but it can't use any of them. I dd'd the first 512bytes of the partition and it is blank. I tried to take the first 512bytes from a 400gb volume on another host, and then write that into the bad one, but that didn't work. Then I tried it with a smaller volume (200gb). I also tried writing in the first 512bytes of the entire disk from a healthy disk. Does anyone have any tricks up their sleeve that they can show me? Xfs_db doesn't recognize that there is anything there. It's like the entire label and everything was wiped out for whatever reason. We're looking at a 24-36 hour restore from tape if I can't get this going again. Help! -- Jeff Harris - jharris@coremetrics.com Senior Systems Administrator CoreMetrics [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Jun 8 16:19:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jun 2005 16:19:15 -0700 (PDT) Received: from smtp.au.arup.com (smtp.au.arup.com [202.3.74.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j58NJ9Xq008803 for ; Wed, 8 Jun 2005 16:19:10 -0700 Received: from unknown (HELO syduxs04.au.arup.com) (10.32.20.4) by smtp.au.arup.com with ESMTP; 09 Jun 2005 09:18:04 +1000 X-IronPort-AV: i="3.93,184,1114956000"; d="scan'208"; a="3414303:sNHT148092304" Received: from sydexc02.global.arup.com (sydexc02.global.arup.com [10.32.11.32]) by syduxs04.au.arup.com (8.12.10/8.12.10) with ESMTP id j58Mr4Ot022232 for ; Thu, 9 Jun 2005 08:53:04 +1000 Received: from bneexc01.global.arup.com ([10.33.11.31]) by sydexc02.global.arup.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Jun 2005 09:18:16 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: kernel panic on full filesystem Date: Thu, 9 Jun 2005 09:18:16 +1000 Message-ID: <2B6FD80A38020542803BA5DC9B3C9754225183@bneexc01.global.arup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: kernel panic on full filesystem Thread-Index: AcVsgFikMoj2Iyb9Q+yWYLv8/UHdIg== From: "Scott Fagg" To: X-OriginalArrivalTime: 08 Jun 2005 23:18:16.0656 (UTC) FILETIME=[59B4C500:01C56C80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j58NJCXq008807 X-archive-position: 5432 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com.au Precedence: bulk X-list: linux-xfs Content-Length: 724 Lines: 17 Awoke this morning to discover a server unresponsive. OS still running but anything involviing a disk read would fail (e.g. login). Kernel panic dump on screen and references to xfs_ functions in the info. Only hint in /var/log/messages was a problem dereferencing a null pointer. Initially i assumed a hardware fault, but then also noticed that the filesystem was 100% full. After a reboot the machine is running fine and i'm cleaning out the full filesystem. Is it conceivable that a full filesystem (not the root filesystem) would cause a kernel panic in XFS ? I vaguely recall having this problem once before a year or two ago. Running FC3 with a kernel.org 2.6.11.1 kernel. 500GB XFS filesystem on hardware raid5. From owner-linux-xfs@oss.sgi.com Wed Jun 8 18:08:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jun 2005 18:08:15 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5918AXq014087 for ; Wed, 8 Jun 2005 18:08:11 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12004; Thu, 9 Jun 2005 11:06:59 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5916vXf167066; Thu, 9 Jun 2005 11:06:58 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j5916u0O155264; Thu, 9 Jun 2005 11:06:56 +1000 (EST) Date: Thu, 9 Jun 2005 11:06:56 +1000 From: Dave Chinner To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: kernel panic on full filesystem Message-ID: <20050609110655.H19332@melbourne.sgi.com> References: <2B6FD80A38020542803BA5DC9B3C9754225183@bneexc01.global.arup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <2B6FD80A38020542803BA5DC9B3C9754225183@bneexc01.global.arup.com>; from scott.fagg@arup.com.au on Thu, Jun 09, 2005 at 09:18:16AM +1000 X-archive-position: 5433 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 747 Lines: 24 On Thu, Jun 09, 2005 at 09:18:16AM +1000, Scott Fagg wrote: > > Awoke this morning to discover a server unresponsive. OS still running > but anything involviing a disk read would fail (e.g. login). Kernel > panic dump on screen and references to xfs_ functions in the info. Only > hint in /var/log/messages was a problem dereferencing a null pointer. Do you have a copy of this info? If so, can you post it so we can try to determine what the problem was? > Is it conceivable that a full filesystem (not the root filesystem) would > cause a kernel panic in XFS ? I vaguely recall having this problem once > before a year or two ago. It certainly shouldn't. Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Wed Jun 8 18:23:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jun 2005 18:23:41 -0700 (PDT) Received: from smtp.au.arup.com (smtp.au.arup.com [202.3.74.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j591NZXq015121 for ; Wed, 8 Jun 2005 18:23:36 -0700 Received: from unknown (HELO syduxs03.au.arup.com) (10.32.20.3) by smtp.au.arup.com with ESMTP; 09 Jun 2005 11:22:30 +1000 X-IronPort-AV: i="3.93,184,1114956000"; d="scan'208"; a="3420711:sNHT44553780" Received: from sydexc02.global.arup.com (sydexc02.global.arup.com [10.32.11.32]) by syduxs03.au.arup.com (8.12.10/8.12.10) with ESMTP id j590qdCa021411; Thu, 9 Jun 2005 10:52:39 +1000 Received: from bneexc01.global.arup.com ([10.33.11.31]) by sydexc02.global.arup.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Jun 2005 11:22:43 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: kernel panic on full filesystem Date: Thu, 9 Jun 2005 11:22:39 +1000 Message-ID: <2B6FD80A38020542803BA5DC9B3C975422518E@bneexc01.global.arup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: kernel panic on full filesystem Thread-Index: AcVskAG9Q8ZeCZyJQq2XWuV0yWzq7gAAOO5g From: "Scott Fagg" To: "Dave Chinner" , X-OriginalArrivalTime: 09 Jun 2005 01:22:43.0407 (UTC) FILETIME=[BC3C8DF0:01C56C91] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j591NbXq015125 X-archive-position: 5434 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com.au Precedence: bulk X-list: linux-xfs Content-Length: 1157 Lines: 43 > > On Thu, Jun 09, 2005 at 09:18:16AM +1000, Scott Fagg wrote: > > > > Awoke this morning to discover a server unresponsive. OS > still running > > but anything involviing a disk read would fail (e.g. login). Kernel > > panic dump on screen and references to xfs_ functions in > the info. Only > > hint in /var/log/messages was a problem dereferencing a > null pointer. > > Do you have a copy of this info? If so, can you post it so we can > try to determine what the problem was? Unfortunately not, it only appeared on screen, never in any log files. Given the clues in can gather from my log files, it did occur at a point in time when a large file copy process was running. > > > Is it conceivable that a full filesystem (not the root > filesystem) would > > cause a kernel panic in XFS ? I vaguely recall having this > problem once > > before a year or two ago. > > It certainly shouldn't. I found a reference to my last problem : http://oss.sgi.com/archives/linux-xfs/2003-08/msg00106.html Full filesystem + ACLs lead to a panic. > > Cheers, > > Dave. > -- > Dave Chinner > R&D Software Engineer > SGI Australian Software Group > From owner-linux-xfs@oss.sgi.com Thu Jun 9 03:18:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jun 2005 03:18:13 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j59AI6Xq027106 for ; Thu, 9 Jun 2005 03:18:07 -0700 Received: from [194.173.12.131] (helo=[192.10.98.53]) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwh2-1DgK5q05g4-0004tZ; Thu, 09 Jun 2005 12:16:58 +0200 Message-ID: <42A81719.9080801@gmx.net> Date: Thu, 09 Jun 2005 12:16:57 +0200 From: Klaus Strebel User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: LVM general discussion and development , linux-xfs@oss.sgi.com Subject: Re: [linux-lvm] lvcreate goes into deep-sleep while creating an xfs snapshot References: <6A58CFF91886D54BBDA1FE988C4DF79D025065@bagex01.baghus-lan.net> In-Reply-To: <6A58CFF91886D54BBDA1FE988C4DF79D025065@bagex01.baghus-lan.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:8a7df7300d3d15a4f701302fdde7adf9 X-archive-position: 5435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 1481 Lines: 42 Sven Riedel schrieb: > Hi, > I'm creating a backup script for a database using lvm snapshots. > The script ran fine for a few test runs, then I added xfs_freeze -f > just before the lvcreate command, as per HOWTO recipe. Now > lvcreate went into deep-sleep and wont wake up: > > update:~/bin# ps ax | grep lvcreate > 25053 pts/2 D /dev/database_vg/tables_lv > > Running lvdisplay in a different terminal to see if lvm itself > is still seeing all LVs results in lvdisplay going into > deep-sleep mode as well. Doing an strace -p 25053 > doesn't display anything (strace won't catch my interrupts > either, but according to ps it's in a regular sleep). > > dmesg doesn't say anything to this situation. > > Is there a known issue with snapshots and xfs_freeze? > Any way I can gather pertinent debugging info? > > I'm running lvm 2.01.04 (package from debian unstable). The HOWTO is way old, with LVM2 the XFS filesystem is 'frozen' automaticly on the mount -onouuid,ro ( not quite sure, but probably also for LVM1 ..., think it's in the XFS code ). So, forget xfs_freeze. It's freezing your box, not your filesystems. XFS-Guys: shouldn't xfs_freeze be removed from xfs_cmds? It's doing more harm than use ( if any use at all ), so ... -- Mit freundlichen Grüssen / best regards Klaus Strebel, Dipl.-Inform. (FH), mailto:klaus.strebel@gmx.net /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \ From owner-linux-xfs@oss.sgi.com Thu Jun 9 08:51:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jun 2005 08:51:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j59Fp5Xq023179 for ; Thu, 9 Jun 2005 08:51:08 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j59FnxBs014635 for ; Thu, 9 Jun 2005 11:49:59 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j59FnsO13280 for ; Thu, 9 Jun 2005 11:49:54 -0400 Received: from null.msp.redhat.com (null.msp.redhat.com [10.15.80.136]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j59Fns6f010412; Thu, 9 Jun 2005 11:49:54 -0400 Received: from null.msp.redhat.com (localhost.localdomain [127.0.0.1]) by null.msp.redhat.com (8.13.4/8.12.11) with ESMTP id j59Fnr2P006490; Thu, 9 Jun 2005 10:49:53 -0500 Received: (from alewis@localhost) by null.msp.redhat.com (8.13.4/8.13.4/Submit) id j59FnnHi006488; Thu, 9 Jun 2005 10:49:49 -0500 Date: Thu, 9 Jun 2005 10:49:49 -0500 From: AJ Lewis To: LVM general discussion and development Cc: linux-xfs@oss.sgi.com Subject: Re: [linux-lvm] lvcreate goes into deep-sleep while creating an xfs snapshot Message-ID: <20050609154949.GA4872@null.msp.redhat.com> References: <6A58CFF91886D54BBDA1FE988C4DF79D025065@bagex01.baghus-lan.net> <42A81719.9080801@gmx.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <42A81719.9080801@gmx.net> User-Agent: Mutt/1.4.2.1i X-archive-position: 5436 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alewis@redhat.com Precedence: bulk X-list: linux-xfs Content-Length: 2363 Lines: 69 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 09, 2005 at 12:16:57PM +0200, Klaus Strebel wrote: > Sven Riedel schrieb: > >Hi, > >I'm creating a backup script for a database using lvm snapshots. > >The script ran fine for a few test runs, then I added xfs_freeze -f=20 > >just before the lvcreate command, as per HOWTO recipe. Now > >lvcreate went into deep-sleep and wont wake up: > > > >update:~/bin# ps ax | grep lvcreate > >25053 pts/2 D > /dev/database_vg/tables_lv > > > >Running lvdisplay in a different terminal to see if lvm itself > >is still seeing all LVs results in lvdisplay going into=20 > >deep-sleep mode as well. Doing an strace -p 25053=20 > >doesn't display anything (strace won't catch my interrupts > >either, but according to ps it's in a regular sleep). > > > >dmesg doesn't say anything to this situation. > > > >Is there a known issue with snapshots and xfs_freeze?=20 > >Any way I can gather pertinent debugging info? > > > >I'm running lvm 2.01.04 (package from debian unstable). >=20 > The HOWTO is way old, with LVM2 the XFS filesystem is 'frozen'=20 > automaticly on the mount -onouuid,ro ( not quite sure, but probably also= =20 > for LVM1 ..., think it's in the XFS code ). > So, forget xfs_freeze. It's freezing your box, not your filesystems. I'm *slowly* working on getting the howto updated for LVM2. I should have = the xfs_freeze-related lines out today. I've been meaning to do that for a whi= le. Please e-mail me if you see other things that are wrong in the HowTo. Thanks,=20 --=20 AJ Lewis Voice: 612-638-0500 Red Hat Inc. E-Mail: alewis@redhat.com One Main Street SE, Suite 209 Minneapolis, MN 55414 =20=20=20 Current GPG fingerprint =3D D9F8 EDCE 4242 855F A03D 9B63 F50C 54A8 578C 8= 715 Grab the key at: http://people.redhat.com/alewis/gpg.html or one of the many keyservers out there... --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCqGUd9QxUqFeMhxURApLoAJ0eRWMxsCAyrSHPdpXWzKdjANr2ywCePK0M 2XsSmUsLSdbnzxraZ5afQ1U= =oGOi -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-linux-xfs@oss.sgi.com Thu Jun 9 12:22:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jun 2005 12:22:50 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j59JMkXq005520 for ; Thu, 9 Jun 2005 12:22:46 -0700 Received: by wproxy.gmail.com with SMTP id 68so76880wri for ; Thu, 09 Jun 2005 12:21:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=B98XCKQ4Id4C09JAzwv2hn2im6E+CIe3sulprHrHmiVAx58VugZ79AG4NwS1wYr7PCdlukz67mj4xLfHCZXli8rvqhltg+7PnKWaJmbfZOr2yu7pshc4Y2qkVnzdtgPPt2O59b/oVQsQympx1Wi/Q6sDOubcHr+PAlZm9CUAtks= Received: by 10.54.116.20 with SMTP id o20mr529029wrc; Thu, 09 Jun 2005 12:21:40 -0700 (PDT) Received: by 10.54.15.56 with HTTP; Thu, 9 Jun 2005 12:21:38 -0700 (PDT) Message-ID: Date: Thu, 9 Jun 2005 16:21:38 -0300 From: Alvaro R Reply-To: Alvaro R To: linux-xfs@oss.sgi.com Subject: Strange swap growth/exhaustion Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j59JMkXq005522 X-archive-position: 5437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: askxfs@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1711 Lines: 51 Hello, I am running SuSE 9.0 Enterprise, latest kernel 2.6.5-7.147-smp, on a IBM Blade server. It has 2 Xeon processors, 2,5 gigs of RAM, and it is attached to a FastT store. I have create a 1,2 terabyte raid0 partition (on top of fastt's raid5) and handle *several* image files (tif, soon to be djvu) with sizes around 70k. most of the files are on a single directory, and all is working fine (uptime is 89 days), but since I converted from reiserfs to XFS I am getting crappy backup thruput, but I am thinking that this is CA's software fault, since it has been patched. Anyway, I have a 1gig swap partition, and it got filled up quickly, while I only run plain Apache2 (worker) to serve the images (no PHP or other dynamic content). and there's nothing that seem to be using this swap area, but it is 100% anyway, I after while created a swapfile, also 1gig, and it also became 100% full, usage growth rate is about 400 megs/hour. RAM is ok, see below: any ideias ? Just started happening with XFS... Thanks in advance. alvaro@blade01:~> cat /proc/meminfo MemTotal: 2594792 kB MemFree: 73116 kB Buffers: 40520 kB Cached: 2347360 kB SwapCached: 220 kB Active: 1031532 kB Inactive: 1384416 kB HighTotal: 1703860 kB HighFree: 3712 kB LowTotal: 890932 kB LowFree: 69404 kB SwapTotal: 2097120 kB SwapFree: 0 kB Dirty: 1776 kB Writeback: 0 kB Mapped: 32948 kB Slab: 79368 kB Committed_AS: 2851264 kB PageTables: 672 kB VmallocTotal: 114680 kB VmallocUsed: 21712 kB VmallocChunk: 76392 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 4096 kB From owner-linux-xfs@oss.sgi.com Thu Jun 9 15:05:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jun 2005 15:05:42 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j59M5cXq018939 for ; Thu, 9 Jun 2005 15:05:39 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j59NqTuU027955 for ; Thu, 9 Jun 2005 16:52:29 -0700 Received: from sgi.com (pc-swilson.americas.sgi.com [169.238.224.54]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j59M3Wad63100940 for ; Thu, 9 Jun 2005 15:03:32 -0700 (PDT) Message-ID: <42A880BE.6090902@sgi.com> Date: Thu, 09 Jun 2005 13:47:42 -0400 From: swilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs on redhat enterprise WS 3.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5438 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: swilson@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 345 Lines: 15 Hi, Im trying to prepare a cxfs client thats required to run the above O.S. It however has 7.2 installed on another disk with data disks using xfs. Im trying to access these data disks for the cxfs proof of concept. I found what I believe are the app rpms but no kernel rpms for 3.0 Could you put me in the right direction. Thanks, Scott From owner-linux-xfs@oss.sgi.com Thu Jun 9 19:00:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jun 2005 19:00:09 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5A203Xq010329 for ; Thu, 9 Jun 2005 19:00:04 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10602; Fri, 10 Jun 2005 11:58:50 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5A1wokt1997617; Fri, 10 Jun 2005 11:58:51 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j5A1qiAP001365; Fri, 10 Jun 2005 11:52:45 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j5A1qfqe001363; Fri, 10 Jun 2005 11:52:41 +1000 Date: Fri, 10 Jun 2005 11:52:41 +1000 From: Nathan Scott To: Marek Materzok Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: XFS oops, kernel 2.4.30 w/grsecurity Message-ID: <20050610015241.GF791@frodo> References: <1118062022.6266.19.camel@lucifer.czad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1118062022.6266.19.camel@lucifer.czad.org> User-Agent: Mutt/1.5.3i X-archive-position: 5439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 998 Lines: 21 On Mon, Jun 06, 2005 at 02:47:02PM +0200, Marek Materzok wrote: > Jun 6 11:40:08 lucifer kernel: Filesystem "ide0(3,6)": XFS internal error xfs_btree_check_lblock at line 222 of file xfs_btree.c. Caller 0xc01ed58d > Jun 6 11:40:08 lucifer kernel: c9871750 c01efc41 c0374857 00000001 d71ffc00 c037484b 000000de c01ed58d > Jun 6 11:40:08 lucifer kernel: c8bd4f80 d76b2940 00ca1740 00000000 00000008 00000000 c987178c cf416124 > ... > Then, the /home partition (/dev/hda6) was disabled, and every access to > it ended with EIO. A reboot fixed the problem - the filesystem was > rebuilt and mounted correctly. Nothing like this happened ever to my XFS > filesystems. This isn't an oops, its what XFS does when it detects on-disk metadata corruption - it shuts down the filesystem, reports a kernel stack trace and some other diagnostics, and returns EIO on subsequent accesses to the filesystem until the problem is resolved and the filesystem is mounted once more. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 9 19:08:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jun 2005 19:08:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5A28cXq011080 for ; Thu, 9 Jun 2005 19:08:39 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10870; Fri, 10 Jun 2005 12:07:31 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5A27Wkt1995142; Fri, 10 Jun 2005 12:07:33 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j5A21SAP001403; Fri, 10 Jun 2005 12:01:28 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j5A21RkA001401; Fri, 10 Jun 2005 12:01:27 +1000 Date: Fri, 10 Jun 2005 12:01:27 +1000 From: Nathan Scott To: swilson Cc: linux-xfs@oss.sgi.com Subject: Re: xfs on redhat enterprise WS 3.0 Message-ID: <20050610020127.GG791@frodo> References: <42A880BE.6090902@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42A880BE.6090902@sgi.com> User-Agent: Mutt/1.5.3i X-archive-position: 5440 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 563 Lines: 19 On Thu, Jun 09, 2005 at 01:47:42PM -0400, swilson wrote: > Hi, > > Im trying to prepare a cxfs client thats required to run the above O.S. > It however has 7.2 installed on another disk with data disks using xfs. > > Im trying to access these data disks for the cxfs proof of concept. > I found what I believe are the app rpms but no kernel rpms for 3.0 > > Could you put me in the right direction. You'll need to contact your local SGI support people (ie. the people you bought CXFS from). This is the open source XFS discussion list. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 9 19:12:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jun 2005 19:12:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5A2CRXq011700 for ; Thu, 9 Jun 2005 19:12:28 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10928; Fri, 10 Jun 2005 12:11:18 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5A2BJkt1994770; Fri, 10 Jun 2005 12:11:19 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j5A25EAP001421; Fri, 10 Jun 2005 12:05:14 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j5A25CxS001419; Fri, 10 Jun 2005 12:05:12 +1000 Date: Fri, 10 Jun 2005 12:05:12 +1000 From: Nathan Scott To: Alvaro R Cc: linux-xfs@oss.sgi.com Subject: Re: Strange swap growth/exhaustion Message-ID: <20050610020512.GH791@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 5441 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 963 Lines: 26 On Thu, Jun 09, 2005 at 04:21:38PM -0300, Alvaro R wrote: > Hello, I am running SuSE 9.0 Enterprise, latest kernel > 2.6.5-7.147-smp, on a IBM Blade server. It has 2 Xeon processors, 2,5 > gigs of RAM, and it is attached to a FastT store. > ... > Anyway, I have a 1gig swap partition, and it got filled up quickly, > while I only run plain Apache2 (worker) to serve the images (no PHP or > other dynamic content). and there's nothing that seem to be using this > swap area, but it is 100% anyway, I after while created a swapfile, > also 1gig, and it also became 100% full, usage growth rate is about > 400 megs/hour. > > RAM is ok, see below: > > any ideias ? Just started happening with XFS... Hmm, well XFS isn't using swap of course - sounds more like a runaway userspace process allocating memory without bound - you might be able to diagnose this further using top(1) and watching for processes that are consuming alot of memory... cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Jun 10 05:40:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jun 2005 05:40:45 -0700 (PDT) Received: from stine.vestdata.no ([217.149.127.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5ACedXq028862 for ; Fri, 10 Jun 2005 05:40:40 -0700 Received: from stine.vestdata.no (stine.vestdata.no [127.0.0.1]) by stine.vestdata.no (8.12.10/8.12.10) with ESMTP id j5ACdSPw030796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jun 2005 14:39:28 +0200 Received: (from ragnark@localhost) by stine.vestdata.no (8.12.10/8.12.10/Submit) id j5ACdSIx030794; Fri, 10 Jun 2005 14:39:28 +0200 Date: Fri, 10 Jun 2005 14:39:28 +0200 From: Ragnar =?iso-8859-15?Q?Kj=F8rstad?= To: Steve Lord , linux-xfs@oss.sgi.com Subject: CXFS questions Message-ID: <20050610123928.GB12293@vestdata.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.1i X-Zet.no-MailScanner-Information: Please contact the ISP for more information X-Zet.no-MailScanner: Found to be clean X-MailScanner-From: ragnark@stine.vestdata.no X-archive-position: 5442 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@ragnark.vestdata.no Precedence: bulk X-list: linux-xfs Content-Length: 831 Lines: 31 Is there a seperate list for CXFS, or is this the right place to ask questions? Anyway: * What is the current scalability for CXFS. The whitepaper says it scales up to 48 nodes now and this will be extended to 64 nodes by the end of 2003. I guess the whitepaper is a little bit outdated? * Does performance scale linearly up to that many nodes, or does it just mean that you will be able to configure CXFS with that many nodes? * What distributions does CXFS support on linux x86_64 and linux ia64 (Altix)? * Are there any compability problems with running x86_64 and ia64 for the same filesystem? * Do the metadataserver still need to run on IRIX or Linux Altix? * Where do I find pricing information for CXFS? -- Ragnar Kjørstad Software Engineer Scali - http://www.scali.com Scaling the Linux Datacenter From owner-linux-xfs@oss.sgi.com Fri Jun 10 07:49:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jun 2005 07:49:24 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5AEnMXq005461 for ; Fri, 10 Jun 2005 07:49:22 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5AGaFl8011921 for ; Fri, 10 Jun 2005 09:36:15 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5AElC0F16695634; Fri, 10 Jun 2005 09:47:12 -0500 (CDT) Message-ID: <42A9A7F0.4000201@sgi.com> Date: Fri, 10 Jun 2005 09:47:12 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?Ragnar_Kj=F8rstad?= CC: linux-xfs@oss.sgi.com Subject: Re: CXFS questions References: <20050610123928.GB12293@vestdata.no> In-Reply-To: <20050610123928.GB12293@vestdata.no> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 5443 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 305 Lines: 10 Ragnar Kjørstad wrote: > Is there a seperate list for CXFS, or is this the right place to ask > questions? Because cxfs is not an open source project, there is not a public list for it as there is for xfs. I'll send a couple quick semi-official answers off-list, since cxfs is off-topic here. -Eric From owner-linux-xfs@oss.sgi.com Fri Jun 10 08:21:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jun 2005 08:21:44 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5AFLcXq015677 for ; Fri, 10 Jun 2005 08:21:38 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5AH8Ysf022874 for ; Fri, 10 Jun 2005 10:08:34 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5AFKTR09926308; Fri, 10 Jun 2005 10:20:30 -0500 (CDT) Message-ID: <42A9AFBD.809@sgi.com> Date: Fri, 10 Jun 2005 10:20:29 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: swilson CC: linux-xfs@oss.sgi.com Subject: Re: xfs on redhat enterprise WS 3.0 References: <42A880BE.6090902@sgi.com> In-Reply-To: <42A880BE.6090902@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5444 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 556 Lines: 22 swilson wrote: > Hi, > > Im trying to prepare a cxfs client thats required to run the above O.S. > It however has 7.2 installed on another disk with data disks using xfs. > > Im trying to access these data disks for the cxfs proof of concept. > I found what I believe are the app rpms but no kernel rpms for 3.0 > > Could you put me in the right direction. > > Thanks, > > Scott Hm, this must be "cxfs on linux-xfs day!" Scott, this sort of question would be better for an internal list. Send me more info off-list & I'll give you a hand. -Eric From owner-linux-xfs@oss.sgi.com Fri Jun 10 08:25:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jun 2005 08:25:53 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5AFPoXq016155 for ; Fri, 10 Jun 2005 08:25:50 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5AHCkTX024368 for ; Fri, 10 Jun 2005 10:12:46 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5AFOh0F16695382; Fri, 10 Jun 2005 10:24:43 -0500 (CDT) Message-ID: <42A9B0BA.6060402@sgi.com> Date: Fri, 10 Jun 2005 10:24:42 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alvaro R CC: linux-xfs@oss.sgi.com Subject: Re: Strange swap growth/exhaustion References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5445 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 496 Lines: 14 Alvaro R wrote: > Anyway, I have a 1gig swap partition, and it got filled up quickly, > while I only run plain Apache2 (worker) to serve the images (no PHP or > other dynamic content). and there's nothing that seem to be using this > swap area, but it is 100% anyway, I after while created a swapfile, > also 1gig, and it also became 100% full, usage growth rate is about > 400 megs/hour. I doubt that it is xfs filling your swap; perhaps top can show you who's using a lot of memory? -Eric From owner-linux-xfs@oss.sgi.com Fri Jun 10 09:16:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jun 2005 09:16:45 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5AGGeXq018986 for ; Fri, 10 Jun 2005 09:16:40 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5AI3aHU007560 for ; Fri, 10 Jun 2005 11:03:36 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5AGEWR09926020; Fri, 10 Jun 2005 11:14:32 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Dgm9P-0006Qo-00; Fri, 10 Jun 2005 11:14:31 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 907752 - fix endianess cleanup fallout in xfstests Message-Id: From: Christoph Hellwig Date: Fri, 10 Jun 2005 11:14:31 -0500 X-archive-position: 5446 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 393 Lines: 13 Date: Fri Jun 10 09:14:17 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-cmds Inspected by: hch The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:194030a xfstests/src/loggen.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/loggen.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h From owner-linux-xfs@oss.sgi.com Fri Jun 10 21:58:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jun 2005 21:58:22 -0700 (PDT) Received: from hotmail.com (bay106-f1.bay106.hotmail.com [65.54.161.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5B4wJXq011240 for ; Fri, 10 Jun 2005 21:58:19 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 10 Jun 2005 21:57:11 -0700 Message-ID: Received: from 65.54.161.203 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 11 Jun 2005 04:57:11 GMT X-Originating-IP: [65.54.161.203] X-Originating-Email: [s_wendy_cheng@hotmail.com] X-Sender: s_wendy_cheng@hotmail.com In-Reply-To: From: "Wendy Cheng" To: askxfs@gmail.com, linux-xfs@oss.sgi.com Subject: RE: Strange swap growth/exhaustion Date: Sat, 11 Jun 2005 04:57:11 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 11 Jun 2005 04:57:11.0765 (UTC) FILETIME=[0733A850:01C56E42] X-archive-position: 5447 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: s_wendy_cheng@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 995 Lines: 37 I personally don't know SuSE distribution at all. However, look at your "HighFree", the high memory is really tight. Assuming you have /proc/slabinfo file ? Cat it out to see what's going on with cache memory. Try to play around with the tunables in /proc/sys/vm to see whether they could help. -- Wendy alvaro@blade01:~> cat /proc/meminfo MemTotal: 2594792 kB MemFree: 73116 kB Buffers: 40520 kB Cached: 2347360 kB SwapCached: 220 kB Active: 1031532 kB Inactive: 1384416 kB HighTotal: 1703860 kB HighFree: 3712 kB LowTotal: 890932 kB LowFree: 69404 kB SwapTotal: 2097120 kB SwapFree: 0 kB Dirty: 1776 kB Writeback: 0 kB Mapped: 32948 kB Slab: 79368 kB Committed_AS: 2851264 kB PageTables: 672 kB VmallocTotal: 114680 kB VmallocUsed: 21712 kB VmallocChunk: 76392 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 4096 kB From owner-linux-xfs@oss.sgi.com Sat Jun 11 09:25:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Jun 2005 09:25:45 -0700 (PDT) Received: from web51002.mail.yahoo.com (web51002.mail.yahoo.com [206.190.38.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5BGPdXq016646 for ; Sat, 11 Jun 2005 09:25:40 -0700 Received: (qmail 15817 invoked by uid 60001); 11 Jun 2005 16:24:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3LUQJBx+IxtjhDJEMBN0TKf3RQq0yLtMyxwtvIxnLreXU2QQRha3PacXw5dyEn2SG24+woWFj+EFq4wbd7agOLa7qPrqcsLy1narIq3z7sw5qG0DzhRIcQc03bMArEtLJH9WI1Qc5ABtcy1l1EWT6YeJkdBAG6c69vB3rO8sAJc= ; Message-ID: <20050611162431.15815.qmail@web51002.mail.yahoo.com> Received: from [216.143.252.225] by web51002.mail.yahoo.com via HTTP; Sat, 11 Jun 2005 09:24:31 PDT Date: Sat, 11 Jun 2005 09:24:31 -0700 (PDT) From: Kipp Aldrich Subject: directIO via mmap'ed frame buffers broken in 2.4.31? To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 5448 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hdkippa@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 342 Lines: 14 I am doing XFS direct IO on PCI mmap'ed frame buffers. I recently updated to 2.4.31 and lost directIO on the mmap'ed frame buffers. I regressed my kernel to 2.4.29, and all works fine. Are there any changes regarding direct IO of mmap'ed frame buffers to be aware of? Kipp A. Aldrich hdkippa@yahoo.com -- Kipp Aldrich hdkippa@yahoo.com From owner-linux-xfs@oss.sgi.com Sat Jun 11 11:15:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Jun 2005 11:15:16 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5BIFBXq020535 for ; Sat, 11 Jun 2005 11:15:11 -0700 Received: by wproxy.gmail.com with SMTP id 68so679003wri for ; Sat, 11 Jun 2005 11:14:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=HvRDCmiemqbhdwqxQceuJeEVjW3Z1h7qgRX9pR5xh5KuTxWUKT6kKE0/Cq3bN+to/hilTjLA8sdMBxu13Rx5kF19UXHjLTwWWOH7kqG7pZ+CwSR+Vps7bDMugEOjX/vBKTUbIzykdUZsJ4mwWJ6hBUEM3f6NVU6ZYP3OP3hoJZs= Received: by 10.54.144.9 with SMTP id r9mr1592999wrd; Sat, 11 Jun 2005 11:14:03 -0700 (PDT) Received: by 10.54.15.56 with HTTP; Sat, 11 Jun 2005 11:14:03 -0700 (PDT) Message-ID: Date: Sat, 11 Jun 2005 15:14:03 -0300 From: Alvaro R Reply-To: Alvaro R To: linux-xfs@oss.sgi.com Subject: Re: Strange swap growth/exhaustion In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4111_33055601.1118513643159" References: X-archive-position: 5449 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: askxfs@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 36734 Lines: 641 ------=_Part_4111_33055601.1118513643159 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, thanks for all your responses. Well, I was unable to find any process eating memory, my only suspect was CA's Brightstore Agent, which was killed, but no memory was regained. Since I have only plain Apache2 running (straight from SuSE rpms, and that runs on all other blades with no problems), and the only thing different on this server is XFS, I was worried that this was a filesystem issue. Attached is cat /proc/slabinfo, and meminfo, along with ps output. I will upgrade the kernel to SuSE's release 151 today, maybe the beast just needs rebooting. Any hints are welcome, thanks. PS - Another hint. I do have NFS running, forgot about that one.. =C1lvaro On 6/11/05, Wendy Cheng wrote: >=20 > I personally don't know SuSE distribution at all. However, look at your > "HighFree", the high memory is really tight. Assuming you have > /proc/slabinfo file ? Cat it out to see what's going on with cache memory. > Try to play around with the tunables in /proc/sys/vm to see whether they > could help. >=20 > -- Wendy >=20 > alvaro@blade01:~> cat /proc/meminfo > MemTotal: 2594792 kB > MemFree: 73116 kB > Buffers: 40520 kB > Cached: 2347360 kB > SwapCached: 220 kB > Active: 1031532 kB > Inactive: 1384416 kB > HighTotal: 1703860 kB > HighFree: 3712 kB > LowTotal: 890932 kB > LowFree: 69404 kB > SwapTotal: 2097120 kB > SwapFree: 0 kB > Dirty: 1776 kB > Writeback: 0 kB > Mapped: 32948 kB > Slab: 79368 kB > Committed_AS: 2851264 kB > PageTables: 672 kB > VmallocTotal: 114680 kB > VmallocUsed: 21712 kB > VmallocChunk: 76392 kB > HugePages_Total: 0 > HugePages_Free: 0 > Hugepagesize: 4096 kB >=20 >=20 > ------=_Part_4111_33055601.1118513643159 Content-Type: text/plain; name="info.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="info.txt" DQpNZW1Ub3RhbDogICAgICAyNTk0NzkyIGtCDQpNZW1GcmVlOiAgICAgICAg IDY0NzU2IGtCDQpCdWZmZXJzOiAgICAgICAgIDM0MjcyIGtCDQpDYWNoZWQ6 ICAgICAgICAyMzY3MDg4IGtCDQpTd2FwQ2FjaGVkOiAgICAgICAgICAwIGtC DQpBY3RpdmU6ICAgICAgICAgNzYwNzI0IGtCDQpJbmFjdGl2ZTogICAgICAx NjcwMDcyIGtCDQpIaWdoVG90YWw6ICAgICAxNzAzODYwIGtCDQpIaWdoRnJl ZTogICAgICAgIDE0NjU2IGtCDQpMb3dUb3RhbDogICAgICAgODkwOTMyIGtC DQpMb3dGcmVlOiAgICAgICAgIDUwMTAwIGtCDQpTd2FwVG90YWw6ICAgICAy MDk3MTIwIGtCDQpTd2FwRnJlZTogICAgICAgICAgICAwIGtCDQpEaXJ0eTog ICAgICAgICAgICAgNDI4IGtCDQpXcml0ZWJhY2s6ICAgICAgICAgICAwIGtC DQpNYXBwZWQ6ICAgICAgICAgMTY2OTg0IGtCDQpTbGFiOiAgICAgICAgICAg IDcyMTAwIGtCDQpDb21taXR0ZWRfQVM6ICAyOTkzMjQ4IGtCDQpQYWdlVGFi bGVzOiAgICAgICAgOTg0IGtCDQpWbWFsbG9jVG90YWw6ICAgMTE0NjgwIGtC DQpWbWFsbG9jVXNlZDogICAgIDIxNzEyIGtCDQpWbWFsbG9jQ2h1bms6ICAg IDc2MzkyIGtCDQpIdWdlUGFnZXNfVG90YWw6ICAgICAwDQpIdWdlUGFnZXNf RnJlZTogICAgICAwDQpIdWdlcGFnZXNpemU6ICAgICA0MDk2IGtCDQoNCg0K DQpzbGFiaW5mbyAtIHZlcnNpb246IDIuMA0KIyBuYW1lICAgICAgICAgICAg PGFjdGl2ZV9vYmpzPiA8bnVtX29ianM+IDxvYmpzaXplPiA8b2JqcGVyc2xh Yj4gPHBhZ2VzcGVyc2xhYj4gOiB0dW5hYmxlcyA8YmF0Y2hjb3VudD4gPGxp bWl0PiA8c2hhcmVkZmFjdG9yPiA6IHNsYWJkYXRhIDxhY3RpdmVfc2xhYnM+ IDxudW1fc2xhYnM+IDxzaGFyZWRhdmFpbD4NCnhmc19hY2wgICAgICAgICAg ICAgICAgMCAgICAgIDAgICAgMzA0ICAgMTMgICAgMSA6IHR1bmFibGVzICAg NTQgICAyNyAgICA4IDogc2xhYmRhdGEgICAgICAwICAgICAgMCAgICAgIDAN Cnhmc19jaGFzaGxpc3QgICAgICAgIDk3MSAgIDMzMjAgICAgIDIwICAxNjYg ICAgMSA6IHR1bmFibGVzICAxMjAgICA2MCAgICA4IDogc2xhYmRhdGEgICAg IDIwICAgICAyMCAgICAgIDANCnhmc19pbGkgICAgICAgICAgICAgMTEyMiAg IDM4NjEgICAgMTQwICAgMjcgICAgMSA6IHR1bmFibGVzICAxMjAgICA2MCAg ICA4IDogc2xhYmRhdGEgICAgMTQzICAgIDE0MyAgICAgIDANCnhmc19pZm9y ayAgICAgICAgICAgICAgMCAgICAgIDAgICAgIDU2ICAgNjYgICAgMSA6IHR1 bmFibGVzICAxMjAgICA2MCAgICA4IDogc2xhYmRhdGEgICAgICAwICAgICAg MCAgICAgIDANCnhmc19lZmlfaXRlbSAgICAgICAgICAgMCAgICAgIDAgICAg MjYwICAgMTUgICAgMSA6IHR1bmFibGVzICAgNTQgICAyNyAgICA4IDogc2xh YmRhdGEgICAgICAwICAgICAgMCAgICAgIDANCnhmc19lZmRfaXRlbSAgICAg ICAgICAgMCAgICAgIDAgICAgMjYwICAgMTUgICAgMSA6IHR1bmFibGVzICAg NTQgICAyNyAgICA4IDogc2xhYmRhdGEgICAgICAwICAgICAgMCAgICAgIDAN Cnhmc19idWZfaXRlbSAgICAgICAgICAgMCAgICAgIDAgICAgMTQ4ICAgMjYg ICAgMSA6IHR1bmFibGVzICAxMjAgICA2MCAgICA4IDogc2xhYmRhdGEgICAg ICAwICAgICAgMCAgICAgIDANCnhmc19kYWJ1ZiAgICAgICAgICAgICAgMCAg ICAgIDAgICAgIDE2ICAyMDAgICAgMSA6IHR1bmFibGVzICAxMjAgICA2MCAg ICA4IDogc2xhYmRhdGEgICAgICAwICAgICAgMCAgICAgIDANCnhmc19kYV9z dGF0ZSAgICAgICAgICAgMCAgICAgIDAgICAgMzM2ICAgMTEgICAgMSA6IHR1 bmFibGVzICAgNTQgICAyNyAgICA4IDogc2xhYmRhdGEgICAgICAwICAgICAg MCAgICAgIDANCnhmc190cmFucyAgICAgICAgICAgICAgMiAgICAgMTMgICAg NTk2ICAgMTMgICAgMiA6IHR1bmFibGVzICAgNTQgICAyNyAgICA4IDogc2xh YmRhdGEgICAgICAxICAgICAgMSAgICAgIDANCnhmc19pbm9kZSAgICAgICAg ICAgODAyMiAgIDgwNTAgICAgMzY4ICAgMTAgICAgMSA6IHR1bmFibGVzICAg NTQgICAyNyAgICA4IDogc2xhYmRhdGEgICAgODA1ICAgIDgwNSAgICAgIDAN Cnhmc19idHJlZV9jdXIgICAgICAgICAgMCAgICAgIDAgICAgMTQwICAgMjcg ICAgMSA6IHR1bmFibGVzICAxMjAgICA2MCAgICA4IDogc2xhYmRhdGEgICAg ICAwICAgICAgMCAgICAgIDANCnhmc19ibWFwX2ZyZWVfaXRlbSAgICAgIDAg ICAgICAwICAgICAxNiAgMjAwICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAg ICAgOCA6IHNsYWJkYXRhICAgICAgMCAgICAgIDAgICAgICAwDQp4ZnNfYnVm X3QgICAgICAgICAgICAgMTAgICAgIDMwICAgIDI1NiAgIDE1ICAgIDEgOiB0 dW5hYmxlcyAgMTIwICAgNjAgICAgOCA6IHNsYWJkYXRhICAgICAgMiAgICAg IDIgICAgICAwDQpsaW52ZnNfaWNhY2hlICAgICAgIDgwMjIgICA4MDYwICAg IDM4OCAgIDEwICAgIDEgOiB0dW5hYmxlcyAgIDU0ICAgMjcgICAgOCA6IHNs YWJkYXRhICAgIDgwNiAgICA4MDYgICAgICAwDQpkbV9zZXNzaW9uICAgICAg ICAgICAgIDAgICAgICAwICAgIDM0NCAgIDExICAgIDEgOiB0dW5hYmxlcyAg IDU0ICAgMjcgICAgOCA6IHNsYWJkYXRhICAgICAgMCAgICAgIDAgICAgICAw DQpkbV9mc3JlZyAgICAgICAgICAgICAgIDAgICAgICAwICAgIDE4OCAgIDIx ICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAgICAgOCA6IHNsYWJkYXRhICAg ICAgMCAgICAgIDAgICAgICAwDQpkbV90b2tkYXRhICAgICAgICAgICAgIDAg ICAgICAwICAgICA1NiAgIDY2ICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAg ICAgOCA6IHNsYWJkYXRhICAgICAgMCAgICAgIDAgICAgICAwDQp1ZGZfaW5v ZGVfY2FjaGUgICAgICAgIDAgICAgICAwICAgIDUxMiAgICA3ICAgIDEgOiB0 dW5hYmxlcyAgIDU0ICAgMjcgICAgOCA6IHNsYWJkYXRhICAgICAgMCAgICAg IDAgICAgICAwDQpmaWI2X25vZGVzICAgICAgICAgICAgIDggICAgMTEyICAg ICAzMiAgMTEyICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAgICAgOCA6IHNs YWJkYXRhICAgICAgMSAgICAgIDEgICAgICAwDQppcDZfZHN0X2NhY2hlICAg ICAgICAgIDkgICAgIDMwICAgIDI1NiAgIDE1ICAgIDEgOiB0dW5hYmxlcyAg MTIwICAgNjAgICAgOCA6IHNsYWJkYXRhICAgICAgMiAgICAgIDIgICAgICAw DQpuZGlzY19jYWNoZSAgICAgICAgICAgIDEgICAgIDE1ICAgIDI1NiAgIDE1 ICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAgICAgOCA6IHNsYWJkYXRhICAg ICAgMSAgICAgIDEgICAgICAwDQpyYXc2X3NvY2sgICAgICAgICAgICAgIDAg ICAgICAwICAgIDc2OCAgICA1ICAgIDEgOiB0dW5hYmxlcyAgIDU0ICAgMjcg ICAgOCA6IHNsYWJkYXRhICAgICAgMCAgICAgIDAgICAgICAwDQp1ZHA2X3Nv Y2sgICAgICAgICAgICAgIDAgICAgICAwICAgIDY0MCAgICA2ICAgIDEgOiB0 dW5hYmxlcyAgIDU0ICAgMjcgICAgOCA6IHNsYWJkYXRhICAgICAgMCAgICAg IDAgICAgICAwDQp0Y3A2X3NvY2sgICAgICAgICAgICAgIDkgICAgIDI4ICAg MTE1MiAgICA3ICAgIDIgOiB0dW5hYmxlcyAgIDI0ICAgMTIgICAgOCA6IHNs YWJkYXRhICAgICAgNCAgICAgIDQgICAgICAwDQppcF9maWJfaGFzaCAgICAg ICAgICAgMTcgICAgMjAwICAgICAxNiAgMjAwICAgIDEgOiB0dW5hYmxlcyAg MTIwICAgNjAgICAgOCA6IHNsYWJkYXRhICAgICAgMSAgICAgIDEgICAgICAw DQpkbV90aW8gICAgICAgICAgICAgICAgIDAgICAgICAwICAgICAxNiAgMjAw ICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAgICAgOCA6IHNsYWJkYXRhICAg ICAgMCAgICAgIDAgICAgICAwDQpkbV9pbyAgICAgICAgICAgICAgICAgIDAg ICAgICAwICAgICAxNiAgMjAwICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAg ICAgOCA6IHNsYWJkYXRhICAgICAgMCAgICAgIDAgICAgICAwDQpyZWlzZXJf aW5vZGVfY2FjaGUgICAgNjY0ICAgIDkzOCAgICA1MTIgICAgNyAgICAxIDog dHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgICAxMzQgICAg MTM0ICAgICAgMA0Kc2NzaV9jbWRfY2FjaGUgICAgICAgIDIwICAgICAyMCAg ICAzODQgICAxMCAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBz bGFiZGF0YSAgICAgIDIgICAgICAyICAgICAgMA0KcWxhMnh4eF9zcmJzICAg ICAgICAgMzAwICAgIDMwMCAgICAxMjggICAzMCAgICAxIDogdHVuYWJsZXMg IDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgMTAgICAgIDEwICAgICAg MA0Kc2dwb29sLTEyOCAgICAgICAgICAgIDMyICAgICAzMiAgIDIwNDggICAg MiAgICAxIDogdHVuYWJsZXMgICAyNCAgIDEyICAgIDggOiBzbGFiZGF0YSAg ICAgMTYgICAgIDE2ICAgICAgMA0Kc2dwb29sLTY0ICAgICAgICAgICAgIDMy ICAgICAzMiAgIDEwMjQgICAgNCAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3 ICAgIDggOiBzbGFiZGF0YSAgICAgIDggICAgICA4ICAgICAgMA0Kc2dwb29s LTMyICAgICAgICAgICAgIDQwICAgICA0MCAgICA1MTIgICAgOCAgICAxIDog dHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgICAgIDUgICAg ICA1ICAgICAgMA0Kc2dwb29sLTE2ICAgICAgICAgICAgIDMyICAgICA0NSAg ICAyNTYgICAxNSAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBz bGFiZGF0YSAgICAgIDMgICAgICAzICAgICAgMA0Kc2dwb29sLTggICAgICAg ICAgICAgIDkwICAgICA5MCAgICAxMjggICAzMCAgICAxIDogdHVuYWJsZXMg IDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgIDMgICAgICAzICAgICAg MA0KY2xpcF9hcnBfY2FjaGUgICAgICAgICAwICAgICAgMCAgICAyNTYgICAx NSAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAg ICAgIDAgICAgICAwICAgICAgMA0KcnBjX2J1ZmZlcnMgICAgICAgICAgICA4 ICAgICAgOCAgIDIwNDggICAgMiAgICAxIDogdHVuYWJsZXMgICAyNCAgIDEy ICAgIDggOiBzbGFiZGF0YSAgICAgIDQgICAgICA0ICAgICAgMA0KcnBjX3Rh c2tzICAgICAgICAgICAgICA4ICAgICAxNSAgICAyNTYgICAxNSAgICAxIDog dHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgIDEgICAg ICAxICAgICAgMA0KcnBjX2lub2RlX2NhY2hlICAgICAgICA4ICAgICAxNCAg ICA1MTIgICAgNyAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBz bGFiZGF0YSAgICAgIDIgICAgICAyICAgICAgMA0KdW5peF9zb2NrICAgICAg ICAgICAgIDk0ICAgIDEzMyAgICA1MTIgICAgNyAgICAxIDogdHVuYWJsZXMg ICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgICAgMTkgICAgIDE5ICAgICAg MA0KaXBfbXJ0X2NhY2hlICAgICAgICAgICAwICAgICAgMCAgICAxMjggICAz MCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAg ICAgIDAgICAgICAwICAgICAgMA0KdGNwX3R3X2J1Y2tldCAgICAgICAgICAw ICAgICAgMCAgICAxMjggICAzMCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYw ICAgIDggOiBzbGFiZGF0YSAgICAgIDAgICAgICAwICAgICAgMA0KdGNwX2Jp bmRfYnVja2V0ICAgICAgICA5ICAgIDIwMCAgICAgMTYgIDIwMCAgICAxIDog dHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgIDEgICAg ICAxICAgICAgMA0KdGNwX29wZW5fcmVxdWVzdCAgICAgICAwICAgICAgMCAg ICAxMjggICAzMCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBz bGFiZGF0YSAgICAgIDAgICAgICAwICAgICAgMA0KaW5ldF9wZWVyX2NhY2hl ICAgICAgICAyICAgICA1OCAgICAgNjQgICA1OCAgICAxIDogdHVuYWJsZXMg IDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgIDEgICAgICAxICAgICAg MA0Kc2VjcGF0aF9jYWNoZSAgICAgICAgICAwICAgICAgMCAgICAxMjggICAz MCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAg ICAgIDAgICAgICAwICAgICAgMA0KeGZybV9kc3RfY2FjaGUgICAgICAgICAw ICAgICAgMCAgICAzODQgICAxMCAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3 ICAgIDggOiBzbGFiZGF0YSAgICAgIDAgICAgICAwICAgICAgMA0KaXBfZHN0 X2NhY2hlICAgICAgICAgIDM4ICAgICA2MCAgICAzODQgICAxMCAgICAxIDog dHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgICAgIDYgICAg ICA2ICAgICAgMA0KYXJwX2NhY2hlICAgICAgICAgICAgIDExICAgICAzMCAg ICAyNTYgICAxNSAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBz bGFiZGF0YSAgICAgIDIgICAgICAyICAgICAgMA0KcmF3NF9zb2NrICAgICAg ICAgICAgICAwICAgICAgMCAgICA1MTIgICAgNyAgICAxIDogdHVuYWJsZXMg ICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgICAgIDAgICAgICAwICAgICAg MA0KdWRwX3NvY2sgICAgICAgICAgICAgICA3ICAgICAyOCAgICA1MTIgICAg NyAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAg ICAgIDQgICAgICA0ICAgICAgMA0KdGNwX3NvY2sgICAgICAgICAgICAgIDIy ICAgICAzMiAgIDEwMjQgICAgNCAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3 ICAgIDggOiBzbGFiZGF0YSAgICAgIDggICAgICA4ICAgICAgMA0KZmxvd19j YWNoZSAgICAgICAgICAgICAwICAgICAgMCAgICAxMjggICAzMCAgICAxIDog dHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgIDAgICAg ICAwICAgICAgMA0KbXF1ZXVlX2lub2RlX2NhY2hlICAgICAgMSAgICAgIDYg ICAgNjQwICAgIDYgICAgMSA6IHR1bmFibGVzICAgNTQgICAyNyAgICA4IDog c2xhYmRhdGEgICAgICAxICAgICAgMSAgICAgIDANCm5mc193cml0ZV9kYXRh ICAgICAgICAzNiAgICAgNDIgICAgNTEyICAgIDcgICAgMSA6IHR1bmFibGVz ICAgNTQgICAyNyAgICA4IDogc2xhYmRhdGEgICAgICA2ICAgICAgNiAgICAg IDANCm5mc19yZWFkX2RhdGEgICAgICAgICAzMiAgICAgMzUgICAgNTEyICAg IDcgICAgMSA6IHR1bmFibGVzICAgNTQgICAyNyAgICA4IDogc2xhYmRhdGEg ICAgICA1ICAgICAgNSAgICAgIDANCm5mc19pbm9kZV9jYWNoZSAgICAgICAg NiAgICAgMTIgICAgNjQwICAgIDYgICAgMSA6IHR1bmFibGVzICAgNTQgICAy NyAgICA4IDogc2xhYmRhdGEgICAgICAyICAgICAgMiAgICAgIDANCm5mc19w YWdlICAgICAgICAgICAgICAgMCAgICAgIDAgICAgMTI4ICAgMzAgICAgMSA6 IHR1bmFibGVzICAxMjAgICA2MCAgICA4IDogc2xhYmRhdGEgICAgICAwICAg ICAgMCAgICAgIDANCmlzb2ZzX2lub2RlX2NhY2hlICAgICAgMCAgICAgIDAg ICAgMzg0ICAgMTAgICAgMSA6IHR1bmFibGVzICAgNTQgICAyNyAgICA4IDog c2xhYmRhdGEgICAgICAwICAgICAgMCAgICAgIDANCm1pbml4X2lub2RlX2Nh Y2hlICAgICAgMCAgICAgIDAgICAgNTEyICAgIDcgICAgMSA6IHR1bmFibGVz ICAgNTQgICAyNyAgICA4IDogc2xhYmRhdGEgICAgICAwICAgICAgMCAgICAg IDANCmh1Z2V0bGJmc19pbm9kZV9jYWNoZSAgICAgIDEgICAgIDEwICAgIDM4 NCAgIDEwICAgIDEgOiB0dW5hYmxlcyAgIDU0ICAgMjcgICAgOCA6IHNsYWJk YXRhICAgICAgMSAgICAgIDEgICAgICAwDQpleHQyX2lub2RlX2NhY2hlICAg ICAgIDAgICAgICAwICAgIDUxMiAgICA3ICAgIDEgOiB0dW5hYmxlcyAgIDU0 ICAgMjcgICAgOCA6IHNsYWJkYXRhICAgICAgMCAgICAgIDAgICAgICAwDQpl eHQyX3hhdHRyICAgICAgICAgICAgIDAgICAgICAwICAgICA0OCAgIDc3ICAg IDEgOiB0dW5hYmxlcyAgMTIwICAgNjAgICAgOCA6IHNsYWJkYXRhICAgICAg MCAgICAgIDAgICAgICAwDQpkcXVvdCAgICAgICAgICAgICAgICAgIDAgICAg ICAwICAgIDEyOCAgIDMwICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAgICAg OCA6IHNsYWJkYXRhICAgICAgMCAgICAgIDAgICAgICAwDQpldmVudHBvbGxf cHdxICAgICAgICAgIDAgICAgICAwICAgICAzNiAgIDk5ICAgIDEgOiB0dW5h YmxlcyAgMTIwICAgNjAgICAgOCA6IHNsYWJkYXRhICAgICAgMCAgICAgIDAg ICAgICAwDQpldmVudHBvbGxfZXBpICAgICAgICAgIDAgICAgICAwICAgIDEy OCAgIDMwICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAgICAgOCA6IHNsYWJk YXRhICAgICAgMCAgICAgIDAgICAgICAwDQpraW9jdHggICAgICAgICAgICAg ICAgIDAgICAgICAwICAgIDI1NiAgIDE1ICAgIDEgOiB0dW5hYmxlcyAgMTIw ICAgNjAgICAgOCA6IHNsYWJkYXRhICAgICAgMCAgICAgIDAgICAgICAwDQpr aW9jYiAgICAgICAgICAgICAgICAgIDAgICAgICAwICAgIDI1NiAgIDE1ICAg IDEgOiB0dW5hYmxlcyAgMTIwICAgNjAgICAgOCA6IHNsYWJkYXRhICAgICAg MCAgICAgIDAgICAgICAwDQpkbm90aWZ5X2NhY2hlICAgICAgICAgIDAgICAg ICAwICAgICAyMCAgMTY2ICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAgICAg OCA6IHNsYWJkYXRhICAgICAgMCAgICAgIDAgICAgICAwDQpmaWxlX2xvY2tf Y2FjaGUgICAgICAgMTcgICAgIDgwICAgICA5NiAgIDQwICAgIDEgOiB0dW5h YmxlcyAgMTIwICAgNjAgICAgOCA6IHNsYWJkYXRhICAgICAgMiAgICAgIDIg ICAgICAwDQpmYXN5bmNfY2FjaGUgICAgICAgICAgIDAgICAgICAwICAgICAx NiAgMjAwICAgIDEgOiB0dW5hYmxlcyAgMTIwICAgNjAgICAgOCA6IHNsYWJk YXRhICAgICAgMCAgICAgIDAgICAgICAwDQpzaG1lbV9pbm9kZV9jYWNoZSAg ICAgNTIgICAgIDYzICAgIDUxMiAgICA3ICAgIDEgOiB0dW5hYmxlcyAgIDU0 ICAgMjcgICAgOCA6IHNsYWJkYXRhICAgICAgOSAgICAgIDkgICAgICAwDQpw b3NpeF90aW1lcnNfY2FjaGUgICAgICAwICAgICAgMCAgICAgODggICA0MyAg ICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAg IDAgICAgICAwICAgICAgMA0KdWlkX2NhY2hlICAgICAgICAgICAgICA1ICAg IDExMiAgICAgMzIgIDExMiAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAg IDggOiBzbGFiZGF0YSAgICAgIDEgICAgICAxICAgICAgMA0KY2ZxX3Bvb2wg ICAgICAgICAgICAgMTkwICAgIDU2MCAgICAgMzIgIDExMiAgICAxIDogdHVu YWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgIDUgICAgICA1 ICAgICAgMA0KY3JxX3Bvb2wgICAgICAgICAgICAgMTE1ICAgIDE4MCAgICAg NDAgICA5MCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFi ZGF0YSAgICAgIDIgICAgICAyICAgICAgMA0KZGVhZGxpbmVfZHJxICAgICAg ICAgICAwICAgICAgMCAgICAgNTIgICA3MSAgICAxIDogdHVuYWJsZXMgIDEy MCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgIDAgICAgICAwICAgICAgMA0K YXNfYXJxICAgICAgICAgICAgICAgICAwICAgICAgMCAgICAgNjQgICA1OCAg ICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAg IDAgICAgICAwICAgICAgMA0KYmxrZGV2X3JlcXVlc3RzICAgICAgIDk2ICAg ICA5NiAgICAxNjAgICAyNCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAg IDggOiBzbGFiZGF0YSAgICAgIDQgICAgICA0ICAgICAgMA0KYmlvdmVjLUJJ T19NQVhfUEFHRVMgICAgMjU2ICAgIDI1NiAgIDMwNzIgICAgMiAgICAyIDog dHVuYWJsZXMgICAyNCAgIDEyICAgIDggOiBzbGFiZGF0YSAgICAxMjggICAg MTI4ICAgICAgMA0KYmlvdmVjLTEyOCAgICAgICAgICAgMjU2ICAgIDI2MCAg IDE1MzYgICAgNSAgICAyIDogdHVuYWJsZXMgICAyNCAgIDEyICAgIDggOiBz bGFiZGF0YSAgICAgNTIgICAgIDUyICAgICAgMA0KYmlvdmVjLTY0ICAgICAg ICAgICAgMjU2ICAgIDI2MCAgICA3NjggICAgNSAgICAxIDogdHVuYWJsZXMg ICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgICAgNTIgICAgIDUyICAgICAg MA0KYmlvdmVjLTE2ICAgICAgICAgICAgMjU2ICAgIDI3MCAgICAyNTYgICAx NSAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAg ICAgMTggICAgIDE4ICAgICAgMA0KYmlvdmVjLTQgICAgICAgICAgICAgMjU2 ICAgIDI5MCAgICAgNjQgICA1OCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYw ICAgIDggOiBzbGFiZGF0YSAgICAgIDUgICAgICA1ICAgICAgMA0KYmlvdmVj LTEgICAgICAgICAgICAgMzIzICAgMTQwMCAgICAgMTYgIDIwMCAgICAxIDog dHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgIDcgICAg ICA3ICAgICAgMA0KYmlvICAgICAgICAgICAgICAgICAgMzIzICAgIDgxMiAg ICAgNjQgICA1OCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBz bGFiZGF0YSAgICAgMTQgICAgIDE0ICAgICAgMA0Kc29ja19pbm9kZV9jYWNo ZSAgICAgMTQ0ICAgIDE4OSAgICA1MTIgICAgNyAgICAxIDogdHVuYWJsZXMg ICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgICAgMjcgICAgIDI3ICAgICAg MA0Kc2tidWZmX2hlYWRfY2FjaGUgICAgODc5ICAgMTE0MCAgICAyNTYgICAx NSAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAg ICAgNzYgICAgIDc2ICAgICA2MA0Kc29jayAgICAgICAgICAgICAgICAgICAz ICAgICAyMCAgICAzODQgICAxMCAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3 ICAgIDggOiBzbGFiZGF0YSAgICAgIDIgICAgICAyICAgICAgMA0KcHJvY19p bm9kZV9jYWNoZSAgICAgNDM2ICAgIDQ0MCAgICAzODQgICAxMCAgICAxIDog dHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgICAgNDQgICAg IDQ0ICAgICAgMA0Kc2lncXVldWUgICAgICAgICAgICAgIDEzICAgICAyNiAg ICAxNDggICAyNiAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBz bGFiZGF0YSAgICAgIDEgICAgICAxICAgICAgMA0KcmFkaXhfdHJlZV9ub2Rl ICAgIDI4NTIyICA0MzAwOCAgICAyNzYgICAxNCAgICAxIDogdHVuYWJsZXMg ICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgIDMwNzIgICAzMDcyICAgICAg MA0KYmRldl9jYWNoZSAgICAgICAgICAgIDExICAgICAyMSAgICA1MTIgICAg NyAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAg ICAgIDMgICAgICAzICAgICAgMA0KbW50X2NhY2hlICAgICAgICAgICAgIDI1 ICAgICA1OCAgICAgNjQgICA1OCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYw ICAgIDggOiBzbGFiZGF0YSAgICAgIDEgICAgICAxICAgICAgMA0KaW5vZGVf Y2FjaGUgICAgICAgICAyNzg3ICAgMjk1MCAgICAzODQgICAxMCAgICAxIDog dHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgICAyOTUgICAg Mjk1ICAgICAgMA0KZGVudHJ5X2NhY2hlICAgICAgIDExODI0ICAxMTk2MCAg ICAxNTIgICAyNiAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBz bGFiZGF0YSAgICA0NjAgICAgNDYwICAgICAgMA0KZmlscCAgICAgICAgICAg ICAgICAgNzM3ICAgMTU3NSAgICAyNTYgICAxNSAgICAxIDogdHVuYWJsZXMg IDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAxMDUgICAgMTA1ICAgICAg MA0KbmFtZXNfY2FjaGUgICAgICAgICAgICAzICAgICAgMyAgIDQwOTYgICAg MSAgICAxIDogdHVuYWJsZXMgICAyNCAgIDEyICAgIDggOiBzbGFiZGF0YSAg ICAgIDMgICAgICAzICAgICAgMA0KaWRyX2xheWVyX2NhY2hlICAgICAgIDM0 ICAgICA4NCAgICAxMzYgICAyOCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYw ICAgIDggOiBzbGFiZGF0YSAgICAgIDMgICAgICAzICAgICAgMA0KYnVmZmVy X2hlYWQgICAgICAgMTA5MzExIDU5NTA1MSAgICAgNTIgICA3MSAgICAxIDog dHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgIDgzODEgICA4 MzgxICAgICAgMA0KbW1fc3RydWN0ICAgICAgICAgICAgIDYyICAgIDEwMiAg ICA2NDAgICAgNiAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBz bGFiZGF0YSAgICAgMTcgICAgIDE3ICAgICAgMA0Kdm1fYXJlYV9zdHJ1Y3Qg ICAgICAxODg3ICAgMzY0NSAgICAgODQgICA0NSAgICAxIDogdHVuYWJsZXMg IDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgODEgICAgIDgxICAgICAg MA0KZnNfY2FjaGUgICAgICAgICAgICAgIDc0ICAgIDM0OCAgICAgNjQgICA1 OCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAg ICAgIDYgICAgICA2ICAgICAgMA0KZmlsZXNfY2FjaGUgICAgICAgICAgIDY1 ICAgIDExMiAgICA1MTIgICAgNyAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3 ICAgIDggOiBzbGFiZGF0YSAgICAgMTYgICAgIDE2ICAgICAgMA0Kc2lnbmFs X2NhY2hlICAgICAgICAgMTIzICAgIDMwMCAgICAxMjggICAzMCAgICAxIDog dHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgMTAgICAg IDEwICAgICAgMA0Kc2lnaGFuZF9jYWNoZSAgICAgICAgMTEyICAgIDE3MCAg IDE0MDggICAgNSAgICAyIDogdHVuYWJsZXMgICAyNCAgIDEyICAgIDggOiBz bGFiZGF0YSAgICAgMzQgICAgIDM0ICAgICAgMA0KdGFza19zdHJ1Y3QgICAg ICAgICAgMjA1ICAgIDI2NSAgIDE2MDAgICAgNSAgICAyIDogdHVuYWJsZXMg ICAyNCAgIDEyICAgIDggOiBzbGFiZGF0YSAgICAgNTMgICAgIDUzICAgICAg MA0KYW5vbl92bWEgICAgICAgICAgICAgNTc4ICAgMjAwMCAgICAgMTIgIDI1 MCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAg ICAgIDggICAgICA4ICAgICAgMA0Kc2l6ZS0xMzEwNzIoRE1BKSAgICAgICAw ICAgICAgMCAxMzEwNzIgICAgMSAgIDMyIDogdHVuYWJsZXMgICAgOCAgICA0 ICAgIDAgOiBzbGFiZGF0YSAgICAgIDAgICAgICAwICAgICAgMA0Kc2l6ZS0x MzEwNzIgICAgICAgICAgICAwICAgICAgMCAxMzEwNzIgICAgMSAgIDMyIDog dHVuYWJsZXMgICAgOCAgICA0ICAgIDAgOiBzbGFiZGF0YSAgICAgIDAgICAg ICAwICAgICAgMA0Kc2l6ZS02NTUzNihETUEpICAgICAgICAwICAgICAgMCAg NjU1MzYgICAgMSAgIDE2IDogdHVuYWJsZXMgICAgOCAgICA0ICAgIDAgOiBz bGFiZGF0YSAgICAgIDAgICAgICAwICAgICAgMA0Kc2l6ZS02NTUzNiAgICAg ICAgICAgIDE0ICAgICAxNCAgNjU1MzYgICAgMSAgIDE2IDogdHVuYWJsZXMg ICAgOCAgICA0ICAgIDAgOiBzbGFiZGF0YSAgICAgMTQgICAgIDE0ICAgICAg MA0Kc2l6ZS0zMjc2OChETUEpICAgICAgICAwICAgICAgMCAgMzI3NjggICAg MSAgICA4IDogdHVuYWJsZXMgICAgOCAgICA0ICAgIDAgOiBzbGFiZGF0YSAg ICAgIDAgICAgICAwICAgICAgMA0Kc2l6ZS0zMjc2OCAgICAgICAgICAgIDQ4 ICAgICA0OCAgMzI3NjggICAgMSAgICA4IDogdHVuYWJsZXMgICAgOCAgICA0 ICAgIDAgOiBzbGFiZGF0YSAgICAgNDggICAgIDQ4ICAgICAgMA0Kc2l6ZS0x NjM4NChETUEpICAgICAgICAwICAgICAgMCAgMTYzODQgICAgMSAgICA0IDog dHVuYWJsZXMgICAgOCAgICA0ICAgIDAgOiBzbGFiZGF0YSAgICAgIDAgICAg ICAwICAgICAgMA0Kc2l6ZS0xNjM4NCAgICAgICAgICAgIDI3ICAgICAyNyAg MTYzODQgICAgMSAgICA0IDogdHVuYWJsZXMgICAgOCAgICA0ICAgIDAgOiBz bGFiZGF0YSAgICAgMjcgICAgIDI3ICAgICAgMA0Kc2l6ZS04MTkyKERNQSkg ICAgICAgICAwICAgICAgMCAgIDgxOTIgICAgMSAgICAyIDogdHVuYWJsZXMg ICAgOCAgICA0ICAgIDAgOiBzbGFiZGF0YSAgICAgIDAgICAgICAwICAgICAg MA0Kc2l6ZS04MTkyICAgICAgICAgICAgMjc1ICAgIDI3NSAgIDgxOTIgICAg MSAgICAyIDogdHVuYWJsZXMgICAgOCAgICA0ICAgIDAgOiBzbGFiZGF0YSAg ICAyNzUgICAgMjc1ICAgICAgMA0Kc2l6ZS00MDk2KERNQSkgICAgICAgICAw ICAgICAgMCAgIDQwOTYgICAgMSAgICAxIDogdHVuYWJsZXMgICAyNCAgIDEy ICAgIDggOiBzbGFiZGF0YSAgICAgIDAgICAgICAwICAgICAgMA0Kc2l6ZS00 MDk2ICAgICAgICAgICAgIDgxICAgICA4MSAgIDQwOTYgICAgMSAgICAxIDog dHVuYWJsZXMgICAyNCAgIDEyICAgIDggOiBzbGFiZGF0YSAgICAgODEgICAg IDgxICAgICAgMA0Kc2l6ZS0yMDQ4KERNQSkgICAgICAgICAwICAgICAgMCAg IDIwNDggICAgMiAgICAxIDogdHVuYWJsZXMgICAyNCAgIDEyICAgIDggOiBz bGFiZGF0YSAgICAgIDAgICAgICAwICAgICAgMA0Kc2l6ZS0yMDQ4ICAgICAg ICAgICAgNzk1ICAgIDgxOCAgIDIwNDggICAgMiAgICAxIDogdHVuYWJsZXMg ICAyNCAgIDEyICAgIDggOiBzbGFiZGF0YSAgICA0MDkgICAgNDA5ICAgICAg MA0Kc2l6ZS0xMDI0KERNQSkgICAgICAgICAwICAgICAgMCAgIDEwMjQgICAg NCAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAg ICAgIDAgICAgICAwICAgICAgMA0Kc2l6ZS0xMDI0ICAgICAgICAgICAgMTY0 ICAgIDIwNCAgIDEwMjQgICAgNCAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3 ICAgIDggOiBzbGFiZGF0YSAgICAgNTEgICAgIDUxICAgICAgMA0Kc2l6ZS01 MTIoRE1BKSAgICAgICAgICAwICAgICAgMCAgICA1MTIgICAgOCAgICAxIDog dHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBzbGFiZGF0YSAgICAgIDAgICAg ICAwICAgICAgMA0Kc2l6ZS01MTIgICAgICAgICAgICAgNTc1ICAgIDYwOCAg ICA1MTIgICAgOCAgICAxIDogdHVuYWJsZXMgICA1NCAgIDI3ICAgIDggOiBz bGFiZGF0YSAgICAgNzYgICAgIDc2ICAgICAgMA0Kc2l6ZS0yNTYoRE1BKSAg ICAgICAgICAwICAgICAgMCAgICAyNTYgICAxNSAgICAxIDogdHVuYWJsZXMg IDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgIDAgICAgICAwICAgICAg MA0Kc2l6ZS0yNTYgICAgICAgICAgICAxNTU0ICAgMTYyMCAgICAyNTYgICAx NSAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAg ICAxMDggICAgMTA4ICAgICAgMA0Kc2l6ZS0xMjgoRE1BKSAgICAgICAgICAw ICAgICAgMCAgICAxMjggICAzMCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYw ICAgIDggOiBzbGFiZGF0YSAgICAgIDAgICAgICAwICAgICAgMA0Kc2l6ZS0x MjggICAgICAgICAgICAzNjM1ICAgNzgzMCAgICAxMjggICAzMCAgICAxIDog dHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAyNjEgICAg MjYxICAgICAgMA0Kc2l6ZS02NChETUEpICAgICAgICAgICAwICAgICAgMCAg ICAgNjQgICA1OCAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBz bGFiZGF0YSAgICAgIDAgICAgICAwICAgICAgMA0Kc2l6ZS02NCAgICAgICAg ICAgICAxNTc2ICAgNTY4NCAgICAgNjQgICA1OCAgICAxIDogdHVuYWJsZXMg IDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgOTggICAgIDk4ICAgICAg MA0Kc2l6ZS0zMihETUEpICAgICAgICAgICAwICAgICAgMCAgICAgMzIgIDEx MiAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAg ICAgIDAgICAgICAwICAgICAgMA0Kc2l6ZS0zMiAgICAgICAgICAgIDQxMDY3 ICA0MTIxNiAgICAgMzIgIDExMiAgICAxIDogdHVuYWJsZXMgIDEyMCAgIDYw ICAgIDggOiBzbGFiZGF0YSAgICAzNjggICAgMzY4ICAgICAgMA0Ka21lbV9j YWNoZSAgICAgICAgICAgMTYwICAgIDE2MCAgICAyNDQgICAxNiAgICAxIDog dHVuYWJsZXMgIDEyMCAgIDYwICAgIDggOiBzbGFiZGF0YSAgICAgMTAgICAg IDEwICAgICAgMA0KDQpvdXRwdXQgb2Y6IHBzIC1ld0hvIHBpZCxwcGlkLHVp ZCxnaWQscG1lbSxzaXplLHZzaXplLHJzcyxwY3B1LG5pY2Usc3RpbWUsdGlt ZSx0bmFtZSxjbWQNCg0KICBQSUQgIFBQSUQgICBVSUQgICBHSUQgJU1FTSBT WiAgVlNaICBSU1MgJUNQVSAgTkkgU1RJTUUgICAgIFRJTUUgVFRZICAgICAg Q01EDQogICAgMSAgICAgMCAgICAgMCAgICAgMCAgMC4wIDE0NCA1ODggIDEx MiAgMC4wICAgMCBNYXIxMiAwMDowMDowNSA/ICAgICAgICBpbml0IFszXSAg DQogICAgMiAgICAgMSAgICAgMCAgICAgMCAgMC4wIDAgICAgIDAgICAgMCAg MC4wICAgMCBNYXIxMiAwMDowMDowMSA/ICAgICAgICAgIFttaWdyYXRpb24v MF0NCiAgICAzICAgICAxICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAw ICAwLjAgIDE5IE1hcjEyIDAwOjAwOjEzID8gICAgICAgICAgW2tzb2Z0aXJx ZC8wXQ0KICAgIDQgICAgIDEgICAgIDAgICAgIDAgIDAuMCAwICAgICAwICAg IDAgIDAuMCAgIDAgTWFyMTIgMDA6MDA6MDAgPyAgICAgICAgICBbbWlncmF0 aW9uLzFdDQogICAgNSAgICAgMSAgICAgMCAgICAgMCAgMC4wIDAgICAgIDAg ICAgMCAgMC4wICAxOSBNYXIxMiAwMDowMDowMCA/ICAgICAgICAgIFtrc29m dGlycWQvMV0NCiAgICA2ICAgICAxICAgICAwICAgICAwICAwLjAgMCAgICAg MCAgICAwICAwLjAgICAwIE1hcjEyIDAwOjAwOjMzID8gICAgICAgICAgW21p Z3JhdGlvbi8yXQ0KICAgIDcgICAgIDEgICAgIDAgICAgIDAgIDAuMCAwICAg ICAwICAgIDAgIDAuMCAgMTkgTWFyMTIgMDA6MDA6MTMgPyAgICAgICAgICBb a3NvZnRpcnFkLzJdDQogICAgOCAgICAgMSAgICAgMCAgICAgMCAgMC4wIDAg ICAgIDAgICAgMCAgMC4wICAgMCBNYXIxMiAwMDowMDoxMSA/ICAgICAgICAg IFttaWdyYXRpb24vM10NCiAgICA5ICAgICAxICAgICAwICAgICAwICAwLjAg MCAgICAgMCAgICAwICAwLjAgIDE5IE1hcjEyIDAwOjAwOjAwID8gICAgICAg ICAgW2tzb2Z0aXJxZC8zXQ0KICAgMTAgICAgIDEgICAgIDAgICAgIDAgIDAu MCAwICAgICAwICAgIDAgIDAuMCAtMTAgTWFyMTIgMDA6MDA6MDcgPyAgICAg ICAgICBbZXZlbnRzLzBdDQogICAxNCAgICAxMCAgICAgMCAgICAgMCAgMC4w IDAgICAgIDAgICAgMCAgMC4wIC0xMCBNYXIxMiAwMDowMDowMCA/ICAgICAg ICAgICAgW2thY3BpZF0NCiAgIDE1ICAgIDEwICAgICAwICAgICAwICAwLjAg MCAgICAgMCAgICAwICAwLjAgLTEwIE1hcjEyIDAwOjAwOjAwID8gICAgICAg ICAgICBba2Jsb2NrZC8wXQ0KICAgMTYgICAgMTAgICAgIDAgICAgIDAgIDAu MCAwICAgICAwICAgIDAgIDAuMCAtMTAgTWFyMTIgMDA6MDA6MDAgPyAgICAg ICAgICAgIFtrYmxvY2tkLzFdDQogICAxNyAgICAxMCAgICAgMCAgICAgMCAg MC4wIDAgICAgIDAgICAgMCAgMC4wIC0xMCBNYXIxMiAwMDowMDowMCA/ICAg ICAgICAgICAgW2tibG9ja2QvMl0NCiAgIDE4ICAgIDEwICAgICAwICAgICAw ICAwLjAgMCAgICAgMCAgICAwICAwLjAgLTEwIE1hcjEyIDAwOjAwOjAwID8g ICAgICAgICAgICBba2Jsb2NrZC8zXQ0KICAgMjQgICAgMTAgICAgIDAgICAg IDAgIDAuMCAwICAgICAwICAgIDAgIDAuMCAtMTAgTWFyMTIgMDA6MDA6MDAg PyAgICAgICAgICAgIFtraGVscGVyXQ0KICAgMjkgICAgMTAgICAgIDAgICAg IDAgIDAuMCAwICAgICAwICAgIDAgIDAuMCAtMTAgTWFyMTIgMDA6MDA6MDAg PyAgICAgICAgICAgIFthaW8vMV0NCiAgIDMxICAgIDEwICAgICAwICAgICAw ICAwLjAgMCAgICAgMCAgICAwICAwLjAgLTEwIE1hcjEyIDAwOjAwOjAwID8g ICAgICAgICAgICBbYWlvLzNdDQogMTE1NyAgICAxMCAgICAgMCAgICAgMCAg MC4wIDAgICAgIDAgICAgMCAgMC4wIC0xMCBNYXIxMiAwMDowMDowMCA/ICAg ICAgICAgICAgW3JlaXNlcmZzLzBdDQogMTE1OSAgICAxMCAgICAgMCAgICAg MCAgMC4wIDAgICAgIDAgICAgMCAgMC4wIC0xMCBNYXIxMiAwMDowMDowMCA/ ICAgICAgICAgICAgW3JlaXNlcmZzLzJdDQogICAxMSAgICAgMSAgICAgMCAg ICAgMCAgMC4wIDAgICAgIDAgICAgMCAgMC4wIC0xMCBNYXIxMiAwMDowMDow MCA/ICAgICAgICAgIFtldmVudHMvMV0NCiAgIDI4ICAgIDExICAgICAwICAg ICAwICAwLjAgMCAgICAgMCAgICAwICAwLjAgLTEwIE1hcjEyIDAwOjAwOjAw ID8gICAgICAgICAgICBbYWlvLzBdDQogICAzMCAgICAxMSAgICAgMCAgICAg MCAgMC4wIDAgICAgIDAgICAgMCAgMC4wIC0xMCBNYXIxMiAwMDowMDowMCA/ ICAgICAgICAgICAgW2Fpby8yXQ0KIDExNTggICAgMTEgICAgIDAgICAgIDAg IDAuMCAwICAgICAwICAgIDAgIDAuMCAtMTAgTWFyMTIgMDA6MDA6MDAgPyAg ICAgICAgICAgIFtyZWlzZXJmcy8xXQ0KIDExNjAgICAgMTEgICAgIDAgICAg IDAgIDAuMCAwICAgICAwICAgIDAgIDAuMCAtMTAgTWFyMTIgMDA6MDA6MDAg PyAgICAgICAgICAgIFtyZWlzZXJmcy8zXQ0KICAgMTIgICAgIDEgICAgIDAg ICAgIDAgIDAuMCAwICAgICAwICAgIDAgIDAuMCAtMTAgTWFyMTIgMDA6MDA6 MDAgPyAgICAgICAgICBbZXZlbnRzLzJdDQoyMTM2NiAgICAxMiAgICAgMCAg ICAgMCAgMC4wIDAgICAgIDAgICAgMCAgMC4wIC0xMCBNYXIxNCAwMDoxNzo0 NyA/ICAgICAgICAgICAgW3hmc2xvZ2QvMF0NCjIxMzY3ICAgIDEyICAgICAw ICAgICAwICAwLjAgMCAgICAgMCAgICAwICAwLjAgLTEwIE1hcjE0IDAwOjAw OjAyID8gICAgICAgICAgICBbeGZzbG9nZC8xXQ0KMjEzNjggICAgMTIgICAg IDAgICAgIDAgIDAuMCAwICAgICAwICAgIDAgIDAuMCAtMTAgTWFyMTQgMDA6 MTU6MTggPyAgICAgICAgICAgIFt4ZnNsb2dkLzJdDQoyMTM2OSAgICAxMiAg ICAgMCAgICAgMCAgMC4wIDAgICAgIDAgICAgMCAgMC4wIC0xMCBNYXIxNCAw MDowNDowMCA/ICAgICAgICAgICAgW3hmc2xvZ2QvM10NCjIxMzcwICAgIDEy ICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAwICAwLjAgLTEwIE1hcjE0 IDAwOjAwOjAwID8gICAgICAgICAgICBbeGZzZGF0YWQvMF0NCjIxMzcxICAg IDEyICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAwICAwLjAgLTEwIE1h cjE0IDAwOjAwOjAwID8gICAgICAgICAgICBbeGZzZGF0YWQvMV0NCjIxMzcy ICAgIDEyICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAwICAwLjAgLTEw IE1hcjE0IDAwOjAwOjAwID8gICAgICAgICAgICBbeGZzZGF0YWQvMl0NCjIx MzczICAgIDEyICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAwICAwLjAg LTEwIE1hcjE0IDAwOjAwOjAwID8gICAgICAgICAgICBbeGZzZGF0YWQvM10N CiAgIDEzICAgICAxICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAwICAw LjAgLTEwIE1hcjEyIDAwOjAwOjAwID8gICAgICAgICAgW2V2ZW50cy8zXQ0K ICA3MTkgICAgMTMgICAgIDAgICAgIDAgIDAuMCAwICAgICAwICAgIDAgIDAu MCAgIDAgTWF5MDQgMDA6MTc6MjEgPyAgICAgICAgICAgIFtwZGZsdXNoXQ0K Mjk5NTMgICAgMTMgICAgIDAgICAgIDAgIDAuMCAwICAgICAwICAgIDAgIDAu MCAgIDAgSnVuMDUgMDA6MDU6NDQgPyAgICAgICAgICAgIFtwZGZsdXNoXQ0K ICAgMTkgICAgIDEgICAgIDAgICAgIDAgIDAuMCAwICAgICAwICAgIDAgIDAu MCAgIDAgTWFyMTIgMDA6MDA6MDYgPyAgICAgICAgICBba2lycWRdDQogICAy NyAgICAgMSAgICAgMCAgICAgMCAgMC4wIDAgICAgIDAgICAgMCAgMC4xICAg MCBNYXIxMiAwMzo1MTozNCA/ICAgICAgICAgIFtrc3dhcGQwXQ0KICA2ODgg ICAgIDEgICAgIDAgICAgIDAgIDAuMCAwICAgICAwICAgIDAgIDAuMCAgIDAg TWFyMTIgMDA6MDA6MDAgPyAgICAgICAgICBba3NlcmlvZF0NCiAgNzMyICAg ICAxICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAwICAwLjAgICAwIE1h cjEyIDAwOjAwOjAwID8gICAgICAgICAgW3Njc2lfZWhfMF0NCiAgNzMzICAg ICAxICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAwICAwLjAgLTIwIE1h cjEyIDAwOjAwOjAwID8gICAgICAgICAgW3FsYTIzMDBfMF9kcGNdDQogMTE0 NiAgICAgMSAgICAgMCAgICAgMCAgMC4wIDAgICAgIDAgICAgMCAgMC4wICAg MCBNYXIxMiAwMDowMDowMCA/ICAgICAgICAgIFtzY3NpX2VoXzFdDQogMTE0 NyAgICAgMSAgICAgMCAgICAgMCAgMC4wIDAgICAgIDAgICAgMCAgMC4wIC0y MCBNYXIxMiAwMDowMDowMCA/ICAgICAgICAgIFtxbGEyMzAwXzFfZHBjXQ0K IDI0MjggICAgIDEgICAgIDAgICAgIDAgIDAuMCAwICAgICAwICAgIDAgIDAu MCAgIDAgTWFyMTIgMDA6MDA6MDAgPyAgICAgICAgICBba2h1YmRdDQogMjk5 NCAgICAgMSAgICAgMCAgICAgMCAgMC4wIDE2OCAxNDA0ICA5NiAgMC4wICAg MCBNYXIxMiAwMDowMDowMCA/ICAgICAgICAgIC9zYmluL3Jlc21ncmQNCiAz MTIzICAgICAxICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAwICAwLjAg ICAwIE1hcjEyIDAwOjAwOjAxID8gICAgICAgICAgW3JwY2lvZF0NCiAzMTI0 ICAgICAxICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAwICAwLjAgICAw IE1hcjEyIDAwOjAwOjAwID8gICAgICAgICAgW2xvY2tkXQ0KIDMyOTAgICAg IDEgICAgIDAgICAgIDAgIDAuMCAyMTIgMTQxMiAgMzIgIDAuMCAgIDAgTWFy MTIgMDA6MDA6MDAgPyAgICAgICAgICBbaHdzY2FuZF0NCiA0MDExICAgICAx ICAgICAwICAgICAwICAwLjAgMTkyIDE1OTIgNTA4ICAwLjAgICAwIE1hcjEy IDAwOjAwOjIwID8gICAgICAgICAgL3Vzci9zYmluL2Nyb24NCiA2MTIxICAg ICAxICAgICAwICAgICAwICAwLjAgMTcyIDE2MDggIDM2ICAwLjAgICAwIE1h cjEyIDAwOjAwOjAwIHR0eTQgICAgICAgL3NiaW4vbWluZ2V0dHkgdHR5NA0K IDYxMjIgICAgIDEgICAgIDAgICAgIDAgIDAuMCAxNzIgMTYwOCAgMzYgIDAu MCAgIDAgTWFyMTIgMDA6MDA6MDAgdHR5NSAgICAgICAvc2Jpbi9taW5nZXR0 eSB0dHk1DQogNjEyMyAgICAgMSAgICAgMCAgICAgMCAgMC4wIDE3MiAxNjA4 ICAzNiAgMC4wICAgMCBNYXIxMiAwMDowMDowMCB0dHk2ICAgICAgIC9zYmlu L21pbmdldHR5IHR0eTYNCjIxMzc0ICAgICAxICAgICAwICAgICAwICAwLjAg MCAgICAgMCAgICAwICAwLjAgICAwIE1hcjE0IDAwOjA4OjE2ID8gICAgICAg ICAgW3hmc2J1ZmRdDQogMjAwMiAgICAgMSAgICAgMCAgICAgMCAgMC4wIDAg ICAgIDAgICAgMCAgMC4wICAgMCBNYXIxNCAwMDowMDo1MSA/ICAgICAgICAg IFt4ZnNzeW5jZF0NCjIzMTM2ICAgICAxICAgICAwICAgICAwICAwLjAgMCAg ICAgMCAgICAwICAwLjMgICAwIE1hcjE2IDA2OjM0OjI2ID8gICAgICAgICAg W25mc2RdDQoyMzEzNyAgICAgMSAgICAgMCAgICAgMCAgMC4wIDAgICAgIDAg ICAgMCAgMC4zICAgMCBNYXIxNiAwNjo0MTo0MSA/ICAgICAgICAgIFtuZnNk XQ0KMjMxNDEgICAgIDEgICAgIDAgICAgIDAgIDAuMCAwICAgICAwICAgIDAg IDAuMyAgIDAgTWFyMTYgMDY6NDg6NTggPyAgICAgICAgICBbbmZzZF0NCjIz MTM4ICAgICAxICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAwICAwLjMg ICAwIE1hcjE2IDA2OjM5OjEzID8gICAgICAgICAgW25mc2RdDQoyMzE0MCAg ICAgMSAgICAgMCAgICAgMCAgMC4wIDAgICAgIDAgICAgMCAgMC4zICAgMCBN YXIxNiAwNjo0MDoyNiA/ICAgICAgICAgIFtuZnNkXQ0KMjMxMzkgICAgIDEg ICAgIDAgICAgIDAgIDAuMCAwICAgICAwICAgIDAgIDAuMyAgIDAgTWFyMTYg MDY6MzE6MzcgPyAgICAgICAgICBbbmZzZF0NCjIzMTQ1ICAgICAxICAgICAw ICAgICAwICAwLjAgMjM5NiAzODcyIDIwNzYgIDAuMCAwIE1hcjE2IDAwOjAw OjMxID8gICAgICAgICAgL3Vzci9zYmluL3JwYy5tb3VudGQNCiAxNDQ2ICAg ICAxICAgICAwICAgICAwICAwLjAgMTcyIDE2MDggMTA0ICAwLjAgICAwIE1h cjIyIDAwOjAwOjAwIHR0eTMgICAgICAgL3NiaW4vbWluZ2V0dHkgdHR5Mw0K MjAyNDUgICAgIDEgICAgIDAgICAgIDAgIDAuMCAxODAgMTQ0MCAzNDggIDAu MCAgIDAgTWFyMjIgMDA6MDA6NTEgPyAgICAgICAgICAvc2Jpbi9zeXNsb2dk IC1hIC92YXIvbGliL250cC9kZXYvbG9nDQoyMDI0OSAgICAgMSAgICAgMCAg ICAgMCAgMC4wIDI5NiAxNTEyIDM1MiAgMC4wICAgMCBNYXIyMiAwMDowMDow MCA/ICAgICAgICAgIC9zYmluL2tsb2dkIC1jIDEgLTIgLXgNCjI0MzI5ICAg ICAxICAgICAwICAgICAwICAwLjAgMTY4IDE2MDQgIDM2ICAwLjAgICAwIE1h cjIzIDAwOjAwOjAwIHR0eTIgICAgICAgL3NiaW4vbWluZ2V0dHkgdHR5Mg0K Mjc1NTIgICAgIDEgICAgIDAgICAgIDAgIDAuMCA2ODQgNjYyMCA0MjggIDAu MCAgIDAgQXByMDYgMDA6MDA6MDAgPyAgICAgICAgICBzc2hkOiByb290IFtw YW1dICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAyNjY2ICAg ICAxICAgICAwICAgICAwICAwLjAgNDMxNiA3MDk2IDQ0OCAgMC4wICAwIE1h eTEwIDAwOjAwOjAyID8gICAgICAgICAgL3Vzci9zYmluL3lwYmluZA0KIDI3 MDIgICAgIDEgICAgIDAgICAgIDAgIDAuMCAxMTQ3MiAxMzE4MCA2MTYgIDAu MCAwIE1heTEwIDAwOjAwOjIwID8gICAgICAgICAvdXNyL3NiaW4vbnNjZA0K IDUzMjIgICAgIDEgICAgIDAgICAgIDAgIDAuMCAzOTIgNDYwOCA1NDAgIDAu MCAgIDAgTWF5MTQgMDA6MDE6MTcgPyAgICAgICAgICAvdXNyL3NiaW4vc3No ZCAtbyBQaWRGaWxlPS92YXIvcnVuL3NzaGQuaW5pdC5waWQNCjI2OTY2ICA1 MzIyICAgICAwICAgICAwICAwLjAgNTY4IDc3MzYgMTk1MiAgMC4wICAwIDE0 OjE0IDAwOjAwOjAwID8gICAgICAgICAgICBzc2hkOiBhbHZhcm8gW3ByaXZd ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCjI2OTkxIDI2OTY2ICAg NTA5ICAgNTAwICAwLjAgNTg0IDc3NTIgMjA3NiAgMC4wICAwIDE0OjE1IDAw OjAwOjAwID8gICAgICAgICAgICAgIHNzaGQ6IGFsdmFyb0BwdHMvMCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KMjY5OTIgMjY5OTEgICA1MDkg ICA1MDAgIDAuMCA2MTIgMzg1MiAxNzI0ICAwLjAgIDAgMTQ6MTUgMDA6MDA6 MDAgcHRzLzAgICAgICAgICAgICAtYmFzaA0KMjcyNjAgMjY5OTIgICA1MDkg ICA1MDAgIDAuMCA4NzYgMjE2NCA2OTYgIDAuMCAgIDAgMTQ6MjggMDA6MDA6 MDAgcHRzLzAgICAgICAgICAgICAgIHBzIC1ld0hvIHBpZCxwcGlkLHVpZCxn aWQscG1lbSxzaXplLHZzaXplLHJzcyxwY3B1LG5pY2Usc3RpbWUsdGltZSx0 bmFtZSxjbWQNCjMyNDY1ICAgICAxICAgICAwICAgICAwICAwLjEgMzM4MCA2 MzA0IDM1NjAgIDAuMCAwIEp1bjAxIDAwOjAwOjA2ID8gICAgICAgICAgcnJk dGltZXINCjMyNDcwICAgICAxICAgICAwICAgICAwICAwLjEgMzIyOCA2Mzc2 IDM2MzIgIDAuMCAwIEp1bjAxIDAwOjAzOjQ5ID8gICAgICAgICAgcGVybCAu L3JlYWQtZGF0YS5wbCBzdGFydCBkaXNraW8NCjMyNDczICAgICAxICAgICAw ICAgICAwICAwLjEgMzEwMCA2MjQ4IDM0ODQgIDAuNSAwIEp1bjAxIDAxOjE0 OjUzID8gICAgICAgICAgcGVybCAuL3JlYWQtZGF0YS5wbCBzdGFydCBuZXRz dGF0DQozMjQ3OCAgICAgMSAgICAgMCAgICAgMCAgMC4xIDMxMDAgNjI0OCAz NTM2ICAwLjAgMCBKdW4wMSAwMDowMjoxMyA/ICAgICAgICAgIHBlcmwgLi9y ZWFkLWRhdGEucGwgc3RhcnQgcGFydA0KMzI0ODIgICAgIDEgICAgIDAgICAg IDAgIDAuMSAzMzYwIDY2MjQgMzg0OCAgMC4wIDAgSnVuMDEgMDA6MTM6MjIg PyAgICAgICAgICBwZXJsIC4vcmVhZC1kYXRhLnBsIHN0YXJ0IHN5c3RlbQ0K MzI0ODUgICAgIDEgICAgIDAgICAgIDAgIDAuMSAzMTA0IDYyNTIgMzQ5MiAg MC4wIDAgSnVuMDEgMDA6MDA6NTggPyAgICAgICAgICBwZXJsIC4vcmVhZC1k YXRhLnBsIHN0YXJ0IHRyYWZmaWMNCiAxNTM0ICAgICAxICAgICAwICAgICAw ICAwLjAgNTMzNiA2ODA0IDU3NiAgMC41ICAwIEp1bjA3IDAwOjMxOjMxID8g ICAgICAgICAgL3Vzci9zYmluL2lwcGwNCiAxNjI2ICAgICAxICAgICAwICAg ICAwICAwLjAgMjIwIDQxMTIgNTU2ICAwLjAgICAwIEp1bjA3IDAwOjAwOjAw ID8gICAgICAgICAgL3Vzci9saWIvcG9zdGZpeC9tYXN0ZXINCiAxNjM3ICAx NjI2ICAgIDUxICAgIDUxICAwLjAgMjI0IDQyNTYgNDIwICAwLjAgICAwIEp1 bjA3IDAwOjAwOjAyID8gICAgICAgICAgICBxbWdyIC1sIC10IGZpZm8gLXUN CjI3MTg2ICAxNjI2ICAgIDUxICAgIDUxICAwLjAgMjI0IDQyMjggMTQ5MiAg MC4wICAwIDE0OjI0IDAwOjAwOjAwID8gICAgICAgICAgICBwaWNrdXAgLWwg LXQgZmlmbyAtdQ0KIDE2NjggICAgIDEgICAgIDEgICAgIDAgIDAuMCAxNzYg MTQyNCA0MjAgIDAuMCAgIDAgSnVuMDcgMDA6MDA6MDAgPyAgICAgICAgICAv c2Jpbi9wb3J0bWFwDQogMzc0NCAgICAgMSAgICAgMCAgICAgMCAgMC4wIDM5 MiAyMDUyIDEwNjggIDAuMCAgMCBKdW4wNyAwMDowMDowMCA/ICAgICAgICAg IC9vcHQvQ0EvQkFCY21hZ3QvY2FhZ2VudGQNCiAyOTI2ICAzNzQ0ICAgICAw ICAgICAwICAwLjAgNDAwIDIwNjAgMTA4OCAgMC4wICAwIEp1bjEwIDAwOjAw OjAwID8gICAgICAgICAgICAvb3B0L0NBL0JBQmNtYWd0L2NhYWdlbnRkDQog MjkyNyAgMjkyNiAgICAgMCAgICAgMCAgMC4wIDEwNDAgMzU2NCA4NjAgIDAu MCAgMCBKdW4xMCAwMDowMDowMCA/ICAgICAgICAgICAgICBjYWJyDQoyNjMz MCAgMzc0NCAgICAgMCAgICAgMCAgMi42IDIxNTYgNzExNjggNjc3MTIgIDAu NiAwIDEzOjI5IDAwOjAwOjE1ID8gICAgICAgICAgdWFnZW50ZA0KMjYzMzEg MjYzMzAgICAgIDAgICAgIDAgIDAuMCAwICAgICAwICAgIDAgIDAuMCAgIDAg MTM6MjkgMDA6MDA6MDAgPyAgICAgICAgICAgICAgW3VhZ2VudGRdIDxkZWZ1 bmN0Pg0KMjYzMzIgMjYzMzAgICAgIDAgICAgIDAgIDIuNSAyMTU2IDcxMTY4 IDY3MzA0ICAwLjYgMCAxMzoyOSAwMDowMDoxNiA/ICAgICAgICAgICAgdWFn ZW50ZA0KMjYzMzQgIDM3NDQgICAgIDAgICAgIDAgIDIuNiAyMTYwIDcxMTcy IDY3NzM2ICAwLjIgMCAxMzoyOSAwMDowMDowNSA/ICAgICAgICAgIHVhZ2Vu dGQNCjI2MzM1IDI2MzM0ICAgICAwICAgICAwICAwLjAgMCAgICAgMCAgICAw ICAwLjAgICAwIDEzOjI5IDAwOjAwOjAwID8gICAgICAgICAgICAgIFt1YWdl bnRkXSA8ZGVmdW5jdD4NCjI2MzM2IDI2MzM0ICAgICAwICAgICAwICAyLjUg MjE1NiA3MTE2OCA2NzMwNCAgMC4xIDAgMTM6MjkgMDA6MDA6MDIgPyAgICAg ICAgICAgIHVhZ2VudGQNCjI2Njc2ICAgICAxICAgICAwICAgICAwICAwLjEg MTA4NCA2MDEyIDMwMjQgIDAuMCAwIEp1bjA4IDAwOjAwOjAwID8gICAgICAg ICAgL3Vzci9zYmluL2h0dHBkMi13b3JrZXIgLWYgL2V0Yy9hcGFjaGUyL2h0 dHBkLmNvbmYNCjMwNTk4IDI2Njc2ICAgIDMwICAgICA4ICAwLjEgMTA4NCA2 MDgwIDI4NjggIDAuMCAwIEp1bjEwIDAwOjAwOjAwID8gICAgICAgICAgICAv dXNyL3NiaW4vaHR0cGQyLXdvcmtlciAtZiAvZXRjL2FwYWNoZTIvaHR0cGQu Y29uZg0KMzA2MjIgMjY2NzYgICAgMzAgICAgIDggIDAuMSA1NzAyOCA2MjA1 NiA0MDI0ICAwLjAgMCBKdW4xMCAwMDowMDowMyA/ICAgICAgICAgIC91c3Iv c2Jpbi9odHRwZDItd29ya2VyIC1mIC9ldGMvYXBhY2hlMi9odHRwZC5jb25m DQozMDYyMyAyNjY3NiAgICAzMCAgICAgOCAgMC4xIDU3OTE2IDYyOTQ0IDQw MTIgIDAuMCAwIEp1bjEwIDAwOjAwOjA0ID8gICAgICAgICAgL3Vzci9zYmlu L2h0dHBkMi13b3JrZXIgLWYgL2V0Yy9hcGFjaGUyL2h0dHBkLmNvbmYNCjMw NjI0IDI2Njc2ICAgIDMwICAgICA4ICAwLjEgNTcwMjggNjIwNTYgNDAyNCAg MC4wIDAgSnVuMTAgMDA6MDA6MDMgPyAgICAgICAgICAvdXNyL3NiaW4vaHR0 cGQyLXdvcmtlciAtZiAvZXRjL2FwYWNoZTIvaHR0cGQuY29uZg0KIDEyMTAg ICAgIDEgICAgIDAgICAgIDAgIDAuMCAxNzIgMTYwOCA1OTYgIDAuMCAgIDAg SnVuMTAgMDA6MDA6MDAgdHR5MSAgICAgICAvc2Jpbi9taW5nZXR0eSAtLW5v Y2xlYXIgdHR5MQ0KDQoNCg== ------=_Part_4111_33055601.1118513643159-- From owner-linux-xfs@oss.sgi.com Sat Jun 11 11:17:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Jun 2005 11:18:01 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5BIHtXq020950 for ; Sat, 11 Jun 2005 11:17:56 -0700 Received: by wproxy.gmail.com with SMTP id 68so679564wri for ; Sat, 11 Jun 2005 11:16:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=N/UhQrzABNbh6lHmLZXA5vrxVwjF27B8FeLc9NHhPCGjJEa782xT9OSCqqFL1N5QWiY6KDyeBmfHxs124R5b1e11L3rqRBmCmviDyJvD8owuTUEzCHKw60RJq2x5GqvN/rTdStc1FNnEgQ4SOtt6CsNVbMYd9U/a1ybtSNne5AE= Received: by 10.54.116.20 with SMTP id o20mr1609320wrc; Sat, 11 Jun 2005 11:16:47 -0700 (PDT) Received: by 10.54.15.56 with HTTP; Sat, 11 Jun 2005 11:16:47 -0700 (PDT) Message-ID: Date: Sat, 11 Jun 2005 15:16:47 -0300 From: Alvaro R Reply-To: Alvaro R To: linux-xfs@oss.sgi.com Subject: Re: Strange swap growth/exhaustion In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j5BIHuXq020952 X-archive-position: 5450 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: askxfs@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 634 Lines: 27 This is what I have now on /proc alvaro@blade01:/proc/sys/vm> /sbin/sysctl -a |grep vm error: permission denied on key 'kernel.cad_pid' error: permission denied on key 'kernel.cap-bound' vm.disable_cap_mlock = 0 vm.block_dump = 0 vm.laptop_mode = 0 vm.max_map_count = 65536 vm.min_free_kbytes = 1914 vm.lowmem_reserve_ratio = 256 32 vm.overcommit_hugepages = 0 vm.nr_hugepages = 0 vm.swappiness = 0 vm.nr_pdflush_threads = 2 vm.dirty_expire_centisecs = 3000 vm.dirty_writeback_centisecs = 500 vm.dirty_ratio = 40 vm.dirty_background_ratio = 10 vm.page-cluster = 3 vm.overcommit_ratio = 50 vm.overcommit_memory = 0 Thanks Álvaro From owner-linux-xfs@oss.sgi.com Sat Jun 11 16:19:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Jun 2005 16:19:42 -0700 (PDT) Received: from servalan.opentrend.net (rbrockway.tor.istop.com [66.11.182.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5BNJXXq006752 for ; Sat, 11 Jun 2005 16:19:33 -0700 Received: from mimosa.opentrend.net (mimosa.opentrend.net [192.168.120.11]) by servalan.opentrend.net (Postfix) with ESMTP id 615E8FBE6 for ; Sat, 11 Jun 2005 18:36:42 -0400 (EDT) Received: by mimosa.opentrend.net (Postfix, from userid 1000) id 0F9053000965; Sat, 11 Jun 2005 19:22:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mimosa.opentrend.net (Postfix) with ESMTP id 0E89938149CE for ; Sat, 11 Jun 2005 19:22:05 -0400 (EDT) Date: Sat, 11 Jun 2005 19:22:05 -0400 (EDT) From: Robert Brockway To: linux-xfs@oss.sgi.com Subject: Re: CXFS questions In-Reply-To: <42A9A7F0.4000201@sgi.com> Message-ID: References: <20050610123928.GB12293@vestdata.no> <42A9A7F0.4000201@sgi.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463809160-155484179-1118532125=:30525" X-archive-position: 5451 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rbrockway@opentrend.net Precedence: bulk X-list: linux-xfs Content-Length: 1264 Lines: 33 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463809160-155484179-1118532125=:30525 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 10 Jun 2005, Eric Sandeen wrote: > Ragnar Kj=C3=B8rstad wrote: > > Is there a seperate list for CXFS, or is this the right place to ask > > questions? >=20 > Because cxfs is not an open source project, there is not a public list=20 > for it as there is for xfs. I'll send a couple quick semi-official=20 > answers off-list, since cxfs is off-topic here. As an avid XFS user who has not used CXFS I would be interested to see=20 answers to questions like this posted on-list. I'm sure the number of=20 CXFS questions would be small enough that it would not be a problem or=20 they could be tagged [OT] or [CXFS]. Rob --=20 Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Ph: +1-416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest http://www.spi-inc.o= rg ---1463809160-155484179-1118532125=:30525-- From owner-linux-xfs@oss.sgi.com Tue Jun 14 16:13:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jun 2005 16:13:20 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5ENDHBK030925 for ; Tue, 14 Jun 2005 16:13:17 -0700 Received: by wproxy.gmail.com with SMTP id 70so29965wra for ; Tue, 14 Jun 2005 16:12:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hOvj+aKJeAfEA0WPfaM4yWeOT4UBEDK5Z7OlLItgIx3B2zep+8Vt3kVdw4As1B4Qt2ZIL6yeL3xvVjLLWhJjKWys+cWHymGBsR//VwdyxKMLowwbTds2pu5X5SqgcTaXLCChZXmBfGg4qM00tgkhzRC/lrn554l+uAZzaGDqIbM= Received: by 10.54.116.2 with SMTP id o2mr3353617wrc; Tue, 14 Jun 2005 10:45:23 -0700 (PDT) Received: by 10.54.15.56 with HTTP; Tue, 14 Jun 2005 10:45:23 -0700 (PDT) Message-ID: Date: Tue, 14 Jun 2005 14:45:23 -0300 From: Alvaro R Reply-To: Alvaro R To: linux-xfs@oss.sgi.com Subject: Re: Strange swap growth/exhaustion In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j5ENDHBK030927 X-archive-position: 5455 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: askxfs@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 145 Lines: 5 Just to let you guys know, I rebooted the server and so far, swap usage is normal. I think that the CA backup agent has a memory leak. Thanks! From owner-linux-xfs@oss.sgi.com Wed Jun 15 11:13:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jun 2005 11:13:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5FIDFH9003505 for ; Wed, 15 Jun 2005 11:13:16 -0700 Received: (qmail invoked by alias); 15 Jun 2005 15:25:23 -0000 Received: from p54995C9B.dip.t-dialin.net (EHLO hal-9006) [84.153.92.155] by mail.gmx.net (mp015) with SMTP; 15 Jun 2005 17:25:23 +0200 X-Authenticated: #11895819 Subject: XFS_WANT_CORRUPTED_GOTO Error (XFS Log crashed) (contains debug log) From: Grand Apeiron To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Wed, 15 Jun 2005 17:25:21 +0200 Message-Id: <1118849122.5058.60.camel@hal-9006> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-archive-position: 5456 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Grand.Apeiron@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 8527 Lines: 226 Hi All, i want to send you the following error report for providing you some debug information of an XFS crash and maybe receiving some ideas what could cause those crashes. First some system information: Debian SID - Kernel 2.6.10 2x300GB Seagate SATA HD's on a Fasttrack SATA II controller Three RAID-1 (md0, md1, md2) devices which are built using partitions of these two disks. Every md-device is formatted with XFS The XFS on the md1 devices made problems. md1 has a size of 66GB. Today i was suddenly unable to access the data on the md1 device. After looking into my syslog I found the first error of the log below. I tried to unmount/remount and xfs_check the filesystem. I was unable to remount /dev/md1 in read-write mode (probably because XFS tried to recover the information of the journal but was unable to because of the XFS_WANT_CORRUPTED_GOTO error). xfs_check came up with an error which said that it can't check the filesystem because of an corrupt XFS log. Since i was able to mount /dev/md1 as read-only. I backed up all my data to another partition and ran xfs_repair -L. This did what it is proposed to do and i am now able to mount and use /dev/md1 as before. But for sure i am nervous about what this all means and why this problem arised now. I am using XFS since 2 years and never had any problems. In addition to the problem described above I found a file with wrong filesize information 3 days ago. The file was shown as a 545TB file. I was able to delete it. Please find my saved logs of the XFS_WANT_CORRUPTED_GOTO problem below. I added a simple comment about the tasks I did, before each log message. Please note that the XFS_WANT_CORRUPTED_GOTO error comes up at two different locations of fs/xfs/xfs_alloc.c. If you answer to this message please answer to the list and to my personal E-Mail address since I am not sure if my subscription to this list has worked till now. I will appreciate any information about why and how this error can occur. Must I hesitate about my hardware or kernel installation? Thank you and Greetings from Germany, Best Regards, Grand Apeiron FIRST ERROR (The problem arises) ----------------------------------------------------------------------- XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1714 of file fs/xfs/xfs_alloc.c. Caller 0xc01aac5e [] xfs_error_report+0x35/0x38 [] xfs_free_ag_extent+0x528/0x5cc [] xfs_free_extent+0xb2/0xdc [] xfs_free_extent+0xb2/0xdc [] xfs_bmap_finish+0x158/0x16c [] xfs_bmap_finish+0xf6/0x16c [] xfs_itruncate_finish+0x1ac/0x2d0 [] xfs_inactive+0x201/0x410 [] vn_rele+0x27/0x74 [] linvfs_clear_inode+0x10/0x1c [] clear_inode+0xd5/0x10c [] generic_delete_inode+0xa6/0xf4 [] generic_drop_inode+0x10/0x20 [] iput+0x5c/0x64 [] sys_unlink+0xc9/0x124 [] syscall_call+0x7/0xb xfs_force_shutdown(md1,0x8) called from line 4073 of file fs/xfs/xfs_bmap.c. Return address = 0xc02032f1 AFTER REBOOT (Changed fstab to noauto before) Mounting manually as root with ro ----------------------------------------------------------------------- XFS mounting filesystem md1 Starting XFS recovery on filesystem: md1 (dev: md1) XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1714 of file fs/xfs/xfs_alloc.c. Caller 0xc01aac5e [] xfs_error_report+0x35/0x38 [] xfs_free_ag_extent+0x528/0x5cc [] xfs_free_extent+0xb2/0xdc [] xfs_free_extent+0xb2/0xdc [] xfs_trans_log_efd_extent+0x1b/0x48 [] xlog_recover_process_efi+0x14b/0x178 [] xlog_recover_process_efi+0x13f/0x178 [] xlog_recover_process_efis+0x2c/0x50 [] xlog_recover_finish+0x18/0x9c [] xfs_mountfs+0x9e0/0xc04 [] xfs_log_mount_finish+0x1c/0x24 [] xfs_mountfs+0xb0c/0xc04 [] __down_failed+0x7/0xc [] xfs_setsize_buftarg+0x31/0x6c [] xfs_ioinit+0x22/0x28 [] xfs_mount+0x2fa/0x378 [] vfs_mount+0x25/0x2c [] linvfs_fill_super+0x78/0x1a4 [] linvfs_fill_super+0x0/0x1a4 [] snprintf+0x16/0x1c [] disk_name+0x24/0x70 [] sb_set_blocksize+0x17/0x44 [] get_sb_bdev+0xd7/0x12c [] kmem_cache_alloc+0x2e/0x38 [] linvfs_get_sb+0x1a/0x20 [] linvfs_fill_super+0x0/0x1a4 [] do_kern_mount+0x4e/0xcc [] do_new_mount+0x5a/0x7c [] do_mount+0x135/0x150 [] copy_mount_options+0x54/0xa4 [] sys_mount+0x7c/0xbc [] syscall_call+0x7/0xb Ending XFS recovery on filesystem: md1 (dev: md1) AFTER FSTAB CHANGE AND MOUNTING AS RW ----------------------------------------------------------------------- XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1637 of file fs/xfs/xfs_alloc.c. Caller 0xc01aac5e [] xfs_error_report+0x35/0x38 [] xfs_free_ag_extent+0x528/0x5cc [] xfs_free_extent+0xb2/0xdc [] xfs_free_extent+0xb2/0xdc [] xfs_bmap_finish+0xf6/0x16c [] xfs_itruncate_finish+0x1ac/0x2d0 [] xfs_inactive+0x201/0x410 [] xfs_itobp+0x1a1/0x1c0 [] vn_rele+0x27/0x74 [] linvfs_clear_inode+0x10/0x1c [] clear_inode+0xd5/0x10c [] generic_delete_inode+0xa6/0xf4 [] generic_drop_inode+0x10/0x20 [] iput+0x5c/0x64 [] xlog_recover_process_iunlinks+0x209/0x35c [] xfs_trans_first_ail+0x13/0x24 [] xfs_log_force+0x34/0x58 [] xlog_recover_finish+0x37/0x9c [] xfs_mountfs+0x9e0/0xc04 [] xfs_log_mount_finish+0x1c/0x24 [] xfs_mountfs+0xb0c/0xc04 [] __down_failed+0x7/0xc [] xfs_setsize_buftarg+0x31/0x6c [] xfs_ioinit+0x22/0x28 [] xfs_mount+0x2fa/0x378 [] vfs_mount+0x25/0x2c [] linvfs_fill_super+0x78/0x1a4 [] linvfs_fill_super+0x0/0x1a4 [] snprintf+0x16/0x1c [] disk_name+0x24/0x70 [] sb_set_blocksize+0x17/0x44 [] get_sb_bdev+0xd7/0x12c [] kmem_cache_alloc+0x2e/0x38 [] linvfs_get_sb+0x1a/0x20 [] linvfs_fill_super+0x0/0x1a4 [] do_kern_mount+0x4e/0xcc [] do_new_mount+0x5a/0x7c [] do_mount+0x135/0x150 [] unmap_vma+0x51/0x58 [] copy_mount_options+0x54/0xa4 [] sys_mount+0x7c/0xbc [] syscall_call+0x7/0xb xfs_force_shutdown(md1,0x8) called from line 4073 of file fs/xfs/xfs_bmap.c. Return address = 0xc02032f1 Filesystem "md1": Corruption of in-memory data detected. Shutting down filesystem: md1 Please umount the filesystem, and rectify the problem(s) Ending XFS recovery on filesystem: md1 (dev: md1) REMOUNTING AS ro ----------------------------------------------------------------------- XFS mounting filesystem md1 Starting XFS recovery on filesystem: md1 (dev: md1) XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1637 of file fs/xfs/xfs_alloc.c. Caller 0xc01aac5e [] xfs_error_report+0x35/0x38 [] xfs_free_ag_extent+0x528/0x5cc [] xfs_free_extent+0xb2/0xdc [] xfs_free_extent+0xb2/0xdc [] xlog_recover_process_efi+0x13f/0x178 [] xlog_recover_process_efis+0x2c/0x50 [] xlog_recover_finish+0x18/0x9c [] xfs_mountfs+0x9e0/0xc04 [] xfs_log_mount_finish+0x1c/0x24 [] xfs_mountfs+0xb0c/0xc04 [] __down_failed+0x7/0xc [] xfs_setsize_buftarg+0x31/0x6c [] xfs_ioinit+0x22/0x28 [] xfs_mount+0x2fa/0x378 [] vfs_mount+0x25/0x2c [] linvfs_fill_super+0x78/0x1a4 [] linvfs_fill_super+0x0/0x1a4 [] snprintf+0x16/0x1c [] disk_name+0x24/0x70 [] sb_set_blocksize+0x17/0x44 [] get_sb_bdev+0xd7/0x12c [] kmem_cache_alloc+0x2e/0x38 [] linvfs_get_sb+0x1a/0x20 [] linvfs_fill_super+0x0/0x1a4 [] do_kern_mount+0x4e/0xcc [] do_new_mount+0x5a/0x7c [] do_mount+0x135/0x150 [] unmap_vma+0x51/0x58 [] copy_mount_options+0x54/0xa4 [] sys_mount+0x7c/0xbc [] syscall_call+0x7/0xb Ending XFS recovery on filesystem: md1 (dev: md1) -- If I would be a tapeworm, I would prefer penguins. From owner-linux-xfs@oss.sgi.com Wed Jun 15 17:25:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jun 2005 17:25:41 -0700 (PDT) Received: from web1.mmaero.com (web1.mmaero.com [67.98.186.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5G0PZH9002128 for ; Wed, 15 Jun 2005 17:25:36 -0700 Received: from web1.mmaero.com (localhost.localdomain [127.0.0.1]) by web1.mmaero.com (8.12.11/8.12.10) with ESMTP id j5G0OM1J027159 for ; Wed, 15 Jun 2005 20:24:22 -0400 Received: from localhost (jlewis@localhost) by web1.mmaero.com (8.12.11/8.12.11/Submit) with ESMTP id j5G0OMZT027155 for ; Wed, 15 Jun 2005 20:24:22 -0400 X-Authentication-Warning: web1.mmaero.com: jlewis owned process doing -bs Date: Wed, 15 Jun 2005 20:24:22 -0400 (EDT) From: Jon Lewis X-X-Sender: jlewis@web1.mmaero.com To: linux-xfs Subject: xfs_repair hung...safe to terminate? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlewis@lewis.org Precedence: bulk X-list: linux-xfs Content-Length: 3849 Lines: 89 After having a system crash twice today with messages like (from the first crash): xfs_iget_core: ambiguous vns: vp/0xc6f0e680, invp/0xecbed200 ------------[ cut here ]------------ kernel BUG at debug.c:106! invalid operand: 0000 nfsd lockd sunrpc autofs eepro100 mii ipt_REJECT iptable_filter ip_tables xfs raid5 xor ext3 jbd raid1 isp_mod sd_mod scsi_mod CPU: 1 EIP: 0010:[] Not tainted EFLAGS: 00010246 EIP is at cmn_err [xfs] 0x9e (2.4.20-35_39.rh8.0.atsmp) eax: 00000000 ebx: 00000000 ecx: 00000096 edx: 00000001 esi: f8dd9412 edi: f8dec63e ebp: 00000293 esp: f5d2bd44 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 661, stackpage=f5d2b000) Stack: f8dd9412 f8dd93e8 f8dec600 ecbed220 7b1f202d 00000000 e4cca100 f8d8aeac 00000000 f8dda160 c6f0e680 ecbed200 f65d0c00 7b1f202d f7bfcc38 c62aea90 f65d0924 00000000 00000003 c62aea8c 00000000 00000000 e4cca100 ecbed220 Call Trace: [] .rodata.str1.1 [xfs] 0x11c2 (0xf5d2bd44)) [] .rodata.str1.1 [xfs] 0x1198 (0xf5d2bd48)) [] message [xfs] 0x0 (0xf5d2bd4c)) [] xfs_iget_core [xfs] 0x45c (0xf5d2bd60)) [] .rodata.str1.32 [xfs] 0x5a0 (0xf5d2bd68)) [] xfs_iget [xfs] 0x143 (0xf5d2bdb0)) [] xfs_vget [xfs] 0x77 (0xf5d2bdf0)) [] vfs_vget [xfs] 0x43 (0xf5d2be20)) [] linvfs_fh_to_dentry [xfs] 0x5d (0xf5d2be30)) [] nfsd_get_dentry [nfsd] 0xb6 (0xf5d2be5c)) [] find_fh_dentry [nfsd] 0x57 (0xf5d2be80)) [] fh_verify [nfsd] 0x189 (0xf5d2beb0)) [] svc_sock_enqueue [sunrpc] 0x1b6 (0xf5d2befc)) [] nfsd3_proc_getattr [nfsd] 0x6f (0xf5d2bf10)) [] nfs3svc_decode_fhandle [nfsd] 0x33 (0xf5d2bf28)) [] nfsd_procedures3 [nfsd] 0x24 (0xf5d2bf3c)) [] nfsd_dispatch [nfsd] 0xce (0xf5d2bf48)) [] nfsd_version3 [nfsd] 0x0 (0xf5d2bf5c)) [] nfsd_dispatch [nfsd] 0x0 (0xf5d2bf60)) [] svc_process_Rsmp_9d8bc81a [sunrpc] 0x45f (0xf5d2bf64)) [] nfsd_procedures3 [nfsd] 0x24 (0xf5d2bf84)) [] nfsd_program [nfsd] 0x0 (0xf5d2bf88)) [] nfsd [nfsd] 0x224 (0xf5d2bfa4)) [] arch_kernel_thread [kernel] 0x2e (0xf5d2bff0)) [] nfsd [nfsd] 0x0 (0xf5d2bff8)) Code: 0f 0b 6a 00 08 94 dd f8 83 c4 0c 5b 5e 5f 5d c3 89 f6 55 b8 <5>xfs_force_shutdown(md(9,2),0x8) called from line 1071 of file xfs_trans.c. Return address = 0xf8dbe6eb Filesystem "md(9,2)": Corruption of in-memory data detected. Shutting down filesystem: md(9,2) Please umount the filesystem, and rectify the problem(s) I figured it'd be a good idea to xfs_repair it. That was a little more than 4 hours ago. The fs is an software RAID5: md2 : active raid5 sdn2[13] sdg2[12] sdm2[11] sdl2[10] sdk2[9] sdj2[8] sdi2[7] sdh2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0] 385414656 blocks level 5, 64k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU] md0 : active raid1 sdn1[1] sdg1[0] 803136 blocks [2/2] [UU] xfs_repair [version 2.6.9] has gotten to: Phase 5 - rebuild AG headers and trees... and seems to have stopped progressing. root 798 91.8 1.0 45080 41576 pts/1 R 15:57 242:04 xfs_repair -l /dev/md0 /dev/md2 Its still using lots of CPU, but there is no disk activity. Further searching suggests this might be a kernel issue and not an actual fs corruption issue. I'd like to upgrade from 2.4.20-35_39.rh8.0.atsmp to 2.4.20-43_41.rh8.0.atsmp, but the question is, is it safe to stop (kill) xfs_repair? Will the fs be mountable if I interrupt xfs_repair at this point? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owner-linux-xfs@oss.sgi.com Wed Jun 15 19:20:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jun 2005 19:21:08 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5G2KiH9005396 for ; Wed, 15 Jun 2005 19:20:45 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA13495; Thu, 16 Jun 2005 12:19:02 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5G2IrXf180716; Thu, 16 Jun 2005 12:18:53 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j5G2IMrZ180748; Thu, 16 Jun 2005 12:18:22 +1000 (EST) Date: Thu, 16 Jun 2005 12:18:22 +1000 From: Dave Chinner To: Jeff Mahoney Cc: Hans Reiser , fs , Linus Torvalds , Andrew Morton , viro VFS , linux-fsdevel , linux-kernel , zhiming@admin.iscas.ac.cn, qufuping@ercist.iscas.ac.cn, madsys@ercist.iscas.ac.cn, xuh@nttdata.com.cn, koichi@intellilink.co.jp, kuroiwaj@intellilink.co.jp, okuyama@intellilink.co.jp, matsui_v@valinux.co.jp, kikuchi_v@valinux.co.jp, fernando@intellilink.co.jp, kskmori@intellilink.co.jp, takenakak@intellilink.co.jp, yamaguchi@intellilink.co.jp, ext2-devel@lists.sourceforge.net, sct@redhat.com, shaggy@austin.ibm.com, linux-xfs@oss.sgi.com, Reiserfs developers mail-list Subject: Re: [RFD] FS behavior (I/O failure) in kernel summit Message-ID: <20050616121822.E125706@melbourne.sgi.com> References: <1118692436.2512.157.camel@CoolQ> <42ADC99D.5000801@namesys.com> <42ADFFD5.1090905@suse.com> <42AE1EE4.5090508@namesys.com> <42B067B6.9030009@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <42B067B6.9030009@suse.com>; from jeffm@suse.com on Wed, Jun 15, 2005 at 01:39:02PM -0400 X-archive-position: 5458 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1998 Lines: 53 On Wed, Jun 15, 2005 at 01:39:02PM -0400, Jeff Mahoney wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hans Reiser wrote: > > Jeff, would you be willing to make a proposal for what should be done? > > I would be interested in your suggestions. > > > > Jeff Mahoney wrote: > > > >>Hans - > >> > >>These tests must have been run on a kernel prior to 2.6.10-rc1. The I/O > >>error code exhibits behavior similar to ext3, so (1b). There are still > >>kinks to be worked out, but it's definitely not the "throw up our arms > >>and give up" that it used to be. > >> > >>Implementing behavior 1a for ext3 and reiserfs should be fairly trivial > >>- it just means that tests to check if the filesystem is in an aborted > >>state ("shutdown" in xfs terms) need to added to the call path in some > >>places, and be moved earlier in others. > > Well it seems to me that all the XFS code does is check to see if the FS > is in a shutdown state really early in the call path. FYI, the up front checks in XFS are simply to stop new I/O from starting if we're already in the shutdown state. However, there's more than that in XFS - there's checks all through it's I/O paths so that I/Os and transactions in flight at (or started after) the time of the shutdown can be aborted before doing further damage to a potentially corrupted filesystem. This part cannot be done generically as it is intimately tied to the filesystem. It is also worth noting that XFS won't shutdown a filesystem on just any I/O error. Shutdowns due to I/O errors only occur when the failure has the potential to leave the filesystem in an inconsistent state. Hence any given operation can return different errors depending on where the I/O error occurred in XFS and what effect that I/O error has on the consistency of the filesystem..... BTW, the correct list to use to get the attention of the XFS folk is linux-xfs@oss.sgi.com. Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Thu Jun 16 02:20:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jun 2005 02:21:02 -0700 (PDT) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5G9KrH9014986 for ; Thu, 16 Jun 2005 02:20:56 -0700 Received: from inara.maison.net (lns-th2-1-gre-82-64-0-69.adsl.proxad.net [82.64.0.69]) by postfix3-1.free.fr (Postfix) with ESMTP id F27E1173499 for ; Thu, 16 Jun 2005 11:19:38 +0200 (CEST) Received: by inara.maison.net (Postfix, from userid 32266) id 7AAA55A66C; Thu, 16 Jun 2005 11:19:38 +0200 (CEST) Date: Thu, 16 Jun 2005 11:19:38 +0200 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: Re: XFS_WANT_CORRUPTED_GOTO Error (XFS Log crashed) (contains debug log) Message-ID: <20050616091938.GF26297@inara.maison.net> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1118849122.5058.60.camel@hal-9006> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1118849122.5058.60.camel@hal-9006> 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.9i X-archive-position: 5459 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: linux-xfs Content-Length: 6543 Lines: 111 We also see error messages like: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 310 of file xfs_alloc.c. ...with much more complicated stack traces. Linux 2.4.21-32.0.1.EL plus some local SCSI tape patches. kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 310 of file xfs_alloc.c. Caller 0xf89aac14 kernel: f3471798 f89dd6cb 00000008 00000001 00000000 f8a1f144 f8a1c985 00000136 kernel: f8a1c979 f89aac14 f89a9adc f8a1c985 00000001 00000000 f8a1c979 00000136 kernel: f89aac14 00000000 00000000 00000000 00000000 f3471978 f2ac6eec f3471864 kernel: Call Trace: [] xfs_error_report [xfs] 0x5b (0xf347179c) kernel: [] .rodata.str1.4 [xfs] 0x274 (0xf34717ac) kernel: [] .rodata.str1.1 [xfs] 0x29 (0xf34717b0) kernel: [] .rodata.str1.1 [xfs] 0x1d (0xf34717b8) kernel: [] xfs_alloc_ag_vextent_near [xfs] 0xbb4 (0xf34717bc) kernel: [] xfs_alloc_fixup_trees [xfs] 0x20c (0xf34717c0) kernel: [] .rodata.str1.1 [xfs] 0x29 (0xf34717c4) kernel: [] .rodata.str1.1 [xfs] 0x1d (0xf34717d0) kernel: [] xfs_alloc_ag_vextent_near [xfs] 0xbb4 (0xf34717d8) kernel: [] xfs_alloc_ag_vextent_near [xfs] 0xbb4 (0xf34717f8) kernel: [] xfs_alloc_ag_vextent [xfs] 0x12e (0xf3471878) kernel: [] xfs_alloc_vextent [xfs] 0x2fc (0xf3471894) kernel: [] xfs_bmap_alloc [xfs] 0x8e7 (0xf34718d0) kernel: [] xfs_bmap_add_extent [xfs] 0x1c3 (0xf347191c) kernel: [] xfs_bmbt_get_state [xfs] 0x2f (0xf3471948) kernel: [] xfs_bmapi [xfs] 0xe7f (0xf34719d8) kernel: [] xfs_bmbt_get_state [xfs] 0x2f (0xf34719fc) kernel: [] xfs_bmap_do_search_extents [xfs] 0xb8 (0xf3471a14) kernel: [] locate_hd_struct [kernel] 0x38 (0xf3471a40) kernel: [] xfs_bmap_search_extents [xfs] 0x6f (0xf3471a58) kernel: [] xfs_log_reserve [xfs] 0xc2 (0xf3471b00) kernel: [] xfs_iomap_write_allocate [xfs] 0x2a1 (0xf3471b54) kernel: [] xfs_trans_unlocked_item [xfs] 0x3b (0xf3471bdc) kernel: [] xfs_iunlock [xfs] 0x5c (0xf3471bf4) kernel: [] xfs_iomap [xfs] 0x401 (0xf3471c08) kernel: [] xfs_bmap [xfs] 0x45 (0xf3471c8c) kernel: [] map_blocks [xfs] 0x62 (0xf3471cac) kernel: [] page_state_convert [xfs] 0x427 (0xf3471ce0) kernel: [] xfs_ilock [xfs] 0x56 (0xf3471cfc) kernel: [] xfs_iget [xfs] 0xf3 (0xf3471d10) kernel: [] xfs_iunlock [xfs] 0x5c (0xf3471d3c) kernel: [] xfs_vget [xfs] 0xe5 (0xf3471d50) kernel: [] linvfs_sops [xfs] 0x0 (0xf3471d70) kernel: [] iput [kernel] 0x55 (0xf3471d78) kernel: [] vfs_vget [xfs] 0x43 (0xf3471d84) kernel: [] linvfs_writepage [xfs] 0x79 (0xf3471d9c) kernel: [] fsync_buffers_list [kernel] 0x181 (0xf3471dc8) kernel: [] fs_flush_pages [xfs] 0x49 (0xf3471df8) kernel: [] xfs_vnodeops [xfs] 0x0 (0xf3471e00) kernel: [] xfs_fsync [xfs] 0x2db (0xf3471e08) kernel: [] linvfs_file_operations [xfs] 0x0 (0xf3471e3c) kernel: [] linvfs_fsync [xfs] 0x5f (0xf3471e48) kernel: [] nfsd_sync [nfsd] 0x70 (0xf3471e6c) kernel: [] linvfs_fsync [xfs] 0x0 (0xf3471e88) kernel: [] nfsd_commit [nfsd] 0xa1 (0xf3471e90) kernel: [] linvfs_file_operations [xfs] 0x0 (0xf3471eb8) kernel: [] svc_udp_recvfrom [sunrpc] 0x181 (0xf3471f14) kernel: [] nfsd3_proc_commit [nfsd] 0xa1 (0xf3471f24) kernel: [] nfs3svc_decode_commitargs [nfsd] 0x29 (0xf3471f3c) kernel: [] nfsd_procedures3 [nfsd] 0x2f4 (0xf3471f50) kernel: [] nfsd_version3 [nfsd] 0x0 (0xf3471f58) kernel: [] nfsd_dispatch [nfsd] 0xce (0xf3471f5c) kernel: [] nfsd_procedures3 [nfsd] 0x2f4 (0xf3471f70) kernel: [] svc_process_Rsmp_927b9469 [sunrpc] 0x42f (0xf3471f78) kernel: [] nfsd [nfsd] 0x207 (0xf3471fb0) kernel: [] nfsd_list [nfsd] 0x0 (0xf3471fd0) kernel: [] nfsd [nfsd] 0x0 (0xf3471fe0) kernel: [] kernel_thread_helper [kernel] 0x5 (0xf3471ff0) Some XFS_WANT_CORRUPTED_GOTOs as well: kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1589 of file xfs_alloc.c. Caller 0xf89aca00 kernel: c222fcd0 f89dd6cb 00000008 00000001 00000000 f8a1f144 f8a1c99f 00000635 kernel: f8a1c979 f89aca00 f89ab7af f8a1c99f 00000001 00000000 f8a1c979 00000635 kernel: f89aca00 00000000 00000000 00000000 00000001 00000000 00000100 0004b9c2 kernel: Call Trace: [] xfs_error_report [xfs] 0x5b (0xc222fcd4) kernel: [] .rodata.str1.4 [xfs] 0x274 (0xc222fce4) kernel: [] .rodata.str1.1 [xfs] 0x43 (0xc222fce8) kernel: [] .rodata.str1.1 [xfs] 0x1d (0xc222fcf0) kernel: [] xfs_free_extent [xfs] 0xf0 (0xc222fcf4) kernel: [] xfs_free_ag_extent [xfs] 0x36f (0xc222fcf8) kernel: [] .rodata.str1.1 [xfs] 0x43 (0xc222fcfc) kernel: [] .rodata.str1.1 [xfs] 0x1d (0xc222fd08) kernel: [] xfs_free_extent [xfs] 0xf0 (0xc222fd10) kernel: [] xfs_free_extent [xfs] 0xf0 (0xc222fd4c) kernel: [] kmem_zone_zalloc [xfs] 0xfe (0xc222fd78) kernel: [] xfs_trans_get_efd [xfs] 0x38 (0xc222fda8) kernel: [] xfs_bmap_finish [xfs] 0x138 (0xc222fdc0) kernel: [] xfs_itruncate_finish [xfs] 0x213 (0xc222fdf8) kernel: [] xfs_inactive_free_eofblocks [xfs] 0x293 (0xc222fe74) kernel: [] xfs_inactive [xfs] 0xf9 (0xc222fee8) kernel: [] free_block [kernel] 0x32 (0xc222fefc) kernel: [] vn_remove [xfs] 0x4c (0xc222ff1c) kernel: [] vn_rele [xfs] 0xb1 (0xc222ff30) kernel: [] linvfs_clear_inode [xfs] 0x18 (0xc222ff48) kernel: [] clear_inode [kernel] 0x102 (0xc222ff54) kernel: [] dispose_list [kernel] 0x3c (0xc222ff60) kernel: [] prune_icache [kernel] 0x8d (0xc222ff7c) kernel: [] shrink_icache_memory [kernel] 0x24 (0xc222ffa0) kernel: [] do_try_to_free_pages_kswapd [kernel] 0x168 (0xc222ffac) kernel: [] kswapd [kernel] 0x68 (0xc222ffd0) kernel: [] kswapd [kernel] 0x0 (0xc222ffe4) kernel: [] kernel_thread_helper [kernel] 0x5 (0xc222fff0) Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Thu Jun 16 06:57:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jun 2005 06:57:38 -0700 (PDT) Received: from web1.mmaero.com (web1.mmaero.com [67.98.186.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5GDvXH9007799 for ; Thu, 16 Jun 2005 06:57:34 -0700 Received: from web1.mmaero.com (localhost.localdomain [127.0.0.1]) by web1.mmaero.com (8.12.11/8.12.10) with ESMTP id j5GDuJn3000427 for ; Thu, 16 Jun 2005 09:56:19 -0400 Received: from localhost (jlewis@localhost) by web1.mmaero.com (8.12.11/8.12.11/Submit) with ESMTP id j5GDuJlY000423 for ; Thu, 16 Jun 2005 09:56:19 -0400 X-Authentication-Warning: web1.mmaero.com: jlewis owned process doing -bs Date: Thu, 16 Jun 2005 09:56:19 -0400 (EDT) From: Jon Lewis X-X-Sender: jlewis@web1.mmaero.com To: linux-xfs Subject: Re: xfs_repair hung...safe to terminate? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5460 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlewis@lewis.org Precedence: bulk X-list: linux-xfs Content-Length: 4688 Lines: 105 This xfs_repair did eventually finish after spinning in Phase 5 for a couple hours. Unfortunately, it doesn't appear to have done us any good, and the system is still doing xfs_force_shutdown(md(9,2),0x8) called from line 1071 of file xfs_trans.c. Return address = 0xf8dbe6eb Filesystem "md(9,2)": Corruption of in-memory data detected. Shutting down filesystem: md(9,2) Please umount the filesystem, and rectify the problem(s) pretty frequently. I've tried running a non-SMP kernel, but that didn't help. Next, I decreased the read/write block sizes for the NFS clients mounting this xfs. I don't know yet if that makes any difference. On Wed, 15 Jun 2005, Jon Lewis wrote: > After having a system crash twice today with messages like (from the first > crash): > > xfs_iget_core: ambiguous vns: vp/0xc6f0e680, invp/0xecbed200 > ------------[ cut here ]------------ > kernel BUG at debug.c:106! > invalid operand: 0000 > nfsd lockd sunrpc autofs eepro100 mii ipt_REJECT iptable_filter ip_tables > xfs raid5 xor ext3 jbd raid1 isp_mod sd_mod scsi_mod > CPU: 1 > EIP: 0010:[] Not tainted > EFLAGS: 00010246 > > EIP is at cmn_err [xfs] 0x9e (2.4.20-35_39.rh8.0.atsmp) > eax: 00000000 ebx: 00000000 ecx: 00000096 edx: 00000001 > esi: f8dd9412 edi: f8dec63e ebp: 00000293 esp: f5d2bd44 > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 661, stackpage=f5d2b000) > Stack: f8dd9412 f8dd93e8 f8dec600 ecbed220 7b1f202d 00000000 e4cca100 > f8d8aeac > 00000000 f8dda160 c6f0e680 ecbed200 f65d0c00 7b1f202d f7bfcc38 > c62aea90 > f65d0924 00000000 00000003 c62aea8c 00000000 00000000 e4cca100 > ecbed220 > Call Trace: [] .rodata.str1.1 [xfs] 0x11c2 (0xf5d2bd44)) > [] .rodata.str1.1 [xfs] 0x1198 (0xf5d2bd48)) > [] message [xfs] 0x0 (0xf5d2bd4c)) > [] xfs_iget_core [xfs] 0x45c (0xf5d2bd60)) > [] .rodata.str1.32 [xfs] 0x5a0 (0xf5d2bd68)) > [] xfs_iget [xfs] 0x143 (0xf5d2bdb0)) > [] xfs_vget [xfs] 0x77 (0xf5d2bdf0)) > [] vfs_vget [xfs] 0x43 (0xf5d2be20)) > [] linvfs_fh_to_dentry [xfs] 0x5d (0xf5d2be30)) > [] nfsd_get_dentry [nfsd] 0xb6 (0xf5d2be5c)) > [] find_fh_dentry [nfsd] 0x57 (0xf5d2be80)) > [] fh_verify [nfsd] 0x189 (0xf5d2beb0)) > [] svc_sock_enqueue [sunrpc] 0x1b6 (0xf5d2befc)) > [] nfsd3_proc_getattr [nfsd] 0x6f (0xf5d2bf10)) > [] nfs3svc_decode_fhandle [nfsd] 0x33 (0xf5d2bf28)) > [] nfsd_procedures3 [nfsd] 0x24 (0xf5d2bf3c)) > [] nfsd_dispatch [nfsd] 0xce (0xf5d2bf48)) > [] nfsd_version3 [nfsd] 0x0 (0xf5d2bf5c)) > [] nfsd_dispatch [nfsd] 0x0 (0xf5d2bf60)) > [] svc_process_Rsmp_9d8bc81a [sunrpc] 0x45f (0xf5d2bf64)) > [] nfsd_procedures3 [nfsd] 0x24 (0xf5d2bf84)) > [] nfsd_program [nfsd] 0x0 (0xf5d2bf88)) > [] nfsd [nfsd] 0x224 (0xf5d2bfa4)) > [] arch_kernel_thread [kernel] 0x2e (0xf5d2bff0)) > [] nfsd [nfsd] 0x0 (0xf5d2bff8)) > > > Code: 0f 0b 6a 00 08 94 dd f8 83 c4 0c 5b 5e 5f 5d c3 89 f6 55 b8 > <5>xfs_force_shutdown(md(9,2),0x8) called from line 1071 of file > xfs_trans.c. Return address = 0xf8dbe6eb > Filesystem "md(9,2)": Corruption of in-memory data detected. Shutting > down > filesystem: md(9,2) > Please umount the filesystem, and rectify the problem(s) > > I figured it'd be a good idea to xfs_repair it. That was a little more > than 4 hours ago. The fs is an software RAID5: > md2 : active raid5 sdn2[13] sdg2[12] sdm2[11] sdl2[10] sdk2[9] sdj2[8] > sdi2[7] sdh2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0] > 385414656 blocks level 5, 64k chunk, algorithm 2 [12/12] > [UUUUUUUUUUUU] > md0 : active raid1 sdn1[1] sdg1[0] > 803136 blocks [2/2] [UU] > > xfs_repair [version 2.6.9] has gotten to: > > Phase 5 - rebuild AG headers and trees... > > and seems to have stopped progressing. > > root 798 91.8 1.0 45080 41576 pts/1 R 15:57 242:04 xfs_repair -l /dev/md0 /dev/md2 > > Its still using lots of CPU, but there is no disk activity. Further > searching suggests this might be a kernel issue and not an actual fs > corruption issue. I'd like to upgrade from 2.4.20-35_39.rh8.0.atsmp to > 2.4.20-43_41.rh8.0.atsmp, but the question is, is it safe to stop (kill) > xfs_repair? Will the fs be mountable if I interrupt xfs_repair at this > point? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owner-linux-xfs@oss.sgi.com Thu Jun 16 07:41:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jun 2005 07:41:35 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5GEfUH9010137 for ; Thu, 16 Jun 2005 07:41:30 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.4/8.13.4/Debian-3) with ESMTP id j5GDaHsi013332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Jun 2005 08:36:18 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.4/8.13.4/Submit) with ESMTP id j5GDaHvV013329; Thu, 16 Jun 2005 08:36:17 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Thu, 16 Jun 2005 08:36:16 -0500 (EST) From: Net Llama! To: Jon Lewis cc: linux-xfs Subject: Re: xfs_repair hung...safe to terminate? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Thu, 16 Jun 2005 08:36:19 -0500 Received-SPF: pass (mail.linux-sxs.org: domain of netllama@linux-sxs.org designates 127.0.0.1 as permitted sender) receiver=mail.linux-sxs.org; client-ip=127.0.0.1; helo=mail.linux-sxs.org; envelope-from=netllama@linux-sxs.org; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; X-archive-position: 5461 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 5240 Lines: 117 You realize you're using a truly ancient kernel, right? Are you at least using a relatively current version of xfs-progs? On Thu, 16 Jun 2005, Jon Lewis wrote: > This xfs_repair did eventually finish after spinning in Phase 5 for a > couple hours. Unfortunately, it doesn't appear to have done us any good, > and the system is still doing > > xfs_force_shutdown(md(9,2),0x8) called from line 1071 of file > xfs_trans.c. Return address = 0xf8dbe6eb > Filesystem "md(9,2)": Corruption of in-memory data detected. Shutting down > filesystem: md(9,2) > Please umount the filesystem, and rectify the problem(s) > > pretty frequently. I've tried running a non-SMP kernel, but that didn't > help. Next, I decreased the read/write block sizes for the NFS clients > mounting this xfs. I don't know yet if that makes any difference. > > On Wed, 15 Jun 2005, Jon Lewis wrote: > > > After having a system crash twice today with messages like (from the first > > crash): > > > > xfs_iget_core: ambiguous vns: vp/0xc6f0e680, invp/0xecbed200 > > ------------[ cut here ]------------ > > kernel BUG at debug.c:106! > > invalid operand: 0000 > > nfsd lockd sunrpc autofs eepro100 mii ipt_REJECT iptable_filter ip_tables > > xfs raid5 xor ext3 jbd raid1 isp_mod sd_mod scsi_mod > > CPU: 1 > > EIP: 0010:[] Not tainted > > EFLAGS: 00010246 > > > > EIP is at cmn_err [xfs] 0x9e (2.4.20-35_39.rh8.0.atsmp) > > eax: 00000000 ebx: 00000000 ecx: 00000096 edx: 00000001 > > esi: f8dd9412 edi: f8dec63e ebp: 00000293 esp: f5d2bd44 > > ds: 0018 es: 0018 ss: 0018 > > Process nfsd (pid: 661, stackpage=f5d2b000) > > Stack: f8dd9412 f8dd93e8 f8dec600 ecbed220 7b1f202d 00000000 e4cca100 > > f8d8aeac > > 00000000 f8dda160 c6f0e680 ecbed200 f65d0c00 7b1f202d f7bfcc38 > > c62aea90 > > f65d0924 00000000 00000003 c62aea8c 00000000 00000000 e4cca100 > > ecbed220 > > Call Trace: [] .rodata.str1.1 [xfs] 0x11c2 (0xf5d2bd44)) > > [] .rodata.str1.1 [xfs] 0x1198 (0xf5d2bd48)) > > [] message [xfs] 0x0 (0xf5d2bd4c)) > > [] xfs_iget_core [xfs] 0x45c (0xf5d2bd60)) > > [] .rodata.str1.32 [xfs] 0x5a0 (0xf5d2bd68)) > > [] xfs_iget [xfs] 0x143 (0xf5d2bdb0)) > > [] xfs_vget [xfs] 0x77 (0xf5d2bdf0)) > > [] vfs_vget [xfs] 0x43 (0xf5d2be20)) > > [] linvfs_fh_to_dentry [xfs] 0x5d (0xf5d2be30)) > > [] nfsd_get_dentry [nfsd] 0xb6 (0xf5d2be5c)) > > [] find_fh_dentry [nfsd] 0x57 (0xf5d2be80)) > > [] fh_verify [nfsd] 0x189 (0xf5d2beb0)) > > [] svc_sock_enqueue [sunrpc] 0x1b6 (0xf5d2befc)) > > [] nfsd3_proc_getattr [nfsd] 0x6f (0xf5d2bf10)) > > [] nfs3svc_decode_fhandle [nfsd] 0x33 (0xf5d2bf28)) > > [] nfsd_procedures3 [nfsd] 0x24 (0xf5d2bf3c)) > > [] nfsd_dispatch [nfsd] 0xce (0xf5d2bf48)) > > [] nfsd_version3 [nfsd] 0x0 (0xf5d2bf5c)) > > [] nfsd_dispatch [nfsd] 0x0 (0xf5d2bf60)) > > [] svc_process_Rsmp_9d8bc81a [sunrpc] 0x45f (0xf5d2bf64)) > > [] nfsd_procedures3 [nfsd] 0x24 (0xf5d2bf84)) > > [] nfsd_program [nfsd] 0x0 (0xf5d2bf88)) > > [] nfsd [nfsd] 0x224 (0xf5d2bfa4)) > > [] arch_kernel_thread [kernel] 0x2e (0xf5d2bff0)) > > [] nfsd [nfsd] 0x0 (0xf5d2bff8)) > > > > > > Code: 0f 0b 6a 00 08 94 dd f8 83 c4 0c 5b 5e 5f 5d c3 89 f6 55 b8 > > <5>xfs_force_shutdown(md(9,2),0x8) called from line 1071 of file > > xfs_trans.c. Return address = 0xf8dbe6eb > > Filesystem "md(9,2)": Corruption of in-memory data detected. Shutting > > down > > filesystem: md(9,2) > > Please umount the filesystem, and rectify the problem(s) > > > > I figured it'd be a good idea to xfs_repair it. That was a little more > > than 4 hours ago. The fs is an software RAID5: > > md2 : active raid5 sdn2[13] sdg2[12] sdm2[11] sdl2[10] sdk2[9] sdj2[8] > > sdi2[7] sdh2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0] > > 385414656 blocks level 5, 64k chunk, algorithm 2 [12/12] > > [UUUUUUUUUUUU] > > md0 : active raid1 sdn1[1] sdg1[0] > > 803136 blocks [2/2] [UU] > > > > xfs_repair [version 2.6.9] has gotten to: > > > > Phase 5 - rebuild AG headers and trees... > > > > and seems to have stopped progressing. > > > > root 798 91.8 1.0 45080 41576 pts/1 R 15:57 242:04 xfs_repair -l /dev/md0 /dev/md2 > > > > Its still using lots of CPU, but there is no disk activity. Further > > searching suggests this might be a kernel issue and not an actual fs > > corruption issue. I'd like to upgrade from 2.4.20-35_39.rh8.0.atsmp to > > 2.4.20-43_41.rh8.0.atsmp, but the question is, is it safe to stop (kill) > > xfs_repair? Will the fs be mountable if I interrupt xfs_repair at this > > point? > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Thu Jun 16 07:55:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jun 2005 07:55:47 -0700 (PDT) Received: from web1.mmaero.com (web1.mmaero.com [67.98.186.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5GEtfH9011203 for ; Thu, 16 Jun 2005 07:55:43 -0700 Received: from web1.mmaero.com (localhost.localdomain [127.0.0.1]) by web1.mmaero.com (8.12.11/8.12.10) with ESMTP id j5GErnPd001193; Thu, 16 Jun 2005 10:53:49 -0400 Received: from localhost (jlewis@localhost) by web1.mmaero.com (8.12.11/8.12.11/Submit) with ESMTP id j5GErnpo001189; Thu, 16 Jun 2005 10:53:49 -0400 X-Authentication-Warning: web1.mmaero.com: jlewis owned process doing -bs Date: Thu, 16 Jun 2005 10:53:49 -0400 (EDT) From: Jon Lewis X-X-Sender: jlewis@web1.mmaero.com To: Net Llama! cc: linux-xfs Subject: Re: xfs_repair hung...safe to terminate? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5462 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlewis@lewis.org Precedence: bulk X-list: linux-xfs Content-Length: 6260 Lines: 136 It's an old server. I'm willing to try (have already compiled) 2.4.31 (unmodified source from kernel.org), but from some searches of the archive and SGI's bugzilla, this looks like a long standing unresolved bug affecting xfs in both 2.4 and 2.6 kernels. At this point, I'm mostly curious if anyone has any ideas for solutions/workarounds, or if it's time to simply abandon use of XFS. http://oss.sgi.com/bugzilla/show_bug.cgi?id=375 http://oss.sgi.com/bugzilla/show_bug.cgi?id=272 On Thu, 16 Jun 2005, Net Llama! wrote: > You realize you're using a truly ancient kernel, right? Are you at least > using a relatively current version of xfs-progs? > > On Thu, 16 Jun 2005, Jon Lewis wrote: > > > This xfs_repair did eventually finish after spinning in Phase 5 for a > > couple hours. Unfortunately, it doesn't appear to have done us any good, > > and the system is still doing > > > > xfs_force_shutdown(md(9,2),0x8) called from line 1071 of file > > xfs_trans.c. Return address = 0xf8dbe6eb > > Filesystem "md(9,2)": Corruption of in-memory data detected. Shutting down > > filesystem: md(9,2) > > Please umount the filesystem, and rectify the problem(s) > > > > pretty frequently. I've tried running a non-SMP kernel, but that didn't > > help. Next, I decreased the read/write block sizes for the NFS clients > > mounting this xfs. I don't know yet if that makes any difference. > > > > On Wed, 15 Jun 2005, Jon Lewis wrote: > > > > > After having a system crash twice today with messages like (from the first > > > crash): > > > > > > xfs_iget_core: ambiguous vns: vp/0xc6f0e680, invp/0xecbed200 > > > ------------[ cut here ]------------ > > > kernel BUG at debug.c:106! > > > invalid operand: 0000 > > > nfsd lockd sunrpc autofs eepro100 mii ipt_REJECT iptable_filter ip_tables > > > xfs raid5 xor ext3 jbd raid1 isp_mod sd_mod scsi_mod > > > CPU: 1 > > > EIP: 0010:[] Not tainted > > > EFLAGS: 00010246 > > > > > > EIP is at cmn_err [xfs] 0x9e (2.4.20-35_39.rh8.0.atsmp) > > > eax: 00000000 ebx: 00000000 ecx: 00000096 edx: 00000001 > > > esi: f8dd9412 edi: f8dec63e ebp: 00000293 esp: f5d2bd44 > > > ds: 0018 es: 0018 ss: 0018 > > > Process nfsd (pid: 661, stackpage=f5d2b000) > > > Stack: f8dd9412 f8dd93e8 f8dec600 ecbed220 7b1f202d 00000000 e4cca100 > > > f8d8aeac > > > 00000000 f8dda160 c6f0e680 ecbed200 f65d0c00 7b1f202d f7bfcc38 > > > c62aea90 > > > f65d0924 00000000 00000003 c62aea8c 00000000 00000000 e4cca100 > > > ecbed220 > > > Call Trace: [] .rodata.str1.1 [xfs] 0x11c2 (0xf5d2bd44)) > > > [] .rodata.str1.1 [xfs] 0x1198 (0xf5d2bd48)) > > > [] message [xfs] 0x0 (0xf5d2bd4c)) > > > [] xfs_iget_core [xfs] 0x45c (0xf5d2bd60)) > > > [] .rodata.str1.32 [xfs] 0x5a0 (0xf5d2bd68)) > > > [] xfs_iget [xfs] 0x143 (0xf5d2bdb0)) > > > [] xfs_vget [xfs] 0x77 (0xf5d2bdf0)) > > > [] vfs_vget [xfs] 0x43 (0xf5d2be20)) > > > [] linvfs_fh_to_dentry [xfs] 0x5d (0xf5d2be30)) > > > [] nfsd_get_dentry [nfsd] 0xb6 (0xf5d2be5c)) > > > [] find_fh_dentry [nfsd] 0x57 (0xf5d2be80)) > > > [] fh_verify [nfsd] 0x189 (0xf5d2beb0)) > > > [] svc_sock_enqueue [sunrpc] 0x1b6 (0xf5d2befc)) > > > [] nfsd3_proc_getattr [nfsd] 0x6f (0xf5d2bf10)) > > > [] nfs3svc_decode_fhandle [nfsd] 0x33 (0xf5d2bf28)) > > > [] nfsd_procedures3 [nfsd] 0x24 (0xf5d2bf3c)) > > > [] nfsd_dispatch [nfsd] 0xce (0xf5d2bf48)) > > > [] nfsd_version3 [nfsd] 0x0 (0xf5d2bf5c)) > > > [] nfsd_dispatch [nfsd] 0x0 (0xf5d2bf60)) > > > [] svc_process_Rsmp_9d8bc81a [sunrpc] 0x45f (0xf5d2bf64)) > > > [] nfsd_procedures3 [nfsd] 0x24 (0xf5d2bf84)) > > > [] nfsd_program [nfsd] 0x0 (0xf5d2bf88)) > > > [] nfsd [nfsd] 0x224 (0xf5d2bfa4)) > > > [] arch_kernel_thread [kernel] 0x2e (0xf5d2bff0)) > > > [] nfsd [nfsd] 0x0 (0xf5d2bff8)) > > > > > > > > > Code: 0f 0b 6a 00 08 94 dd f8 83 c4 0c 5b 5e 5f 5d c3 89 f6 55 b8 > > > <5>xfs_force_shutdown(md(9,2),0x8) called from line 1071 of file > > > xfs_trans.c. Return address = 0xf8dbe6eb > > > Filesystem "md(9,2)": Corruption of in-memory data detected. Shutting > > > down > > > filesystem: md(9,2) > > > Please umount the filesystem, and rectify the problem(s) > > > > > > I figured it'd be a good idea to xfs_repair it. That was a little more > > > than 4 hours ago. The fs is an software RAID5: > > > md2 : active raid5 sdn2[13] sdg2[12] sdm2[11] sdl2[10] sdk2[9] sdj2[8] > > > sdi2[7] sdh2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0] > > > 385414656 blocks level 5, 64k chunk, algorithm 2 [12/12] > > > [UUUUUUUUUUUU] > > > md0 : active raid1 sdn1[1] sdg1[0] > > > 803136 blocks [2/2] [UU] > > > > > > xfs_repair [version 2.6.9] has gotten to: > > > > > > Phase 5 - rebuild AG headers and trees... > > > > > > and seems to have stopped progressing. > > > > > > root 798 91.8 1.0 45080 41576 pts/1 R 15:57 242:04 xfs_repair -l /dev/md0 /dev/md2 > > > > > > Its still using lots of CPU, but there is no disk activity. Further > > > searching suggests this might be a kernel issue and not an actual fs > > > corruption issue. I'd like to upgrade from 2.4.20-35_39.rh8.0.atsmp to > > > 2.4.20-43_41.rh8.0.atsmp, but the question is, is it safe to stop (kill) > > > xfs_repair? Will the fs be mountable if I interrupt xfs_repair at this > > > point? > > > > ---------------------------------------------------------------------- > > Jon Lewis | I route > > Senior Network Engineer | therefore you are > > Atlantic Net | > > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Lonni J Friedman netllama@linux-sxs.org > LlamaLand http://netllama.linux-sxs.org > ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owner-linux-xfs@oss.sgi.com Thu Jun 16 08:22:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jun 2005 08:22:53 -0700 (PDT) Received: from locomotive.unixthugs.org (locomotive.csh.rit.edu [129.21.60.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5GFMaH9016142 for ; Thu, 16 Jun 2005 08:22:37 -0700 Received: from [192.168.1.13] (208-186-49-45.nrp3feld.roc.ny.frontiernet.net [208.186.49.45]) by locomotive.unixthugs.org (Postfix) with ESMTP id A070F656F4; Thu, 16 Jun 2005 11:21:13 -0400 (EDT) Message-ID: <42B198E7.80100@suse.com> Date: Thu, 16 Jun 2005 11:21:11 -0400 From: Jeff Mahoney User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Chinner Cc: Hans Reiser , fs , Linus Torvalds , Andrew Morton , viro VFS , linux-fsdevel , linux-kernel , zhiming@admin.iscas.ac.cn, qufuping@ercist.iscas.ac.cn, madsys@ercist.iscas.ac.cn, xuh@nttdata.com.cn, koichi@intellilink.co.jp, kuroiwaj@intellilink.co.jp, okuyama@intellilink.co.jp, matsui_v@valinux.co.jp, kikuchi_v@valinux.co.jp, fernando@intellilink.co.jp, kskmori@intellilink.co.jp, takenakak@intellilink.co.jp, yamaguchi@intellilink.co.jp, ext2-devel@lists.sourceforge.net, sct@redhat.com, shaggy@austin.ibm.com, linux-xfs@oss.sgi.com, Reiserfs developers mail-list Subject: Re: [RFD] FS behavior (I/O failure) in kernel summit References: <1118692436.2512.157.camel@CoolQ> <42ADC99D.5000801@namesys.com> <42ADFFD5.1090905@suse.com> <42AE1EE4.5090508@namesys.com> <42B067B6.9030009@suse.com> <20050616121822.E125706@melbourne.sgi.com> In-Reply-To: <20050616121822.E125706@melbourne.sgi.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 5463 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffm@suse.com Precedence: bulk X-list: linux-xfs Content-Length: 1597 Lines: 44 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Chinner wrote: >>Well it seems to me that all the XFS code does is check to see if the FS >>is in a shutdown state really early in the call path. > > FYI, the up front checks in XFS are simply to stop new I/O from starting > if we're already in the shutdown state. > > However, there's more than that in XFS - there's checks all through > it's I/O paths so that I/Os and transactions in flight at (or > started after) the time of the shutdown can be aborted before doing > further damage to a potentially corrupted filesystem. This part > cannot be done generically as it is intimately tied to the > filesystem. > > It is also worth noting that XFS won't shutdown a filesystem on just > any I/O error. Shutdowns due to I/O errors only occur when the > failure has the potential to leave the filesystem in an inconsistent > state. Hence any given operation can return different errors > depending on where the I/O error occurred in XFS and what effect > that I/O error has on the consistency of the filesystem..... Sorry, I should have clarified. I was only refering to the handling of operations that aren't already in flight. Currently, ReiserFS (and ext3) will set the filesystem read-only on error, which ends up returning -EROFS in situations where that error code is correct, but not entirely appropriate. - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCsZjnLPWxlyuTD7IRAuk5AKCplbYsl3YFml9/M1GRtuvBz21jvwCgoWKn Mpl0khchSkQ1RwI/mkZ8buY= =DxvJ -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Jun 16 08:48:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jun 2005 08:48:06 -0700 (PDT) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5GFm0H9017447 for ; Thu, 16 Jun 2005 08:48:01 -0700 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 19AFBFB67B; Thu, 16 Jun 2005 17:46:44 +0200 (CEST) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jun 2005 17:46:43 +0200 From: Anders Saaby Organization: Cohaesio A/S To: KELEMEN Peter Subject: Re: XFS_WANT_CORRUPTED_GOTO Error (XFS Log crashed) (contains debug log) Date: Thu, 16 Jun 2005 17:46:43 +0200 User-Agent: KMail/1.8.1 Cc: linux-xfs@oss.sgi.com References: <1118849122.5058.60.camel@hal-9006> <20050616091938.GF26297@inara.maison.net> In-Reply-To: <20050616091938.GF26297@inara.maison.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506161746.43590.as@cohaesio.com> X-OriginalArrivalTime: 16 Jun 2005 15:46:44.0019 (UTC) FILETIME=[988A7030:01C5728A] X-archive-position: 5464 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Content-Length: 760 Lines: 25 On Thursday 16 June 2005 11:19, KELEMEN Peter wrote: > We also see error messages like: > XFS internal error XFS_WANT_CORRUPTED_RETURN at line 310 of file > xfs_alloc.c. ...with much more complicated stack traces. Are you able to run a clean xfs_repair on this filesystem? Does this server have ECC memory? - I have seen quite a lot af these errors earlier - replacing non-ECC with ECC memory did the trick. /My 5 cents. -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs@oss.sgi.com Thu Jun 16 17:11:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jun 2005 17:11:25 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5H0BJH9020301 for ; Thu, 16 Jun 2005 17:11:20 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10495; Fri, 17 Jun 2005 10:09:57 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5H09vkt2173732; Fri, 17 Jun 2005 10:09:57 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j5H09rOQ2199126; Fri, 17 Jun 2005 10:09:53 +1000 (EST) Date: Fri, 17 Jun 2005 10:09:53 +1000 From: Nathan Scott To: Jon Lewis Cc: Net Llama! , linux-xfs Subject: Re: xfs_repair hung...safe to terminate? Message-ID: <20050617100953.I2141098@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jlewis@lewis.org on Thu, Jun 16, 2005 at 10:53:49AM -0400 X-archive-position: 5465 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 959 Lines: 23 On Thu, Jun 16, 2005 at 10:53:49AM -0400, Jon Lewis wrote: > It's an old server. I'm willing to try (have already compiled) 2.4.31 > (unmodified source from kernel.org), but from some searches of the archive > and SGI's bugzilla, this looks like a long standing unresolved bug > affecting xfs in both 2.4 and 2.6 kernels. At this point, I'm mostly > curious if anyone has any ideas for solutions/workarounds, or if it's time > to simply abandon use of XFS. Upgrading your kernel is your best bet. CVS on oss.sgi.com is always very stable these days, and kernel.org always lags it slightly (of course) so I'd recommend using CVS. There were a series of xfs_iget related races that Christoph plugged several months ago. Most, if not all, of these are now resolved - we have one/two reports of people running stress for several days and then finally tripping over this issue, but we have been unable to reproduce that problem so far. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Jun 17 07:03:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jun 2005 07:03:14 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5HE38H9025218 for ; Fri, 17 Jun 2005 07:03:10 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5HFovq5017598 for ; Fri, 17 Jun 2005 08:50:57 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5HE1q0F17121222; Fri, 17 Jun 2005 09:01:52 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DjHPr-0005UT-00; Fri, 17 Jun 2005 09:01:51 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 938062 - consolidate extent item freeing Message-Id: From: Christoph Hellwig Date: Fri, 17 Jun 2005 09:01:51 -0500 X-archive-position: 5467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 821 Lines: 23 Date: Fri Jun 17 07:01:39 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:194415a fs/xfs/xfs_extfree_item.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h - consolidate extent item freeing fs/xfs/xfs_extfree_item.c - 1.59 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.c.diff?r1=text&tr1=1.59&r2=text&tr2=1.58&f=h - consolidate extent item freeing fs/xfs/xfs_log_recover.c - 1.297 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.297&r2=text&tr2=1.296&f=h - consolidate extent item freeing From owner-linux-xfs@oss.sgi.com Fri Jun 17 07:15:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jun 2005 07:15:06 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5HEF1H9026008 for ; Fri, 17 Jun 2005 07:15:01 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5HEDkxT029053 for ; Fri, 17 Jun 2005 09:13:46 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5HEDjR010393722; Fri, 17 Jun 2005 09:13:45 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DjHbN-0005zo-00; Fri, 17 Jun 2005 09:13:45 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 938063 - simplify ASSERT Message-Id: From: Christoph Hellwig Date: Fri, 17 Jun 2005 09:13:45 -0500 X-archive-position: 5468 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 952 Lines: 27 Date: Fri Jun 17 07:13:33 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: felixb,nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:194416a fs/xfs/support/debug.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h - simplify ASSERT fs/xfs/support/debug.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h - simplify ASSERT fs/xfs/linux-2.6/xfs_ksyms.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h - simplify ASSERT fs/xfs/linux-2.4/xfs_ksyms.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h - simplify ASSERT From owner-linux-xfs@oss.sgi.com Fri Jun 17 07:35:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jun 2005 07:35:31 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5HEZQH9028219 for ; Fri, 17 Jun 2005 07:35:26 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5HGNFjC025474 for ; Fri, 17 Jun 2005 09:23:16 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5HEYA0F17123187; Fri, 17 Jun 2005 09:34:10 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DjHv8-0006jD-00; Fri, 17 Jun 2005 09:34:10 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 938064 - (mostly) remove xfs_inval_cached_pages Message-Id: From: Christoph Hellwig Date: Fri, 17 Jun 2005 09:34:10 -0500 X-archive-position: 5469 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1658 Lines: 40 Since the last round of direct I/O locking changes it is just a wrapper around VOP_FLUSHINVAL_PAGES, so it's not nessecary anymore. Keep a simplified version for kernels < 2.4.22, as these don't have the changed direct I/O locking. Date: Fri Jun 17 07:33:58 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:194420a fs/xfs/xfs_vnodeops.c - 1.646 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.646&r2=text&tr2=1.645&f=h - (mostly) remove xfs_inval_cached_pages fs/xfs/xfs_dfrag.c - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dfrag.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h - (mostly) remove xfs_inval_cached_pages fs/xfs/linux-2.6/xfs_lrw.h - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h - (mostly) remove xfs_inval_cached_pages fs/xfs/linux-2.6/xfs_lrw.c - 1.225 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.225&r2=text&tr2=1.224&f=h - (mostly) remove xfs_inval_cached_pages fs/xfs/linux-2.4/xfs_lrw.h - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.h.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h - (mostly) remove xfs_inval_cached_pages fs/xfs/linux-2.4/xfs_lrw.c - 1.221 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.c.diff?r1=text&tr1=1.221&r2=text&tr2=1.220&f=h - (mostly) remove xfs_inval_cached_pages From owner-linux-xfs@oss.sgi.com Sat Jun 18 09:42:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 18 Jun 2005 09:42:48 -0700 (PDT) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5IGghH9031845 for ; Sat, 18 Jun 2005 09:42:43 -0700 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id j5IGfOrC021466 for ; Sat, 18 Jun 2005 12:41:24 -0400 (EDT) Date: Sat, 18 Jun 2005 12:41:24 -0400 (EDT) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: XFS_WANT_CORRUPTED_RETURN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 1478 Lines: 29 Hi, I encounter the attached messages in the system logs. This is on a remote machine that I have to manage, about 4000 miles away, thus which I can not access. I'd like to take the best action possible. Please advise.... RH9.0 linux with 2.4.22 kernel, XFS, on i386 UP PIII 1GHz. Has been running for more than a year rock stable. Cheers, Gaspar --------------------------- Jun 18 09:25:06 hat5 kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 317 of file xfs_alloc.c. Caller 0xc0175bd4 Jun 18 09:25:06 hat5 kernel: c8dcf9e8 c0174a9c c031c40c 00000001 00000000 c031c400 0000013d c0175bd4 Jun 18 09:25:06 hat5 kernel: 00000000 00000000 00000000 00000000 c8dcfba4 cd1f40c0 c8dcfa90 c0175bd4 Jun 18 09:25:06 hat5 kernel: cd1f40c0 cd1f4144 00019924 00000036 00019930 00000004 00000002 00019930 Jun 18 09:25:06 hat5 kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [ ] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] ... rebooted remotely Jun 18 09:30:05 hat5 kernel: SGI XFS snapshot-2.4.22-2003-10-10_04:57_UTC with ACLs, no debug enabled Jun 18 09:30:05 hat5 kernel: SGI XFS Quota Management subsystem From owner-linux-xfs@oss.sgi.com Sun Jun 19 08:36:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jun 2005 08:36:30 -0700 (PDT) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5JFaNH9016949 for ; Sun, 19 Jun 2005 08:36:24 -0700 Received: from inara.maison.net (lns-th2-1-gre-82-64-0-69.adsl.proxad.net [82.64.0.69]) by postfix3-1.free.fr (Postfix) with ESMTP id BCB181734C8 for ; Sun, 19 Jun 2005 17:35:04 +0200 (CEST) Received: by inara.maison.net (Postfix, from userid 32266) id 485D95A66C; Sun, 19 Jun 2005 17:35:04 +0200 (CEST) Date: Sun, 19 Jun 2005 17:35:04 +0200 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: Re: XFS_WANT_CORRUPTED_GOTO Error (XFS Log crashed) (contains debug log) Message-ID: <20050619153504.GE28987@inara.maison.net> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1118849122.5058.60.camel@hal-9006> <20050616091938.GF26297@inara.maison.net> <200506161746.43590.as@cohaesio.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200506161746.43590.as@cohaesio.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.9i X-archive-position: 5474 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: linux-xfs Content-Length: 488 Lines: 18 * Anders Saaby (as@cohaesio.com) [20050616 17:46]: > Are you able to run a clean xfs_repair on this filesystem? Yes. > Does this server have ECC memory? No clue, have to visually inspect it (at least dmidecode doesn't especially say the memory bank is ECC). Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Sun Jun 19 11:06:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jun 2005 11:06:16 -0700 (PDT) Received: from poros.telenet-ops.be (poros.telenet-ops.be [195.130.132.44]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5JI6AH9022268 for ; Sun, 19 Jun 2005 11:06:11 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by poros.telenet-ops.be (Postfix) with SMTP id AF3153BC09D; Sun, 19 Jun 2005 20:04:50 +0200 (MEST) Received: from precious.kicks-ass.org (dD5E00CD8.access.telenet.be [213.224.12.216]) by poros.telenet-ops.be (Postfix) with ESMTP id 576DB3BC156; Sun, 19 Jun 2005 20:04:50 +0200 (MEST) Received: from precious.kicks-ass.org ([127.0.0.1] ident=6946e4c97d0f2ad123315432485a1ff5) by precious.kicks-ass.org with esmtp (Exim 4.51) id 1Dk3E2-0002ar-B7; Sun, 19 Jun 2005 19:04:50 +0200 From: Jan De Luyck To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6.12] XFS: Undeletable directory Date: Sun, 19 Jun 2005 19:04:49 +0200 User-Agent: KMail/1.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506191904.49639.lkml@kcore.org> X-archive-position: 5475 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@kcore.org Precedence: bulk X-list: linux-xfs Content-Length: 666 Lines: 32 Hello lists, I've had some XFS troubles today, and after cleaning up with xfs_repair and so I'm stuck with one undeletable directory in /lost+found: precious:/lost+found# ls -l total 8 drwxrwxrwx 2 root root 8192 Jun 19 2005 4207214 precious:/lost+found# rm -r 4207214 rm: cannot remove directory `4207214': Directory not empty precious:/lost+found# ls -l 4207214/ total 0 precious:/lost+found# So there's one dir 4207214 there, and i can rename it and whatever, just not remove it. xfs_repair didn't solve the problem. Any ideas? Thanks, Jan -- *** ******* ********* ****** Confucious say: "Is stuffy inside fortune cookie." ******* *** From owner-linux-xfs@oss.sgi.com Sun Jun 19 12:35:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jun 2005 12:35:39 -0700 (PDT) Received: from poros.telenet-ops.be (poros.telenet-ops.be [195.130.132.44]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5JJZaH9030021 for ; Sun, 19 Jun 2005 12:35:36 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by poros.telenet-ops.be (Postfix) with SMTP id 90A433BC207; Sun, 19 Jun 2005 21:34:18 +0200 (MEST) Received: from precious.kicks-ass.org (dD5E00CD8.access.telenet.be [213.224.12.216]) by poros.telenet-ops.be (Postfix) with ESMTP id 6BC183BC0F2; Sun, 19 Jun 2005 21:34:18 +0200 (MEST) Received: from precious.kicks-ass.org ([127.0.0.1] ident=7bd66e52449adbdc34877716ae1dcc72) by precious.kicks-ass.org with esmtp (Exim 4.51) id 1Dk4cd-0002oR-3N; Sun, 19 Jun 2005 20:34:19 +0200 From: Jan De Luyck To: Edwin Eefting Subject: Re: [2.6.12] XFS: Undeletable directory Date: Sun, 19 Jun 2005 20:34:18 +0200 User-Agent: KMail/1.8.1 Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <200506191904.49639.lkml@kcore.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506192034.18690.lkml@kcore.org> X-archive-position: 5477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@kcore.org Precedence: bulk X-list: linux-xfs Content-Length: 401 Lines: 18 On Sunday 19 June 2005 21:25, Edwin Eefting wrote: > ls -la 4207214/ also shows nothing? > perhaps there's something weirds thats hidden. > Nothing out of the ordinary: devilkin@precious:/lost+found$ ls -la 4207214/ total 8 drwxrwxrwx 2 root root 8192 Jun 19 2005 . drwxr-xr-x 3 root root 20 Jun 19 2005 .. devilkin@precious:/lost+found$ Jan -- We are not anticipating any emergencies. From owner-linux-xfs@oss.sgi.com Sun Jun 19 12:34:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jun 2005 12:34:06 -0700 (PDT) Received: from kantoor.datux.nl ([212.203.31.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5JJY2H9029837 for ; Sun, 19 Jun 2005 12:34:02 -0700 Received: (qmail 18870 invoked by uid 115); 19 Jun 2005 19:15:44 -0000 Received: from unknown ([127.0.0.1]) by localhost (kantoor [127.0.0.1]) (amavisd-new, port 628) id 08538-04; Sun, 19 Jun 2005 21:15:44 +0200 (CEST) Received: from iedereen.moet.overstappennaarlinux.nl (195.169.61.235) by kantoor.datux.nl with SMTP; 19 Jun 2005 19:15:44 -0000 Date: Sun, 19 Jun 2005 19:25:56 +0000 (Local time zone must be set--see zic manual page) From: Edwin Eefting X-X-Sender: psy@hobbybop To: Jan De Luyck cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.12] XFS: Undeletable directory In-Reply-To: <200506191904.49639.lkml@kcore.org> Message-ID: References: <200506191904.49639.lkml@kcore.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 5476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: psy@datux.nl Precedence: bulk X-list: linux-xfs Content-Length: 884 Lines: 45 ls -la 4207214/ also shows nothing? perhaps there's something weirds thats hidden. On Sun, 19 Jun 2005, Jan De Luyck wrote: > Hello lists, > > I've had some XFS troubles today, and after cleaning up with xfs_repair and so > I'm stuck with one undeletable directory in /lost+found: > > precious:/lost+found# ls -l > total 8 > drwxrwxrwx 2 root root 8192 Jun 19 2005 4207214 > precious:/lost+found# rm -r 4207214 > rm: cannot remove directory `4207214': Directory not empty > precious:/lost+found# ls -l 4207214/ > total 0 > precious:/lost+found# > > So there's one dir 4207214 there, and i can rename it and whatever, just not > remove it. > > xfs_repair didn't solve the problem. > > Any ideas? > > Thanks, > > Jan > -- > *** > ******* > ********* > ****** Confucious say: "Is stuffy inside fortune cookie." > ******* > *** > > > > !DSPAM:42b5b179178417078914163! > > > From owner-linux-xfs@oss.sgi.com Sun Jun 19 16:03:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jun 2005 16:04:04 -0700 (PDT) Received: from h80ad2661.async.vt.edu (h80ad2661.async.vt.edu [128.173.38.97]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5JN3tH9004167 for ; Sun, 19 Jun 2005 16:03:57 -0700 Received: from turing-police.cc.vt.edu (localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.13.4/8.13.4) with ESMTP id j5JN2M5P009849; Sun, 19 Jun 2005 19:02:22 -0400 Message-Id: <200506192302.j5JN2M5P009849@turing-police.cc.vt.edu> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.1-RC3 To: Jan De Luyck Cc: Edwin Eefting , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.12] XFS: Undeletable directory In-Reply-To: Your message of "Sun, 19 Jun 2005 20:34:18 +0200." <200506192034.18690.lkml@kcore.org> From: Valdis.Kletnieks@vt.edu References: <200506191904.49639.lkml@kcore.org> <200506192034.18690.lkml@kcore.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1119222140_7087P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 19 Jun 2005 19:02:21 -0400 X-archive-position: 5478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Valdis.Kletnieks@vt.edu Precedence: bulk X-list: linux-xfs Content-Length: 1103 Lines: 35 --==_Exmh_1119222140_7087P Content-Type: text/plain; charset=us-ascii On Sun, 19 Jun 2005 20:34:18 +0200, Jan De Luyck said: > On Sunday 19 June 2005 21:25, Edwin Eefting wrote: > > ls -la 4207214/ also shows nothing? > Nothing out of the ordinary: > > devilkin@precious:/lost+found$ ls -la 4207214/ > total 8 > drwxrwxrwx 2 root root 8192 Jun 19 2005 . > drwxr-xr-x 3 root root 20 Jun 19 2005 .. Might want to do 'ls -lai' to get the inode numbers for . and .. and then go sanity check them ('.' should have the same inode number as lost+found/4207214, and '..' should have the same inode number as lost+found) (and yes, I *know* fsck should whinge loudly if this is the case. Wouldn't be the first time I've seen an fsck fail to pick up on obvious corruption...) --==_Exmh_1119222140_7087P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFCtfl8cC3lWbTT17ARAnbIAJ4nFX/5XX57+dudJNxdU+Vtc5CQXACfTtoR 5ugck2GH9ITwOPO285ZSEqg= =JRxM -----END PGP SIGNATURE----- --==_Exmh_1119222140_7087P-- From owner-linux-xfs@oss.sgi.com Sun Jun 19 17:20:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jun 2005 17:20:15 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5K0KAH9010889 for ; Sun, 19 Jun 2005 17:20:11 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA17987; Mon, 20 Jun 2005 10:18:48 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id B4C3A49AC162; Mon, 20 Jun 2005 10:22:55 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 938145 - quota cleanups Message-Id: <20050620002255.B4C3A49AC162@chook.melbourne.sgi.com> Date: Mon, 20 Jun 2005 10:22:55 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3321 Lines: 72 Makes more sense to use the fsxattr interface instead of adding new ioctls for project IDs. Date: Mon Jun 20 10:13:14 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22899a xfs_fs.h - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fs.h.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h linux-2.6/xfs_ioctl.c - 1.121 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.121&r2=text&tr2=1.120&f=h linux-2.4/xfs_ioctl.c - 1.116 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.116&r2=text&tr2=1.115&f=h linux-2.6/xfs_ioctl32.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl32.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h Merge fixes into realtime quota code, since one/two bugs reported from code inspection; its still not enabled though. Date: Mon Jun 20 10:15:19 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22900a xfsidbg.c - 1.275 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.275&r2=text&tr2=1.274&f=h xfs_vnodeops.c - 1.647 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.647&r2=text&tr2=1.646&f=h xfs_bmap.c - 1.325 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.325&r2=text&tr2=1.324&f=h xfs_quota.h - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_quota.h.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h quota/xfs_trans_dquot.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_trans_dquot.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h quota/xfs_quota_priv.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_quota_priv.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h quota/xfs_qm.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h quota/xfs_qm.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h xfs_iomap.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h Merge a few minor fixes to the quota warning code. Date: Mon Jun 20 10:17:51 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22901a quota/xfs_qm_syscalls.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h quota/xfs_dquot.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h quota/xfs_qm.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h From owner-linux-xfs@oss.sgi.com Sun Jun 19 17:24:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jun 2005 17:24:46 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5K0OeH9011951 for ; Sun, 19 Jun 2005 17:24:40 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18094; Mon, 20 Jun 2005 10:23:19 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id BC72F49AC162; Mon, 20 Jun 2005 10:27:27 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 938145 - remove projid ioctls Message-Id: <20050620002727.BC72F49AC162@chook.melbourne.sgi.com> Date: Mon, 20 Jun 2005 10:27:27 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5480 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 626 Lines: 16 Switch to using fsxattr instead of special projid ioctls. Date: Mon Jun 20 10:22:54 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22902a xfsprogs/include/xfs_fs.h - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_fs.h.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h xfsprogs/libxcmd/projects.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxprojects.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs@oss.sgi.com Sun Jun 19 17:27:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jun 2005 17:27:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5K0RFH9012818 for ; Sun, 19 Jun 2005 17:27:16 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18158; Mon, 20 Jun 2005 10:25:54 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id D79D149AC162; Mon, 20 Jun 2005 10:30:02 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 907001 - make blocktrash expert-mode only Message-Id: <20050620003002.D79D149AC162@chook.melbourne.sgi.com> Date: Mon, 20 Jun 2005 10:30:02 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5481 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 472 Lines: 14 Make blocktrash an expert-mode-only xfs_db command since its dangerous. Date: Mon Jun 20 10:24:48 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22903a xfsprogs/db/check.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/check.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h From owner-linux-xfs@oss.sgi.com Mon Jun 20 00:12:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jun 2005 00:12:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5K7ChH9004215 for ; Mon, 20 Jun 2005 00:12:44 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA26024; Mon, 20 Jun 2005 17:11:19 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5K7BLkt2288400; Mon, 20 Jun 2005 17:11:22 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j5K751O7002132; Mon, 20 Jun 2005 17:05:02 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j5K74x6r002130; Mon, 20 Jun 2005 17:05:00 +1000 Date: Mon, 20 Jun 2005 17:04:59 +1000 From: Nathan Scott To: Jan De Luyck Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.12] XFS: Undeletable directory Message-ID: <20050620070459.GB1549@frodo> References: <200506191904.49639.lkml@kcore.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506191904.49639.lkml@kcore.org> User-Agent: Mutt/1.5.3i X-archive-position: 5482 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1277 Lines: 41 On Sun, Jun 19, 2005 at 07:04:49PM +0200, Jan De Luyck wrote: > Hello lists, > > I've had some XFS troubles today, and after cleaning up with xfs_repair and so > I'm stuck with one undeletable directory in /lost+found: > > precious:/lost+found# ls -l > total 8 > drwxrwxrwx 2 root root 8192 Jun 19 2005 4207214 > precious:/lost+found# rm -r 4207214 > rm: cannot remove directory `4207214': Directory not empty > precious:/lost+found# ls -l 4207214/ > total 0 > precious:/lost+found# > > So there's one dir 4207214 there, and i can rename it and whatever, just not > remove it. > > xfs_repair didn't solve the problem. > > Any ideas? What does: xfs_db -r -c 'inode 4207214' -c print /dev/XXX report? I have seen a similar thing once before, awhile back, where the directory inode was "empty" (only . and ..) and hence should've been in shortform, but other fields indicated the inode was in extent form still. Never got to the bottom of it... I'd guess there's somehow a case where the kernel XFS code can miss this transformation - not sure where/how though. If it comes to it, you can always zero out individual inode fields for that inode in xfs_db (with -x option to enable write mode) and then xfs_repair should be able to get past it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jun 20 03:21:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jun 2005 03:21:51 -0700 (PDT) Received: from outmx007.isp.belgacom.be (outmx007.isp.belgacom.be [195.238.3.234]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5KALjH9021673 for ; Mon, 20 Jun 2005 03:21:46 -0700 Received: from outmx007.isp.belgacom.be (localhost [127.0.0.1]) by outmx007.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j5KAKMqe028278 for ; Mon, 20 Jun 2005 12:20:23 +0200 (envelope-from ) Received: from precious.kicks-ass.org (92-157.241.81.adsl.skynet.be [81.241.157.92]) by outmx007.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j5KAKKAI028243; Mon, 20 Jun 2005 12:20:20 +0200 (envelope-from ) Received: from precious.kicks-ass.org ([127.0.0.1] ident=d6094ea18ff4b2c4f39dabc571766e56) by precious.kicks-ass.org with esmtp (Exim 4.51) id 1DkJO9-0004Xb-Gg; Mon, 20 Jun 2005 12:20:21 +0200 From: Jan De Luyck To: linux-kernel@vger.kernel.org Subject: Re: [2.6.12] XFS: Undeletable directory Date: Mon, 20 Jun 2005 12:20:20 +0200 User-Agent: KMail/1.8.1 Cc: Valdis.Kletnieks@vt.edu, Edwin Eefting , linux-xfs@oss.sgi.com References: <200506191904.49639.lkml@kcore.org> <200506192034.18690.lkml@kcore.org> <200506192302.j5JN2M5P009849@turing-police.cc.vt.edu> In-Reply-To: <200506192302.j5JN2M5P009849@turing-police.cc.vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506201220.20703.lkml@kcore.org> X-archive-position: 5483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@kcore.org Precedence: bulk X-list: linux-xfs Content-Length: 765 Lines: 25 On Monday 20 June 2005 01:02, Valdis.Kletnieks@vt.edu wrote: > On Sun, 19 Jun 2005 20:34:18 +0200, Jan De Luyck said: > > On Sunday 19 June 2005 21:25, Edwin Eefting wrote: > > > ls -la 4207214/ also shows nothing? > > > > Nothing out of the ordinary: > > > > devilkin@precious:/lost+found$ ls -la 4207214/ > > total 8 > > drwxrwxrwx 2 root root 8192 Jun 19 2005 . > > drwxr-xr-x 3 root root 20 Jun 19 2005 .. > > Might want to do 'ls -lai' to get the inode numbers for . and .. and > then go sanity check them ('.' should have the same inode number as > lost+found/4207214, and '..' should have the same inode number as > lost+found) The inode numbers are correct. Jan -- If the very old will remember, the very young will listen. -- Chief Dan George From owner-linux-xfs@oss.sgi.com Mon Jun 20 03:26:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jun 2005 03:26:47 -0700 (PDT) Received: from outmx012.isp.belgacom.be (outmx012.isp.belgacom.be [195.238.3.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5KAQhH9022169 for ; Mon, 20 Jun 2005 03:26:44 -0700 Received: from outmx012.isp.belgacom.be (localhost [127.0.0.1]) by outmx012.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j5KAPHBl014595 for ; Mon, 20 Jun 2005 12:25:17 +0200 (envelope-from ) Received: from precious.kicks-ass.org (92-157.241.81.adsl.skynet.be [81.241.157.92]) by outmx012.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j5KAPA6r014510; Mon, 20 Jun 2005 12:25:10 +0200 (envelope-from ) Received: from precious.kicks-ass.org ([127.0.0.1] ident=8586b5200f1df0ec385853c409a35e62) by precious.kicks-ass.org with esmtp (Exim 4.51) id 1DkJSp-0004nm-E4; Mon, 20 Jun 2005 12:25:11 +0200 From: Jan De Luyck To: linux-kernel@vger.kernel.org Subject: Re: [2.6.12] XFS: Undeletable directory Date: Mon, 20 Jun 2005 12:25:10 +0200 User-Agent: KMail/1.8.1 Cc: Nathan Scott , linux-xfs@oss.sgi.com References: <200506191904.49639.lkml@kcore.org> <20050620070459.GB1549@frodo> In-Reply-To: <20050620070459.GB1549@frodo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506201225.11129.lkml@kcore.org> X-archive-position: 5484 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@kcore.org Precedence: bulk X-list: linux-xfs Content-Length: 1450 Lines: 56 On Monday 20 June 2005 09:04, Nathan Scott wrote: > What does: xfs_db -r -c 'inode 4207214' -c print /dev/XXX > report? precious:/lost+found/4207214# xfs_db -r -c 'inode 4207214' -c print /dev/hda6 core.magic = 0x494e core.mode = 040777 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 2 core.uid = 0 core.gid = 0 core.flushiter = 275 core.atime.sec = Sun Jun 19 20:38:29 2005 core.atime.nsec = 790399992 core.mtime.sec = Sun Jun 19 20:37:45 2005 core.mtime.nsec = 608116720 core.ctime.sec = Sun Jun 19 20:38:16 2005 core.ctime.nsec = 795375536 core.size = 8192 core.nblocks = 2 core.extsize = 0 core.nextents = 2 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.rtinherit = 0 core.projinherit = 0 core.nosymlinks = 0 core.gen = 0 next_unlinked = null u.bmx[0-1] = [startoff,startblock,blockcount,extentflag] 0:[1,286547,1,0] 1:[8388608,286559,1,0] precious:/lost+found/4207214# > If it comes to it, you can always zero out individual inode fields > for that inode in xfs_db (with -x option to enable write mode) and > then xfs_repair should be able to get past it. Any idea how this should be set? Thanks. -- Hacker's Law: The belief that enhanced understanding will necessarily stir a nation to action is one of mankind's oldest illusions. From owner-linux-xfs@oss.sgi.com Mon Jun 20 16:22:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jun 2005 16:22:11 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5KNM6H9015233 for ; Mon, 20 Jun 2005 16:22:07 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA16083 for ; Tue, 21 Jun 2005 09:20:46 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id A31B349AC162; Tue, 21 Jun 2005 09:25:05 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge in current KDB version. Message-Id: <20050620232505.A31B349AC162@chook.melbourne.sgi.com> Date: Tue, 21 Jun 2005 09:25:05 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2105 Lines: 34 Date: Tue Jun 21 09:20:35 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: kaos@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: 2.6.x-xfs-melb:linux:22921a Documentation/kdb/kdb.mm - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb.mm.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h Documentation/kdb/kdb_md.man - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb_md.man.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h kdb/kdbmain.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdbmain.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h kdb/modules/kdbm_vm.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/modules/kdbm_vm.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h kdb/modules/kdbm_task.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/modules/kdbm_task.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/linux/dis-asm.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/dis-asm.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/linux/kdb.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/kdb.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/linux/kdbprivate.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/kdbprivate.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h kdb/modules/Makefile - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/modules/Makefile.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h kdb/ChangeLog - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/ChangeLog.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h kdb/kdbsupport.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdbsupport.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h kdb/kdb_bp.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdb_bp.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h From owner-linux-xfs@oss.sgi.com Mon Jun 20 18:17:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jun 2005 18:17:23 -0700 (PDT) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5L1HJH9019162 for ; Mon, 20 Jun 2005 18:17:19 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id C04421C51112; Tue, 21 Jun 2005 09:15:58 +0800 (PHT) Received: from musang.free.net.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 7EF271C5110C; Tue, 21 Jun 2005 09:15:55 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id C7831600168; Tue, 21 Jun 2005 09:15:52 +0800 (PHT) Date: Tue, 21 Jun 2005 09:15:52 +0800 From: Federico Sevilla III To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.6.12] XFS: Undeletable directory Message-ID: <20050621011552.GC4927@free.net.ph> Mail-Followup-To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <200506191904.49639.lkml@kcore.org> <20050620070459.GB1549@frodo> <200506201225.11129.lkml@kcore.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506201225.11129.lkml@kcore.org> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.9i X-archive-position: 5486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 610 Lines: 18 On Mon, Jun 20, 2005 at 12:25:10PM +0200, Jan De Luyck wrote: > On Monday 20 June 2005 09:04, Nathan Scott wrote: > > If it comes to it, you can always zero out individual inode fields > > for that inode in xfs_db (with -x option to enable write mode) and > > then xfs_repair should be able to get past it. > > Any idea how this should be set? # xfs_db -x -c 'inode XXX' -c 'write core.nextents 0' -c 'write core.size 0' /dev/hdXX Cheers! --> Jijo -- Federico Sevilla III : jijo.free.net.ph : When we speak of free software GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price. From owner-linux-xfs@oss.sgi.com Mon Jun 20 20:48:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jun 2005 20:48:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5L3mUH9002512 for ; Mon, 20 Jun 2005 20:48:31 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA22083 for ; Tue, 21 Jun 2005 13:47:10 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 3A3F949AC162; Tue, 21 Jun 2005 13:51:31 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - scripts Message-Id: <20050621035131.3A3F949AC162@chook.melbourne.sgi.com> Date: Tue, 21 Jun 2005 13:51:31 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 563 Lines: 16 Add a script to extract our ptools mods into a git repository. Date: Tue Jun 21 13:46:55 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22928a xfsmisc/p_mod2git - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsmisc/p_mod2git xfsmisc/developers.pl - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsmisc/developers.pl.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h From owner-linux-xfs@oss.sgi.com Tue Jun 21 16:10:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Jun 2005 16:11:00 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5LNAqH9027509 for ; Tue, 21 Jun 2005 16:10:52 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA15982 for ; Wed, 22 Jun 2005 09:09:31 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 7437949AC169; Wed, 22 Jun 2005 09:14:02 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - minor 2.6 updates Message-Id: <20050621231402.7437949AC169@chook.melbourne.sgi.com> Date: Wed, 22 Jun 2005 09:14:02 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5488 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1382 Lines: 26 Merge back mainline 2.6 changes - qsort and ROTL transition. Date: Wed Jun 22 09:09:12 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: torvalds@osdl.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22938a xfs_da_btree.c - 1.153 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.153&r2=text&tr2=1.152&f=h support/debug.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h Makefile-linux-2.6 - 1.197 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.6.diff?r1=text&tr1=1.197&r2=text&tr2=1.196&f=h linux-2.6/xfs_linux.h - 1.129 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.129&r2=text&tr2=1.128&f=h linux-2.6/xfs_super.c - 1.335 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.335&r2=text&tr2=1.334&f=h linux-2.4/xfs_linux.h - 1.140 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.140&r2=text&tr2=1.139&f=h linux-2.6/xfs_ksyms.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h From owner-linux-xfs@oss.sgi.com Tue Jun 21 22:26:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Jun 2005 22:26:09 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5M5Q4H9022250 for ; Tue, 21 Jun 2005 22:26:05 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA24302 for ; Wed, 22 Jun 2005 15:24:40 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4039B49AC169; Wed, 22 Jun 2005 15:29:14 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - scripts Message-Id: <20050622052914.4039B49AC169@chook.melbourne.sgi.com> Date: Wed, 22 Jun 2005 15:29:14 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1093 Lines: 33 Tweak the p_mod2git script a bit. Date: Tue Jun 21 16:17:21 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22930a xfsmisc/p_mod2git - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsmisc/p_mod2git.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Update scripts for pushing kernel changes to upstream maintainers. Date: Wed Jun 22 15:24:15 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22947a xfsmisc/bk-make-xfs - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsmisc/bk-make-xfs xfsmisc/git-make-xfs - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsmisc/git-make-xfs xfsmisc/README - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsmisc/README.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h From owner-linux-xfs@oss.sgi.com Wed Jun 22 06:59:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jun 2005 06:59:44 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5MDxbH9017227 for ; Wed, 22 Jun 2005 06:59:38 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5MFm5nw007333 for ; Wed, 22 Jun 2005 08:48:05 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5MDvFR010712828; Wed, 22 Jun 2005 08:57:16 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Dl5j9-0005kM-00; Wed, 22 Jun 2005 08:57:15 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 938306 - replace vn_get usage by ihold Message-Id: From: Christoph Hellwig Date: Wed, 22 Jun 2005 08:57:15 -0500 X-archive-position: 5490 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1993 Lines: 48 vn_get is possibly racy and overly complicated for usage under Linux. We can simply use ihold whith the mount lock held to check whether an inode is beeing freed or grab a reference if it is not. Date: Wed Jun 22 06:56:22 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:194627a fs/xfs/xfs_vfsops.c - 1.469 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.469&r2=text&tr2=1.468&f=h - replace vn_get usage by ihold fs/xfs/quota/xfs_qm_syscalls.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - replace vn_get usage by ihold fs/xfs/linux-2.6/xfs_vnode.c - 1.128 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.128&r2=text&tr2=1.127&f=h - replace vn_get usage by ihold fs/xfs/linux-2.6/xfs_vnode.h - 1.105 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h - replace vn_get usage by ihold fs/xfs/linux-2.4/xfs_vnode.c - 1.129 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.c.diff?r1=text&tr1=1.129&r2=text&tr2=1.128&f=h - replace vn_get usage by ihold fs/xfs/linux-2.4/xfs_vnode.h - 1.98 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.98&r2=text&tr2=1.97&f=h - replace vn_get usage by ihold fs/xfs/linux-2.6/xfs_ksyms.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h - replace vn_get usage by ihold fs/xfs/linux-2.4/xfs_ksyms.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - replace vn_get usage by ihold From owner-linux-xfs@oss.sgi.com Wed Jun 22 13:07:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jun 2005 13:07:39 -0700 (PDT) Received: from chris.happyjack.org (c-67-170-85-37.hsd1.wa.comcast.net [67.170.85.37]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5MK7XH9001146 for ; Wed, 22 Jun 2005 13:07:36 -0700 Received: by chris.happyjack.org (Postfix, from userid 1000) id 5DEA6C255F; Wed, 22 Jun 2005 13:06:11 -0700 (PDT) Date: Wed, 22 Jun 2005 13:06:10 -0700 From: Chris Spiegel To: linux-ide@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Kernel BUG report Message-ID: <20050622200609.GA12159@midgard.spiegels> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 5491 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@happyjack.org Precedence: bulk X-list: linux-xfs Content-Length: 3725 Lines: 92 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I ran into a bug while reorganizing an XFS filesystem with xfs_fsr. I'm running a vanilla 2.6.12 from kernel.org on a dual P4 Xeon system. I have a RAID1 setup with two IDE drives, hdb and hdc. /dev/md0 is encrypted using dm-crypt, so the filesystem was created on /dev/mapper/md0. At the time I received the bug, the array was running in degraded mode, with only hdb1. I was also running "shred" on hdc1, preparing to attach it to md0. My IDE controller is: 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) My first thought is that it's a hardware problem. I've had intermittent IDE issues, although there have been no recent errors logged as reported by smartctl. Regardless, I thought I should report this -- but if it's an issue that can easily be explained by hardware problems, that's likely the culprit. Let me know if you need any more information. Chris --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=crashdump kernel BUG at include/asm/dma-mapping.h:44! invalid operand: 0000 [#1] PREEMPT SMP Modules linked in: xfs snd_intel8x0 CPU: 3 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.12) EIP is at ide_build_sglist+0x92/0xb0 eax: 00000000 ebx: df812000 ecx: 00000000 edx: 00000000 esi: 00000021 edi: cf0b6ab8 ebp: 00000000 esp: d301badc ds: 007b es: 007b ss: 0068 Process xfs_fsr (pid: 2167, threadinfo=d301a000 task=d2228530) Stack: c05bbba8 cf0b6ab8 df810000 c05bb980 00000000 c02d147f c05bbba8 cf0b6ab8 c0133930 00000000 c05bb980 cf0b6ab8 c05bb980 c05bbba8 00000000 c02d18ec c05bbba8 cf0b6ab8 00000012 12310071 c05bb980 c05bbba8 c02d39e9 c05bbba8 Call Trace: [] ide_build_dmatable+0x3f/0x170 [] autoremove_wake_function+0x0/0x60 [] ide_dma_setup+0x3c/0xd0 [] __ide_do_rw_disk+0x2f9/0x520 [] __delay+0x12/0x20 [] start_request+0x156/0x240 [] ide_do_request+0x22b/0x3c0 [] do_ide_request+0x24/0x30 [] __generic_unplug_device+0x3e/0x40 [] generic_unplug_device+0x1e/0x30 [] unplug_slaves+0xe8/0x100 [] dm_table_unplug_all+0x46/0x50 [] dm_unplug_all+0x27/0x40 [] blk_backing_dev_unplug+0x19/0x20 [] dio_await_one+0xc0/0xd0 [] dio_await_completion+0x2b/0x60 [] direct_io_worker+0x3f9/0x5a0 [] xfs_ilock_map_shared+0x25/0x40 [xfs] [] __blockdev_direct_IO+0x2eb/0x3fd [] linvfs_get_blocks_direct+0x0/0x50 [xfs] [] linvfs_unwritten_convert_direct+0x0/0x70 [xfs] [] linvfs_direct_IO+0xe5/0xf0 [xfs] [] linvfs_get_blocks_direct+0x0/0x50 [xfs] [] linvfs_unwritten_convert_direct+0x0/0x70 [xfs] [] _spin_unlock+0xd/0x30 [] update_atime+0x9c/0xd0 [] generic_file_direct_IO+0x72/0x120 [] generic_file_direct_write+0x76/0x190 [] xfs_write+0x53d/0xd20 [xfs] [] linvfs_aio_read_invis+0x8e/0xa0 [xfs] [] linvfs_write+0x10c/0x140 [xfs] [] linvfs_ioctl+0x60/0x80 [xfs] [] autoremove_wake_function+0x0/0x60 [] _spin_lock+0x16/0x90 [] dnotify_parent+0x3a/0xb0 [] vfs_write+0xae/0x130 [] sys_write+0x51/0x80 [] sysenter_past_esp+0x54/0x75 Code: 13 85 c0 74 26 8b 3d 10 2f 5b c0 41 29 f8 8b 7c 13 04 c1 f8 05 c1 e0 0c 01 f8 39 f1 89 44 13 08 7c d7 83 c4 08 89 f0 5b 5e 5f c3 <0f> 0b 2c 00 03 ea 45 c0 eb d0 0f 0b 29 00 03 ea 45 c0 eb b1 8d --SLDf9lqlvOQaIe6s-- From owner-linux-xfs@oss.sgi.com Wed Jun 22 13:45:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jun 2005 13:45:55 -0700 (PDT) Received: from informatik.uni-bremen.de (imh.informatik.uni-bremen.de [134.102.224.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5MKjlH9005670 for ; Wed, 22 Jun 2005 13:45:50 -0700 Received: from [192.168.0.149] (dialin-212-144-040-127.arcor-ip.net [212.144.40.127]) (authenticated bits=0) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j5MKiCSr007778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Jun 2005 22:44:17 +0200 (MEST) Message-ID: <42B9CDBD.70004@tzi.de> Date: Wed, 22 Jun 2005 22:44:45 +0200 From: Wolfgang Kohnen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: growfs: attempt to access beyond end of device X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 5492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wollie@tzi.de Precedence: bulk X-list: linux-xfs Content-Length: 5418 Lines: 112 Hello! I am not subscribed to this list. I just experienced an xfs fs shutting down while putting heavy read/write load on the disks and simultaneously growing the fs via xfs_growfs and I wanted to give someone the opportunity to look after this, just in case I've spot a yet unknown behaviour. My Linux Kernel is 2.6.8-2-686-smp (Debian packaged kernel). I give you here the last lines from kern.log. If you are interested, I could provide all log lines of this observation (over 500k uncompressed) and additional information. BTW: I was compiling 16 ISOs (14 CDR, 2 DVD) of Debian Sarge via jigdo from a local lan mirror in parallel. :-) Greets, Wollie Jun 22 22:00:29 amaranta kernel: dm-0: rw=0, want=1030768558088, limit=146800640 Jun 22 22:00:29 amaranta kernel: I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xeffe980002 ("xfs_trans_read_buf") error 5 buf count 512 Jun 22 22:00:29 amaranta kernel: attempt to access beyond end of device Jun 22 22:00:29 amaranta kernel: dm-0: rw=0, want=1030772490248, limit=146800640 Jun 22 22:00:29 amaranta kernel: I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xeffed40002 ("xfs_trans_read_buf") error 5 buf count 512 Jun 22 22:00:29 amaranta kernel: attempt to access beyond end of device Jun 22 22:00:29 amaranta kernel: dm-0: rw=0, want=1030776422408, limit=146800640 Jun 22 22:00:29 amaranta kernel: I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xefff100002 ("xfs_trans_read_buf") error 5 buf count 512 Jun 22 22:00:29 amaranta kernel: attempt to access beyond end of device Jun 22 22:00:29 amaranta kernel: dm-0: rw=0, want=1030780354568, limit=146800640 Jun 22 22:00:29 amaranta kernel: I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xefff4c0002 ("xfs_trans_read_buf") error 5 buf count 512 Jun 22 22:00:29 amaranta kernel: attempt to access beyond end of device Jun 22 22:00:29 amaranta kernel: dm-0: rw=0, want=1030784286728, limit=146800640 Jun 22 22:00:29 amaranta kernel: I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xefff880002 ("xfs_trans_read_buf") error 5 buf count 512 Jun 22 22:00:29 amaranta kernel: attempt to access beyond end of device Jun 22 22:00:29 amaranta kernel: dm-0: rw=0, want=1030788218888, limit=146800640 Jun 22 22:00:29 amaranta kernel: I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xefffc40002 ("xfs_trans_read_buf") error 5 buf count 512 Jun 22 22:00:29 amaranta kernel: xfs_force_shutdown(dm-0,0x8) called from line 1088 of file fs/xfs/xfs_trans.c. Return address = 0xf89fd44b Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+749942/5290900] xfs_ialloc_read_agi+0xf5/0x14a [xfs] Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+743746/5290900] xfs_ialloc_ag_select+0x2b1/0x340 [xfs] Jun 22 22:00:29 amaranta last message repeated 2 times Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+746719/5290900] xfs_dialloc+0xb0e/0xb50 [xfs] Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+819002/5290900] xlog_grant_log_space+0x189/0x4f0 [xfs] Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+775613/5290900] xfs_ialloc+0x5c/0x4a0 [xfs] Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+928262/5290900] kmem_zone_zalloc+0x35/0x60 [xfs] Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+883954/5290900] xfs_dir_ialloc+0x91/0x2e0 [xfs] Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+870677/5290900] xfs_trans_reserve+0x84/0x1f0 [xfs] Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+911902/5290900] xfs_mkdir+0x2ad/0x740 [xfs] Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+506124/5290900] xfs_acl_vhasacl_default+0x3b/0x50 [xfs] Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+958474/5290900] linvfs_mknod+0x389/0x420 [xfs] Jun 22 22:00:29 amaranta kernel: [tcp_v4_do_rcv+298/304] tcp_v4_do_rcv+0x12a/0x130 Jun 22 22:00:29 amaranta kernel: [tcp_v4_rcv+1828/2496] tcp_v4_rcv+0x724/0x9c0 Jun 22 22:00:29 amaranta kernel: [path_release+21/80] path_release+0x15/0x50 Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+960122/5290900] linvfs_permission+0x29/0x30 [xfs] Jun 22 22:00:29 amaranta kernel: [__crc_pm_idle+958683/5290900] linvfs_mkdir+0x2a/0x30 [xfs] Jun 22 22:00:29 amaranta kernel: [vfs_mkdir+176/320] vfs_mkdir+0xb0/0x140 Jun 22 22:00:29 amaranta kernel: [sys_mkdir+184/256] sys_mkdir+0xb8/0x100 Jun 22 22:00:29 amaranta kernel: [syscall_call+7/11] syscall_call+0x7/0xb Jun 22 22:00:29 amaranta kernel: xfs_force_shutdown(dm-0,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xf89fd44b Jun 22 22:00:29 amaranta kernel: Filesystem "dm-0": Corruption of in-memory data detected. Shutting down filesystem: dm-0 Jun 22 22:00:29 amaranta kernel: Please umount the filesystem, and rectify the problem(s) Jun 22 22:03:41 amaranta kernel: xfs_force_shutdown(dm-0,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xf89fd44b Jun 22 22:04:49 amaranta kernel: xfs_force_shutdown(dm-0,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xf89fd44b Jun 22 22:05:05 amaranta kernel: XFS mounting filesystem dm-0 Jun 22 22:05:05 amaranta kernel: Starting XFS recovery on filesystem: dm-0 (dev: dm-0) Jun 22 22:05:06 amaranta kernel: Ending XFS recovery on filesystem: dm-0 (dev: dm-0) Jun 22 22:05:24 amaranta kernel: XFS mounting filesystem dm-0 Jun 22 22:05:24 amaranta kernel: Ending clean XFS mount for filesystem: dm-0 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Jun 22 20:37:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jun 2005 20:37:48 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5N3bgH9008581 for ; Wed, 22 Jun 2005 20:37:43 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA23318 for ; Thu, 23 Jun 2005 13:36:20 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id EC58C49AC17D; Thu, 23 Jun 2005 13:41:05 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - fix 2.4 builds Message-Id: <20050623034105.EC58C49AC17D@chook.melbourne.sgi.com> Date: Thu, 23 Jun 2005 13:41:05 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5493 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 770 Lines: 18 Fix up 2.4 kernel builds after backporting 2.6 changes. Date: Thu Jun 23 13:36:04 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch,sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22954a support/debug.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h linux-2.4/xfs_lrw.c - 1.222 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.c.diff?r1=text&tr1=1.222&r2=text&tr2=1.221&f=h linux-2.4/xfs_linux.h - 1.141 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.141&r2=text&tr2=1.140&f=h From owner-linux-xfs@oss.sgi.com Wed Jun 22 23:59:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jun 2005 23:59:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5N6xHH9020019 for ; Wed, 22 Jun 2005 23:59:18 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA28176; Thu, 23 Jun 2005 16:57:53 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id C4B5A49AC17D; Thu, 23 Jun 2005 17:02:40 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 938410 - truncate tracing Message-Id: <20050623070240.C4B5A49AC17D@chook.melbourne.sgi.com> Date: Thu, 23 Jun 2005 17:02:40 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5496 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1061 Lines: 22 Add a chunk of tracing code to diagnose truncate related issues. Date: Thu Jun 23 16:57:39 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch,cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22966a xfsidbg.c - 1.276 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.276&r2=text&tr2=1.275&f=h linux-2.6/xfs_lrw.h - 1.49 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.h.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h linux-2.6/xfs_aops.c - 1.89 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.89&r2=text&tr2=1.88&f=h linux-2.4/xfs_lrw.h - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h linux-2.4/xfs_aops.c - 1.89 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.89&r2=text&tr2=1.88&f=h From owner-linux-xfs@oss.sgi.com Wed Jun 22 23:56:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jun 2005 23:56:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5N6uPH9019485 for ; Wed, 22 Jun 2005 23:56:26 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA28102; Thu, 23 Jun 2005 16:54:54 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id B890A49AC17D; Thu, 23 Jun 2005 16:59:40 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 938408 - replace inter_module calls for 2.6 Message-Id: <20050623065940.B890A49AC17D@chook.melbourne.sgi.com> Date: Thu, 23 Jun 2005 16:59:40 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5494 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 649 Lines: 17 Replace the use of inter_module interfaces here, since those interfaces are deprecated. Date: Thu Jun 23 16:49:38 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22964a linux-2.6/xfs_vfs.h - 1.52 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h linux-2.6/xfs_vfs.c - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.c.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h From owner-linux-xfs@oss.sgi.com Wed Jun 22 23:57:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jun 2005 23:57:14 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5N6vAH9019607 for ; Wed, 22 Jun 2005 23:57:11 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA28109; Thu, 23 Jun 2005 16:55:46 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id CCB4249AC17D; Thu, 23 Jun 2005 17:00:33 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 938409 - metadata IO completion cleanup Message-Id: <20050623070033.CCB4249AC17D@chook.melbourne.sgi.com> Date: Thu, 23 Jun 2005 17:00:33 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 5495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 485 Lines: 14 Make metadata IO completion consistent with other IO completion handlers. Date: Thu Jun 23 16:55:22 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22965a linux-2.6/xfs_buf.c - 1.198 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.198&r2=text&tr2=1.197&f=h From owner-linux-xfs@oss.sgi.com Thu Jun 23 11:25:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Jun 2005 11:25:11 -0700 (PDT) Received: from corp1.cosmixcorp.com (206.173.21.32.ptr.us.xo.net [206.173.21.32]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5NIP6H9009512 for ; Thu, 23 Jun 2005 11:25:06 -0700 Received: from search1.cosmixcorp.com ([206.173.21.85]) by corp1.cosmixcorp.com (8.13.0/8.13.0) with ESMTP id j5NIV8gq032333 for ; Thu, 23 Jun 2005 11:31:08 -0700 (PDT) Subject: Need Advice replacing MySQL with XFS From: Douglass Judd To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1119550795.9282.8.camel@sedna.cambrianventures.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Thu, 23 Jun 2005 11:19:55 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 5497 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doug@cosmixcorp.com Precedence: bulk X-list: linux-xfs Content-Length: 955 Lines: 25 I've written a web crawler (distributed across 16 machines) using MySQL (INNODB) as the underlying document store. I'm using MySQL for its b-tree index to quickly access each document using the MD5 hash of the URL as the key. I'm considering replacing the MySQL table that I use as the document repository with a simple directory heirarchy in XFS. Here are my basic requirements: 1. Each machine will start out with about 20 Million documents but needs to be able to grow to 100 Million documents, each document is about 10KB in size. 2. Given a key (16 byte hash value), need to be able to efficiently insert documents and locate/update existing documents. 3. Need to be able to sequentially scan the entire repository, exporting all of the documents for the next stage of processing. First of all, is this even doable? Is there an optimal number of entries per directory for best performance? Any advice would be greatly appreciated. - Doug From owner-linux-xfs@oss.sgi.com Thu Jun 23 14:54:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Jun 2005 14:55:00 -0700 (PDT) Received: from liquid-x.net (BrimStone.liquid-x.net [64.93.28.206] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5NLsvH9021793 for ; Thu, 23 Jun 2005 14:54:58 -0700 Received: from localhost.localdomain (mercury [127.0.0.1]) by liquid-x.net (8.12.5/8.12.5) with ESMTP id j5NM6efP005691 for ; Thu, 23 Jun 2005 15:06:41 -0700 Received: from localhost (kronos@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) with ESMTP id j5NM6eZK005687 for ; Thu, 23 Jun 2005 15:06:40 -0700 X-Authentication-Warning: localhost.localdomain: kronos owned process doing -bs Date: Thu, 23 Jun 2005 15:06:40 -0700 (PDT) From: Dan X-X-Sender: kronos@localhost.localdomain To: linux-xfs@oss.sgi.com Subject: Questions regarding stack size with RHEL AS 4.0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dranok@liquid-x.net Precedence: bulk X-list: linux-xfs Content-Length: 3616 Lines: 105 I'm about to put together a low-end 3.2TiB fileserver for archival purposes. It will not be hit heavy and will mostly house backup archives / etc. The heaviest use scenario would be two NFS clients writing multi-GB files and two CIFS (samba) clients reading different multi-GB files. Since not *all* files are large files (maybe a couple million smaller 4k-100k files) I don't want to use ext3. I do, however, want a single filesystem (LVM has been...annoying in the past [performance, etc]). XFS seems like the perfect option, but I'm concerned by the research I've done on the 4k stack size issue. Performance isn't the most important thing (obviously faster is better than slower), but I value stability and low overhead (space-wise) more. Here's the end setup I'll have: o celeron 2.6GHz o 1GB ram o RHEL 4.0 AS (Update1) installed across two mirrored PATA drives (md0) - swap across same (md1) o 2 x Promise SX8 PCI-X SATA controller cards - Each card will have 6 drives connected to it - These 12 drives will be setup as raid5 device (/dev/md2) - /dev/md2 will have a single 3.2TiB XFS filesystem on it - This filesystem will be exported via NFS and Samba I have two questions: ----------------------- 1) Here's the mkfs command I will start testing with, I'm assuming it will determine sunit and swidth correctly? If not, is the following true: sunit == chunksize ; swidt = (N-1) * sunit? mkfs.xfs -d unwritten=0 -i size=512,align=1 -l internal=1,version=2 -N /dev/md2 2) What would be the better approach to fix the stack problem? I'm thinking I have a very high chance of running into it based on my setup.. Option 1 below is what I was first thinking, but then I read that it might be better to have 8k thread stacks AND separate IRQ stacks. This is detailed in Option 2 below. I'm only planning on running NFS and Samba, so my questions are: a) Which is preferable, option 1 or option 2? b) Is it possible that option 2 could fubar anything? Or is it safe? I'm fairly convinced option 1 is safe since I don't care about the diskdump stuff... Thanks!! Dan. Option 1: -=-=-=-=- o Install kernel 2.6.9 SRPM o manually apply patch to SPECS/kernel-2.6.9-i686 + http://oss.sgi.com/archives/linux-xfs/2005-03/txtEk2XINYe9v.txt + Also disable the following patches: #%patch1553 -p1 #%patch1554 -p1 #%patch1555 -p1 #%patch1556 -p1 #%patch1557 -p1 #%patch1558 -p1 #%patch1559 -p1 #%patch1560 -p1 #%patch1561 -p1 #%patch2303 -p1 #%patch2304 -p1 o rpmbuild -ba --target=i686 SPECS/kernel-2.6.spec + Hit CTRL-C when it gets to compile stuff.. o cd BUILD/kernel-2.6.9/ o cp kernel-2.6.9-i686.config .config o vi .config + add: CONFIG_4KSTACKS=n o make menuconfig + Filesystems - XFS + Kernel Hacking - Make sure 4k stacks is DISABLED o make and build kernel & modules, etc ... Option 2: -=-=-=-=- o Install kernel 2.6.9 SRPM o rpmbuild -ba --target=i686 SPECS/kernel-2.6.spec + Hit CTRL-C when it gets to compile stuff.. o cd BUILD/kernel-2.6.9/ o cp kernel-2.6.9-i686.config .config o vi include/asm-i386/thread_info.h: #define PREEMPT_ACTIVE 0x10000000 #ifdef CONFIG_4KSTACKS -#define THREAD_SIZE (4096) +#define THREAD_SIZE (8192) #else #define THREAD_SIZE (8192) #endif -#define STACK_WARN (THREAD_SIZE/8) +#define STACK_WARN (THREAD_SIZE/2) o make and build kernel & modules, etc ... From owner-linux-xfs@oss.sgi.com Thu Jun 23 21:31:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Jun 2005 21:31:20 -0700 (PDT) Received: from mail.pacrimopen.com (mail.pacrimopen.com [64.65.177.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5O4VGH9014252 for ; Thu, 23 Jun 2005 21:31:17 -0700 Received: from mail.diaradiology.org (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id 3291E845118C for ; Thu, 23 Jun 2005 21:29:54 -0700 (PDT) Received: from [10.0.0.3] (pool-71-111-80-36.ptldor.dsl-w.verizon.net [71.111.80.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id 5FED17CB1F9C for ; Thu, 23 Jun 2005 21:29:53 -0700 (PDT) Message-ID: <42BB8C44.2010303@pacrimopen.com> Date: Thu, 23 Jun 2005 21:29:56 -0700 From: Joshua Schmidlkofer User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050509) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Opteron Systems X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 5499 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kernel@pacrimopen.com Precedence: bulk X-list: linux-xfs Content-Length: 210 Lines: 8 Should I be using the inode64 option on my Opteron and EMT64 systems? I am using Gentoo amd64 stuff, so everything is build 64bit, I just wondered if I should be using the inode64 option. Thanks, Joshua From owner-linux-xfs@oss.sgi.com Thu Jun 23 23:39:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Jun 2005 23:39:56 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5O6doH9020174 for ; Thu, 23 Jun 2005 23:39:51 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA28628; Fri, 24 Jun 2005 16:38:21 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id BC5ED49AC17D; Fri, 24 Jun 2005 16:43:19 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 938502 - xfs_bmapi does not free space after ENOSPC Message-Id: <20050624064319.BC5ED49AC17D@chook.melbourne.sgi.com> Date: Fri, 24 Jun 2005 16:43:19 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 5500 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 780 Lines: 20 Prevent the incore superblock sb_fdblocks count from leaking when we are getting ENOSPC errors on writes. When we fail to allocate space for indirect blocks in xfs_bmapi() make sure we release the direct block allocation before returning. Date: Fri Jun 24 16:36:10 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:22986a fs/xfs/xfs_bmap.c - 1.326 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.326&r2=text&tr2=1.325&f=h - If we fail to allocate space for indirect blocks in xfs_bmapi(), make sure we release the direct block allocation before returning. From owner-linux-xfs@oss.sgi.com Fri Jun 24 05:01:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Jun 2005 05:01:05 -0700 (PDT) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.182.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5OC11H9010647 for ; Fri, 24 Jun 2005 05:01:01 -0700 Received: from filter05.roc.ny.frontiernet.net (filter05.roc.ny.frontiernet.net [66.133.183.72]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id 6357836435A; Fri, 24 Jun 2005 11:59:36 +0000 (UTC) Received: from relay01.roc.ny.frontiernet.net ([66.133.182.164]) by filter05.roc.ny.frontiernet.net (filter05.roc.ny.frontiernet.net [66.133.183.72]) (amavisd-new, port 10024) with LMTP id 24685-05-86; Fri, 24 Jun 2005 11:59:36 +0000 (UTC) Received: from [192.168.1.100] (67-137-96-87.dsl2.brv.mn.frontiernet.net [67.137.96.87]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id A1538364343; Fri, 24 Jun 2005 11:59:30 +0000 (UTC) Message-ID: <42BBF5A1.3000502@xfs.org> Date: Fri, 24 Jun 2005 06:59:29 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joshua Schmidlkofer Cc: linux-xfs@oss.sgi.com Subject: Re: Opteron Systems References: <42BB8C44.2010303@pacrimopen.com> In-Reply-To: <42BB8C44.2010303@pacrimopen.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5501 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 490 Lines: 17 Joshua Schmidlkofer wrote: > Should I be using the inode64 option on my Opteron and EMT64 systems? I am using Gentoo amd64 stuff, so everything is > build 64bit, I just wondered if I should be using the inode64 option. > > > Thanks, > > Joshua > If your filesystems are 1 Tbyte or larger then yes, otherwise it does not really make any difference. You can enable this at any point, once you have done it though, the inodes will be out there and you cannot get rid of them. Steve From owner-linux-xfs@oss.sgi.com Sun Jun 26 20:39:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Jun 2005 20:39:32 -0700 (PDT) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5R3dLH9006893 for ; Sun, 26 Jun 2005 20:39:22 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5R3bqfE1999416; Mon, 27 Jun 2005 13:37:53 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j5R3boYS2621832; Mon, 27 Jun 2005 13:37:50 +1000 (AEST) Date: Mon, 27 Jun 2005 13:37:50 +1000 From: Tim Shimmin To: Steve Lord Cc: Joshua Schmidlkofer , linux-xfs@oss.sgi.com Subject: Re: Opteron Systems Message-ID: <20050627133749.F2458792@boing.melbourne.sgi.com> References: <42BB8C44.2010303@pacrimopen.com> <42BBF5A1.3000502@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <42BBF5A1.3000502@xfs.org>; from lord@xfs.org on Fri, Jun 24, 2005 at 06:59:29AM -0500 X-archive-position: 5503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 751 Lines: 20 On Fri, Jun 24, 2005 at 06:59:29AM -0500, Steve Lord wrote: > Joshua Schmidlkofer wrote: > > Should I be using the inode64 option on my Opteron and EMT64 systems? > > I am using Gentoo amd64 stuff, so everything is > > build 64bit, I just wondered if I should be using the inode64 option. > > Thanks, Joshua > > If your filesystems are 1 Tbyte or larger then yes, otherwise it > does not really make any difference. You can enable this at any point, > > once you have done it though, the inodes will be out there and > you cannot get rid of them. > On IRIX we do have xfs_reno(1M) which can renumber inodes by swaping extents, copying dirents, copying EAs etc...(relies on XFS to allocate new inode). However, it is not ported to Linux. --Tim From owner-linux-xfs@oss.sgi.com Mon Jun 27 15:36:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jun 2005 15:36:11 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5RMa5H9012905 for ; Mon, 27 Jun 2005 15:36:06 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5S0PFWx032506 for ; Mon, 27 Jun 2005 17:25:15 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5RMXb0F17749069; Mon, 27 Jun 2005 17:33:37 -0500 (CDT) Message-ID: <42C07EC1.10607@sgi.com> Date: Mon, 27 Jun 2005 17:33:37 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Spiegel CC: linux-ide@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel BUG report References: <20050622200609.GA12159@midgard.spiegels> In-Reply-To: <20050622200609.GA12159@midgard.spiegels> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5505 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3810 Lines: 90 Chris Spiegel wrote: > Hi, > > I ran into a bug while reorganizing an XFS filesystem with xfs_fsr. > > I'm running a vanilla 2.6.12 from kernel.org on a dual P4 Xeon system. > > I have a RAID1 setup with two IDE drives, hdb and hdc. /dev/md0 is > encrypted using dm-crypt, so the filesystem was created on > /dev/mapper/md0. At the time I received the bug, the array was running > in degraded mode, with only hdb1. I was also running "shred" on hdc1, > preparing to attach it to md0. > > My IDE controller is: > 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) > > My first thought is that it's a hardware problem. I've had intermittent > IDE issues, although there have been no recent errors logged as reported > by smartctl. Regardless, I thought I should report this -- but if it's > an issue that can easily be explained by hardware problems, that's > likely the culprit. > > Let me know if you need any more information. Do you have CONFIG_4KSTACKS turned on? -Eric > Chris > > > ------------------------------------------------------------------------ > > kernel BUG at include/asm/dma-mapping.h:44! > invalid operand: 0000 [#1] > PREEMPT SMP > Modules linked in: xfs snd_intel8x0 > CPU: 3 > EIP: 0060:[] Not tainted VLI > EFLAGS: 00010246 (2.6.12) > EIP is at ide_build_sglist+0x92/0xb0 > eax: 00000000 ebx: df812000 ecx: 00000000 edx: 00000000 > esi: 00000021 edi: cf0b6ab8 ebp: 00000000 esp: d301badc > ds: 007b es: 007b ss: 0068 > Process xfs_fsr (pid: 2167, threadinfo=d301a000 task=d2228530) > Stack: c05bbba8 cf0b6ab8 df810000 c05bb980 00000000 c02d147f c05bbba8 cf0b6ab8 > c0133930 00000000 c05bb980 cf0b6ab8 c05bb980 c05bbba8 00000000 c02d18ec > c05bbba8 cf0b6ab8 00000012 12310071 c05bb980 c05bbba8 c02d39e9 c05bbba8 > Call Trace: > [] ide_build_dmatable+0x3f/0x170 > [] autoremove_wake_function+0x0/0x60 > [] ide_dma_setup+0x3c/0xd0 > [] __ide_do_rw_disk+0x2f9/0x520 > [] __delay+0x12/0x20 > [] start_request+0x156/0x240 > [] ide_do_request+0x22b/0x3c0 > [] do_ide_request+0x24/0x30 > [] __generic_unplug_device+0x3e/0x40 > [] generic_unplug_device+0x1e/0x30 > [] unplug_slaves+0xe8/0x100 > [] dm_table_unplug_all+0x46/0x50 > [] dm_unplug_all+0x27/0x40 > [] blk_backing_dev_unplug+0x19/0x20 > [] dio_await_one+0xc0/0xd0 > [] dio_await_completion+0x2b/0x60 > [] direct_io_worker+0x3f9/0x5a0 > [] xfs_ilock_map_shared+0x25/0x40 [xfs] > [] __blockdev_direct_IO+0x2eb/0x3fd > [] linvfs_get_blocks_direct+0x0/0x50 [xfs] > [] linvfs_unwritten_convert_direct+0x0/0x70 [xfs] > [] linvfs_direct_IO+0xe5/0xf0 [xfs] > [] linvfs_get_blocks_direct+0x0/0x50 [xfs] > [] linvfs_unwritten_convert_direct+0x0/0x70 [xfs] > [] _spin_unlock+0xd/0x30 > [] update_atime+0x9c/0xd0 > [] generic_file_direct_IO+0x72/0x120 > [] generic_file_direct_write+0x76/0x190 > [] xfs_write+0x53d/0xd20 [xfs] > [] linvfs_aio_read_invis+0x8e/0xa0 [xfs] > [] linvfs_write+0x10c/0x140 [xfs] > [] linvfs_ioctl+0x60/0x80 [xfs] > [] autoremove_wake_function+0x0/0x60 > [] _spin_lock+0x16/0x90 > [] dnotify_parent+0x3a/0xb0 > [] vfs_write+0xae/0x130 > [] sys_write+0x51/0x80 > [] sysenter_past_esp+0x54/0x75 > Code: 13 85 c0 74 26 8b 3d 10 2f 5b c0 41 29 f8 8b 7c 13 04 c1 f8 05 c1 e0 0c 01 f8 39 f1 89 44 13 08 7c d7 83 c4 08 89 f0 5b 5e 5f c3 <0f> 0b 2c 00 03 ea 45 c0 eb d0 0f 0b 29 00 03 ea 45 c0 eb b1 8d > From owner-linux-xfs@oss.sgi.com Mon Jun 27 15:35:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jun 2005 15:35:23 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5RMZEH9012854 for ; Mon, 27 Jun 2005 15:35:14 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5S0OLDU032339 for ; Mon, 27 Jun 2005 17:24:21 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5RMWi0F17745398; Mon, 27 Jun 2005 17:32:44 -0500 (CDT) Message-ID: <42C07E8C.7010104@sgi.com> Date: Mon, 27 Jun 2005 17:32:44 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan CC: linux-xfs@oss.sgi.com Subject: Re: Questions regarding stack size with RHEL AS 4.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 850 Lines: 17 Dan wrote: > I'm about to put together a low-end 3.2TiB fileserver for archival > purposes. It will not be hit heavy and will mostly house backup archives > / etc. The heaviest use scenario would be two NFS clients writing > multi-GB files and two CIFS (samba) clients reading different multi-GB > files. Since not *all* files are large files (maybe a couple million > smaller 4k-100k files) I don't want to use ext3. I do, however, want > a single filesystem (LVM has been...annoying in the past [performance, > etc]). XFS seems like the perfect option, but I'm concerned by the > research I've done on the 4k stack size issue. I think we already talked on IRC, but for posterity, I mentioned using SLES9 instead of RHEL4 for this application, because it already has tested xfs support, and it does not have the 4k stack issue. -Eric From owner-linux-xfs@oss.sgi.com Mon Jun 27 23:51:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jun 2005 23:51:08 -0700 (PDT) Received: from mail-a.speedkom.net (mail-a.speedkom.net [213.182.0.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5S6p3H9008603 for ; Mon, 27 Jun 2005 23:51:04 -0700 Received: from exchange2.in.riwa-gis.de (mail.riwa-gis.de [213.182.7.84]) by mail-a.speedkom.net with SMTP id j5S6n5tG025769; Tue, 28 Jun 2005 08:49:13 +0200 Received: from mail pickup service by exchange2.in.riwa-gis.de with Microsoft SMTPSVC; Tue, 28 Jun 2005 08:49:04 +0200 PureMessageGuid: {92878EA4-2FA4-4C8D-841D-C334D8FE965B} thread-index: AcV7aNLCSnZS9Pt4REyXmD6lB3a5zQ== Received: from mailin2-a.mx.speedkom.net ([213.182.0.50]) by exchange2.in.riwa-gis.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Jun 2005 00:37:29 +0200 Received: from oss.sgi.com (oss.sgi.com [192.48.159.27]) by mailin2-a.mx.speedkom.net with ESMTP id j5RMbLqL028924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Jun 2005 00:37:28 +0200 Received: from oss (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5RMcOH9013328; Mon, 27 Jun 2005 15:38:27 -0700 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jun 2005 15:36:11 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5RMa5H9012905 for ; Mon, 27 Jun 2005 15:36:06 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5S0PFWx032506 for ; Mon, 27 Jun 2005 17:25:15 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5RMXb0F17749069; Mon, 27 Jun 2005 17:33:37 -0500 (CDT) Date: Tue, 28 Jun 2005 08:49:04 +0200 Message-ID: <011901c57bad$79559e20$0c14a8c0@in.riwagis.de> Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft CDO for Exchange 2000 From: "Eric Sandeen" User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chris Spiegel" Cc: , Subject: Re: Kernel BUG report References: <20050622200609.GA12159@midgard.spiegels> In-Reply-To: <20050622200609.GA12159@midgard.spiegels> Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 5505 X-ecartis-version: Ecartis v1.0.0 X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs X-OriginalArrivalTime: 27 Jun 2005 22:37:39.0242 (UTC) FILETIME=[D2BE28A0:01C57B68] X-archive-position: 5507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3811 Lines: 91 Chris Spiegel wrote: > Hi, > > I ran into a bug while reorganizing an XFS filesystem with xfs_fsr. > > I'm running a vanilla 2.6.12 from kernel.org on a dual P4 Xeon system. > > I have a RAID1 setup with two IDE drives, hdb and hdc. /dev/md0 is > encrypted using dm-crypt, so the filesystem was created on > /dev/mapper/md0. At the time I received the bug, the array was running > in degraded mode, with only hdb1. I was also running "shred" on hdc1, > preparing to attach it to md0. > > My IDE controller is: > 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) > > My first thought is that it's a hardware problem. I've had intermittent > IDE issues, although there have been no recent errors logged as reported > by smartctl. Regardless, I thought I should report this -- but if it's > an issue that can easily be explained by hardware problems, that's > likely the culprit. > > Let me know if you need any more information. Do you have CONFIG_4KSTACKS turned on? -Eric > Chris > > > ------------------------------------------------------------------------ > > kernel BUG at include/asm/dma-mapping.h:44! > invalid operand: 0000 [#1] > PREEMPT SMP > Modules linked in: xfs snd_intel8x0 > CPU: 3 > EIP: 0060:[] Not tainted VLI > EFLAGS: 00010246 (2.6.12) > EIP is at ide_build_sglist+0x92/0xb0 > eax: 00000000 ebx: df812000 ecx: 00000000 edx: 00000000 > esi: 00000021 edi: cf0b6ab8 ebp: 00000000 esp: d301badc > ds: 007b es: 007b ss: 0068 > Process xfs_fsr (pid: 2167, threadinfo=d301a000 task=d2228530) > Stack: c05bbba8 cf0b6ab8 df810000 c05bb980 00000000 c02d147f c05bbba8 cf0b6ab8 > c0133930 00000000 c05bb980 cf0b6ab8 c05bb980 c05bbba8 00000000 c02d18ec > c05bbba8 cf0b6ab8 00000012 12310071 c05bb980 c05bbba8 c02d39e9 c05bbba8 > Call Trace: > [] ide_build_dmatable+0x3f/0x170 > [] autoremove_wake_function+0x0/0x60 > [] ide_dma_setup+0x3c/0xd0 > [] __ide_do_rw_disk+0x2f9/0x520 > [] __delay+0x12/0x20 > [] start_request+0x156/0x240 > [] ide_do_request+0x22b/0x3c0 > [] do_ide_request+0x24/0x30 > [] __generic_unplug_device+0x3e/0x40 > [] generic_unplug_device+0x1e/0x30 > [] unplug_slaves+0xe8/0x100 > [] dm_table_unplug_all+0x46/0x50 > [] dm_unplug_all+0x27/0x40 > [] blk_backing_dev_unplug+0x19/0x20 > [] dio_await_one+0xc0/0xd0 > [] dio_await_completion+0x2b/0x60 > [] direct_io_worker+0x3f9/0x5a0 > [] xfs_ilock_map_shared+0x25/0x40 [xfs] > [] __blockdev_direct_IO+0x2eb/0x3fd > [] linvfs_get_blocks_direct+0x0/0x50 [xfs] > [] linvfs_unwritten_convert_direct+0x0/0x70 [xfs] > [] linvfs_direct_IO+0xe5/0xf0 [xfs] > [] linvfs_get_blocks_direct+0x0/0x50 [xfs] > [] linvfs_unwritten_convert_direct+0x0/0x70 [xfs] > [] _spin_unlock+0xd/0x30 > [] update_atime+0x9c/0xd0 > [] generic_file_direct_IO+0x72/0x120 > [] generic_file_direct_write+0x76/0x190 > [] xfs_write+0x53d/0xd20 [xfs] > [] linvfs_aio_read_invis+0x8e/0xa0 [xfs] > [] linvfs_write+0x10c/0x140 [xfs] > [] linvfs_ioctl+0x60/0x80 [xfs] > [] autoremove_wake_function+0x0/0x60 > [] _spin_lock+0x16/0x90 > [] dnotify_parent+0x3a/0xb0 > [] vfs_write+0xae/0x130 > [] sys_write+0x51/0x80 > [] sysenter_past_esp+0x54/0x75 > Code: 13 85 c0 74 26 8b 3d 10 2f 5b c0 41 29 f8 8b 7c 13 04 c1 f8 05 c1 e0 0c 01 f8 39 f1 89 44 13 08 7c d7 83 c4 08 89 f0 5b 5e 5f c3 <0f> 0b 2c 00 03 ea 45 c0 eb d0 0f 0b 29 00 03 ea 45 c0 eb b1 8d > From owner-linux-xfs@oss.sgi.com Mon Jun 27 23:50:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jun 2005 23:50:56 -0700 (PDT) Received: from mail-a.speedkom.net (mail-a.speedkom.net [213.182.0.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5S6ooH9008577 for ; Mon, 27 Jun 2005 23:50:50 -0700 Received: from exchange2.in.riwa-gis.de (mail.riwa-gis.de [213.182.7.84]) by mail-a.speedkom.net with SMTP id j5S6n5tE025769; Tue, 28 Jun 2005 08:49:13 +0200 Received: from mail pickup service by exchange2.in.riwa-gis.de with Microsoft SMTPSVC; Tue, 28 Jun 2005 08:49:04 +0200 PureMessageGuid: {92878EA4-2FA4-4C8D-841D-C334D8FE965B} thread-index: AcV7aM5wGQDoKwVVRKiZ+xuVmZHIEA== Received: from mailin2-a.mx.speedkom.net ([213.182.0.50]) by exchange2.in.riwa-gis.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Jun 2005 00:37:29 +0200 Received: from oss.sgi.com (oss.sgi.com [192.48.159.27]) by mailin2-a.mx.speedkom.net with ESMTP id j5RMbLbY028925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Jun 2005 00:37:28 +0200 Received: from oss (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5RMcOH9013324; Mon, 27 Jun 2005 15:38:27 -0700 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jun 2005 15:35:23 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5RMZEH9012854 for ; Mon, 27 Jun 2005 15:35:14 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5S0OLDU032339 for ; Mon, 27 Jun 2005 17:24:21 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5RMWi0F17745398; Mon, 27 Jun 2005 17:32:44 -0500 (CDT) Date: Tue, 28 Jun 2005 08:49:04 +0200 Message-ID: <011601c57bad$7950e330$0c14a8c0@in.riwagis.de> Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft CDO for Exchange 2000 From: "Eric Sandeen" User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dan" Cc: Subject: Re: Questions regarding stack size with RHEL AS 4.0 References: In-Reply-To: Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 5504 X-ecartis-version: Ecartis v1.0.0 X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs X-OriginalArrivalTime: 27 Jun 2005 22:37:31.0961 (UTC) FILETIME=[CE672A90:01C57B68] X-archive-position: 5506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 851 Lines: 18 Dan wrote: > I'm about to put together a low-end 3.2TiB fileserver for archival > purposes. It will not be hit heavy and will mostly house backup archives > / etc. The heaviest use scenario would be two NFS clients writing > multi-GB files and two CIFS (samba) clients reading different multi-GB > files. Since not *all* files are large files (maybe a couple million > smaller 4k-100k files) I don't want to use ext3. I do, however, want > a single filesystem (LVM has been...annoying in the past [performance, > etc]). XFS seems like the perfect option, but I'm concerned by the > research I've done on the 4k stack size issue. I think we already talked on IRC, but for posterity, I mentioned using SLES9 instead of RHEL4 for this application, because it already has tested xfs support, and it does not have the 4k stack issue. -Eric From owner-linux-xfs@oss.sgi.com Tue Jun 28 02:10:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jun 2005 02:10:05 -0700 (PDT) Received: from raad.intranet (dial169-164.awalnet.net [213.184.169.164] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5S99xH9025320 for ; Tue, 28 Jun 2005 02:10:01 -0700 Received: from i810 (rescueCli [10.254.254.253]) by raad.intranet (8.8.7/8.8.7) with ESMTP id MAA13488 for ; Tue, 28 Jun 2005 12:08:25 +0300 Message-Id: <200506280908.MAA13488@raad.intranet> From: "Al Boldi" To: Subject: XFS corruption during power-blackout Date: Tue, 28 Jun 2005 12:08:05 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcV7VVlEB06iPAm0R0SOBxzhNMKQcAAU5UMQAAW/rMA= X-archive-position: 5508 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: a1426z@gawab.com Precedence: bulk X-list: linux-xfs Content-Length: 1109 Lines: 28 Hans Reiser wrote: > Steve, there is a remark about XFS below which you are going to be > more expert on. > > Theodore Ts'o wrote: > >> >>XFS has similar issues where it assumes that hardware has powerfail >>interrupts, and that the OS can use said powerfail interrupt to stop >>DMA's in its tracks on an power failure, so that you don't have >>garbage written to key filesystem data structures when the memory >>starts suffering from the dropping voltage on the power bus faster >>than the DMA engine or the disk drives. So XFS is a great filesystem >>--- but you'd better be running it on a UPS, or on a system which has >>power fail interrupts and an OS that knows what to do. Ext3, because >>it does physical block journalling, does not suffer from this problem. >>(Yes, Resierfs uses logical journalling as well, so it suffers from >>the same problem.) >> True now, not so around 2.4.20 when XFS was rock-solid. I think they tried to improve on performance and broke something. I wish they would fix that because it forced me back to ext3, as in consistency over performance any time. From owner-linux-xfs@oss.sgi.com Tue Jun 28 02:29:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jun 2005 02:29:24 -0700 (PDT) Received: from mail.SerNet.de (mail.SerNet.DE [193.159.217.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5S9TLH9026525 for ; Tue, 28 Jun 2005 02:29:22 -0700 Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.51 #1) id 1DnCNe-0006bd-7L; Tue, 28 Jun 2005 11:27:46 +0200 Received: by intern.SerNet.DE id 1DnCNe-0004Im-00; Tue, 28 Jun 2005 11:27:46 +0200 Received: by intern.SerNet.DE id 1DnCNe-0004Ii-00; Tue, 28 Jun 2005 11:27:46 +0200 Received: by pell.sernet.de (Postfix, from userid 8354) id 9C0403F667; Tue, 28 Jun 2005 11:28:06 +0200 (CEST) Date: Tue, 28 Jun 2005 11:28:06 +0200 From: =?iso-8859-1?Q?Bj=F6rn?= JACKE To: Tim Shimmin Cc: Steve Lord , Joshua Schmidlkofer , linux-xfs@oss.sgi.com Subject: Re: Opteron Systems References: <42BB8C44.2010303@pacrimopen.com> <42BBF5A1.3000502@xfs.org> <20050627133749.F2458792@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20050627133749.F2458792@boing.melbourne.sgi.com> X-Q: Zuhoeren ist eine leise, aber elementare Aeusserung guten Benehmens. X-Operating-System: Linux 2.6.11.12-20050623094128-default i686 User-Agent: Mutt/1.5.8i Message-Id: Organization: Service Network GmbH, Goettingen, Germany Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j5S9TMH9026528 X-archive-position: 5509 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bj@sernet.de Precedence: bulk X-list: linux-xfs Content-Length: 469 Lines: 14 On 2005-06-27 at 13:37 +1000 Tim Shimmin sent off: > On IRIX we do have xfs_reno(1M) which can renumber inodes > by swaping extents, copying dirents, copying EAs etc...(relies on XFS > to allocate new inode). > However, it is not ported to Linux. is the sourcecode available so that doing a linux port is possible or would this have to be done from scratch? Bjoern -- Björn Jacke, SerNet Service Network GmbH Phone: +49-(0)551-370000-0, Fax: +49-(0)551-370000-9 From owner-linux-xfs@oss.sgi.com Tue Jun 28 05:13:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jun 2005 05:14:01 -0700 (PDT) Received: from ibox-server.openwired.net (60.Red-81-44-253.pooles.rima-tde.net [81.44.253.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5SCDmH9004177 for ; Tue, 28 Jun 2005 05:13:54 -0700 Received: from localhost (localhost [127.0.0.1]) by ibox-server.openwired.net (Postfix) with ESMTP id F20102E00F6 for ; Tue, 28 Jun 2005 14:10:16 +0100 (BST) Received: from ibox-server.openwired.net ([127.0.0.1]) by localhost (ibox-server.openwired.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18031-05 for ; Tue, 28 Jun 2005 14:10:14 +0100 (BST) Received: from [10.0.0.85] (unknown [10.0.0.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ibox-server.openwired.net (Postfix) with ESMTP id 71EF22E00F5 for ; Tue, 28 Jun 2005 14:10:14 +0100 (BST) Subject: patche for kernel 2.4.21-27.0.2.EL From: Carlos Gomez To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1119960899.3113.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 28 Jun 2005 14:14:59 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 5510 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: carlos.gomez@openwired.net Precedence: bulk X-list: linux-xfs Content-Length: 161 Lines: 6 Hi, I'm Carlos, I'm searching a xfs's patche for my linux. It uses kernel 2.4.21-27.0.2.EL, I don't see your xfs-2.4.20 patche, please, can you send me? thanks From owner-linux-xfs@oss.sgi.com Tue Jun 28 09:10:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jun 2005 09:10:41 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5SGAbH9031365 for ; Tue, 28 Jun 2005 09:10:38 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5SG9AxT005065 for ; Tue, 28 Jun 2005 11:09:10 -0500 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5SG990F17789557; Tue, 28 Jun 2005 11:09:09 -0500 (CDT) Message-ID: <42C17625.5070500@sgi.com> Date: Tue, 28 Jun 2005 11:09:09 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Gomez CC: linux-xfs@oss.sgi.com Subject: Re: patche for kernel 2.4.21-27.0.2.EL References: <1119960899.3113.2.camel@localhost.localdomain> In-Reply-To: <1119960899.3113.2.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5511 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 283 Lines: 16 Carlos Gomez wrote: > Hi, > I'm Carlos, I'm searching a xfs's patche for my linux. It uses kernel > 2.4.21-27.0.2.EL, I don't see your xfs-2.4.20 patche, please, can you > send me? > thanks > Try: ftp://oss.sgi.com/projects/xfs/testing/RHEL3/SRPMS/ for a starting point. -Eric From owner-linux-xfs@oss.sgi.com Tue Jun 28 17:26:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jun 2005 17:26:58 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5T0QrH9026383 for ; Tue, 28 Jun 2005 17:26:54 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05328; Wed, 29 Jun 2005 10:25:21 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5T0POkt2565744; Wed, 29 Jun 2005 10:25:26 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j5T0Inf1001073; Wed, 29 Jun 2005 10:18:49 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j5T0IlRL001071; Wed, 29 Jun 2005 10:18:47 +1000 Date: Wed, 29 Jun 2005 10:18:47 +1000 From: Nathan Scott To: Al Boldi Cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption during power-blackout Message-ID: <20050629001847.GB850@frodo> References: <200506280908.MAA13488@raad.intranet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506280908.MAA13488@raad.intranet> User-Agent: Mutt/1.5.3i X-archive-position: 5512 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 483 Lines: 15 On Tue, Jun 28, 2005 at 12:08:05PM +0300, Al Boldi wrote: > True now, not so around 2.4.20 when XFS was rock-solid. I think they tried > to improve on performance and broke something. I wish they would fix that > because it forced me back to ext3, as in consistency over performance any > time. Can you provide any details at all (ideally, a test case if its easily reproducible?) - your comments above are a bit too vague for me to intuit anything from them. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jun 28 21:55:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jun 2005 21:55:46 -0700 (PDT) Received: from raad.intranet ([213.184.187.99]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5T4tWH9019613 for ; Tue, 28 Jun 2005 21:55:34 -0700 Received: from i810 (rescueCli [10.254.254.253]) by raad.intranet (8.8.7/8.8.7) with ESMTP id HAA14576; Wed, 29 Jun 2005 07:53:34 +0300 Message-Id: <200506290453.HAA14576@raad.intranet> From: "Al Boldi" To: "'Nathan Scott'" Cc: , , , Subject: RE: XFS corruption during power-blackout Date: Wed, 29 Jun 2005 07:53:09 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20050629001847.GB850@frodo> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Thread-Index: AcV8R0RHxfHf5G1vQ8WamfNExp4fCAAFiv1g X-archive-position: 5513 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: a1426z@gawab.com Precedence: bulk X-list: linux-xfs Content-Length: 1144 Lines: 32 Hi Nathan, You wrote: { On Tue, Jun 28, 2005 at 12:08:05PM +0300, Al Boldi wrote: > True now, not so around 2.4.20 when XFS was rock-solid. I think they > tried to improve on performance and broke something. I wish they would > fix that because it forced me back to ext3, as in consistency over > performance any time. Can you provide any details... } Specifically, in 2.4.20 I did an acid test: Spawn 10 cp -a on some big dir like /usr. Let it run for a few seconds, then pull the plug. Don't reset-button, reset is different then pulling the plug. Don't poweroff-button, poweroff is different then pulling the plug. On reboot diff the dirs spawned. What I found were 4 things in the dest dir: 1. Missing Dirs,Files. That's OK. 2. Files of size 0. That's acceptable. 3. Corrupted Files. That's unacceptable. 4. Corrupted Files with original fingerprint. That's ABSOLUTELY unacceptable. Ext3 performed best with minimal files of size 0. XFS was second with more files of size 0. Reiser,JFS was worst with corruptions. When XFS was added into the vanilla-Kernel it caused corruptions like Reiser and JFS, which forced me back to Ext3. From owner-linux-xfs@oss.sgi.com Wed Jun 29 09:41:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 09:41:20 -0700 (PDT) Received: from mx2.tippett.com (mx2.tippett.com [64.81.248.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5TGfGH9028194 for ; Wed, 29 Jun 2005 09:41:17 -0700 Received: from hermes.tippett.com (hermes.tippett.com [192.168.3.20]) by mx2.tippett.com (8.12.8/8.12.8) with ESMTP id j5TGLhEj027805; Wed, 29 Jun 2005 09:21:44 -0700 Received: from [192.168.3.62] (gangsta.tippett.com [192.168.3.62]) by hermes.tippett.com (SGI-8.12.5/8.12.5) with ESMTP id j5TGdPlg5668303; Wed, 29 Jun 2005 09:39:26 -0700 (PDT) Message-ID: <42C2CE98.3020504@tippett.com> Date: Wed, 29 Jun 2005 09:38:48 -0700 From: Christian Rice Reply-To: xian@tippett.com Organization: Tippett Studio User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Al Boldi CC: "'Nathan Scott'" , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, reiserfs-list@namesys.com Subject: Re: XFS corruption during power-blackout References: <200506290453.HAA14576@raad.intranet> In-Reply-To: <200506290453.HAA14576@raad.intranet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (mx2.tippett.com [192.168.12.2]); Wed, 29 Jun 2005 09:21:47 -0700 (PDT) X-Scanned-By: MIMEDefang 2.48 on 192.168.12.2 X-archive-position: 5514 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xian@tippett.com Precedence: bulk X-list: linux-xfs Content-Length: 1599 Lines: 51 Al Boldi wrote: >Hi Nathan, >You wrote: { >On Tue, Jun 28, 2005 at 12:08:05PM +0300, Al Boldi wrote: > > >>True now, not so around 2.4.20 when XFS was rock-solid. I think they >>tried to improve on performance and broke something. I wish they would >>fix that because it forced me back to ext3, as in consistency over >>performance any time. >> >> > >Can you provide any details... >} > >Specifically, in 2.4.20 I did an acid test: >Spawn 10 cp -a on some big dir like /usr. >Let it run for a few seconds, then pull the plug. >Don't reset-button, reset is different then pulling the plug. >Don't poweroff-button, poweroff is different then pulling the plug. >On reboot diff the dirs spawned. > >What I found were 4 things in the dest dir: >1. Missing Dirs,Files. That's OK. >2. Files of size 0. That's acceptable. >3. Corrupted Files. That's unacceptable. >4. Corrupted Files with original fingerprint. That's ABSOLUTELY >unacceptable. > >Ext3 performed best with minimal files of size 0. >XFS was second with more files of size 0. >Reiser,JFS was worst with corruptions. > >When XFS was added into the vanilla-Kernel it caused corruptions like Reiser >and JFS, which forced me back to Ext3. > > > > > Pardon me if I haven't seen the whole thread. Do you have hard drive write cache turned off or, if it's a raid card, a battery backup on the write cache? That makes a big difference when operators begin doing things like pulling plugs and hitting reset. Again, no offense, just one of those "have you taken it out of the box, plugged it in and turned it on" kind of questions. From owner-linux-xfs@oss.sgi.com Wed Jun 29 10:04:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 10:04:10 -0700 (PDT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5TH47H9029692 for ; Wed, 29 Jun 2005 10:04:07 -0700 Received: from pimout4-ext.prodigy.net (pimout4-int.prodigy.net [207.115.4.203]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j5TH2ACg008657 for ; Wed, 29 Jun 2005 13:02:15 -0400 X-ORBL: [63.202.173.158] Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout4-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j5TH2Apc052270; Wed, 29 Jun 2005 13:02:14 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 2E231528F22; Wed, 29 Jun 2005 10:02:09 -0700 (PDT) Date: Wed, 29 Jun 2005 10:02:09 -0700 From: Chris Wedgwood To: Al Boldi Cc: "'Nathan Scott'" , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, reiserfs-list@namesys.com Subject: Re: XFS corruption during power-blackout Message-ID: <556815.441dd7d1ebc32b4a80e049e0ddca5d18e872c6e8a722b2aefa7525e9504533049d801014.ANY@taniwha.stupidest.org> References: <20050629001847.GB850@frodo> <200506290453.HAA14576@raad.intranet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506290453.HAA14576@raad.intranet> X-archive-position: 5515 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 396 Lines: 12 On Wed, Jun 29, 2005 at 07:53:09AM +0300, Al Boldi wrote: > What I found were 4 things in the dest dir: > 1. Missing Dirs,Files. That's OK. > 2. Files of size 0. That's acceptable. > 3. Corrupted Files. That's unacceptable. > 4. Corrupted Files with original fingerprint. That's ABSOLUTELY > unacceptable. disk usually default to caching these days and can lose data as a result, disable that From owner-linux-xfs@oss.sgi.com Wed Jun 29 10:57:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 10:57:50 -0700 (PDT) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5THviH9000451 for ; Wed, 29 Jun 2005 10:57:44 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Jun 2005 10:56:14 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Jun 2005 10:56:13 -0700 Message-ID: <42C2E0BC.8040508@xfs.org> Date: Wed, 29 Jun 2005 12:56:12 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: Al Boldi , "'Nathan Scott'" , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, reiserfs-list@namesys.com Subject: Re: XFS corruption during power-blackout References: <20050629001847.GB850@frodo> <200506290453.HAA14576@raad.intranet> <556815.441dd7d1ebc32b4a80e049e0ddca5d18e872c6e8a722b2aefa7525e9504533049d801014.ANY@taniwha.stupidest.org> In-Reply-To: <556815.441dd7d1ebc32b4a80e049e0ddca5d18e872c6e8a722b2aefa7525e9504533049d801014.ANY@taniwha.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2005 17:56:13.0812 (UTC) FILETIME=[D7118340:01C57CD3] X-archive-position: 5516 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1417 Lines: 40 Chris Wedgwood wrote: > On Wed, Jun 29, 2005 at 07:53:09AM +0300, Al Boldi wrote: > > >>What I found were 4 things in the dest dir: >>1. Missing Dirs,Files. That's OK. >>2. Files of size 0. That's acceptable. >>3. Corrupted Files. That's unacceptable. >>4. Corrupted Files with original fingerprint. That's ABSOLUTELY >>unacceptable. > > > disk usually default to caching these days and can lose data as a > result, disable that > There are IDE drives where the vendor will tell you that you will drasticly shorten the life of a drive if you turn off caching. There are also cool bits of technology which use the rotational energy of the spinning down drive to dump the cache out to a special track (or this may be an urban legend, not sure). Problem is, no one but the vendors really knows what any particular disk is going to do when you pull the plug. I did spend a bunch of time once ensuring that when you typed sync on xfs you could pull the power right after that and everything from before the sync survived. There have been a lot of changes both in xfs and the surrounding kernel since then. I do not know if anyone has attempted this effort again recently. If you care sufficiently about your data to want to do power fail testing then, even assuming the filesystem works perfectly: a) have a working, tested, regular backup policy b) keep the backups in a different building c) buy a UPS. Steve From owner-linux-xfs@oss.sgi.com Wed Jun 29 13:58:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 13:58:32 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5TKwPH9018638 for ; Wed, 29 Jun 2005 13:58:26 -0700 Received: from pimout2-ext.prodigy.net (pimout2-int.prodigy.net [207.115.4.217]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j5TKuqeC006769 for ; Wed, 29 Jun 2005 16:56:57 -0400 X-ORBL: [63.202.173.158] Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout2-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j5TKugOH373916; Wed, 29 Jun 2005 16:56:43 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id C4A0E528F22; Wed, 29 Jun 2005 13:56:41 -0700 (PDT) Date: Wed, 29 Jun 2005 13:56:41 -0700 From: Chris Wedgwood To: Steve Lord Cc: Al Boldi , "'Nathan Scott'" , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, reiserfs-list@namesys.com Subject: Re: XFS corruption during power-blackout Message-ID: <254889.27725ab660aa106eb6acc07307d71ef1fbd5b6fd366aebef9e2f611750fbcb467e46e8a4.IBX@taniwha.stupidest.org> References: <20050629001847.GB850@frodo> <200506290453.HAA14576@raad.intranet> <556815.441dd7d1ebc32b4a80e049e0ddca5d18e872c6e8a722b2aefa7525e9504533049d801014.ANY@taniwha.stupidest.org> <42C2E0BC.8040508@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42C2E0BC.8040508@xfs.org> X-archive-position: 5517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1204 Lines: 28 On Wed, Jun 29, 2005 at 12:56:12PM -0500, Steve Lord wrote: > There are also cool bits of technology which use the rotational > energy of the spinning down drive to dump the cache out to a special > track (or this may be an urban legend, not sure). This seems only to be true for very small writes. I suspect on power loss a drive and finish writing the current sector. Anyhow, I've tested power loss on drives with caching enabled and they definatley do lose data. Sometimes a couple of MBs worth. I don't know if this is true for all drives but NONE of the ones I had access to when testing did anything like save the cache --- pretty much all data that was inflight got lost. > I did spend a bunch of time once ensuring that when you typed sync > on xfs you could pull the power right after that and everything from > before the sync survived. I think this is probably still true. If I sync then drop power I don't seem to have any problems provided caching is off. If caching is enabled I still lose data. Linux does have a concept of write barriers but these are presently not implemented for XFS right now. Once they are I assume sunc + poweroff will be reliable with caching enabled. From owner-linux-xfs@oss.sgi.com Wed Jun 29 14:12:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 14:12:16 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5TLC9H9020174 for ; Wed, 29 Jun 2005 14:12:10 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA00495; Thu, 30 Jun 2005 07:10:30 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5TLAWkt2588386; Thu, 30 Jun 2005 07:10:32 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j5TLASj42588869; Thu, 30 Jun 2005 07:10:28 +1000 (EST) Date: Thu, 30 Jun 2005 07:10:28 +1000 From: Nathan Scott To: Steve Lord Cc: Chris Wedgwood , Al Boldi , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, reiserfs-list@namesys.com Subject: Re: XFS corruption during power-blackout Message-ID: <20050630071027.A2559808@wobbly.melbourne.sgi.com> References: <20050629001847.GB850@frodo> <200506290453.HAA14576@raad.intranet> <556815.441dd7d1ebc32b4a80e049e0ddca5d18e872c6e8a722b2aefa7525e9504533049d801014.ANY@taniwha.stupidest.org> <42C2E0BC.8040508@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <42C2E0BC.8040508@xfs.org>; from lord@xfs.org on Wed, Jun 29, 2005 at 12:56:12PM -0500 X-archive-position: 5518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 487 Lines: 16 On Wed, Jun 29, 2005 at 12:56:12PM -0500, Steve Lord wrote: > I did spend a bunch of time once ensuring that when you typed > sync on xfs you could pull the power right after that and > everything from before the sync survived. There have been a > lot of changes both in xfs and the surrounding kernel since > then. I do not know if anyone has attempted this effort > again recently. Yep, someone has, a number of times. And as Homer would say "its still good!". cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Jun 29 14:32:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 14:32:53 -0700 (PDT) Received: from chris.happyjack.org (c-67-170-85-37.hsd1.wa.comcast.net [67.170.85.37]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5TLWmH9022450 for ; Wed, 29 Jun 2005 14:32:50 -0700 Received: by chris.happyjack.org (Postfix, from userid 1000) id B9265C22E2; Wed, 29 Jun 2005 14:31:19 -0700 (PDT) Date: Wed, 29 Jun 2005 14:31:19 -0700 From: Chris Spiegel To: Eric Sandeen Cc: linux-ide@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Kernel BUG report Message-ID: <20050629212823.GA5222@midgard.spiegels> References: <20050622200609.GA12159@midgard.spiegels> <42C07EC1.10607@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42C07EC1.10607@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 5519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@happyjack.org Precedence: bulk X-list: linux-xfs Content-Length: 3051 Lines: 71 On Mon, Jun 27, 2005 at 05:33:37PM -0500, Eric Sandeen wrote: > >I ran into a bug while reorganizing an XFS filesystem with xfs_fsr. > > Do you have CONFIG_4KSTACKS turned on? > > -Eric No, I don't. Chris > >------------------------------------------------------------------------ > > > >kernel BUG at include/asm/dma-mapping.h:44! > >invalid operand: 0000 [#1] > >PREEMPT SMP > >Modules linked in: xfs snd_intel8x0 > >CPU: 3 > >EIP: 0060:[] Not tainted VLI > >EFLAGS: 00010246 (2.6.12) > >EIP is at ide_build_sglist+0x92/0xb0 > >eax: 00000000 ebx: df812000 ecx: 00000000 edx: 00000000 > >esi: 00000021 edi: cf0b6ab8 ebp: 00000000 esp: d301badc > >ds: 007b es: 007b ss: 0068 > >Process xfs_fsr (pid: 2167, threadinfo=d301a000 task=d2228530) > >Stack: c05bbba8 cf0b6ab8 df810000 c05bb980 00000000 c02d147f c05bbba8 > >cf0b6ab8 c0133930 00000000 c05bb980 cf0b6ab8 c05bb980 c05bbba8 > > 00000000 c02d18ec c05bbba8 cf0b6ab8 00000012 12310071 c05bb980 > > c05bbba8 c02d39e9 c05bbba8 Call Trace: > > [] ide_build_dmatable+0x3f/0x170 > > [] autoremove_wake_function+0x0/0x60 > > [] ide_dma_setup+0x3c/0xd0 > > [] __ide_do_rw_disk+0x2f9/0x520 > > [] __delay+0x12/0x20 > > [] start_request+0x156/0x240 > > [] ide_do_request+0x22b/0x3c0 > > [] do_ide_request+0x24/0x30 > > [] __generic_unplug_device+0x3e/0x40 > > [] generic_unplug_device+0x1e/0x30 > > [] unplug_slaves+0xe8/0x100 > > [] dm_table_unplug_all+0x46/0x50 > > [] dm_unplug_all+0x27/0x40 > > [] blk_backing_dev_unplug+0x19/0x20 > > [] dio_await_one+0xc0/0xd0 > > [] dio_await_completion+0x2b/0x60 > > [] direct_io_worker+0x3f9/0x5a0 > > [] xfs_ilock_map_shared+0x25/0x40 [xfs] > > [] __blockdev_direct_IO+0x2eb/0x3fd > > [] linvfs_get_blocks_direct+0x0/0x50 [xfs] > > [] linvfs_unwritten_convert_direct+0x0/0x70 [xfs] > > [] linvfs_direct_IO+0xe5/0xf0 [xfs] > > [] linvfs_get_blocks_direct+0x0/0x50 [xfs] > > [] linvfs_unwritten_convert_direct+0x0/0x70 [xfs] > > [] _spin_unlock+0xd/0x30 > > [] update_atime+0x9c/0xd0 > > [] generic_file_direct_IO+0x72/0x120 > > [] generic_file_direct_write+0x76/0x190 > > [] xfs_write+0x53d/0xd20 [xfs] > > [] linvfs_aio_read_invis+0x8e/0xa0 [xfs] > > [] linvfs_write+0x10c/0x140 [xfs] > > [] linvfs_ioctl+0x60/0x80 [xfs] > > [] autoremove_wake_function+0x0/0x60 > > [] _spin_lock+0x16/0x90 > > [] dnotify_parent+0x3a/0xb0 > > [] vfs_write+0xae/0x130 > > [] sys_write+0x51/0x80 > > [] sysenter_past_esp+0x54/0x75 > >Code: 13 85 c0 74 26 8b 3d 10 2f 5b c0 41 29 f8 8b 7c 13 04 c1 f8 05 c1 e0 > >0c 01 f8 39 f1 89 44 13 08 7c d7 83 c4 08 89 f0 5b 5e 5f c3 <0f> 0b 2c 00 > >03 ea 45 c0 eb d0 0f 0b 29 00 03 ea 45 c0 eb b1 8d From owner-linux-xfs@oss.sgi.com Wed Jun 29 16:12:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 16:12:46 -0700 (PDT) Received: from mx1.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5TNCbH9028891 for ; Wed, 29 Jun 2005 16:12:38 -0700 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 98424E909; Thu, 30 Jun 2005 01:11:05 +0200 (CEST) To: Chris Wedgwood Cc: Al Boldi , "'Nathan Scott'" , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, reiserfs-list@namesys.com Subject: Re: SPAM: Re: XFS corruption during power-blackout References: <20050629001847.GB850@frodo.suse.lists.linux.kernel> <200506290453.HAA14576@raad.intranet.suse.lists.linux.kernel> <556815.441dd7d1ebc32b4a80e049e0ddca5d18e872c6e8a722b2aefa7525e9504533049d801014.ANY@taniwha.stupidest.org.suse.lists.linux.kernel> <42C2E0BC.8040508@xfs.org.suse.lists.linux.kernel> <254889.27725ab660aa106eb6acc07307d71ef1fbd5b6fd366aebef9e2f611750fbcb467e46e8a4.IBX@taniwha.stupidest.org.suse.lists.linux.kernel> From: Andi Kleen Date: 30 Jun 2005 01:11:03 +0200 In-Reply-To: <254889.27725ab660aa106eb6acc07307d71ef1fbd5b6fd366aebef9e2f611750fbcb467e46e8a4.IBX@taniwha.stupidest.org.suse.lists.linux.kernel> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5520 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 626 Lines: 17 Chris Wedgwood writes: > If caching is enabled I still lose data. Linux does have a concept of > write barriers but these are presently not implemented for XFS right > now. I implemented them some time ago for log writes in XFS. Not for fsync though, although fsync usually does a log write afterwards so it should work in practice too. fdatasync might not. Don't know if the code hasn't bit rotted away and it also was a bit dumb. It was definitely there at some point. But then a lot of ATA disks and SCSI don't support barriers. Or at least the IDE barrier tests fails on several of my machines. -Andi From owner-linux-xfs@oss.sgi.com Wed Jun 29 18:18:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 18:18:26 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j5U1IKH9007575 for ; Wed, 29 Jun 2005 18:18:21 -0700 Received: (qmail invoked by alias); 30 Jun 2005 01:16:48 -0000 Received: from G0dce.g.pppool.de (EHLO [192.168.10.11]) [80.185.13.206] by mail.gmx.net (mp025) with SMTP; 30 Jun 2005 03:16:48 +0200 X-Authenticated: #2986359 Message-ID: <42C34803.40807@gmx.net> Date: Thu, 30 Jun 2005 03:16:51 +0200 From: evilninja User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Chris Spiegel Subject: Re: Kernel BUG report References: <20050622200609.GA12159@midgard.spiegels> <42C07EC1.10607@sgi.com> <20050629212823.GA5222@midgard.spiegels> In-Reply-To: <20050629212823.GA5222@midgard.spiegels> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-archive-position: 5521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 694 Lines: 26 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Spiegel schrieb: > On Mon, Jun 27, 2005 at 05:33:37PM -0500, Eric Sandeen wrote: > >>>I ran into a bug while reorganizing an XFS filesystem with xfs_fsr. >> sorry, i probably missed your original post, but is this reproducible if so, how? and, this report is with kernel 2.6.12, did it happen with older kernels too? - -- BOFH excuse #312: incompatible bit-registration operators -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCw0gDC/PVm5+NVoYRAstwAJ9Ps7H9roMJv7/nBDij1kznVOGZcwCg6dMT wTzwMv5XR3OlLM6X1p1jvm8= =ynDT -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Jun 29 18:33:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 18:33:50 -0700 (PDT) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5U1XjH9008742 for ; Wed, 29 Jun 2005 18:33:46 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5U1W6fE2707686; Thu, 30 Jun 2005 11:32:06 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j5U1W3QW2707592; Thu, 30 Jun 2005 11:32:03 +1000 (AEST) Date: Thu, 30 Jun 2005 11:32:03 +1000 From: Tim Shimmin To: =?iso-8859-1?Q?Bj=F6rn_JACKE?= Cc: Joshua Schmidlkofer , linux-xfs@oss.sgi.com Subject: Re: Opteron Systems Message-ID: <20050630113203.N2249146@boing.melbourne.sgi.com> References: <42BB8C44.2010303@pacrimopen.com> <42BBF5A1.3000502@xfs.org> <20050627133749.F2458792@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bj@sernet.de on Tue, Jun 28, 2005 at 11:28:06AM +0200 X-archive-position: 5522 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 577 Lines: 19 Hi Bjoern, On Tue, Jun 28, 2005 at 11:28:06AM +0200, Björn JACKE wrote: > On 2005-06-27 at 13:37 +1000 Tim Shimmin sent off: > > On IRIX we do have xfs_reno(1M) which can renumber inodes > > by swaping extents, copying dirents, copying EAs etc...(relies on XFS > > to allocate new inode). > > However, it is not ported to Linux. > > is the sourcecode available so that doing a linux port is possible or > would this have to be done from scratch? > The source code would need to be reviewed first. What need has arisen for you such that you want xfs_reno? Cheers, --Tim From owner-linux-xfs@oss.sgi.com Wed Jun 29 18:55:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 18:55:21 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5U1tHH9010155 for ; Wed, 29 Jun 2005 18:55:17 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5U3ih1h015717 for ; Wed, 29 Jun 2005 20:44:43 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5U1qmbT55366386 for ; Wed, 29 Jun 2005 18:52:48 -0700 (PDT) Received: from sgigollum (mtv-vpn-sw-corp-0-21.corp.sgi.com [134.15.0.21]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j5U1pddO42762177; Wed, 29 Jun 2005 18:51:40 -0700 (PDT) Message-Id: <200506300151.j5U1pddO42762177@cthulhu.engr.sgi.com> Reply-To: From: "Mike Gigante" To: "=?iso-8859-1?Q?'Bj=F6rn_JACKE'?=" , "'Tim Shimmin'" Cc: "'Steve Lord'" , "'Joshua Schmidlkofer'" , Subject: RE: Opteron Systems Date: Thu, 30 Jun 2005 11:51:36 +1000 Organization: SGI MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcV7w89/XwHputJ8S5ezbnhbOcvHWgBUhTxA X-archive-position: 5523 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mg@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 185 Lines: 8 There are no plans to provide xfs_reno on Linux. The principal reason for xfs_reno was to deal with legacy Irix XFS filesystems that were created before inode32 was available. Mike From owner-linux-xfs@oss.sgi.com Wed Jun 29 21:36:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jun 2005 21:36:42 -0700 (PDT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5U4aXH9023906 for ; Wed, 29 Jun 2005 21:36:34 -0700 Received: from pimout3-ext.prodigy.net (pimout3-int.prodigy.net [207.115.4.218]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j5U4YbCi028415 for ; Thu, 30 Jun 2005 00:34:44 -0400 X-ORBL: [63.202.173.158] Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout3-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j5U4Yi0d228008; Thu, 30 Jun 2005 00:34:44 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 8F7D8528F22; Wed, 29 Jun 2005 21:34:43 -0700 (PDT) Date: Wed, 29 Jun 2005 21:34:43 -0700 From: Chris Wedgwood To: Andi Kleen Cc: Al Boldi , "'Nathan Scott'" , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, reiserfs-list@namesys.com Subject: Re: SPAM: Re: XFS corruption during power-blackout Message-ID: <367867.1263d54e6d6102a1bac5bc8924d7aeb8243f5cbbb3568fcaabb74308aeb953fe1c2f5773.ANY@taniwha.stupidest.org> References: <20050629001847.GB850@frodo.suse.lists.linux.kernel> <200506290453.HAA14576@raad.intranet.suse.lists.linux.kernel> <556815.441dd7d1ebc32b4a80e049e0ddca5d18e872c6e8a722b2aefa7525e9504533049d801014.ANY@taniwha.stupidest.org.suse.lists.linux.kernel> <42C2E0BC.8040508@xfs.org.suse.lists.linux.kernel> <254889.27725ab660aa106eb6acc07307d71ef1fbd5b6fd366aebef9e2f611750fbcb467e46e8a4.IBX@taniwha.stupidest.org.suse.lists.linux.kernel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5524 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 585 Lines: 15 On Thu, Jun 30, 2005 at 01:11:03AM +0200, Andi Kleen wrote: > Don't know if the code hasn't bit rotted away and it also was a bit > dumb. It was definitely there at some point. It did rot away sadly but someone (speak up!) was working on a newer version of this I just don't know how much time they've had to work on this recently. > But then a lot of ATA disks and SCSI don't support barriers. Or at > least the IDE barrier tests fails on several of my machines. IDE has no barriers. I thought the kernel was aware of this and flushed when in those cases? Does that not work? From owner-linux-xfs@oss.sgi.com Thu Jun 30 07:31:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 07:31:59 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5UEVoH9003224 for ; Thu, 30 Jun 2005 07:31:51 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5UEUKxT004746 for ; Thu, 30 Jun 2005 09:30:21 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5UEUKR011259899 for ; Thu, 30 Jun 2005 09:30:20 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j5UEUIaV48342153; Thu, 30 Jun 2005 09:30:18 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j5UEUFgc014854; Thu, 30 Jun 2005 09:30:17 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j5UEUEEJ014852; Thu, 30 Jun 2005 09:30:15 -0500 Date: Thu, 30 Jun 2005 09:30:15 -0500 From: Eric Sandeen Message-Id: <200506301430.j5UEUEEJ014852@penguin.americas.sgi.com> To: linux-xfs@oss.sgi.com Cc: sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 937447 - clean up warnings in 2.4 ioctl code X-archive-position: 5527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 467 Lines: 15 clean up warnings with proper casts in copy_from_user Date: Thu Jun 30 07:29:47 PDT 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:195228a linux-2.4/xfs_ioctl.c - 1.117 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.117&r2=text&tr2=1.116&f=h From owner-linux-xfs@oss.sgi.com Thu Jun 30 08:20:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 08:20:15 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5UFKBH9011556 for ; Thu, 30 Jun 2005 08:20:11 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5UH9frK022780 for ; Thu, 30 Jun 2005 10:09:41 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5UFIfR011263658 for ; Thu, 30 Jun 2005 10:18:41 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j5UFIcaV48482225; Thu, 30 Jun 2005 10:18:38 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j5UFIcgc030014; Thu, 30 Jun 2005 10:18:38 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j5UFIcuu030012; Thu, 30 Jun 2005 10:18:38 -0500 Date: Thu, 30 Jun 2005 10:18:38 -0500 From: Eric Sandeen Message-Id: <200506301518.j5UFIcuu030012@penguin.americas.sgi.com> To: linux-xfs@oss.sgi.com Cc: sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 938899 - add ioctl32 handlers for 2.4 X-archive-position: 5528 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1121 Lines: 29 Add ioctl32 handlers for x86_64 & ppc64, for most ioctls on 2.4 kernels Date: Thu Jun 30 08:18:01 PDT 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: hch The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:195237a linux-2.4/xfs_ioctl32.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl32.h - new file; externs for ioctl32 registration routines linux-2.4/xfs_ioctl32.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl32.c - new file; set up table of ioctl32 converters, add conversion routine for xfs_flock64_t ioctls, add registration routines. linux-2.4/Makefile - 1.206 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/Makefile.diff?r1=text&tr1=1.206&r2=text&tr2=1.205&f=h - Add new ioctl32 source file linux-2.4/xfs_super.c - 1.307 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.307&r2=text&tr2=1.306&f=h - call ioctl32 registration routines on module init/exit From owner-linux-xfs@oss.sgi.com Thu Jun 30 09:36:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 09:36:27 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5UGaKH9017284 for ; Thu, 30 Jun 2005 09:36:25 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j5UIPpGN013636 for ; Thu, 30 Jun 2005 11:25:51 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j5UGYpR011266710 for ; Thu, 30 Jun 2005 11:34:51 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j5UGYnaV48274457; Thu, 30 Jun 2005 11:34:49 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j5UGYngc002118; Thu, 30 Jun 2005 11:34:49 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j5UGYmtj002116; Thu, 30 Jun 2005 11:34:48 -0500 Date: Thu, 30 Jun 2005 11:34:48 -0500 From: Eric Sandeen Message-Id: <200506301634.j5UGYmtj002116@penguin.americas.sgi.com> To: linux-xfs@oss.sgi.com Cc: sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 938905 - fix xfs_ioc_space writeable file test X-archive-position: 5530 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 673 Lines: 19 Fix check for writeable file in xfs_ioc_space ioctl code Date: Thu Jun 30 09:34:29 PDT 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: hch The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:195240a linux-2.6/xfs_ioctl.c - 1.122 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.122&r2=text&tr2=1.121&f=h linux-2.4/xfs_ioctl.c - 1.118 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.118&r2=text&tr2=1.117&f=h - Use f_mode when testing FMODE_WRITE not f_flags From owner-linux-xfs@oss.sgi.com Thu Jun 30 09:33:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 09:33:37 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5UGXPH9016775 for ; Thu, 30 Jun 2005 09:33:25 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5UGVtXS017025 for ; Thu, 30 Jun 2005 12:31:55 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5UGVtlF246226 for ; Thu, 30 Jun 2005 12:31:55 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5UGVsxf001462 for ; Thu, 30 Jun 2005 12:31:55 -0400 Received: from d01mlc04.pok.ibm.com (d01mlc04.pok.ibm.com [9.56.228.37]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5UGVshR001459; Thu, 30 Jun 2005 12:31:54 -0400 In-Reply-To: <254889.27725ab660aa106eb6acc07307d71ef1fbd5b6fd366aebef9e2f611750fbcb467e46e8a4.IBX@taniwha.stupidest.org> To: Chris Wedgwood Cc: Al Boldi , linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com, Steve Lord , "'Nathan Scott'" , reiserfs-list@namesys.com MIME-Version: 1.0 Subject: Re: XFS corruption during power-blackout X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Bryan Henderson Date: Thu, 30 Jun 2005 12:30:20 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 06/30/2005 12:31:54, Serialize complete at 06/30/2005 12:31:54 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 5529 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hbryan@us.ibm.com Precedence: bulk X-list: linux-xfs Content-Length: 1452 Lines: 32 >I don't know if this is true for all drives but NONE of the ones I had >access to when testing did anything like save the cache --- pretty >much all data that was inflight got lost. For another point of reference - were these ATA (personal class) or SCSI (commercial class) drives or both? Is write caching the default on typical SCSI devices? >Linux does have a concept of >write barriers but these are presently not implemented for XFS right >now. Once they are I assume sync + poweroff will be reliable with >caching enabled. But be careful with the 'sync' program/system call. As defined by POSIX, it is not a synchronizing operation. It's supposed to cause buffered writes to get hardened some time soon, not right now. So in theory, you can't pull the plug after typing "sync." In Linux, the implementation has changed a few times in this respect. In some versions, it at least _tries_ to implement "everything that was buffered when sync() started is hardened before sync() returns." In others, it implements "everything that was buffered when sync() started is hardened before the next sync() returns," and some 'sync' programs do multiple sync()s. And it's also filesystem-type-dependent. I don't know exactly what the present state is. fsync(), on the other hand, is a true synchronizing operation. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems From owner-linux-xfs@oss.sgi.com Thu Jun 30 11:48:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 11:48:39 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5UImHH9026891 for ; Thu, 30 Jun 2005 11:48:18 -0700 Received: from pimout1-ext.prodigy.net (pimout1-int.prodigy.net [207.115.5.65]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j5UIkieC012850 for ; Thu, 30 Jun 2005 14:46:48 -0400 X-ORBL: [63.202.173.158] Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout1-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j5UIkS8J085560; Thu, 30 Jun 2005 14:46:30 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id AC260528F22; Thu, 30 Jun 2005 11:46:27 -0700 (PDT) Date: Thu, 30 Jun 2005 11:46:27 -0700 From: Chris Wedgwood To: Bryan Henderson Cc: Al Boldi , linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com, Steve Lord , "'Nathan Scott'" , reiserfs-list@namesys.com Subject: Re: XFS corruption during power-blackout Message-ID: <054069.b93858d6b97c07747dc32be2dd8981b254d981528781006053dce7be58de88865a43b162.IBX@taniwha.stupidest.org> References: <254889.27725ab660aa106eb6acc07307d71ef1fbd5b6fd366aebef9e2f611750fbcb467e46e8a4.IBX@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5532 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 2390 Lines: 65 On Thu, Jun 30, 2005 at 12:30:20PM -0400, Bryan Henderson wrote: > For another point of reference - were these ATA (personal class) or > SCSI (commercial class) drives or both? IDE were Maxtor some old Maxtor 60GB disks and some not-so-old 200GB WD drives. Maxtor has 2MB cache. WD 8MB. The SCSI disks where 10K RPM SCA somethings. I think they were Segate (they've since been taken or else I would check). I have no idea what the cache is on those. > Is write caching the default on typical SCSI devices? I'm not sure. It seemed to be off by default for the SCSI disks and on by default for IDE when I checked. I can't rule out the bios/controller doing something there though. > But be careful with the 'sync' program/system call. As defined by > POSIX, it is not a synchronizing operation. Yes, but POSIX is broken in places. The linux implmentation (now and for sometime but not always) won't return until all dirty data is flushed. POSIX is a bit more sane about fsync(): The fsync() function can be used by an application to indicate that all data for the open file description named by fildes is to be transferred to the storage device associated with the file described by fildes in an implementation-dependent manner. The fsync() function does not return until the system has completed that action or until an error is detected. > It's supposed to cause buffered writes to get hardened some time > soon, not right now. So in theory, you can't pull the plug after > typing "sync." Data lss internal to the disks aside you can uner Linux. I do it all the time. Various other people do and this is something some people do test. > In others, it implements "everything that was buffered when sync() > started is hardened before the next sync() returns," That is what happens now. I'm not sure any other behavior makes sense does it? If it happens differently I would call that a bug. > and some 'sync' programs do multiple sync()s. Such programs are arguably broken (grub maybe?). If one doesn't work, then why should doing it -times? > And it's also filesystem-type-dependent. If a filesystem doesn't flush reliably with sync, I would call that a bug. > fsync(), on the other hand, is a true synchronizing operation. Again that requires the fs to behave correctly so if it fails it should be reported as a bug. From owner-linux-xfs@oss.sgi.com Thu Jun 30 12:46:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 12:46:39 -0700 (PDT) Received: from moskovskaya.fh-wedel.de (mail.fh-wedel.de [213.39.232.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5UJkQH9001249 for ; Thu, 30 Jun 2005 12:46:26 -0700 Received: from wohnheim.fh-wedel.de ([213.39.233.138]:34458) by moskovskaya.fh-wedel.de with esmtp (Exim 4.34) id 1Do4xX-0000LY-Ti; Thu, 30 Jun 2005 21:44:27 +0200 Received: from joern by wohnheim.fh-wedel.de with local (Exim 3.35 #1 (Debian)) id 1Do4xh-0003cO-00; Thu, 30 Jun 2005 21:44:37 +0200 Date: Thu, 30 Jun 2005 21:44:37 +0200 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Chris Wedgwood Cc: Bryan Henderson , Al Boldi , linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com, Steve Lord , "'Nathan Scott'" , reiserfs-list@namesys.com Subject: Re: XFS corruption during power-blackout Message-ID: <20050630194437.GC8374@wohnheim.fh-wedel.de> References: <254889.27725ab660aa106eb6acc07307d71ef1fbd5b6fd366aebef9e2f611750fbcb467e46e8a4.IBX@taniwha.stupidest.org> <054069.b93858d6b97c07747dc32be2dd8981b254d981528781006053dce7be58de88865a43b162.IBX@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <054069.b93858d6b97c07747dc32be2dd8981b254d981528781006053dce7be58de88865a43b162.IBX@taniwha.stupidest.org> User-Agent: Mutt/1.3.28i X-archive-position: 5533 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joern@wohnheim.fh-wedel.de Precedence: bulk X-list: linux-xfs Content-Length: 863 Lines: 26 On Thu, 30 June 2005 11:46:27 -0700, Chris Wedgwood wrote: > On Thu, Jun 30, 2005 at 12:30:20PM -0400, Bryan Henderson wrote: > > > In others, it implements "everything that was buffered when sync() > > started is hardened before the next sync() returns," > > That is what happens now. I'm not sure any other behavior makes sense > does it? > > If it happens differently I would call that a bug. While I agree with all the rest, this part confuses me. Do you mean that sync() should altually return immediatly, but the second sync() block until all data present at the time of the previous sync() is hardened? Or do you rather mean that a single sync() should block until all data currently present is hardened? Jörn -- It is better to die of hunger having lived without grief and fear, than to live with a troubled spirit amid abundance. -- Epictetus From owner-linux-xfs@oss.sgi.com Thu Jun 30 13:34:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 13:34:14 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5UKY4H9004005 for ; Thu, 30 Jun 2005 13:34:05 -0700 Received: from pimout1-ext.prodigy.net (pimout1-int.prodigy.net [207.115.5.65]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j5UKWZeC006999 for ; Thu, 30 Jun 2005 16:32:36 -0400 X-ORBL: [63.202.173.158] Received: from taniwha.stupidest.org (adsl-63-202-173-158.dsl.snfc21.pacbell.net [63.202.173.158]) by pimout1-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j5UKWNCM083996; Thu, 30 Jun 2005 16:32:28 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id A1985528F22; Thu, 30 Jun 2005 13:32:23 -0700 (PDT) Date: Thu, 30 Jun 2005 13:32:23 -0700 From: Chris Wedgwood To: J?rn Engel Cc: Bryan Henderson , Al Boldi , linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com, Steve Lord , "'Nathan Scott'" , reiserfs-list@namesys.com Subject: Re: XFS corruption during power-blackout Message-ID: <947885.634f7bc00f9a47e9c90ffbeec9ebb14a812e2dab7a64e2d09cedc7aa2589ffaf3593543a.IBX@taniwha.stupidest.org> References: <254889.27725ab660aa106eb6acc07307d71ef1fbd5b6fd366aebef9e2f611750fbcb467e46e8a4.IBX@taniwha.stupidest.org> <054069.b93858d6b97c07747dc32be2dd8981b254d981528781006053dce7be58de88865a43b162.IBX@taniwha.stupidest.org> <20050630194437.GC8374@wohnheim.fh-wedel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050630194437.GC8374@wohnheim.fh-wedel.de> X-archive-position: 5534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 483 Lines: 12 On Thu, Jun 30, 2005 at 09:44:37PM +0200, J?rn Engel wrote: > Or do you rather mean that a single sync() should block until all data > currently present is hardened? Logically sync() should return only after all dirty buffers that existed before sync() was called are flushed. Anything more than this (i.e. waiting on newly (since sync was called but before it returns) dirtied buffers) could live-lock (actually, this used to happen sometimes, I don't know if that's the case). From owner-linux-xfs@oss.sgi.com Thu Jun 30 13:50:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 13:50:29 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5UKoMH9005005 for ; Thu, 30 Jun 2005 13:50:22 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5UKmoen004344 for ; Thu, 30 Jun 2005 16:48:50 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5UKmolF246046 for ; Thu, 30 Jun 2005 16:48:50 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5UKmocE017284 for ; Thu, 30 Jun 2005 16:48:50 -0400 Received: from [9.56.227.90] (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5UKmoS4017274; Thu, 30 Jun 2005 16:48:50 -0400 In-Reply-To: <054069.b93858d6b97c07747dc32be2dd8981b254d981528781006053dce7be58de88865a43b162.IBX@taniwha.stupidest.org> To: Chris Wedgwood Cc: Al Boldi , linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com, Steve Lord , "'Nathan Scott'" , reiserfs-list@namesys.com MIME-Version: 1.0 Subject: Re: XFS corruption during power-blackout X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Bryan Henderson Date: Thu, 30 Jun 2005 13:49:22 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_06092005|June 09, 2005) at 06/30/2005 16:48:49, Serialize complete at 06/30/2005 16:48:49 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 5535 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hbryan@us.ibm.com Precedence: bulk X-list: linux-xfs Content-Length: 2993 Lines: 69 >POSIX is broken in places ... >If it happens differently I would call that a bug. I think you're confusing goodness with correctness. POSIX is a definition; it can't be broken. A bug is where don't meet your own specification. So if the spec doesn't say you have to be synchronous, it's not a bug not to be synchronous. Call it a design flaw if you want. >> In others, it implements "everything that was buffered when sync() >> started is hardened before the next sync() returns," > >That is what happens now. I'm not sure any other behavior makes sense >does it? I think you quoted the wrong part. From context, I think you meant "everything that was buffered when sync() started is hardened before sync() returns." And it's also my understanding that current Linux does that. Another Linux sync() behavior is that it keeps syncing super blocks until every super block is clean at the same moment. That has given me fits. I don't know what the goal of that is -- it came in around 2.4.10. >POSIX is a bit more sane about fsync(): > > The fsync() function can be used by an application to indicate > that all data for the open file description named by fildes is > to be transferred to the storage device associated with the file > described by fildes in an implementation-dependent manner. The > fsync() function does not return until the system has completed > that action or until an error is detected. Strange; that's not the way I remember it. I remember it being much more vague; in particular, I remember a specification that did not assume that a file is associated with a particular device and referred instead to "stable storage," the definition of which was entirely up to the implementation. In other words, the definition I've been working from was more grown-up. I wonder what the difference is. >> and some 'sync' programs do multiple sync()s. > >Such programs are arguably broken (grub maybe?). If one doesn't work, >then why should doing it -times? It's because of the words before that: "everything that was buffered when sync() started is hardened before the next sync() returns." The point is that the second sync() is the one that waits (it actually waits for the previous one to finish before it starts). By the way, I'm not talking about Linux at this point. I'm talking about so-called POSIX systems in general. But it does sound like Linux has a pretty firm philosophy of synchronous sync (I see it documented in an old man page), so I guess it's OK to rely on it. There are scenarios where you'd rather not have a process tied up while syncing takes place. Stepping back, I would guess the primary original purpose of sync() was to allow you to make a sync daemon. Early Unix systems did not have in-kernel safety clean timers. A user space process did that. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems From owner-linux-xfs@oss.sgi.com Thu Jun 30 14:09:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 14:10:05 -0700 (PDT) Received: from moskovskaya.fh-wedel.de (mail.fh-wedel.de [213.39.232.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5UL9rH9006510 for ; Thu, 30 Jun 2005 14:09:54 -0700 Received: from wohnheim.fh-wedel.de ([213.39.233.138]:42531) by moskovskaya.fh-wedel.de with esmtp (Exim 4.34) id 1Do6GH-0006Pz-UW; Thu, 30 Jun 2005 23:08:06 +0200 Received: from joern by wohnheim.fh-wedel.de with local (Exim 3.35 #1 (Debian)) id 1Do6GD-0004Bk-00; Thu, 30 Jun 2005 23:07:49 +0200 Date: Thu, 30 Jun 2005 23:07:49 +0200 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Chris Wedgwood Cc: Bryan Henderson , Al Boldi , linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com, Steve Lord , "'Nathan Scott'" , reiserfs-list@namesys.com Subject: Re: XFS corruption during power-blackout Message-ID: <20050630210749.GA16084@wohnheim.fh-wedel.de> References: <254889.27725ab660aa106eb6acc07307d71ef1fbd5b6fd366aebef9e2f611750fbcb467e46e8a4.IBX@taniwha.stupidest.org> <054069.b93858d6b97c07747dc32be2dd8981b254d981528781006053dce7be58de88865a43b162.IBX@taniwha.stupidest.org> <20050630194437.GC8374@wohnheim.fh-wedel.de> <947885.634f7bc00f9a47e9c90ffbeec9ebb14a812e2dab7a64e2d09cedc7aa2589ffaf3593543a.IBX@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <947885.634f7bc00f9a47e9c90ffbeec9ebb14a812e2dab7a64e2d09cedc7aa2589ffaf3593543a.IBX@taniwha.stupidest.org> User-Agent: Mutt/1.3.28i X-archive-position: 5536 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joern@wohnheim.fh-wedel.de Precedence: bulk X-list: linux-xfs Content-Length: 752 Lines: 23 On Thu, 30 June 2005 13:32:23 -0700, Chris Wedgwood wrote: > On Thu, Jun 30, 2005 at 09:44:37PM +0200, J?rn Engel wrote: > > > Or do you rather mean that a single sync() should block until all data > > currently present is hardened? > > Logically sync() should return only after all dirty buffers that > existed before sync() was called are flushed. That's what I thought. Thanks for the confirmation. > Anything more than this (i.e. waiting on newly (since sync was called > but before it returns) dirtied buffers) could live-lock (actually, > this used to happen sometimes, I don't know if that's the case). ... and would be totally useless anyway, yep. Jörn -- The strong give up and move away, while the weak give up and stay. -- unknown From owner-linux-xfs@oss.sgi.com Thu Jun 30 18:15:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 18:15:22 -0700 (PDT) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j611F8H9023648 for ; Thu, 30 Jun 2005 18:15:08 -0700 Received: from saturn (c211-28-166-127.eburwd2.vic.optusnet.com.au [211.28.166.127]) by mail02.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j611DApH016649; Fri, 1 Jul 2005 11:13:12 +1000 Received: from [192.168.1.54] (helo=kennedy.flamingspork.com) by saturn with esmtp (Exim 3.35 #1 (Debian)) id 1DoA5d-0007sa-00; Fri, 01 Jul 2005 11:13:09 +1000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by kennedy.flamingspork.com (Postfix) with ESMTP id 8BB151C23C39; Fri, 1 Jul 2005 11:09:02 +1000 (EST) Subject: Re: XFS corruption during power-blackout From: Stewart Smith To: Chris Wedgwood Cc: Bryan Henderson , Al Boldi , linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com, Steve Lord , "'Nathan Scott'" , reiserfs-list@namesys.com In-Reply-To: <054069.b93858d6b97c07747dc32be2dd8981b254d981528781006053dce7be58de88865a43b162.IBX@taniwha.stupidest.org> References: <254889.27725ab660aa106eb6acc07307d71ef1fbd5b6fd366aebef9e2f611750fbcb467e46e8a4.IBX@taniwha.stupidest.org> <054069.b93858d6b97c07747dc32be2dd8981b254d981528781006053dce7be58de88865a43b162.IBX@taniwha.stupidest.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vYORHOKhdez9j8DqZeqo" Date: Fri, 01 Jul 2005 11:09:01 +1000 Message-Id: <1120180141.6048.102.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-archive-position: 5537 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: linux-xfs Content-Length: 2775 Lines: 75 --=-vYORHOKhdez9j8DqZeqo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-06-30 at 11:46 -0700, Chris Wedgwood wrote: > Yes, but POSIX is broken in places. The linux implmentation (now and > for sometime but not always) won't return until all dirty data is > flushed. POSIX, in regard to fsync() provides "flexibility for the implementation" - maybe your environment is special and you don't buffer anything, so fsync() is null. Or perhaps you cannot control some of the disk caches, so fsync() is null. In newer systems, you can check for the flag POSIX_SYNCHRONIZED_IO (or similar) that, if set, gaurentees that fsync() is synchronously flushing buffers to disk. However, this only came into the spec in 99 or 2000 i think, so there are still a lot of systems in which you have to know the behaviour. > > and some 'sync' programs do multiple sync()s. >=20 > Such programs are arguably broken (grub maybe?). If one doesn't work, > then why should doing it -times? It's a legacy from the days when it was an async operation. The idea went: that the time it took to type sync and press enter three times (note, no using up-arrow, enter - typing) would be long enough for the buffers that started to get flushed on the first sync to have hit disk. > > And it's also filesystem-type-dependent. >=20 > If a filesystem doesn't flush reliably with sync, I would call that a > bug. >=20 > > fsync(), on the other hand, is a true synchronizing operation. >=20 > Again that requires the fs to behave correctly so if it fails it > should be reported as a bug. It's all fun and games - reliably getting data to disk is not fun. If Linux can reliably follow the idea that fsync() is synchronous and really does flush everything to disk, then it will be a lot better off then a lot of other platforms. Also, it'd be useful to have a list of where bugs affecting this have been found and in what kernels - It is not out of the question explicitly coding in exceptions (read: big warnings to users) for these systems. I guess a list of known-bad drives and controllers could be useful too. Doubly useful if the kernel could report this, but a userspace list would also be good.=20 --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-vYORHOKhdez9j8DqZeqo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iQCVAwUAQsSXrYwDm44RooHBAQJ6hQP9H9lfHmJSHCLxz+sfbmiUAeY44udyywOs tQSnNDhNbiP8ICWHJCcFjxWEo5pVOEeMvd+G4E0bYpGtAMm91bW780Y0ZQGuzrHQ WaL4aa43fApYNPhg9EiwyJd9zyi7c9Yn5/XKuottolgxZ7oKWGoqwT60RIO21st7 V2jvpIiSjX0= =16RG -----END PGP SIGNATURE----- --=-vYORHOKhdez9j8DqZeqo-- From owner-linux-xfs@oss.sgi.com Thu Jun 30 20:33:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jun 2005 20:33:58 -0700 (PDT) Received: from chris.happyjack.org (c-67-170-85-37.hsd1.wa.comcast.net [67.170.85.37]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j613XrH9004491 for ; Thu, 30 Jun 2005 20:33:55 -0700 Received: by chris.happyjack.org (Postfix, from userid 1000) id CDE3FC23D9; Thu, 30 Jun 2005 20:32:22 -0700 (PDT) Date: Thu, 30 Jun 2005 20:32:22 -0700 From: Chris Spiegel To: evilninja Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel BUG report Message-ID: <20050701033222.GA31855@midgard.spiegels> References: <20050622200609.GA12159@midgard.spiegels> <42C07EC1.10607@sgi.com> <20050629212823.GA5222@midgard.spiegels> <42C34803.40807@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42C34803.40807@gmx.net> User-Agent: Mutt/1.4.2.1i X-archive-position: 5538 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@happyjack.org Precedence: bulk X-list: linux-xfs Content-Length: 536 Lines: 16 On Thu, Jun 30, 2005 at 03:16:51AM +0200, evilninja wrote: > Chris Spiegel schrieb: > > On Mon, Jun 27, 2005 at 05:33:37PM -0500, Eric Sandeen wrote: > > > >>>I ran into a bug while reorganizing an XFS filesystem with xfs_fsr. > >> > > sorry, i probably missed your original post, but is this reproducible if > so, how? and, this report is with kernel 2.6.12, did it happen with older > kernels too? No, unfortunately it was a one-time occurrence (so far, anyway). Although, depending on the problem, perhaps it's fortunate! Chris