From owner-linux-xfs@oss.sgi.com Thu Sep 1 00:46:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Sep 2005 00:46:14 -0700 (PDT) Received: from indonesia.procaptura.com (indonesia.procaptura.com [193.214.130.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j817k8iL013267 for ; Thu, 1 Sep 2005 00:46:09 -0700 Received: from localhost ([127.0.0.1]) by indonesia.procaptura.com with esmtp (Exim 4.30) id 1EAjjX-0006iD-1B for linux-xfs@oss.sgi.com; Thu, 01 Sep 2005 09:43:39 +0200 Message-ID: <4316B12B.8020104@procaptura.com> Date: Thu, 01 Sep 2005 09:43:39 +0200 From: Toralf Lund User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Directory versions (again)... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6021 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: toralf@procaptura.com Precedence: bulk X-list: linux-xfs I still have some IRIX xfs disks that I'd like to move to a Linux box. Now, the FAQ sais > Make sure that the directory format is version 2 on the IRIX filesystems (this is the default since IRIX 6.5.5). Linux can only read v2 directories. So unless this has changed recently, I need to make sure the fs has version 2 directories. The question is, how do I check the version of a given volume? I know I've done this a number of times in the past, but I always seem to forget how I did it, and finding info on this in the manual pages is not very easy. Can someone please remind me? (Suggestion: Add a line to the above mentioned FAQ entry starting with "To return the directory version of an existing filesystem, execute the command") - Toralf From owner-linux-xfs@oss.sgi.com Thu Sep 1 03:41:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Sep 2005 03:41:05 -0700 (PDT) Received: from waldorf.loreland.org (waldorf.loreland.org [210.48.107.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j81AexiL024357 for ; Thu, 1 Sep 2005 03:41:00 -0700 Received: from localhost (localhost [127.0.0.1]) by waldorf.loreland.org (Postfix) with ESMTP id 7849E4DE41D; Thu, 1 Sep 2005 22:38:29 +1200 (NZST) Received: from waldorf.loreland.org ([127.0.0.1]) by localhost (waldorf [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15761-05; Thu, 1 Sep 2005 22:38:28 +1200 (NZST) Received: from [192.168.9.61] (akl-ns25.oktobor.com [210.48.107.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by waldorf.loreland.org (Postfix) with ESMTP id 9866A4AD58A; Thu, 1 Sep 2005 22:38:28 +1200 (NZST) Message-ID: <4316DA13.8020203@loreland.org> Date: Thu, 01 Sep 2005 22:38:11 +1200 From: James Braid User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Toralf Lund CC: linux-xfs@oss.sgi.com Subject: Re: Directory versions (again)... References: <4316B12B.8020104@procaptura.com> In-Reply-To: <4316B12B.8020104@procaptura.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6022 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jamesb@loreland.org Precedence: bulk X-list: linux-xfs Toralf Lund wrote: > I still have some IRIX xfs disks that I'd like to move to a Linux box. > Now, the FAQ sais > >> Make sure that the directory format is version 2 on the IRIX filesystems > > (this is the default since IRIX 6.5.5). > Linux can only read v2 directories. > > So unless this has changed recently, I need to make sure the fs has > version 2 directories. The question is, how do I check the version of a > given volume? I know I've done this a number of times in the past, but I > always seem to forget how I did it, and finding info on this in the > manual pages is not very easy. Can someone please remind me? on IRIX, 'xfs_growfs -n /filesystem' should do the trick From owner-linux-xfs@oss.sgi.com Thu Sep 1 04:00:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Sep 2005 04:01:00 -0700 (PDT) Received: from gw-eur4.philips.com (gw-eur4.philips.com [161.85.125.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j81B0qiL026291 for ; Thu, 1 Sep 2005 04:00:53 -0700 Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com [130.144.57.168]) by gw-eur4.philips.com (Postfix) with ESMTP id 99DC04972C for ; Thu, 1 Sep 2005 10:58:19 +0000 (UTC) Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 6C0F716FC8 for ; Thu, 1 Sep 2005 10:58:19 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP id 478AC2C8B for ; Thu, 1 Sep 2005 10:58:19 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id 1D1E83C for ; Thu, 1 Sep 2005 10:58:19 +0000 (GMT) Subject: xfs_repair To: xfs X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Darren Miller Date: Thu, 1 Sep 2005 11:56:13 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.3FP1HF265 | August 8, 2005) at 01/09/2005 12:56:15 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 6023 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: darren.miller@philips.com Precedence: bulk X-list: linux-xfs 2.6.36 aborts during phase6, 2.5.6 doesn't compile at all, but the source from CVS aborts during phase 2 on a bad INODE reallocation. Any news when a working version of xfs_repair will be available to cope with problem filesystems? ============================================================================== Darren Miller Principal Systems Support Engineer Microsoft Certified Professional SCO Advanced Certified Engineer Information Systems Department (Core Server Support) Philips Semiconductors, Milbrook Industrial Estate, Southampton, SO15 0DJ, England Direct Dial In: +44 (0) 2380 312681 From owner-linux-xfs@oss.sgi.com Thu Sep 1 05:55:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Sep 2005 05:55:07 -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 j81Ct1iL005671 for ; Thu, 1 Sep 2005 05:55:01 -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 j81EqSLJ004241 for ; Thu, 1 Sep 2005 07:52: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 j81CqAsS86933275; Thu, 1 Sep 2005 05:52:11 -0700 (PDT) Message-ID: <4316F97A.60901@sgi.com> Date: Thu, 01 Sep 2005 07:52:10 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren Miller CC: xfs Subject: Re: xfs_repair References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6024 X-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 Darren Miller wrote: > 2.6.36 aborts during phase6, 2.5.6 doesn't compile at all, but the source > from CVS aborts during phase 2 on a bad INODE reallocation. > > Any news when a working version of xfs_repair will be available to cope > with problem filesystems? Please file a bug at http://oss.sgi.com/bugzilla/ with as much info as possible on the CVS problem. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Thu Sep 1 06:08:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Sep 2005 06:08:32 -0700 (PDT) Received: from indonesia.procaptura.com (indonesia.procaptura.com [193.214.130.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j81D8NiL006979 for ; Thu, 1 Sep 2005 06:08:24 -0700 Received: from localhost ([127.0.0.1]) by indonesia.procaptura.com with esmtp (Exim 4.30) id 1EAolJ-0002ON-FP; Thu, 01 Sep 2005 15:05:49 +0200 Message-ID: <4316FCAD.9060003@procaptura.com> Date: Thu, 01 Sep 2005 15:05:49 +0200 From: Toralf Lund User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Braid CC: linux-xfs@oss.sgi.com Subject: Re: Directory versions (again)... References: <4316B12B.8020104@procaptura.com> <4316DA13.8020203@loreland.org> In-Reply-To: <4316DA13.8020203@loreland.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6025 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: toralf@procaptura.com Precedence: bulk X-list: linux-xfs James Braid wrote: >Toralf Lund wrote: > > >>I still have some IRIX xfs disks that I'd like to move to a Linux box. >>Now, the FAQ sais >> >> >> >>>Make sure that the directory format is version 2 on the IRIX filesystems >>> >>> >>(this is the default since IRIX 6.5.5). >>Linux can only read v2 directories. >> >>So unless this has changed recently, I need to make sure the fs has >>version 2 directories. The question is, how do I check the version of a >>given volume? I know I've done this a number of times in the past, but I >>always seem to forget how I did it, and finding info on this in the >>manual pages is not very easy. Can someone please remind me? >> >> > >on IRIX, 'xfs_growfs -n /filesystem' should do the trickOK > > Right. It's the "naming =" value, isn't it? I actually tried the command earlier, but never realised that the info was in there when I looked at the output ;-/ Thanks. - Toralf From owner-linux-xfs@oss.sgi.com Thu Sep 1 06:24:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Sep 2005 06:24:53 -0700 (PDT) Received: from waldorf.loreland.org (waldorf.loreland.org [210.48.107.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j81DOniL008618 for ; Thu, 1 Sep 2005 06:24:49 -0700 Received: from localhost (localhost [127.0.0.1]) by waldorf.loreland.org (Postfix) with ESMTP id 19A8D4DE3C7; Fri, 2 Sep 2005 01:22:19 +1200 (NZST) Received: from waldorf.loreland.org ([127.0.0.1]) by localhost (waldorf [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30957-02-2; Fri, 2 Sep 2005 01:22:18 +1200 (NZST) Received: from [192.168.9.61] (akl-ns25.oktobor.com [210.48.107.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by waldorf.loreland.org (Postfix) with ESMTP id 53FD14DE1E5; Fri, 2 Sep 2005 01:22:18 +1200 (NZST) Message-ID: <43170079.70101@loreland.org> Date: Fri, 02 Sep 2005 01:22:01 +1200 From: James Braid User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Toralf Lund CC: linux-xfs@oss.sgi.com Subject: Re: Directory versions (again)... References: <4316B12B.8020104@procaptura.com> <4316DA13.8020203@loreland.org> <4316FCAD.9060003@procaptura.com> In-Reply-To: <4316FCAD.9060003@procaptura.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6026 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jamesb@loreland.org Precedence: bulk X-list: linux-xfs Toralf Lund wrote: > James Braid wrote: >> Toralf Lund wrote: >>> So unless this has changed recently, I need to make sure the fs has >>> version 2 directories. The question is, how do I check the version of a >>> given volume? I know I've done this a number of times in the past, but I >>> always seem to forget how I did it, and finding info on this in the >>> manual pages is not very easy. Can someone please remind me? >>> >> >> >> on IRIX, 'xfs_growfs -n /filesystem' should do the trickOK >> >> > Right. It's the "naming =" value, isn't it? yep, thats right.. you can have version 2 logs as well, but thats a linux-only think afaik. From owner-linux-xfs@oss.sgi.com Thu Sep 1 18:14:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Sep 2005 18:14:18 -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 j821EAiL010994 for ; Thu, 1 Sep 2005 18:14:11 -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 j821BcfE4499681; Fri, 2 Sep 2005 11:11:38 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j821BYEE4727414; Fri, 2 Sep 2005 11:11:34 +1000 (AEST) Date: Fri, 2 Sep 2005 11:11:34 +1000 From: Tim Shimmin To: James Braid Cc: Toralf Lund , linux-xfs@oss.sgi.com Subject: Re: Directory versions (again)... Message-ID: <20050902111134.U4600499@boing.melbourne.sgi.com> References: <4316B12B.8020104@procaptura.com> <4316DA13.8020203@loreland.org> <4316FCAD.9060003@procaptura.com> <43170079.70101@loreland.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: <43170079.70101@loreland.org>; from jamesb@loreland.org on Fri, Sep 02, 2005 at 01:22:01AM +1200 X-archive-position: 6027 X-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 On Fri, Sep 02, 2005 at 01:22:01AM +1200, James Braid wrote: > Toralf Lund wrote: > > James Braid wrote: > >> Toralf Lund wrote: > >>> So unless this has changed recently, I need to make sure the fs has > >>> version 2 directories. The question is, how do I check the version of a > >>> given volume? I know I've done this a number of times in the past, but I > >>> always seem to forget how I did it, and finding info on this in the > >>> manual pages is not very easy. Can someone please remind me? > >>> > >> > >> > >> on IRIX, 'xfs_growfs -n /filesystem' should do the trickOK > >> > >> > > Right. It's the "naming =" value, isn't it? > > yep, thats right.. > > you can have version 2 logs as well, but thats a linux-only think afaik. > FYI, v2 logs have been in IRIX since IRIX 6.5.26 (were in Linux for a while before then). --Tim From owner-linux-xfs@oss.sgi.com Thu Sep 1 18:16:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Sep 2005 18:16:07 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j821FxiL011244 for ; Thu, 1 Sep 2005 18:16:03 -0700 Received: by zproxy.gmail.com with SMTP id 18so203692nzp for ; Thu, 01 Sep 2005 18:13:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=f4p1hXptnQnCMCKKMS1chOvMBnYf4Mbd+N44qJmY/lbb4Os97Wk7kakzv7VIqSKrjX9/shmnLKGI9KJwTPyQBsHZCUPJBlJMjKePRbjVLK1E9d9bn8tXx1TT64GSHz7FUTQHrwDW/lPaxzPU0JaArNb9RmFwUMPBjT62Icn0xlI= Received: by 10.36.91.1 with SMTP id o1mr1725711nzb; Thu, 01 Sep 2005 18:13:30 -0700 (PDT) Received: by 10.36.160.1 with HTTP; Thu, 1 Sep 2005 18:13:29 -0700 (PDT) Message-ID: Date: Thu, 1 Sep 2005 21:13:30 -0400 From: A JM To: evilninja Subject: Re: [OT] Re: XFS - hard drive dying Cc: linux-xfs@oss.sgi.com In-Reply-To: <4302BB34.9030400@gmx.net> Mime-Version: 1.0 References: <4300C29D.1030302@gmx.net> <14367.195.126.66.126.1124137430.squirrel@housecafe.dyndns.org> <44568.195.126.66.126.1124142843.squirrel@housecafe.dyndns.org> <4302BB34.9030400@gmx.net> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 494 X-archive-position: 6028 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vbtalent@gmail.com Precedence: bulk X-list: linux-xfs Christian, I've managed to get an image file of the drive that was dying using dd_rescue and have tried to run xfs_repair -f /dev/hdb1 with the following results, does it mean anything to you? I'm still having a difficult time with this thing but have made some progress. Thanks for any light you can shed. AJM, .....found candidate secondary superblock... superblock read failed, offset 209002168320, size 2048, ag 0, rval 22 fatal error -- Success [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Sep 2 15:03:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Sep 2005 15:03:52 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j82M3giL031626 for ; Fri, 2 Sep 2005 15:03:43 -0700 Received: from g0a19.g.pppool.de ([80.185.10.25] helo=mail.housecafe.de) by mail.g-house.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EBJdU-0004w4-Et; Sat, 03 Sep 2005 00:03:48 +0200 Received: from prinz64.housecafe.de ([192.168.10.11] helo=[127.0.0.1]) by mail.housecafe.de with esmtp (Exim 4.52) id 1EBJat-0006Ub-7h; Sat, 03 Sep 2005 00:01:07 +0200 Message-ID: <4318CBA2.3010702@gmx.net> Date: Sat, 03 Sep 2005 00:01:06 +0200 From: "evilninja@gmx.net" User-Agent: Mozilla Thunderbird 1.0+ (Windows/20050721) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: A JM Subject: Re: [OT] Re: XFS - hard drive dying References: <4300C29D.1030302@gmx.net> <14367.195.126.66.126.1124137430.squirrel@housecafe.dyndns.org> <44568.195.126.66.126.1124142843.squirrel@housecafe.dyndns.org> <4302BB34.9030400@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0535-3, 02.09.2005), Outbound message X-Antivirus-Status: Clean X-archive-position: 6031 X-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: 1467 Lines: 42 A JM schrieb: > Christian, > > I've managed to get an image file of the drive that was dying using > dd_rescue and have tried to run xfs_repair -f /dev/hdb1 with the following um, what was hdb1 again? in [1] you showed us your fstab, hdb1 is not listed there? is it part of your LVM setup? iirc it was the latter - a part of your LVM setup. if this is so and if i understand LVM correctly, you *always* work with fs-related tools on the logical volume. so you really should try to 0) find out your lvm-setup ( /etc/lvm/lvm.conf !) 1) setup your LVM, e.g.: % vgcreate VGforMyth /dev/hdb1 /dev/hdb4 /dev/hdb... % lvcreate -n video VGforMyth 2) xfs_repair -n /dev/VGforMyth/video but if you really have trouble with LVM you should probably ask some lvm-user [2]. i've never really used LVM, just played around with it a bit. after LVM issues are sorted out, you can go on and 1) find out what filesystem was on your logical volume and 2) run the right fsck tool. Christian. [1] http://oss.sgi.com/archives/linux-xfs/2005-08/msg00070.html [2] http://www.redhat.com/mailman/listinfo/linux-lvm PS: as to what the error shows here: > .....found candidate secondary superblock... > superblock read failed, offset 209002168320, size 2048, ag 0, rval 22 > > fatal error -- Success i don't know. it's bad, it's not something i expect from any fsck tool and the message is not very userfriendly at all. win95 error messages come to my mind...aaargh. From owner-linux-xfs@oss.sgi.com Fri Sep 2 15:20:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Sep 2005 15:20:51 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j82MKhiL000823 for ; Fri, 2 Sep 2005 15:20:44 -0700 Received: by zproxy.gmail.com with SMTP id 18so352420nzp for ; Fri, 02 Sep 2005 15:18:14 -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; b=Ll3tURjUJSRWZ12CAv7ep3xRAueSmrCjcdMufZMIC97a0xg6eZefK5JLHrZtIWXnBWPg92+Xthq+Ce3mG28AISA6h/QtfyCzxSx0egBodqF2wVsU+Ru8su6TZSLgsCnP3o3fGsvk0qe/VvtNJkrv82dB4umJPEwoB2hm/Jjtt3o= Received: by 10.36.31.4 with SMTP id e4mr1580614nze; Fri, 02 Sep 2005 15:18:13 -0700 (PDT) Received: by 10.36.160.1 with HTTP; Fri, 2 Sep 2005 15:18:13 -0700 (PDT) Message-ID: Date: Fri, 2 Sep 2005 18:18:13 -0400 From: A JM Reply-To: vbtalent@gmail.com To: linux-xfs@oss.sgi.com Subject: evil@g-house.de,evilninja@gmx.net Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6032 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vbtalent@gmail.com Precedence: bulk X-list: linux-xfs Status: RO Content-Length: 495 Lines: 18 Christian, I've managed to get an image file of the drive that was dying using dd_rescue and have tried to run xfs_repair -f /dev/hdb1 with the following results, does it mean anything to you? I'm still having a difficult time with this thing but have made some progress. Thanks for any light you can shed. AJM, .....found candidate secondary superblock... superblock read failed, offset 209002168320, size 2048, ag 0, rval 22 fatal error -- Success [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Sep 3 02:31:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Sep 2005 02:31:30 -0700 (PDT) Received: from astra.simleu.ro ([80.97.44.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j839VQiL018219 for ; Sat, 3 Sep 2005 02:31:27 -0700 Received: from saytrin.hq.k1024.org (unknown [62.217.245.194]) by astra.simleu.ro (Postfix) with ESMTP id 99B8450 for ; Sat, 3 Sep 2005 12:28:54 +0300 (EEST) Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id 4D5D81803BB; Sat, 3 Sep 2005 12:30:05 +0300 (EEST) Date: Sat, 3 Sep 2005 12:30:05 +0300 From: Iustin Pop To: linux-xfs@oss.sgi.com Subject: Free blocks btrees are not counted against sb->sb_fdblocks? Message-ID: <20050903093005.GA30775@saytrin.hq.k1024.org> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.10i X-archive-position: 6035 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 1019 Lines: 24 Hello to all, I believe that the blocks used by the free block btrees (BNO + CNT) are not substracted from the superblock's fdblocks. Except for the roots of course, which are included in the XFS_PREALLOC_BLOCKS(mp). Is there a reason for this? Especially since the inode btrees are substracted... Furthermore, I think this is why a full filesystem sometime shows a few kb's free - they are actually in the btrees and can't be used. How did I got to this result: whenever the level of the trees is > 1, SUM(agf->agf_freeblks) + SUM(agf->agf_flcount) != sb->sb_fdblocks. How does this happen? The blocks are allocated using xfs_alloc_get_freelist which does not modify the superblock counters. The debug checks in xfs_trans_apply_sb_deltas are ok, because the xfs_alloc_btree.c code modifies also tp->t_ag_btree_delta and keeps them in sync (xfs_alloc_get_freelist decrements tp->t_ag_freeblks_delta by 1, xfs_alloc_split increments tp->t_ag_btree_delta by 1 and thus they cancel each other). Regards, Iustin Pop From owner-linux-xfs@oss.sgi.com Sat Sep 3 04:00:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Sep 2005 04:00:46 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j83B0diL023798 for ; Sat, 3 Sep 2005 04:00:40 -0700 Received: by zproxy.gmail.com with SMTP id 18so408446nzp for ; Sat, 03 Sep 2005 03:58:09 -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=LF7aytYnYwwhJP0cP2FVoBFLWjm9o0l9IevB0sYe01akX9hSxw/8vWcjyy7yos1vyRd1piL0vYX8f6EnINl8SDWNLWavbo/vxALYXA8AB1svdmLweLkx2ergXIL/fkUSVkVuF/bN3yRnI4leUltLY15m0n77T8qOTBp81F0tyrs= Received: by 10.36.160.8 with SMTP id i8mr658455nze; Sat, 03 Sep 2005 03:58:08 -0700 (PDT) Received: by 10.36.160.1 with HTTP; Sat, 3 Sep 2005 03:58:08 -0700 (PDT) Message-ID: Date: Sat, 3 Sep 2005 06:58:08 -0400 From: A JM Reply-To: vbtalent@gmail.com To: evil@g-house.de, evilninja@gmx.net, linux-xfs@oss.sgi.com Subject: Re: XFS - hard drive dying In-Reply-To: Mime-Version: 1.0 References: Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6036 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vbtalent@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1258 Lines: 40 Forget the image, I used dd_rescue to move the data to another drive with little luck in any recovery. When running xfe_repair on the device these are the messages I'm seeing. .................................... *xfs_repair /dev/hdb* *Phase 1 - find and verify superblock...* *bad primary superblock - bad magic number !!!* * * *attempting to find secondary superblock...* "*found candidate secondary superblock...* *error reading superblock 27 -- seek to offset "some large number" failed* *unable to verify superblock, continuing...* Thanks for any input you guys can give. AJM, ---------- Forwarded message ---------- From: A JM Date: Sep 2, 2005 6:18 PM Subject: evil@g-house.de,evilninja@gmx.net To: linux-xfs@oss.sgi.com Christian, I've managed to get an image file of the drive that was dying using dd_rescue and have tried to run xfs_repair -f /dev/hdb1 with the following results, does it mean anything to you? I'm still having a difficult time with this thing but have made some progress. Thanks for any light you can shed. AJM, .....found candidate secondary superblock... superblock read failed, offset 209002168320, size 2048, ag 0, rval 22 fatal error -- Success [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Sep 3 07:55:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Sep 2005 07:56:00 -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 j83EttiL007482 for ; Sat, 3 Sep 2005 07:55:56 -0700 Received: (qmail invoked by alias); 03 Sep 2005 14:53:24 -0000 Received: from G0a19.g.pppool.de (EHLO [192.168.10.11]) [80.185.10.25] by mail.gmx.net (mp025) with SMTP; 03 Sep 2005 16:53:24 +0200 X-Authenticated: #2986359 Message-ID: <4319B8DD.7080200@gmx.net> Date: Sat, 03 Sep 2005 16:53:17 +0200 From: evilninja User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS - hard drive dying References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-archive-position: 6037 X-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: 883 Lines: 29 A JM schrieb: > Forget the image, I used dd_rescue to move the data to another drive with > little luck in any recovery. When running xfe_repair on the device these are > the messages I'm seeing. > .................................... > *xfs_repair /dev/hdb* -----------------------^ really? > *Phase 1 - find and verify superblock...* > *bad primary superblock - bad magic number !!!* > * * > *attempting to find secondary superblock...* > "*found candidate secondary superblock...* > *error reading superblock 27 -- seek to offset "some large number" failed* > *unable to verify superblock, continuing...* well, these error messages are *exactly* the same i get when i do this: % mkfs.ext3 /dev/sda6 % xfs_repair /dev/sda6 so i suspect /dev/hdb (hdb1?) contains no xfs and you should really seek some help with LVM.... -- BOFH excuse #260: We're upgrading /dev/null From owner-linux-xfs@oss.sgi.com Sat Sep 3 11:04:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Sep 2005 11:04:25 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j83I3xiL021039 for ; Sat, 3 Sep 2005 11:04:02 -0700 Received: by zproxy.gmail.com with SMTP id 18so437037nzp for ; Sat, 03 Sep 2005 11:01:29 -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:cc:in-reply-to:mime-version:content-type:references; b=eIQjTbyiRFzZXSWbl4FKjuZdKJn/FwqLUTluVecOkV1ZrkcudQQ/vA+L3oQDQEpQ1CQU+6HG1C6b98ey9JluZkOLcGSGUHD9TmUqJrWq1ZmXWotJ9EFpjm3dMW2Adjic5haBEnwB8y99ZoP9wFg8MUvGOwxpewfAaxXHuCFFeb8= Received: by 10.37.18.59 with SMTP id v59mr3258542nzi; Sat, 03 Sep 2005 11:01:29 -0700 (PDT) Received: by 10.36.160.1 with HTTP; Sat, 3 Sep 2005 11:01:29 -0700 (PDT) Message-ID: Date: Sat, 3 Sep 2005 14:01:29 -0400 From: A JM Reply-To: vbtalent@gmail.com To: evilninja Subject: Re: XFS - hard drive dying Cc: linux-xfs@oss.sgi.com In-Reply-To: <4319B8DD.7080200@gmx.net> Mime-Version: 1.0 References: <4319B8DD.7080200@gmx.net> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6038 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vbtalent@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1341 Lines: 40 > > Thanks for the reply Christian. Point taken on the filesystem. Just so that I understand and know that I have creted the backup device correctly please tell me if the following steps were correct. 1) I deleted all partitions on the destination device. 2) I dd_rescued to the new device using the following 'dd_rescue /dev/hdd /dev/hdb' (hdd being the bad drive and hdb being the good drive) 3) I ran xfs_repair /dev/hdb. I just looked at the dev/hdb using fdisk and this is what it shows. root@0[knoppix]# fdisk /dev/hdb The number of cylinders for this disk is set to 30515. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help): p Disk /dev/hdb: 251.0 GB, 251000193024 bytes 255 heads, 63 sectors/track, 30515 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdb1 1 24792 199141708+ 8e Linux LVM So, it appears to have copied the information over correctly because the entire drive was used in the LVM. Should I have used /dev/hdb1 when trying xfs_repair assuming it's an xfs file system? AJM, [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Sep 3 11:38:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Sep 2005 11:38:32 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j83IcLiL023276 for ; Sat, 3 Sep 2005 11:38:24 -0700 Received: by zproxy.gmail.com with SMTP id 18so439102nzp for ; Sat, 03 Sep 2005 11:35:51 -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:cc:in-reply-to:mime-version:content-type:references; b=HA1BxtClLRpW9hZImDp+7L1Cs+M5ptHRRKn547asr3ERYeEy2z5kB5UA+BV2W2FmBe8vTLtrOxgL/V0vkLfa7FWAWH/RpZrrHvRjrijaXA/gOnIWbKNQVYDvD1e1cIPG4hyfTXYEwqYxuRR4f8m0zXzVONslcRb5BXNYF8+pwDI= Received: by 10.36.221.12 with SMTP id t12mr3264413nzg; Sat, 03 Sep 2005 11:35:51 -0700 (PDT) Received: by 10.36.160.1 with HTTP; Sat, 3 Sep 2005 11:35:51 -0700 (PDT) Message-ID: Date: Sat, 3 Sep 2005 14:35:51 -0400 From: A JM Reply-To: vbtalent@gmail.com To: evilninja Subject: Re: XFS - hard drive dying Cc: linux-xfs@oss.sgi.com In-Reply-To: Mime-Version: 1.0 References: <4319B8DD.7080200@gmx.net> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6039 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vbtalent@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 264 Lines: 8 A slightly differnet error message when running xfs_repair /dev/hdb1 "*found candidate secondary superblock...* *error reading superblock 22 -- seek to offset 209002168320 failed* *unable to verify superblock, continuing...* [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Sep 3 12:44:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Sep 2005 12:45:01 -0700 (PDT) Received: from astra.simleu.ro ([80.97.44.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j83JiqiL030492 for ; Sat, 3 Sep 2005 12:44:53 -0700 Received: from saytrin.hq.k1024.org (unknown [62.217.245.194]) by astra.simleu.ro (Postfix) with ESMTP id 947B450; Sat, 3 Sep 2005 22:42:17 +0300 (EEST) Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id B4B86180050; Sat, 3 Sep 2005 22:43:20 +0300 (EEST) Date: Sat, 3 Sep 2005 22:43:20 +0300 From: Iustin Pop To: A JM Cc: evilninja , linux-xfs@oss.sgi.com Subject: Re: XFS - hard drive dying Message-ID: <20050903194320.GA6857@saytrin.hq.k1024.org> Mail-Followup-To: A JM , evilninja , linux-xfs@oss.sgi.com References: <4319B8DD.7080200@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.10i X-archive-position: 6040 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 2357 Lines: 57 On Sat, Sep 03, 2005 at 02:01:29PM -0400, A JM wrote: > Just so that I understand and know that I have creted the backup device > correctly please tell me if the following steps were correct. > 1) I deleted all partitions on the destination device. Good. > 2) I dd_rescued to the new device using the following 'dd_rescue /dev/hdd > /dev/hdb' (hdd being the bad drive and hdb being the good drive) Good. > 3) I ran xfs_repair /dev/hdb. This is wrong. /dev/hdb is a partioned disk, not a XFS filesystem. > I just looked at the dev/hdb using fdisk and this is what it shows. > Device Boot Start End Blocks Id System > /dev/hdb1 1 24792 199141708+ 8e Linux LVM > So, it appears to have copied the information over correctly because the > entire drive was used in the LVM. Yes, but this means you can't xfs_repair /dev/hdb or /dev/hdb1 > Should I have used /dev/hdb1 when trying xfs_repair assuming it's an xfs > file system? No, /dev/hdb1 is a PV not a filesystem. What I understand from your emails is this: - you had a LVM setup, with /dev/hdd one of your physical volumes - /dev/hdd failed and you managed to copy parts of it in /dev/hdb - you are trying xfs_repair /dev/hdb or /dev/hdb1 If the first two points are correct, then you are wrong in the third step. /dev/hdb1 in not in any kind of way an XFS filesystem. It's a PV, and you won't be able to xfs_repair it, because it probably starts with LVM metadata and the offsets are thus wrong in the file - even if you manage to reach a valid superblock. What you need to do, if I understood correctly your situation: 1. try to re-activate your VG - VGforMyth. It is important that you do this with the failed harddrive (/dev/hdd) not in the system. First, do: # pvscan this should show you all the PV of the VGforMyth, with /dev/hdb1 being now in the place of /dev/hdd1. Then do a vgchange -a y VGforMyth. If this is not successfull, please post the output of these commands, the output of pvdisplay /dev/hdb1 and the contents of the /etc/lvm directory (if it's not too big). Especially the /etc/lvm/archive/* right before your harddrive failed. 2. after you have activated correctly the VG, then it is time to xfs_repair the correct logical volume: # xfs_repair -n /dev/VGforMyth/video This should work, if the LVM configuration is sane. Hope this helps! Regards, Iustin Pop From owner-linux-xfs@oss.sgi.com Sat Sep 3 13:20:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Sep 2005 13:20:35 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j83KKUiL000733 for ; Sat, 3 Sep 2005 13:20:31 -0700 Received: by zproxy.gmail.com with SMTP id 18so445922nzp for ; Sat, 03 Sep 2005 13:18:00 -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=f2azskcbV5LgDwplwk8hCDAnH8CjyLEXQuxTeCF5qTjjmoRefv+Mp31whl7ljA0nMYTIJGlQVcNA7de02DuUL35rOy+jLvP7NpVLZOVb+FWRL7TaaPqJALUq5coZSkwK1Hv/1E1dScwPln+z9IZxfZ4LlH9cHdUX7enyxnOUUS4= Received: by 10.36.221.73 with SMTP id t73mr3314982nzg; Sat, 03 Sep 2005 13:18:00 -0700 (PDT) Received: by 10.36.160.1 with HTTP; Sat, 3 Sep 2005 13:18:00 -0700 (PDT) Message-ID: Date: Sat, 3 Sep 2005 16:18:00 -0400 From: A JM Reply-To: vbtalent@gmail.com To: evilninja@gmx.net, linux-xfs@oss.sgi.com, iusty@k1024.org Subject: Re: XFS - hard drive dying In-Reply-To: <20050903194320.GA6857@saytrin.hq.k1024.org> Mime-Version: 1.0 References: <4319B8DD.7080200@gmx.net> <20050903194320.GA6857@saytrin.hq.k1024.org> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6041 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vbtalent@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 481 Lines: 11 Yes, I think you understood correctly. The LVM spanned 1 full disk (hdb or hdb1) and a partition on another disk (hda4). I might have a "slight" problem re-activating the VG since the original OS has been rebuilt and therefore doesn't contain what I'm assuming from your post, the original VG data? This is not good! Can I re-create the VG on the rebuilt OS and try to incorporate hdb1 back into the new VG? Then try running xfs_repair? [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Sep 4 02:37:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 02:37:15 -0700 (PDT) Received: from mail.memphys.sdu.dk (mail.memphys.sdu.dk [130.225.154.186]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j849bBiL014460 for ; Sun, 4 Sep 2005 02:37:12 -0700 Received: from server.memphys.sdu.dk ([130.225.154.187]) by mail.memphys.sdu.dk with esmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1EBqta-0001Hz-Iw for linux-xfs@oss.sgi.com; Sun, 04 Sep 2005 11:34:38 +0200 Message-ID: <20050904113438.5j38mhi32ce9yc44@imptest.memphys.sdu.dk> Date: Sun, 4 Sep 2005 11:34:38 +0200 From: Claus Jeppesen To: linux-xfs@oss.sgi.com Subject: XFS - forcing quotacheck. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Content-Scan: exiscan-acl patch (http://duncanthrax.net/exiscan-acl/) X-archive-position: 6043 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeppesen@memphys.sdu.dk Precedence: bulk X-list: linux-xfs Content-Length: 1438 Lines: 40 Gentle people, I've experienced that XFS can loose synchronization between content in the filesystem and quota infomation. I would very much like to know what one should do in order to force a 'quotachek' ? Is there a 'bit' one can switch on, by xfs_db e.g., which would force a quotacheck the next time the filesystem is mounted with quota turned on ? - since XFS itself is not always aware of the slippage of quota-information, see my P.S. Thanx, Claus. P.S. I've experienced two situations where quotainformation can be de-synchronized with respect to the filesystem content: 1) Overflowing the device with the XFS filesystem, say dd'ing a lot of large files until dd reports no more space left. The XFS log is internal. 2) Sequences of mounting and un-mounting with and with-out '-o usrquota' - the idea being that files would be deleted or created when no quota support was requested. And despite the claim by the xfs_repair man-page, a quotachek would NOT be performed every time a '-o usrquota' was specified with the mount command [AFTER a situation where the filesystem had just been mounted without '-o usrquota']. -- Claus Jeppesen Memphys Center, SDU Campusvej 55 5230 Odense M, Denmark Ph: +45-65503475 Fax: +45-66158760 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-linux-xfs@oss.sgi.com Sun Sep 4 02:59:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 02:59:31 -0700 (PDT) Received: from astra.simleu.ro ([80.97.44.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j849xNiL015537 for ; Sun, 4 Sep 2005 02:59:23 -0700 Received: from saytrin.hq.k1024.org (unknown [62.217.245.194]) by astra.simleu.ro (Postfix) with ESMTP id 3724350; Sun, 4 Sep 2005 12:56:23 +0300 (EEST) Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id AA4241800AC; Sun, 4 Sep 2005 12:56:39 +0300 (EEST) Date: Sun, 4 Sep 2005 12:56:39 +0300 From: Iustin Pop To: A JM Cc: linux-xfs@oss.sgi.com Subject: Re: XFS - hard drive dying Message-ID: <20050904095639.GA8344@saytrin.hq.k1024.org> Mail-Followup-To: A JM , linux-xfs@oss.sgi.com References: <4319B8DD.7080200@gmx.net> <20050903194320.GA6857@saytrin.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.10i X-archive-position: 6044 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 855 Lines: 19 On Sat, Sep 03, 2005 at 04:18:00PM -0400, A JM wrote: > Yes, I think you understood correctly. The LVM spanned 1 full disk (hdb or > hdb1) and a partition on another disk (hda4). > I might have a "slight" problem re-activating the VG since the original OS > has been rebuilt and therefore doesn't contain what I'm assuming from your > post, the original VG data? This is not good! Uh oh... Could be a problem. > Can I re-create the VG on the rebuilt OS and try to incorporate hdb1 back > into the new VG? Then try running xfs_repair? Well, if both /dev/hda4 and /dev/hdb1 are available, you should be able to recreate it. As far as I know, in default configurations, metadata is written on all PVs. Try: vgscan and see if you see the VGforMyth volume. If not, try pvdisplay /dev/hda4 and pvdisplay /dev/hdb1. Post the output. Regards, Iustin Pop From owner-linux-xfs@oss.sgi.com Sun Sep 4 03:14:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 03:14:17 -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 j84AEAiL016608 for ; Sun, 4 Sep 2005 03:14:10 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j84CCAjC010553 for ; Sun, 4 Sep 2005 05:12:10 -0700 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j84ADvAQ52205033 for ; Sun, 4 Sep 2005 03:13:57 -0700 (PDT) X-ASG-Debug-ID: 1125828688-2931-12-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id 911FAD021947 for ; Sun, 4 Sep 2005 03:11:28 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j84ABPlI025054; Sun, 4 Sep 2005 05:11:26 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j84ABNNZ025050; Sun, 4 Sep 2005 05:11:23 -0500 Date: Sun, 4 Sep 2005 05:11:23 -0500 From: Christoph Hellwig Message-Id: <200509041011.j84ABNNZ025050@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.snlinux@sgi.com, bunk@stusta.de X-ASG-Orig-Subj: TAKE 942227 - replace "extern inline" with "static inline" Subject: TAKE 942227 - replace "extern inline" with "static inline" X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.3711 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6045 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 621 Lines: 17 Patch from Adrian Bunk , thanks a lot! Date: Sun Sep 4 03:09:57 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: bunk@stusta.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:198642a fs/xfs/linux-2.6/xfs_buf.h - 1.106 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.106&r2=text&tr2=1.105&f=h fs/xfs/linux-2.4/xfs_buf.h - 1.111 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.h.diff?r1=text&tr1=1.111&r2=text&tr2=1.110&f=h From owner-linux-xfs@oss.sgi.com Sun Sep 4 05:01:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 05:01:42 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j84C1aiL025152 for ; Sun, 4 Sep 2005 05:01:36 -0700 Received: by zproxy.gmail.com with SMTP id 18so489970nzp for ; Sun, 04 Sep 2005 04:59:05 -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=sfV3YAXcRrHJ+lTlc/fRKEDGU/zCf9iuwgsLvxFUx51bal01XlJSMbhbnZyCmry0QIMTWRdsluDjM+LlhKS9PoJHRmZTMJVsUUk7AQBrf344xkEgzJ72PE0lhWVI6LkY+DxRBpO9YoAqlsblSlJIRNrf+2o97PLQkyVByb/ujoY= Received: by 10.36.119.11 with SMTP id r11mr3742836nzc; Sun, 04 Sep 2005 04:59:05 -0700 (PDT) Received: by 10.36.160.1 with HTTP; Sun, 4 Sep 2005 04:59:05 -0700 (PDT) Message-ID: Date: Sun, 4 Sep 2005 07:59:05 -0400 From: A JM Reply-To: vbtalent@gmail.com To: linux-xfs@oss.sgi.com, iusty@k1024.org Subject: Re: XFS - hard drive dying In-Reply-To: <20050904095639.GA8344@saytrin.hq.k1024.org> Mime-Version: 1.0 References: <4319B8DD.7080200@gmx.net> <20050903194320.GA6857@saytrin.hq.k1024.org> <20050904095639.GA8344@saytrin.hq.k1024.org> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6046 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vbtalent@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1999 Lines: 50 The volume group I created was as far as I know a "default" setup... If I'm going to try to re-create the VG, the /dev/hdb1 (dying 200gig Maxtor ) will be dd' d to a 250gig drive, different size. Since I'm dd'ing the drive and it's creating a partition /dev/hdb1 on the new drive will that cause a problem? I'm guessing not, since it's essentially identical just larger? Just thinking out loud here, since I'm trying to fix (xfs_repair) a VG and the essential data I'm looking for "should" still be intact on the new drive I just dd'd from the dying one. How will the newly created VG on dev/hda4 know to incorporate the exisitng VG on the second drive /dev/hdb1? and will it matter if the VG on /dev/hda4 is not identical to the original as long as it knows to incorporate all of /dev/hdb1 into the VG and the VG name is the same therefore I can run xfs_repair on it. Don't you have to set the "blocks" or something when incorporating a new drive into the VG? Thanks for all the help and ideas. On 9/4/05, Iustin Pop wrote: > > On Sat, Sep 03, 2005 at 04:18:00PM -0400, A JM wrote: > > Yes, I think you understood correctly. The LVM spanned 1 full disk (hdb > or > > hdb1) and a partition on another disk (hda4). > > I might have a "slight" problem re-activating the VG since the original > OS > > has been rebuilt and therefore doesn't contain what I'm assuming from > your > > post, the original VG data? This is not good! > Uh oh... Could be a problem. > > Can I re-create the VG on the rebuilt OS and try to incorporate hdb1 > back > > into the new VG? Then try running xfs_repair? > Well, if both /dev/hda4 and /dev/hdb1 are available, you should be able > to recreate it. As far as I know, in default configurations, metadata is > written on all PVs. > > Try: vgscan and see if you see the VGforMyth volume. If not, try > pvdisplay /dev/hda4 and pvdisplay /dev/hdb1. Post the output. > > Regards, > Iustin Pop > [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Sep 4 05:06:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 05:06:33 -0700 (PDT) Received: from astra.simleu.ro ([80.97.44.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j84C6QiL025682 for ; Sun, 4 Sep 2005 05:06:27 -0700 Received: from saytrin.hq.k1024.org (unknown [62.217.245.194]) by astra.simleu.ro (Postfix) with ESMTP id EC39250; Sun, 4 Sep 2005 15:03:52 +0300 (EEST) Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id 648571800AC; Sun, 4 Sep 2005 15:05:13 +0300 (EEST) Date: Sun, 4 Sep 2005 15:05:13 +0300 From: Iustin Pop To: A JM Cc: linux-xfs@oss.sgi.com Subject: Re: XFS - hard drive dying Message-ID: <20050904120513.GB8344@saytrin.hq.k1024.org> Mail-Followup-To: A JM , linux-xfs@oss.sgi.com References: <4319B8DD.7080200@gmx.net> <20050903194320.GA6857@saytrin.hq.k1024.org> <20050904095639.GA8344@saytrin.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.10i X-archive-position: 6047 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 1672 Lines: 35 On Sun, Sep 04, 2005 at 07:59:05AM -0400, A JM wrote: > The volume group I created was as far as I know a "default" setup... > > If I'm going to try to re-create the VG, the /dev/hdb1 (dying 200gig Maxtor > ) will be dd' d to a 250gig drive, different size. Since I'm dd'ing the > drive and it's creating a partition /dev/hdb1 on the new drive will that > cause a problem? I'm guessing not, since it's essentially identical just > larger? Well, a dd copy will have make /dev/hdb1 the same size as the old /dev/hdd1, but since the /dev/hdb is larger it will have some space unused. > Just thinking out loud here, since I'm trying to fix (xfs_repair) a VG and > the essential data I'm looking for "should" still be intact on the new drive > I just dd'd from the dying one. How will the newly created VG on dev/hda4 > know to incorporate the exisitng VG on the second drive /dev/hdb1? and will > it matter if the VG on /dev/hda4 is not identical to the original as long as > it knows to incorporate all of /dev/hdb1 into the VG and the VG name is the > same therefore I can run xfs_repair on it. NO NO NO, you must NOT create a new VG. You must re-activate your old VG. Basically, LVM writes information about the volume groups onto each physical volume. So, if you have /dev/hda4 INTACT and /dev/hdb1 at least partially intact, you should be able to tell LVM to re-activate your old VG. I repeat - what do pvscan and pvs say? And what do vgscan and vgs say? > Don't you have to set the "blocks" or something when incorporating a new > drive into the VG? If you would re-create the VG, yes. But you trying to re-activate, not re-create. Regards, Iustin Pop From owner-linux-xfs@oss.sgi.com Sun Sep 4 05:37:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 05:38:07 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j84CbxiL027827 for ; Sun, 4 Sep 2005 05:37:59 -0700 Received: by zproxy.gmail.com with SMTP id 18so492351nzp for ; Sun, 04 Sep 2005 05:35:28 -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=mfEcG7YMCI/i9wt3FCNSRWCs6soxnJ2DEda4ikWBx5f0Ju9xguszs8L7EupxKeApUouYR1lN1I8SnWXKrn5IfTp3Qw+2qyzgisZF/k8x5UpTN89q7h4l6AMpq3HWq4zlBiORgr+bkZJoIEBH3wUKWxQA4lwzKWnIOkRDn7VrtrM= Received: by 10.36.32.16 with SMTP id f16mr3838401nzf; Sun, 04 Sep 2005 05:35:28 -0700 (PDT) Received: by 10.36.160.1 with HTTP; Sun, 4 Sep 2005 05:35:28 -0700 (PDT) Message-ID: Date: Sun, 4 Sep 2005 08:35:28 -0400 From: A JM Reply-To: vbtalent@gmail.com To: A JM , linux-xfs@oss.sgi.com Subject: Re: XFS - hard drive dying In-Reply-To: <20050904120513.GB8344@saytrin.hq.k1024.org> Mime-Version: 1.0 References: <4319B8DD.7080200@gmx.net> <20050903194320.GA6857@saytrin.hq.k1024.org> <20050904095639.GA8344@saytrin.hq.k1024.org> <20050904120513.GB8344@saytrin.hq.k1024.org> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6048 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vbtalent@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 655 Lines: 21 It's not good then if I can't create new and incorporate the old due to the old OS bieng re-worked, unless I have a back-up which I'm looking for.... [root@myth ~]# pvscan PV /dev/hda5 VG VolGroup01 lvm2 [140.34 GB / 32.00 MB free] Total: 1 [140.34 GB] / in use: 1 [140.34 GB] / in no VG: 0 [0 ] [root@myth ~]# pvs PV VG Fmt Attr PSize PFree /dev/hda5 VolGroup01 lvm2 a- 140.34G 32.00M [root@myth ~]# vgscan Reading all physical volumes. This may take a while... Found volume group "VolGroup01" using metadata type lvm2 [root@myth ~]# vgs VG #PV #LV #SN Attr VSize VFree VolGroup01 1 1 0 wz--n 140.34G 32.00M AJM, [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Sep 4 06:06:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 06:06:30 -0700 (PDT) Received: from astra.simleu.ro ([80.97.44.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j84D6LiL030127 for ; Sun, 4 Sep 2005 06:06:22 -0700 Received: from saytrin.hq.k1024.org (unknown [62.217.245.194]) by astra.simleu.ro (Postfix) with ESMTP id 823B950; Sun, 4 Sep 2005 16:03:46 +0300 (EEST) Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id 2461B1800AC; Sun, 4 Sep 2005 16:04:56 +0300 (EEST) Date: Sun, 4 Sep 2005 16:04:56 +0300 From: Iustin Pop To: A JM Cc: linux-xfs@oss.sgi.com Subject: Re: XFS - hard drive dying Message-ID: <20050904130456.GC8344@saytrin.hq.k1024.org> Mail-Followup-To: A JM , linux-xfs@oss.sgi.com References: <4319B8DD.7080200@gmx.net> <20050903194320.GA6857@saytrin.hq.k1024.org> <20050904095639.GA8344@saytrin.hq.k1024.org> <20050904120513.GB8344@saytrin.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.10i X-archive-position: 6049 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 367 Lines: 15 On Sun, Sep 04, 2005 at 08:35:28AM -0400, A JM wrote: > It's not good then if I can't create new and incorporate the old due to the > old OS bieng re-worked, unless I have a back-up which I'm looking for.... This is strange. When you reinstalled the OS, did you by change erase /dev/hda4? Also, what do: pvdisplay /dev/hda4 and pvdisplay /dev/hdb1 say? Iustin From owner-linux-xfs@oss.sgi.com Sun Sep 4 09:44:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 09:45:04 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j84GiviL010862 for ; Sun, 4 Sep 2005 09:44:58 -0700 Received: by zproxy.gmail.com with SMTP id 18so509690nzp for ; Sun, 04 Sep 2005 09:42:26 -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=e2mDMb/bOmWNYq+9vhCubTh/uwXDA1QsyWy9WlIqf0ImT0TXh+b42F9XAFvpacBF+ITBSjx/NyDBaAFmK5Xk7Db/XEH/gwDew8cMGPRdMY74Bhsfl2Vt5CuzSsJd3W5YeGbkmZmLGqk2NZ6hIGlCLVDMrBYzXKzclq/lUE6iG8M= Received: by 10.36.105.12 with SMTP id d12mr1845716nzc; Sun, 04 Sep 2005 09:42:26 -0700 (PDT) Received: by 10.36.160.1 with HTTP; Sun, 4 Sep 2005 09:42:26 -0700 (PDT) Message-ID: Date: Sun, 4 Sep 2005 12:42:26 -0400 From: A JM Reply-To: vbtalent@gmail.com To: linux-xfs@oss.sgi.com, iusty@k1024.org Subject: Re: XFS - hard drive dying In-Reply-To: <20050904130456.GC8344@saytrin.hq.k1024.org> Mime-Version: 1.0 References: <4319B8DD.7080200@gmx.net> <20050903194320.GA6857@saytrin.hq.k1024.org> <20050904095639.GA8344@saytrin.hq.k1024.org> <20050904120513.GB8344@saytrin.hq.k1024.org> <20050904130456.GC8344@saytrin.hq.k1024.org> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6050 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vbtalent@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 862 Lines: 23 Yes, I think what happened was that I dd'd to the wrong drive by accident since I was using Knoppix. /dev/hda wouldn't boot and that was all she wrote! That was the reason for the reinstall. I can run dd again on /dev/hdb1 as last night I ran xfs_repair on /dev/hdb1 to see what would happen and it made some changes so that's robably why there isn't any VG information? It won't be worth the time though if you don't think it's possible to fix the VG if /dev/hd4, the initial part of the VG is missing and that I wouldn't be able to recreate it anyway. [root@myth ~]# pvdisplay /dev/hda4 No physical volume label read from /dev/hda4 Failed to read physical volume "/dev/hda4" [root@myth ~]# pvdisplay /dev/hdb1 No physical volume label read from /dev/hdb1 Failed to read physical volume "/dev/hdb1" [root@myth ~]# [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Sep 4 11:13:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 11:13:47 -0700 (PDT) Received: from astra.simleu.ro ([80.97.44.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j84IDhiL014905 for ; Sun, 4 Sep 2005 11:13:44 -0700 Received: from saytrin.hq.k1024.org (unknown [62.217.245.194]) by astra.simleu.ro (Postfix) with ESMTP id F044F50; Sun, 4 Sep 2005 21:11:09 +0300 (EEST) Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id C3CC21800AC; Sun, 4 Sep 2005 21:12:28 +0300 (EEST) Date: Sun, 4 Sep 2005 21:12:28 +0300 From: Iustin Pop To: A JM Cc: linux-xfs@oss.sgi.com Subject: Re: XFS - hard drive dying Message-ID: <20050904181228.GD8344@saytrin.hq.k1024.org> Mail-Followup-To: A JM , linux-xfs@oss.sgi.com References: <4319B8DD.7080200@gmx.net> <20050903194320.GA6857@saytrin.hq.k1024.org> <20050904095639.GA8344@saytrin.hq.k1024.org> <20050904120513.GB8344@saytrin.hq.k1024.org> <20050904130456.GC8344@saytrin.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.10i X-archive-position: 6052 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 833 Lines: 21 On Sun, Sep 04, 2005 at 12:42:26PM -0400, A JM wrote: > Yes, I think what happened was that I dd'd to the wrong drive by accident > since I was using Knoppix. /dev/hda wouldn't boot and that was all she > wrote! That was the reason for the reinstall. > > I can run dd again on /dev/hdb1 as last night I ran xfs_repair on /dev/hdb1 > to see what would happen and it made some changes so that's robably why > there isn't any VG information? Well I don't know - but at least /dev/hda4 should be ok. > > It won't be worth the time though if you don't think it's possible to fix > the VG if /dev/hd4, the initial part of the VG is missing and that I > wouldn't be able to recreate it anyway. Well, sorry to say but if you are missing /dev/hda4 (the other part of the VG) then... Hope you have backups! Best regards, Iustin Pop From owner-linux-xfs@oss.sgi.com Sun Sep 4 15:45:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 15:45:18 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j84MjBiL030226 for ; Sun, 4 Sep 2005 15:45:11 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 0C6132000CAC; Sun, 4 Sep 2005 18:42:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 06D6DA0031F6 for ; Sun, 4 Sep 2005 18:42:30 -0400 (EDT) Date: Sun, 4 Sep 2005 18:42:30 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: linux-xfs@oss.sgi.com Subject: Help! Defragmenting XFS killed my partition? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6053 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Content-Length: 1435 Lines: 58 p34:~# xfs_db -V xfs_db version 2.6.20 p34:~# xfs_fsr -V xfs_fsr version 2.2.30 p34:~# p34:~# uname -a Linux p34 2.6.13 #7 SMP Sat Sep 3 08:08:01 EDT 2005 i686 GNU/Linux N 3 root 6:23pm (476) Warning: /dev/hdk1 is 12% fragmented. p34:~# xfs_db -c frag -r /dev/hdk1 p34:~# xfs_fsr /dev/hdk1 .. Then I check the fragmentation manually. p34:~# xfs_db -c frag -r /dev/hdk1 xfs_db: /dev/hdk1 is invalid (cannot read first 512 bytes) p34:~# umount /d3 p34:~# mount /d3 mount: /dev/hdk1: can't read superblock p34:~# ?? p34:~# fdisk /dev/hdk The number of cylinders for this disk is set to 30515. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help): p Disk /dev/hdk: 251.0 GB, 251000193024 bytes 255 heads, 63 sectors/track, 30515 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdk1 1 30515 245111706 83 Linux Command (m for help): q p34:~# How do I get back the data? What happened? XFS bug? I have been running xfs_fsr for a 4-5 days now and it has been working great across different machines, however, I may have just lost 230GB of data, can anyone help? Thanks. From owner-linux-xfs@oss.sgi.com Sun Sep 4 16:05:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 16:05:37 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j84N5UiL031564 for ; Sun, 4 Sep 2005 16:05:30 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 88C742000CAC; Sun, 4 Sep 2005 19:02:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 88033A0035CB for ; Sun, 4 Sep 2005 19:02:58 -0400 (EDT) Date: Sun, 4 Sep 2005 19:02:58 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: linux-xfs@oss.sgi.com Subject: Re: Help! Defragmenting XFS killed my partition? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6054 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Content-Length: 5415 Lines: 141 I take that back, it looks like my drive just died, coincidence? hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=107317663, high=6, low=6654367, sector=107317535 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 107317535 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=414375286, high=24, low=11722102, sector=414375255 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 414375255 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=474418460, high=28, low=4656412, sector=474418431 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 474418431 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=368476792, high=21, low=16155256, sector=368476703 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 368476703 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=480110089, high=28, low=10348041, sector=480110007 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 480110007 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=410468331, high=24, low=7815147, sector=410468127 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 410468127 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=410468331, high=24, low=7815147, sector=410468135 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 410468135 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=410468331, high=24, low=7815147, sector=410468143 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 410468143 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=37475735, high=2, low=3921303, sector=37475671 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 37475671 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=142214565, high=8, low=7996837, sector=142214375 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 142214375 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=142214565, high=8, low=7996837, sector=142214383 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 142214383 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=142214565, high=8, low=7996837, sector=142214391 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 142214391 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=142214565, high=8, low=7996837, sector=142214399 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 142214399 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=402440697, high=23, low=16564729, sector=402440639 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 402440639 hdk: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdk: dma_intr: error=0x40 { UncorrectableError }, LBAsect=402440697, high=23, low=16564729, sector=402440647 ide: failed opcode was: unknown end_request: I/O error, dev hdk, sector 402440647 On Sun, 4 Sep 2005, Justin Piszcz wrote: > p34:~# xfs_db -V > xfs_db version 2.6.20 > p34:~# xfs_fsr -V > xfs_fsr version 2.2.30 > p34:~# > p34:~# uname -a > Linux p34 2.6.13 #7 SMP Sat Sep 3 08:08:01 EDT 2005 i686 GNU/Linux > > > N 3 root 6:23pm (476) Warning: /dev/hdk1 is 12% fragmented. > > p34:~# xfs_db -c frag -r /dev/hdk1 > p34:~# xfs_fsr /dev/hdk1 > > .. > > Then I check the fragmentation manually. > > p34:~# xfs_db -c frag -r /dev/hdk1 > xfs_db: /dev/hdk1 is invalid (cannot read first 512 bytes) > > p34:~# umount /d3 > p34:~# mount /d3 > mount: /dev/hdk1: can't read superblock > p34:~# > > ?? > > p34:~# fdisk /dev/hdk > > The number of cylinders for this disk is set to 30515. > There is nothing wrong with that, but this is larger than 1024, > and could in certain setups cause problems with: > 1) software that runs at boot time (e.g., old versions of LILO) > 2) booting and partitioning software from other OSs > (e.g., DOS FDISK, OS/2 FDISK) > > Command (m for help): p > > Disk /dev/hdk: 251.0 GB, 251000193024 bytes > 255 heads, 63 sectors/track, 30515 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > /dev/hdk1 1 30515 245111706 83 Linux > > Command (m for help): q > > p34:~# > > How do I get back the data? What happened? XFS bug? > > I have been running xfs_fsr for a 4-5 days now and it has been working great > across different machines, however, I may have just lost 230GB of data, can > anyone help? > > Thanks. > > From owner-linux-xfs@oss.sgi.com Sun Sep 4 16:13:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 16:13:10 -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 j84ND4iL032159 for ; Sun, 4 Sep 2005 16:13: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 JAA25523; Mon, 5 Sep 2005 09:10:22 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4CA8249AC19B; Mon, 5 Sep 2005 09:10:21 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 942232 - unwritten extents oddity Message-Id: <20050904231021.4CA8249AC19B@chook.melbourne.sgi.com> Date: Mon, 5 Sep 2005 09:10:21 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6055 X-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: 628 Lines: 17 Fix incorrect use of BMAPI_READ in unwritten extent handling (luckily just cosmetic). Date: Mon Sep 5 09:09:46 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:23718a xfs_iomap.c - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h linux-2.6/xfs_aops.c - 1.95 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.95&r2=text&tr2=1.94&f=h From owner-linux-xfs@oss.sgi.com Sun Sep 4 16:21:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 16:21: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 j84NLniL004459 for ; Sun, 4 Sep 2005 16:21:49 -0700 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j851K4x5024887 for ; Sun, 4 Sep 2005 18:20:04 -0700 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j84NIH2Z264146883 for ; Sun, 4 Sep 2005 16:18:17 -0700 (PDT) X-ASG-Debug-ID: 1125875896-16915-53-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id E096F4F4E28 for ; Sun, 4 Sep 2005 16:18:16 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j84NIE1q019158; Sun, 4 Sep 2005 18:18:15 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j84NIDFF019157; Sun, 4 Sep 2005 18:18:13 -0500 Date: Sun, 4 Sep 2005 18:18:13 -0500 From: Christoph Hellwig Message-Id: <200509042318.j84NIDFF019157@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com X-ASG-Orig-Subj: TAKE 942063 - Make sure the threads and shaker in xfs_buf are de-initialized in reverse startup order Subject: TAKE 942063 - Make sure the threads and shaker in xfs_buf are de-initialized in reverse startup order X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.3724 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6056 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 400 Lines: 13 Date: Sun Sep 4 16:17:49 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:198651a fs/xfs/linux-2.6/xfs_buf.c - 1.204 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.204&r2=text&tr2=1.203&f=h From owner-linux-xfs@oss.sgi.com Sun Sep 4 19:16:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 19:16:51 -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 j852GkiL010735 for ; Sun, 4 Sep 2005 19:16:46 -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 j852EPJJ006857 for ; Sun, 4 Sep 2005 22:14:25 -0400 X-ORBL: [67.124.117.85] Received: from stupidest.org (adsl-67-124-117-85.dsl.snfc21.pacbell.net [67.124.117.85]) by pimout2-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j852EEdZ039632; Sun, 4 Sep 2005 22:14:14 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id E0910528F26; Sun, 4 Sep 2005 19:14:13 -0700 (PDT) Date: Sun, 4 Sep 2005 19:14:13 -0700 From: Chris Wedgwood To: Justin Piszcz Cc: linux-xfs@oss.sgi.com Subject: Re: Help! Defragmenting XFS killed my partition? Message-ID: <20050905021413.GB22746@taniwha.stupidest.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 6058 X-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: 331 Lines: 10 On Sun, Sep 04, 2005 at 07:02:58PM -0400, Justin Piszcz wrote: > I take that back, it looks like my drive just died, coincidence? Actually, your drive might have been failing before and increase write activity pushed it over the edge (ran out of places to remap sectors too). Either way this is a 'get a new driver' situation. From owner-linux-xfs@oss.sgi.com Sun Sep 4 19:16:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 19:16:05 -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 j852G1iL010615 for ; Sun, 4 Sep 2005 19:16:01 -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 j852DeJJ006256 for ; Sun, 4 Sep 2005 22:13:40 -0400 X-ORBL: [67.124.117.85] Received: from stupidest.org (adsl-67-124-117-85.dsl.snfc21.pacbell.net [67.124.117.85]) by pimout2-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j852DBwE019332; Sun, 4 Sep 2005 22:13:24 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id C2E03528F26; Sun, 4 Sep 2005 19:13:10 -0700 (PDT) Date: Sun, 4 Sep 2005 19:13:10 -0700 From: Chris Wedgwood To: Justin Piszcz Cc: linux-xfs@oss.sgi.com Subject: Re: Help! Defragmenting XFS killed my partition? Message-ID: <20050905021310.GA22746@taniwha.stupidest.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 6057 X-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: 146 Lines: 6 On Sun, Sep 04, 2005 at 07:02:58PM -0400, Justin Piszcz wrote: > I take that back, it looks like my drive just died, coincidence? Coincidence. From owner-linux-xfs@oss.sgi.com Sun Sep 4 20:59:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Sep 2005 21:00:51 -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 j853xliL020004 for ; Sun, 4 Sep 2005 20:59:48 -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 j853vDfE4838048; Mon, 5 Sep 2005 13:57:13 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j853vBGu4746246; Mon, 5 Sep 2005 13:57:11 +1000 (AEST) Date: Mon, 5 Sep 2005 13:57:10 +1000 From: Tim Shimmin To: Claus Jeppesen Cc: linux-xfs@oss.sgi.com Subject: Re: XFS - forcing quotacheck. Message-ID: <20050905135710.E4600499@boing.melbourne.sgi.com> References: <20050904113438.5j38mhi32ce9yc44@imptest.memphys.sdu.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050904113438.5j38mhi32ce9yc44@imptest.memphys.sdu.dk>; from jeppesen@memphys.sdu.dk on Sun, Sep 04, 2005 at 11:34:38AM +0200 X-archive-position: 6059 X-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: 943 Lines: 25 Hi Claus, On Sun, Sep 04, 2005 at 11:34:38AM +0200, Claus Jeppesen wrote: > > Gentle people, > > I've experienced that XFS can loose synchronization between content in the > filesystem and quota infomation. I would very much like to know what one should > do in order to force a 'quotachek' ? > > Is there a 'bit' one can switch on, by xfs_db e.g., which would force a > quotacheck the next time the filesystem is mounted with quota turned on ? - Yes, see below. A quotacheck is supposed to happen on mount with quotas if previously it has been mounted without quotas. This, however, was broken for quite a while until recently. If you have access to the cvs xfs kernel source and build your own kernel then this was fixed on August 4th. Alternatively, you can unmount the fs and clear the sb_qflags value in the 1st superblock using xfs_db and then mount again with quotas. $ xfs_db -x -c 'sb 0' -c 'write qflags 0' $device --Tim From owner-linux-xfs@oss.sgi.com Mon Sep 5 02:33:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Sep 2005 02:33:34 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j859XQiL009536 for ; Mon, 5 Sep 2005 02:33:27 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 293BB2000CAC; Mon, 5 Sep 2005 05:30:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 20DC1A0031BB for ; Mon, 5 Sep 2005 05:30:54 -0400 (EDT) Date: Mon, 5 Sep 2005 05:30:53 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: linux-xfs@oss.sgi.com Subject: Help with failing drive. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6060 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Content-Length: 461 Lines: 17 All, When I use dd_rescue, the first 95 sectors fail, possibly due to xfs_fsr re-mapping parts of the drive during the defrag. Is there anyway I can fix the boot block/XFS (first 95 sectors) so I can see the rest of the drive? So far dd_rescue has been running just fine after it passes the first 95 sectors. Any ideas on how I should proceed to get the rest of the (233GB) of data back, as only the first 95 sectors cannot be read? Thanks, Justin. From owner-linux-xfs@oss.sgi.com Mon Sep 5 03:12:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Sep 2005 03:12:53 -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 j85ACgiL012114 for ; Mon, 5 Sep 2005 03:12:43 -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 UAA07529; Mon, 5 Sep 2005 20:10:05 +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 j85AAFkt4592976; Mon, 5 Sep 2005 20:10:16 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j85AADtq4530941; Mon, 5 Sep 2005 20:10:13 +1000 (EST) Date: Mon, 5 Sep 2005 20:10:13 +1000 From: Nathan Scott To: Justin Piszcz Cc: linux-xfs@oss.sgi.com Subject: Re: Help with failing drive. Message-ID: <20050905201013.A4571781@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 jpiszcz@lucidpixels.com on Mon, Sep 05, 2005 at 05:30:53AM -0400 X-archive-position: 6061 X-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: 701 Lines: 24 On Mon, Sep 05, 2005 at 05:30:53AM -0400, Justin Piszcz wrote: > All, > > When I use dd_rescue, the first 95 sectors fail, possibly due to xfs_fsr > re-mapping parts of the drive during the defrag. Is there anyway I can > fix the boot block/XFS (first 95 sectors) so I can see the rest of the > drive? If there is, its at some level below XFS. > So far dd_rescue has been running just fine after it passes the first 95 > sectors. > > Any ideas on how I should proceed to get the rest of the (233GB) of data > back, as only the first 95 sectors cannot be read? Run xfs_repair on the result of the dd_rescue and it will attempt to stitch it back together again for you. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 5 04:55:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Sep 2005 04:55:15 -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 j85Bt9iL022188 for ; Mon, 5 Sep 2005 04:55:10 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j85BqbxT000591 for ; Mon, 5 Sep 2005 06:52:37 -0500 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j85Bt2AQ52611828; Mon, 5 Sep 2005 04:55:02 -0700 (PDT) X-ASG-Debug-ID: 1125921153-9902-34-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6D48BD0C9AFA; Mon, 5 Sep 2005 04:52:33 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j85BqVMx015441; Mon, 5 Sep 2005 06:52:32 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j85BqMZb015428; Mon, 5 Sep 2005 06:52:22 -0500 Date: Mon, 5 Sep 2005 06:52:22 -0500 From: Christoph Hellwig Message-Id: <200509051152.j85BqMZb015428@naboo.americas.sgi.com> To: Cc: linux-xfs@oss.sgi.com, hch@melbourne.sgi.com X-ASG-Orig-Subj: PARTIAL TAKE 908809 - remove unused pagebuf flags Subject: PARTIAL TAKE 908809 - remove unused pagebuf flags X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.3737 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6062 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 558 Lines: 15 Date: Mon Sep 5 04:52:04 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:198656a fs/xfs/linux-2.6/xfs_buf.h - 1.107 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h fs/xfs/linux-2.6/xfs_buf.c - 1.205 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.205&r2=text&tr2=1.204&f=h From owner-linux-xfs@oss.sgi.com Mon Sep 5 05:39:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Sep 2005 05:39:36 -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 j85CdSiL024839 for ; Mon, 5 Sep 2005 05:39:31 -0700 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j85CauxT008389 for ; Mon, 5 Sep 2005 07:36:56 -0500 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j85Cau2Z264505624 for ; Mon, 5 Sep 2005 05:36:56 -0700 (PDT) X-ASG-Debug-ID: 1125923815-29456-17-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id A69ABD0CB001 for ; Mon, 5 Sep 2005 05:36:55 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j85CarJW019948; Mon, 5 Sep 2005 07:36:54 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j85CaqkR019944; Mon, 5 Sep 2005 07:36:52 -0500 Date: Mon, 5 Sep 2005 07:36:52 -0500 From: Christoph Hellwig Message-Id: <200509051236.j85CaqkR019944@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com X-ASG-Orig-Subj: TAKE 942243 - Add format checking to cmn_err and icmn_err Subject: TAKE 942243 - Add format checking to cmn_err and icmn_err X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.3738 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6063 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1231 Lines: 25 Date: Mon Sep 5 05:36:32 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:198658a fs/xfs/xfs_log.c - 1.307 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.307&r2=text&tr2=1.306&f=h fs/xfs/xfs_ialloc.c - 1.180 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.180&r2=text&tr2=1.179&f=h fs/xfs/xfs_rw.c - 1.390 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rw.c.diff?r1=text&tr1=1.390&r2=text&tr2=1.389&f=h fs/xfs/xfs_mount.c - 1.359 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.359&r2=text&tr2=1.358&f=h fs/xfs/xfs_inode.c - 1.417 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.417&r2=text&tr2=1.416&f=h fs/xfs/xfs_bmap.c - 1.327 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.327&r2=text&tr2=1.326&f=h fs/xfs/support/debug.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h From owner-linux-xfs@oss.sgi.com Mon Sep 5 05:52:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Sep 2005 05:52:59 -0700 (PDT) Received: from halifax.chebucto.ns.ca (chebucto.ns.Ca [192.75.95.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j85CqqiL025663 for ; Mon, 5 Sep 2005 05:52:52 -0700 Received: from Dyip-172.chebucto.ns.Ca ([192.75.95.172]:56691 "EHLO cerberus.cwmannwn.nowhere" smtp-auth: TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by halifax.chebucto.ns.ca with ESMTP id S9732AbVIEMsw (ORCPT ); Mon, 5 Sep 2005 09:48:52 -0300 Date: Mon, 5 Sep 2005 09:49:36 -0300 (ADT) From: "George N. White III" X-X-Sender: gwhite@cerberus.cwmannwn.nowhere Reply-To: "George N. White III" To: linux-xfs@oss.sgi.com Subject: Re: Help! Defragmenting XFS killed my partition? In-Reply-To: <20050905021413.GB22746@taniwha.stupidest.org> Message-ID: References: <20050905021413.GB22746@taniwha.stupidest.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6064 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aa056@chebucto.ns.ca Precedence: bulk X-list: linux-xfs Content-Length: 1115 Lines: 31 On Sun, 4 Sep 2005, Chris Wedgwood wrote: > On Sun, Sep 04, 2005 at 07:02:58PM -0400, Justin Piszcz wrote: > >> I take that back, it looks like my drive just died, coincidence? > > Actually, your drive might have been failing before and increase write > activity pushed it over the edge (ran out of places to remap sectors > too). > > Either way this is a 'get a new driver' situation. Not necessarily. A bad cable, power glitches, or a bulging capacitor in the CPU voltage converter could produce disk errors. The history of the drive is often a good indication. If you don't use it much, a bad drive can sit in a system for years without causing problems. Problems tend to become visible under stress, which can certainly include fsr, especially if you haven't been using it routinely. Errors in a routine fsr on a system that hasn't crashed or had other problems for months or years are often a hint that the disk should have been replaced yesterday. Drives usually fail when new or, if heavily used, a couple days after the warranty has expired. -- George N. White III From owner-linux-xfs@oss.sgi.com Mon Sep 5 11:53:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Sep 2005 11:53:47 -0700 (PDT) Received: from astra.simleu.ro ([80.97.44.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j85IrgiL017420 for ; Mon, 5 Sep 2005 11:53:43 -0700 Received: from saytrin.hq.k1024.org (unknown [62.217.245.194]) by astra.simleu.ro (Postfix) with ESMTP id 0540650 for ; Mon, 5 Sep 2005 21:51:06 +0300 (EEST) Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id D43301800AD; Mon, 5 Sep 2005 21:52:21 +0300 (EEST) Date: Mon, 5 Sep 2005 21:52:21 +0300 From: Iustin Pop To: linux-xfs@oss.sgi.com Subject: Where/how to submit for review patch for shrink support? Message-ID: <20050905185221.GA5209@saytrin.hq.k1024.org> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.10i X-archive-position: 6066 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 3666 Lines: 90 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello to all, I would like to know in what form should I submit my patch and where (probably to the list). The diff I have was made against 2.6.12.5 and applies/compiles cleanly against 2.6.13 also. Detailed explanation: I've completed the first part of the shrink support: - first patch: permits shrink of the filesystem if all requested blocks are free; - second patch (not yet finished): add support for marking allocation groups offline with regard to space and inode allocation so that you can clear out the space; - third part, probably userspace, which will help clear the indented space (using xfs_swap_extents and inode switch maybe). Now, regarding the first patch. What it does is enable the kernel to shrink a filesystem if it passes certain checks, which ensure (I believe) that the space to be removed is free. The code is almost non-intrusive: - it adds a function xfs_shrink_data_private to xfs_fsops.c - it modifies xfs_growfs_data_private to call the above function if shrinking - it adds one function to xfs_alloc_btree.c to enable calculation of the bno or cnt btree - it adds one function to xfs_ialloc_btree.c to enable calculation of the inode btree and the space used by the inode chunks - (only intrusive item) it removes from xfs_trans_mod_sb the ASSERT(delta > 0); for XFS_TRANS_SB_DBLOCKS and XFS_TRANS_SB_AGCOUNT Except for the ASSERT() removal, the code is called only and only when shrinking. Example of behavior: you have a filesystem of 8 a.g. of 1000 blocks each, and want to shrink the filesystem from 8000 to 5500 blocks. The new routine will: - check if you have an internal journal and abort if you would trip over it; - check that you have enough space by making an xfs_trans_reserve - for (in this example) the a.g. 6 & 7 (starting from 0), which will be completely removed: * check that no allocated inodes exist in that a.g. (agi_freecount == agi_count) * check that the used space in that a.g. is used only by metadata: deleted and unreclaimed inodes, inode allocation btrees, bno and cnt allocation btrees and freelist - for the a.g. 5, it will try and make an exact allocation of space from block 500 to the end, which would fail if anything is in that space; thus, if the allocation succeeds, it means we can chop off that space; Now the patch does not include memory management stuff (except for a simple resizing of mp->m_perag if we chop an entire a.g.), since I didn't understand this issue. Also I'm not sure what can happen in some inodes or data is in the cache but not flushed, or if this can even happen when using transactions. Since xfs_growfs_data_private didn't contain any such stuff, I presumed shrink doesn't also. Probably wrong assumption... Testing was done using user mode linux 2.6.12.5 on an i386 host. In the current state, I can't seem to generate any oops or panics (using XFS_DEBUG=y manually set in the Makefile), and xfs_check and xfs_repair do not complain. I also was able to grow-shrink-grow-shrink-.... a filesystem without problems. I would like to know if this has any chance of being considered for inclusion... or if I wasted my time :) Iustin Pop --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDHJPl4mx23Z34NMIRAk6xAJ9EzraqvzFHPUGKte5QWLN9B30IkwCg2fHi VRrFUCgQkRBRsMub+0iMVRs= =w6c/ -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-linux-xfs@oss.sgi.com Mon Sep 5 12:13:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Sep 2005 12:13:13 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j85JD4iL018502 for ; Mon, 5 Sep 2005 12:13:05 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.52 #1 (Red Hat Linux)) id 1ECMMR-0005sI-VW for linux-xfs@oss.sgi.com; Mon, 05 Sep 2005 20:10:32 +0100 Date: Mon, 5 Sep 2005 20:10:31 +0100 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: Re: Where/how to submit for review patch for shrink support? Message-ID: <20050905191031.GB18315@infradead.org> References: <20050905185221.GA5209@saytrin.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050905185221.GA5209@saytrin.hq.k1024.org> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6067 X-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@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 960 Lines: 22 On Mon, Sep 05, 2005 at 09:52:21PM +0300, Iustin Pop wrote: > Hello to all, > > I would like to know in what form should I submit my patch and where > (probably to the list). The diff I have was made against 2.6.12.5 and > applies/compiles cleanly against 2.6.13 also. Please try to rediff it against the CVS tree at oss.sgi.com (there's not much differences, it's just the development tree), and then submit it to the list. > Now the patch does not include memory management stuff (except for a > simple resizing of mp->m_perag if we chop an entire a.g.), since I > didn't understand this issue. Also I'm not sure what can happen in some > inodes or data is in the cache but not flushed, or if this can even > happen when using transactions. Since xfs_growfs_data_private didn't > contain any such stuff, I presumed shrink doesn't also. Probably wrong > assumption... Yeah, that sounds a little fishy. I'll take a look at the patch once you'll post it. From owner-linux-xfs@oss.sgi.com Mon Sep 5 16:00:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Sep 2005 16:00: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 j85N0DiL000915 for ; Mon, 5 Sep 2005 16:00: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 IAA20379 for ; Tue, 6 Sep 2005 08:57:39 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 8900D49BFAA3; Tue, 6 Sep 2005 08:57:38 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - blktrace update Message-Id: <20050905225738.8900D49BFAA3@chook.melbourne.sgi.com> Date: Tue, 6 Sep 2005 08:57:38 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6068 X-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: 2174 Lines: 36 Merge in rev3 of the blktrace patch from Jens Axboe. Date: Tue Sep 6 08:57:22 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: axboe@suse.de 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:23729a split-patches/blktrace-rev3 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/blktrace-rev3 drivers/block/Kconfig - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/Kconfig.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/block/Makefile - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/Makefile.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/block/elevator.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/elevator.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/block/ioctl.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/ioctl.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/block/ll_rw_blk.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/ll_rw_blk.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h include/linux/blkdev.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/blkdev.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/linux/fs.h - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/fs.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h split-patches/series - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h drivers/block/blktrace.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/blktrace.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/jens-blk-trace - 1.3 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/jens-blk-trace.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/blktrace.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/blktrace.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs@oss.sgi.com Mon Sep 5 16:22:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Sep 2005 16:23:04 -0700 (PDT) Received: from astra.simleu.ro ([80.97.44.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j85NMtiL006971 for ; Mon, 5 Sep 2005 16:22:56 -0700 Received: from saytrin.hq.k1024.org (unknown [62.217.245.194]) by astra.simleu.ro (Postfix) with ESMTP id 4C29E50 for ; Tue, 6 Sep 2005 02:20:14 +0300 (EEST) Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id 7FEE81800AC; Tue, 6 Sep 2005 02:21:26 +0300 (EEST) Date: Tue, 6 Sep 2005 02:21:26 +0300 From: Iustin Pop To: linux-xfs@oss.sgi.com Subject: Re: Where/how to submit for review patch for shrink support? Message-ID: <20050905232126.GA4979@saytrin.hq.k1024.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20050905185221.GA5209@saytrin.hq.k1024.org> <20050905191031.GB18315@infradead.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E39vaYmALEf/7YXx" Content-Disposition: inline In-Reply-To: <20050905191031.GB18315@infradead.org> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.10i X-archive-position: 6069 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 22941 Lines: 699 --E39vaYmALEf/7YXx Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 05, 2005 at 08:10:31PM +0100, Christoph Hellwig wrote: >=20 > Please try to rediff it against the CVS tree at oss.sgi.com (there's not > much differences, it's just the development tree), and then submit it to > the list. Ok, done (I hope the format is ok). Notes about the patch: - I left the printk's I used in place, maybe they help with understanding the code; - the xfs_inobtsize and xfs_alloc_btsize are called recursivelly, I don't know if this can be a problem with stack usage; however, it was the simplest way at the moment and the max depth is equal to the max depth of the btrees; - almost all the code is based on guesswork and looking at the xfs kernel & userspace code; I have the most doubts about the usage of xfs_alloc_vextent and the parameters I filled its argument with; If anything is unclear, please ask for more information. > Yeah, that sounds a little fishy. I'll take a look at the patch once > you'll post it. Ok, thanks a lot! Iustin --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cvs.diff" Content-Transfer-Encoding: quoted-printable diff -urN -x xfs_ialloc_btree.h.orig -x xfs_trans.c.orig -x Entries.Log -x = Entries linux-2.6-xfs.orig/fs/xfs/xfs_alloc_btree.c linux-2.6-xfs/fs/xfs/xf= s_alloc_btree.c --- linux-2.6-xfs.orig/fs/xfs/xfs_alloc_btree.c 2005-01-14 13:57:33.0000000= 00 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_alloc_btree.c 2005-09-06 02:01:39.024407208 +0= 300 @@ -1773,6 +1773,82 @@ */ =20 /* + * Compute the size (in blocks) of the btree in the given level/block numb= er + */ +int /* error */ +xfs_alloc_btsize( + struct xfs_btree_cur *cur, /* btree cursor */ + int level, /* current level */ + xfs_agblock_t agbno, /* a.g. relative btree block number */ + int *result)/* pointer to variable to be incremented */ +{ + xfs_agnumber_t agno; + xfs_alloc_block_t *block=3DNULL; /* current btree block */ + int error; /* error return value */ + int ptrno; /* current key number */ + xfs_daddr_t d; /* disk address of btree block */ + xfs_buf_t *bp; /* buffer pointer for btree block */ + + XFS_STATS_INC(xs_abt_lookup); + + if(level =3D=3D 0) { /* level =3D=3D 0 means no childs and thus one block= usage */ + (*result)++; + return 0; + } + + { + xfs_agf_t *agf; /* a.g. freespace header */ + + agf =3D XFS_BUF_TO_AGF(cur->bc_private.a.agbp); + agno =3D INT_GET(agf->agf_seqno, ARCH_CONVERT); + } + + + d =3D XFS_AGB_TO_DADDR(cur->bc_mp, agno, agbno); + printk("btsize agno=3D%d agbno=3D%d diskaddr=3D%lld level=3D%d result=3D%= d\n", agno, agbno, d, level, *result); + bp =3D cur->bc_bufs[level]; + if (bp && XFS_BUF_ADDR(bp) !=3D d) + bp =3D (xfs_buf_t *)0; + if (!bp) { + /* + * Need to get a new buffer. Read it, then + * set it in the cursor, releasing the old one. + */ + if ((error =3D xfs_btree_read_bufs(cur->bc_mp, cur->bc_tp, agno, + agbno, 0, &bp, XFS_ALLOC_BTREE_REF))) + return error; + xfs_btree_setbuf(cur, level, bp); + /* + * Point to the btree block, now that we have the buffer + */ + block =3D XFS_BUF_TO_ALLOC_BLOCK(bp); + if ((error =3D xfs_btree_check_sblock(cur, block, level, + bp))) + return error; + } else + block =3D XFS_BUF_TO_ALLOC_BLOCK(bp); +=20=20=20=20=20=20=20=20 + /* + * Iterate over each child in this non-leaf block + */ + for (ptrno =3D 0; ptrno < INT_GET(block->bb_numrecs, ARCH_CONVERT); ptrno= ++) { + xfs_alloc_ptr_t *child; + xfs_agblock_t newbno; + + child =3D XFS_ALLOC_PTR_ADDR(block, ptrno + 1, cur); + newbno =3D INT_GET(*child, ARCH_CONVERT); + + printk("\twill enter ptrno=3D%d (of %d) agbno=3D%d\n", ptrno, INT_GET(bl= ock->bb_numrecs, ARCH_CONVERT), newbno); + + if((error =3D xfs_alloc_btsize(cur, level - 1, newbno, result))) + return error; +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 + } + (*result)++; + return 0; +} + +/* * Decrement cursor by one record at the level. * For nonzero levels the leaf-ward information is untouched. */ diff -urN -x xfs_ialloc_btree.h.orig -x xfs_trans.c.orig -x Entries.Log -x = Entries linux-2.6-xfs.orig/fs/xfs/xfs_alloc_btree.h linux-2.6-xfs/fs/xfs/xf= s_alloc_btree.h --- linux-2.6-xfs.orig/fs/xfs/xfs_alloc_btree.h 2003-06-27 21:04:26.0000000= 00 +0300 +++ linux-2.6-xfs/fs/xfs/xfs_alloc_btree.h 2005-09-06 02:01:39.025407056 +0= 300 @@ -164,6 +164,16 @@ */ =20 /* + * Compute the size (in blocks) of the btree in the given level/block numb= er + */ +int /* error */ +xfs_alloc_btsize( + struct xfs_btree_cur *cur, /* btree cursor */ + int level, /* current level */ + xfs_agblock_t agbno, /* a.g. relative btree block number */ + int *result); /* pointer to variable to be incremente= d */ + +/* * Decrement cursor by one record at the level. * For nonzero levels the leaf-ward information is untouched. */ diff -urN -x xfs_ialloc_btree.h.orig -x xfs_trans.c.orig -x Entries.Log -x = Entries linux-2.6-xfs.orig/fs/xfs/xfs_fsops.c linux-2.6-xfs/fs/xfs/xfs_fsop= s.c --- linux-2.6-xfs.orig/fs/xfs/xfs_fsops.c 2005-05-18 12:18:24.000000000 +03= 00 +++ linux-2.6-xfs/fs/xfs/xfs_fsops.c 2005-09-06 02:01:39.026406904 +0300 @@ -66,6 +66,8 @@ * File system operations */ =20 +static int xfs_shrink_data_private(xfs_mount_t *mp, xfs_growfs_data_t *in); + int xfs_fs_geometry( xfs_mount_t *mp, @@ -153,7 +155,9 @@ =20 nb =3D in->newblocks; pct =3D in->imaxpct; - if (nb < mp->m_sb.sb_dblocks || pct < 0 || pct > 100) + if (nb < mp->m_sb.sb_dblocks) + return xfs_shrink_data_private(mp, in); + if (pct < 0 || pct > 100) return XFS_ERROR(EINVAL); dpct =3D pct - mp->m_sb.sb_imax_pct; error =3D xfs_read_buf(mp, mp->m_ddev_targp, @@ -416,6 +420,318 @@ } =20 static int +xfs_shrink_data_private( + xfs_mount_t *mp, /* mount point for filesystem */ + xfs_growfs_data_t *in) /* growfs data input struct */ +{ + xfs_agf_t *agf; + xfs_agi_t *agi; + xfs_agnumber_t agno; + xfs_buf_t *bp; + int dpct; + int error; + xfs_agnumber_t nagcount; /* new number of a.g. */ + xfs_agnumber_t nagimax =3D 0; + xfs_rfsblock_t nb, nb_mod; + xfs_rfsblock_t new; + xfs_rfsblock_t nfree; + xfs_agnumber_t oagcount; + int pct; + xfs_sb_t *sbp; + xfs_trans_t *tp; + xfs_alloc_arg_t allocarg; + long icount =3D 0; /* sum of total inode count deleted by shrink */ + long ifree =3D 0; /* sum of free inode count deleted by shrink */ + long inofree =3D 0; /* space used by inodes and inode btree */ + + nb =3D in->newblocks; + pct =3D in->imaxpct; + if (nb > mp->m_sb.sb_dblocks || pct < 0 || pct > 100)=20 + return XFS_ERROR(EINVAL); + dpct =3D pct - mp->m_sb.sb_imax_pct; + error =3D xfs_read_buf(mp, mp->m_ddev_targp, + XFS_FSB_TO_BB(mp, nb) - XFS_FSS_TO_BB(mp, 1), + XFS_FSS_TO_BB(mp, 1), 0, &bp); + if (error) + return error; + ASSERT(bp); + xfs_buf_relse(bp); + + new =3D nb; /* use new as a temporary here */ + nb_mod =3D do_div(new, mp->m_sb.sb_agblocks); + printk("Cur ag=3D%d, cur blocks=3D%d\n", mp->m_sb.sb_agcount, mp->m_sb.sb= _dblocks); + nagcount =3D new + (nb_mod !=3D 0); + printk("New ag=3D%d, new blocks=3D%d, nb_mod=3D%d\n", new, nb, nb_mod); + if (nb_mod && nb_mod < XFS_MIN_AG_BLOCKS) { + printk("nb_mod (%d) < XFS_MIN_AG_BLOCKS (%d)\n", nb_mod, XFS_MIN_AG_BLOC= KS); + nagcount--; + nb =3D nagcount * mp->m_sb.sb_agblocks; + printk("ne2 ag=3D%d, ne2 blocks=3D%d\n", nagcount, nb); + if (nb >=3D mp->m_sb.sb_dblocks) + return XFS_ERROR(EINVAL); + } + printk("Will resize from %d to %d, delta is %d\n", mp->m_sb.sb_dblocks, n= b, mp->m_sb.sb_dblocks - nb); + /* Check to see if we trip over the log section */ + printk("logstart=3D%ld logblocks=3D%ld\n", mp->m_sb.sb_logstart, mp->m_sb= .sb_logblocks); + if (nb < mp->m_sb.sb_logstart + mp->m_sb.sb_logblocks) + return XFS_ERROR(EINVAL); + new =3D nb - mp->m_sb.sb_dblocks; + oagcount =3D mp->m_sb.sb_agcount; + tp =3D xfs_trans_alloc(mp, XFS_TRANS_GROWFS); + printk("reserving %d\n", XFS_GROWFS_SPACE_RES(mp) + (-new)); + if ((error =3D xfs_trans_reserve(tp, XFS_GROWFS_SPACE_RES(mp) + (-new), + XFS_GROWDATA_LOG_RES(mp), 0, 0, 0))) { + xfs_trans_cancel(tp, 0); + return error; + } + + nfree =3D 0; + for(agno =3D oagcount - 1; agno >=3D nagcount; agno--) { + xfs_extlen_t usedblks; /* total used blocks in this a.g. */ + xfs_extlen_t freeblks; /* free blocks in this a.g. */ + xfs_extlen_t metaused; /* blocks used by metadata */ + xfs_agblock_t aglen; + xfs_btree_cur_t *cur; /* cursor used for btree iteration */ + xfs_extlen_t sizeibt; /* blocks used by inode btree */ + xfs_extlen_t sizeino; /* blocks used by inode chunks */ + xfs_extlen_t sizebno; /* blocks used by by-number btree */ + xfs_extlen_t sizecnt; /* blocks used by by-count btree */ + printk("doing agno=3D%d\n", agno); + + /* + * Check the inodes and get ino btree usage + */ + error =3D xfs_ialloc_read_agi(mp, tp, agno, &bp); + if (error) { + goto error0; + } + ASSERT(bp); + agi =3D XFS_BUF_TO_AGI(bp); + /* This a.g. has inodes in use, can't shrink */ + if(INT_GET(agi->agi_count, ARCH_CONVERT) !=3D INT_GET(agi->agi_freecount= , ARCH_CONVERT)) { + printk("agi %d has %d inodes in use\n", agno, INT_GET(agi->agi_count, A= RCH_CONVERT) - INT_GET(agi->agi_freecount, ARCH_CONVERT)); + error =3D XFS_ERROR(ENOSPC); + goto error0; + } + /* Record the number of inodes (total and free) + * to substract from the superblock + */ + icount -=3D INT_GET(agi->agi_count, ARCH_CONVERT); + ifree -=3D INT_GET(agi->agi_freecount, ARCH_CONVERT); + + /* Compute the number of blocks used by inode chunks + * in this a.g. + */ + cur =3D xfs_btree_init_cursor(mp, tp, bp, agno, XFS_BTNUM_INO, NULL, 0); + sizeibt =3D sizeino =3D 0; + error =3D xfs_inobtsize(cur, cur->bc_nlevels - 1, INT_GET(agi->agi_root,= ARCH_CONVERT), &sizeibt, &sizeino); + xfs_btree_del_cursor(cur, XFS_BTREE_NOERROR); + if(error) { + goto error0; + } + printk("agi %d shows %d block in use by ino btree, %d blocks by inodes\n= ", agno, sizeibt, sizeino); + + /* Compute number of blocks used by the freelist and free btrees in this= a.g. */ + error =3D xfs_alloc_read_agf(mp, tp, agno, 0, &bp); + if (error) { + goto error0; + } + ASSERT(bp); + agf =3D XFS_BUF_TO_AGF(bp); +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 + freeblks =3D INT_GET(agf->agf_freeblks, ARCH_CONVERT); + printk("Usage: %d prealloc, %d flcount\n", XFS_PREALLOC_BLOCKS(mp), INT_= GET(agf->agf_flcount, ARCH_CONVERT)); + /* BNO btree processing */ + sizebno =3D 0; + cur =3D xfs_btree_init_cursor(mp, tp, bp, agno, XFS_BTNUM_BNO, NULL, 0); + error =3D xfs_alloc_btsize(cur, cur->bc_nlevels - 1, INT_GET(agf->agf_ro= ots[XFS_BTNUM_BNO], ARCH_CONVERT), &sizebno); + xfs_btree_del_cursor(cur, XFS_BTREE_NOERROR); + if(error) { + goto error0; + } + printk("agf %d shows %d block in use by bno btree\n", agno, sizebno); + /* CNT btree processing */ + sizecnt =3D 0; + cur =3D xfs_btree_init_cursor(mp, tp, bp, agno, XFS_BTNUM_CNT, NULL, 0); + error =3D xfs_alloc_btsize(cur, cur->bc_nlevels - 1, INT_GET(agf->agf_ro= ots[XFS_BTNUM_CNT], ARCH_CONVERT), &sizecnt); + xfs_btree_del_cursor(cur, XFS_BTREE_NOERROR); + if(error) { + goto error0; + } + printk("agf %d shows %d block in use by cnt btree\n", agno, sizecnt); +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 + /* Done gathering data, check sizes */ + /* We don't add here the sizebno and sizecnt since + * it appears they are not computed as 'used' space + */ + metaused =3D sizeino + sizeibt - 1; + + usedblks =3D XFS_PREALLOC_BLOCKS(mp) + \ + INT_GET(agf->agf_flcount, ARCH_CONVERT) + \ + metaused + sizebno - 1 + sizecnt - 1; + aglen =3D INT_GET(agf->agf_length, ARCH_CONVERT); + printk("agno=3D%d agf_length=3D%d computed used=3D%d known free=3D%d\n",= agno, aglen, usedblks, INT_GET(agf->agf_freeblks, ARCH_CONVERT)); + if(usedblks + freeblks !=3D aglen) { + printk("agno %d is not free (%d blocks allocated)\n", agno, aglen-usedb= lks-freeblks); + error =3D XFS_ERROR(ENOSPC); + goto error0; + } + new +=3D aglen; + printk("will lower with %d\n", aglen - XFS_PREALLOC_BLOCKS(mp) - metause= d); + nfree -=3D aglen - XFS_PREALLOC_BLOCKS(mp); + /* add not substract because previously these were counted as used + * think of it as first free'ing the inodes and the inode btree + * and then chopping all the other blocks from the fdblocks + */ + inofree +=3D metaused; + } + /* + * There are new blocks in the old last a.g. + */ + if (new) { + printk("Shrinking last a.g. with %d blocks\n", new); + memset(&allocarg, 0, sizeof(allocarg)); + error =3D xfs_alloc_read_agf(mp, tp, agno, 0, &bp); + if (error) { + goto error0; + } + ASSERT(bp); + agf =3D XFS_BUF_TO_AGF(bp); + allocarg.tp =3D tp; + allocarg.mp =3D mp; + allocarg.agbp =3D bp; + allocarg.agno =3D agno; + allocarg.agbno =3D INT_GET(agf->agf_length, ARCH_CONVERT) + new; + allocarg.fsbno =3D XFS_AGB_TO_FSB(mp, agno, allocarg.agbno); + allocarg.minlen =3D -new; + allocarg.maxlen =3D -new; + allocarg.prod =3D -new; + allocarg.mod =3D 0; + allocarg.minleft =3D 0; + allocarg.total =3D -new; + allocarg.type =3D XFS_ALLOCTYPE_THIS_BNO; + allocarg.alignment =3D 1; + printk("agf_free before=3D%d\n", INT_GET(agf->agf_freeblks, ARCH_CONVERT= )); + error =3D xfs_alloc_vextent(&allocarg); + if (error) { + printk("error in alloc extent\n"); + goto error0; + } + if(allocarg.agbno =3D=3D NULLAGBLOCK) { + error =3D XFS_ERROR(ENOSPC); + goto error0; + } + printk("agf_free after=3D%d\n", INT_GET(agf->agf_freeblks, ARCH_CONVERT)= ); + //nfree +=3D new; /* + because new is already negative */ + /* + * Change the agi length. + */ + error =3D xfs_ialloc_read_agi(mp, tp, agno, &bp); + if (error) { + goto error0; + } + ASSERT(bp); + agi =3D XFS_BUF_TO_AGI(bp); + INT_MOD(agi->agi_length, ARCH_CONVERT, new); + printk("agno=3D%d agi_length=3D%ld\n", agno, INT_GET(agi->agi_length, AR= CH_CONVERT)); + + xfs_ialloc_log_agi(tp, bp, XFS_AGI_LENGTH); + /* + * Change agf length. + */ + INT_MOD(agf->agf_length, ARCH_CONVERT, new); + printk("agno=3D%d agf_length=3D%ld\n", agno, INT_GET(agf->agf_length, AR= CH_CONVERT)); + ASSERT(INT_GET(agf->agf_length, ARCH_CONVERT) =3D=3D + INT_GET(agi->agi_length, ARCH_CONVERT)); + } + printk("nfree value: %d, oagcount=3D%d, nagcount=3D%d\n", nfree, oagcount= , nagcount); + xfs_trans_agblocks_delta(tp, nfree); + xfs_trans_agblocks_delta(tp, inofree); + + if (nagcount < oagcount) + xfs_trans_mod_sb(tp, XFS_TRANS_SB_AGCOUNT, nagcount - oagcount); + if (nb < mp->m_sb.sb_dblocks) + xfs_trans_mod_sb(tp, XFS_TRANS_SB_DBLOCKS, + nb - mp->m_sb.sb_dblocks); + if (nfree) + xfs_trans_mod_sb(tp, XFS_TRANS_SB_FDBLOCKS, nfree); + if (inofree) + xfs_trans_mod_sb(tp, XFS_TRANS_SB_FDBLOCKS, inofree); + if (icount) + xfs_trans_mod_sb(tp, XFS_TRANS_SB_ICOUNT, icount); + if (ifree) + xfs_trans_mod_sb(tp, XFS_TRANS_SB_IFREE, ifree); + if (dpct) + xfs_trans_mod_sb(tp, XFS_TRANS_SB_IMAXPCT, dpct); + error =3D xfs_trans_commit(tp, 0, NULL); + if (error) { + return error; + } + /* Free memory if the number of a.g. has changed */ + if (nagcount < oagcount) { + down_write(&mp->m_peraglock); + for (agno =3D nagcount; agno < oagcount; agno++) + if (mp->m_perag[agno].pagb_list) + kmem_free(mp->m_perag[agno].pagb_list, + sizeof(xfs_perag_busy_t) * + XFS_PAGB_NUM_SLOTS); +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 + mp->m_perag =3D kmem_realloc(mp->m_perag, + sizeof(xfs_perag_t) * nagcount, + sizeof(xfs_perag_t) * oagcount, + KM_SLEEP); + /* FIXME: here we could instead just lower + * nagimax to nagcount; is it better this way? + */ + mp->m_flags |=3D XFS_MOUNT_32BITINODES; + nagimax =3D xfs_initialize_perag(mp, nagcount); + up_write(&mp->m_peraglock); + } + + /* New allocation groups fully initialized, so update mount struct */ + if (nagimax) + mp->m_maxagi =3D nagimax; + if (mp->m_sb.sb_imax_pct) { + __uint64_t icount =3D mp->m_sb.sb_dblocks * mp->m_sb.sb_imax_pct; + do_div(icount, 100); + mp->m_maxicount =3D icount << mp->m_sb.sb_inopblog; + } else + mp->m_maxicount =3D 0; + for (agno =3D 1; agno < nagcount; agno++) { + error =3D xfs_read_buf(mp, mp->m_ddev_targp, + XFS_AGB_TO_DADDR(mp, agno, XFS_SB_BLOCK(mp)), + XFS_FSS_TO_BB(mp, 1), 0, &bp); + if (error) { + xfs_fs_cmn_err(CE_WARN, mp, + "error %d reading secondary superblock for ag %d", + error, agno); + break; + } + sbp =3D XFS_BUF_TO_SBP(bp); + xfs_xlatesb(sbp, &mp->m_sb, -1, XFS_SB_ALL_BITS); + /* + * If we get an error writing out the alternate superblocks, + * just issue a warning and continue. The real work is + * already done and committed. + */ + if (!(error =3D xfs_bwrite(mp, bp))) { + continue; + } else { + xfs_fs_cmn_err(CE_WARN, mp, + "write error %d updating secondary superblock for ag %d", + error, agno); + break; /* no point in continuing */ + } + } + return 0; + + error0: + xfs_trans_cancel(tp, XFS_TRANS_ABORT); + return error; +} + + +static int xfs_growfs_log_private( xfs_mount_t *mp, /* mount point for filesystem */ xfs_growfs_log_t *in) /* growfs log input struct */ diff -urN -x xfs_ialloc_btree.h.orig -x xfs_trans.c.orig -x Entries.Log -x = Entries linux-2.6-xfs.orig/fs/xfs/xfs_ialloc_btree.c linux-2.6-xfs/fs/xfs/x= fs_ialloc_btree.c --- linux-2.6-xfs.orig/fs/xfs/xfs_ialloc_btree.c 2005-01-13 00:38:29.000000= 000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_ialloc_btree.c 2005-09-06 02:01:39.029406448 += 0300 @@ -1672,6 +1672,95 @@ */ =20 /* + * Compute the size (in blocks) of the btree in the given level/block numb= er + */ +int /* error */ +xfs_inobtsize( + struct xfs_btree_cur *cur, /* btree cursor */ + int level, /* current level */ + xfs_agblock_t agbno, /* a.g. relative btree block number */ + int *btsize,/* pointer to btree size, to be incremented */ + int *inosize) /* pointer to inode blocks, to be incremented */ +{ + xfs_agnumber_t agno; + xfs_alloc_block_t *block=3DNULL; /* current btree block */ + int error; /* error return value */ + int ptrno; /* current key number */ + xfs_daddr_t d; /* disk address of btree block */ + xfs_buf_t *bp; /* buffer pointer for btree block */ + + { + xfs_agi_t *agi; /* a.g. inode header */ + + agi =3D XFS_BUF_TO_AGI(cur->bc_private.i.agbp); + agno =3D INT_GET(agi->agi_seqno, ARCH_CONVERT); + } + + + d =3D XFS_AGB_TO_DADDR(cur->bc_mp, agno, agbno); + printk("inobtsize agno=3D%d agbno=3D%d diskaddr=3D%lld level=3D%d bt=3D%d= ino=3D%d\n", agno, agbno, d, level, *btsize, *inosize); + bp =3D cur->bc_bufs[level]; + if (bp && XFS_BUF_ADDR(bp) !=3D d) + bp =3D (xfs_buf_t *)0; + if (!bp) { + /* + * Need to get a new buffer. Read it, then + * set it in the cursor, releasing the old one. + */ + if ((error =3D xfs_btree_read_bufs(cur->bc_mp, cur->bc_tp, agno, + agbno, 0, &bp, XFS_INO_BTREE_REF))) + return error; + xfs_btree_setbuf(cur, level, bp); + /* + * Point to the btree block, now that we have the buffer + */ + block =3D XFS_BUF_TO_INOBT_BLOCK(bp); + if ((error =3D xfs_btree_check_sblock(cur, block, level, + bp))) + return error; + } else + block =3D XFS_BUF_TO_INOBT_BLOCK(bp); + + if(level =3D=3D 0) { + printk("numrecs=3D%d\n", INT_GET(block->bb_numrecs, ARCH_CONVERT)); + for( ptrno =3D 0; ptrno < INT_GET(block->bb_numrecs, ARCH_CONVERT); ptrn= o++) { + xfs_inobt_rec_t *rec; + xfs_agino_t istart, istop; + xfs_agblock_t bstart, bstop; + + rec =3D XFS_INOBT_REC_ADDR(block, ptrno + 1, cur); + istart =3D INT_GET(rec->ir_startino, ARCH_CONVERT); + istop =3D istart + XFS_INODES_PER_CHUNK - 1; + bstart =3D XFS_AGINO_TO_AGBNO(cur->bc_mp, istart); + bstop =3D XFS_AGINO_TO_AGBNO(cur->bc_mp, istop); + printk("level0, recno %d, start inode %d, stop inode %d, start block %d= , stop block %d, used blocks %d\n", + ptrno, istart, istop, bstart, bstop, bstop - bstart + 1); + (*inosize) +=3D bstop - bstart + 1; + } + (*btsize)++; + return 0; + } + + /* + * Iterate over each child in this non-leaf block + */ + for (ptrno =3D 0; ptrno < INT_GET(block->bb_numrecs, ARCH_CONVERT); ptrno= ++) { + xfs_inobt_ptr_t *ptr; + xfs_agblock_t newbno; + + ptr =3D XFS_INOBT_PTR_ADDR(block, ptrno + 1, cur); + newbno =3D INT_GET(*ptr, ARCH_CONVERT); + printk("\twill enter ptrno=3D%d (of %d) agbno=3D%d\n", ptrno, INT_GET(bl= ock->bb_numrecs, ARCH_CONVERT), newbno); + + if((error =3D xfs_inobtsize(cur, level - 1, newbno, btsize, inosize))) + return error; + + } + (*btsize)++; + return 0; +} + +/* * Decrement cursor by one record at the level. * For nonzero levels the leaf-ward information is untouched. */ diff -urN -x xfs_ialloc_btree.h.orig -x xfs_trans.c.orig -x Entries.Log -x = Entries linux-2.6-xfs.orig/fs/xfs/xfs_ialloc_btree.h linux-2.6-xfs/fs/xfs/x= fs_ialloc_btree.h --- linux-2.6-xfs.orig/fs/xfs/xfs_ialloc_btree.h 2005-06-07 17:39:14.000000= 000 +0300 +++ linux-2.6-xfs/fs/xfs/xfs_ialloc_btree.h 2005-09-06 02:01:39.040404776 += 0300 @@ -219,6 +219,17 @@ */ =20 /* + * Compute the size (in blocks) of the btree in the given level/block numb= er + */ +int /* error */ +xfs_inobtsize( + struct xfs_btree_cur *cur, /* btree cursor */ + int level, + xfs_agblock_t agbno, /* a.g. relative btree block number */ + int *btsize,/* pointer to btree size, to be incremented */ + int *inosize); /* pointer to inode blocks, to be incremented */ + +/* * Decrement cursor by one record at the level. * For nonzero levels the leaf-ward information is untouched. */ diff -urN -x xfs_ialloc_btree.h.orig -x xfs_trans.c.orig -x Entries.Log -x = Entries linux-2.6-xfs.orig/fs/xfs/xfs_trans.c linux-2.6-xfs/fs/xfs/xfs_tran= s.c --- linux-2.6-xfs.orig/fs/xfs/xfs_trans.c 2005-07-13 06:43:58.000000000 +03= 00 +++ linux-2.6-xfs/fs/xfs/xfs_trans.c 2005-09-06 02:01:39.041404624 +0300 @@ -396,11 +396,9 @@ tp->t_res_frextents_delta +=3D delta; break; case XFS_TRANS_SB_DBLOCKS: - ASSERT(delta > 0); tp->t_dblocks_delta +=3D delta; break; case XFS_TRANS_SB_AGCOUNT: - ASSERT(delta > 0); tp->t_agcount_delta +=3D delta; break; case XFS_TRANS_SB_IMAXPCT: --OXfL5xGRrasGEqWY-- --E39vaYmALEf/7YXx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDHNL24mx23Z34NMIRAgssAKDPfHPAGt6rVX9vI+t+vcB59XWObQCfUoNk Px+nUhlItl/dpUx4EhWs6/Q= =a4jF -----END PGP SIGNATURE----- --E39vaYmALEf/7YXx-- From owner-linux-xfs@oss.sgi.com Mon Sep 5 23:23:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Sep 2005 23:23:34 -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 j866NSiL001925 for ; Mon, 5 Sep 2005 23:23:28 -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 j866L4JJ015786 for ; Tue, 6 Sep 2005 02:21:04 -0400 X-ORBL: [67.124.117.85] Received: from stupidest.org (adsl-67-124-117-85.dsl.snfc21.pacbell.net [67.124.117.85]) by pimout2-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j866Kq9T302018; Tue, 6 Sep 2005 02:20:52 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id C4DBE528F26; Mon, 5 Sep 2005 23:20:51 -0700 (PDT) Date: Mon, 5 Sep 2005 23:20:51 -0700 From: Chris Wedgwood To: "George N. White III" Cc: linux-xfs@oss.sgi.com Subject: Re: Help! Defragmenting XFS killed my partition? Message-ID: <20050906062051.GA25039@taniwha.stupidest.org> References: <20050905021413.GB22746@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 6071 X-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: 343 Lines: 9 On Mon, Sep 05, 2005 at 09:49:36AM -0300, George N. White III wrote: > Not necessarily. A bad cable, power glitches, or a bulging > capacitor in the CPU voltage converter could produce disk errors. > The history of the drive is often a good indication. Looking at the errors posted I would guess most likely a dead drive than a bad cable. From owner-linux-xfs@oss.sgi.com Tue Sep 6 15:48:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Sep 2005 15:48:56 -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 j86MmniL015247 for ; Tue, 6 Sep 2005 15:48:49 -0700 Received: from hastur.corp.sgi.com (hastur.corp.sgi.com [198.149.32.33]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j870lDQe008722 for ; Tue, 6 Sep 2005 17:47:13 -0700 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by hastur.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j86MipeS190398256 for ; Tue, 6 Sep 2005 15:44:52 -0700 (PDT) X-ASG-Debug-ID: 1126046703-3786-15-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2422D526F5F for ; Tue, 6 Sep 2005 15:45:03 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j86Mj0P9017575; Tue, 6 Sep 2005 17:45:01 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j86MixRn017560; Tue, 6 Sep 2005 17:44:59 -0500 Date: Tue, 6 Sep 2005 17:44:59 -0500 From: Christoph Hellwig Message-Id: <200509062244.j86MixRn017560@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com X-ASG-Orig-Subj: TAKE 912426 - write barrier support Subject: TAKE 912426 - write barrier support X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.3772 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6072 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2896 Lines: 51 Issue all log sync operations as ordered writes. In addition flush the disk cache on fsync if the sync cached operation didn't sync the log to disk (this requires some additional bookeping in the transaction and log code). If the device doesn't claim to support barriers, the filesystem has an extern log volume or the trial superblock write with barriers enabled failed we disable barriers and print a warning. We should probably fail the mount completely, but that could lead to nasty boot failures for the root filesystem. Not enabled by default yet, needs more destructive testing first. Date: Tue Sep 6 15:44:36 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:198723a fs/xfs/xfsidbg.c - 1.282 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.282&r2=text&tr2=1.281&f=h fs/xfs/xfs_log.h - 1.74 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.h.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h fs/xfs/xfs_log.c - 1.308 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.308&r2=text&tr2=1.307&f=h fs/xfs/xfs_vnodeops.c - 1.650 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.650&r2=text&tr2=1.649&f=h fs/xfs/xfs_vfsops.c - 1.472 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.472&r2=text&tr2=1.471&f=h fs/xfs/xfs_clnt.h - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_clnt.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h fs/xfs/xfs_mount.h - 1.201 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.201&r2=text&tr2=1.200&f=h fs/xfs/xfs_trans.c - 1.164 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.164&r2=text&tr2=1.163&f=h fs/xfs/xfs_trans.h - 1.132 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.h.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h fs/xfs/linux-2.6/xfs_super.h - 1.64 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.h.diff?r1=text&tr1=1.64&r2=text&tr2=1.63&f=h fs/xfs/linux-2.6/xfs_super.c - 1.343 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.343&r2=text&tr2=1.342&f=h fs/xfs/linux-2.6/xfs_buf.h - 1.108 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.108&r2=text&tr2=1.107&f=h fs/xfs/linux-2.6/xfs_buf.c - 1.207 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.207&r2=text&tr2=1.206&f=h fs/xfs/linux-2.6/xfs_ksyms.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h From owner-linux-xfs@oss.sgi.com Wed Sep 7 07:33:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Sep 2005 07:33:33 -0700 (PDT) Received: from asteria.debian.or.at (asteria.debian.or.at [86.59.5.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j87EXNiL029807 for ; Wed, 7 Sep 2005 07:33:23 -0700 Received: by asteria.debian.or.at (Postfix, from userid 1002) id 7A8A27093A5; Wed, 7 Sep 2005 16:30:49 +0200 (CEST) Date: Wed, 7 Sep 2005 16:30:49 +0200 From: Peter Palfrader To: linux-xfs@oss.sgi.com Subject: Kernel Oopses on 2.6.13 Message-ID: <20050907143048.GA11805@opium.palfrader.org> Mail-Followup-To: Peter Palfrader , linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline X-PGP: 1024D/94C09C7F 5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F X-Request-PGP: http://www.palfrader.org/keys/94C09C7F.asc X-Accept-Language: de, en User-Agent: Mutt/1.5.9i X-archive-position: 6075 X-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@palfrader.org Precedence: bulk X-list: linux-xfs Content-Length: 9105 Lines: 229 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Hi, I'm running a pristine 2.6.13 and got an Oops. After rebooting when mounting the filesystem to replay the log (as suggested by xfs_check) I got another one. I have attached the output of ksymoops from both Oopses. I hope they can help you to make your great filesystem even better :) Let me know if you need anything else. cheers, -- Peter --UugvWAfsgieZRqgk Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: attachment; filename="oops1.out" ksymoops 2.4.9 on i686 2.6.13-came32. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.13-came32/ (default) -m /boot/System.map-2.6.13-came32 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod Unable to handle kernel NULL pointer dereference at virtual address 0000007a c021be3e *pde = 00000000 Oops: 0002 [#1] CPU: 0 EIP: 0060:[] Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 (2.6.13-came32) eax: 0000007a ebx: 00000007 ecx: e788d73c edx: 0000007a esi: f7fcbdcc edi: db311000 ebp: f4a34674 esp: f7fcbd40 ds: 007b es: 007b ss: 0068 Stack: f760de20 0a8c0010 00078000 f4a34674 c0236837 f4a34674 db311000 00000000 00000000 db311000 c021d343 f4a34674 00000000 00000000 00000000 f4a34674 00000000 e788d73c c05fa2c0 db311010 00000000 0000002d f7bc9400 00000007 Call Trace: [] xfs_btree_check_sblock+0x77/0xe0 [] xfs_alloc_lookup+0x143/0x440 [] xfs_alloc_delete+0x1b/0x80 [] xfs_free_ag_extent+0x142/0x680 [] xfs_free_extent+0xc6/0xf0 [] kmem_zone_zalloc+0x22/0x50 [] xfs_trans_get_efd+0x22/0x30 [] xfs_bmap_finish+0x102/0x180 [] xfs_remove+0x29c/0x440 [] linvfs_permission+0x1b/0x30 [] linvfs_unlink+0x1b/0x40 [] vfs_unlink+0x12d/0x1a0 [] sys_unlink+0x99/0x110 [] syscall_call+0x7/0xb Code: 8b 79 60 66 8b 47 06 25 ff ff 00 00 89 c2 c1 e2 08 c1 e8 08 09 c2 81 e2 ff ff 00 00 39 d3 7e 0f 8b 9c 24 88 00 00 00 c7 03 00 00 <00> 00 eb b8 ba 00 e0 ff ff b8 c0 a2 5f c0 21 e2 8b 52 10 8b 0c >>EIP; c021be3e <===== >>ecx; e788d73c >>esi; f7fcbdcc >>edi; db311000 >>ebp; f4a34674 >>esp; f7fcbd40 Trace; c0236837 Trace; c021d343 Trace; c021e7eb Trace; c021a6c2 Trace; c021baf6 Trace; c0273aa2 Trace; c0269c52 Trace; c022d4b2 Trace; c026fd8c Trace; c027a5cb Trace; c027a31b Trace; c01660fd Trace; c0166209 Trace; c0102c79 This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c021be13 00000000 <_EIP>: Code; c021be13 0: 8b 79 60 mov 0x60(%ecx),%edi Code; c021be16 3: 66 8b 47 06 mov 0x6(%edi),%ax Code; c021be1a 7: 25 ff ff 00 00 and $0xffff,%eax Code; c021be1f c: 89 c2 mov %eax,%edx Code; c021be21 e: c1 e2 08 shl $0x8,%edx Code; c021be24 11: c1 e8 08 shr $0x8,%eax Code; c021be27 14: 09 c2 or %eax,%edx Code; c021be29 16: 81 e2 ff ff 00 00 and $0xffff,%edx Code; c021be2f 1c: 39 d3 cmp %edx,%ebx Code; c021be31 1e: 7e 0f jle 2f <_EIP+0x2f> Code; c021be33 20: 8b 9c 24 88 00 00 00 mov 0x88(%esp),%ebx Code; c021be3a 27: c7 .byte 0xc7 Code; c021be3b 28: 03 00 add (%eax),%eax This decode from eip onwards should be reliable Code; c021be3e 00000000 <_EIP>: Code; c021be3e <===== 0: 00 00 add %al,(%eax) <===== Code; c021be40 2: eb b8 jmp ffffffbc <_EIP+0xffffffbc> Code; c021be42 4: ba 00 e0 ff ff mov $0xffffe000,%edx Code; c021be47 9: b8 c0 a2 5f c0 mov $0xc05fa2c0,%eax Code; c021be4c e: 21 e2 and %esp,%edx Code; c021be4e 10: 8b 52 10 mov 0x10(%edx),%edx Code; c021be51 13: 8b .byte 0x8b Code; c021be52 14: 0c .byte 0xc 1 warning and 1 error issued. Results may not be reliable. --UugvWAfsgieZRqgk Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: attachment; filename="oops2.out" ksymoops 2.4.9 on i686 2.6.13-came32. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.13-came32/ (default) -m /boot/System.map-2.6.13-came32 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod 021be3e FLAGS: 00010293 (2.6.13-came32) 00000000 c0275b7e c16f6fa0 00019011 00000000 00000000 00000000 00000001 c1bef420 f6f8c65c c05fa2c0 f74bc010 00000000 00000000 f7b7f400 00000072 [] _pagebuf_map_pages+0x7e/0xa0 [] xfs_alloc_delete+0x1b/0x80 [] xfs_alloc_fixup_trees+0x71/0x2e0 [] xfs_alloc_ag_vextent_near+0x3d2/0xa10 [] xfs_alloc_ag_vextent+0x117/0x120 [] xfs_alloc_vextent+0x450/0x580 [] scsi_put_command+0x6f/0xb0 [] xfs_bmap_alloc+0xa0d/0x18a0 [] xfs_bmbt_get_state+0x1e/0x30 [] xfs_bmap_do_search_extents+0x114/0x4c0 [] scsi_softirq+0xa6/0xd0 [] xfs_bmapi+0x11b9/0x1640 [] xfs_bmbt_get_state+0x1e/0x30 [] xfs_bmap_do_search_extents+0x114/0x4c0 [] mempool_alloc_slab+0xf/0x20 [] xlog_grant_push_ail+0x3a/0x110 [] xlog_grant_push_ail+0xdf/0x110 [] xfs_log_reserve+0xa8/0xc0 [] xfs_iomap_write_allocate+0x297/0x500 [] as_update_arq+0x1a/0x50 [] as_add_request+0x187/0x1f0 [] xfs_log_move_tail+0x44/0x180 [] xfs_iomap+0x359/0x480 [] generic_make_request+0x133/0x200 [] xfs_bmap+0x2d/0x40 [] xfs_map_blocks+0x35/0x70 [] xfs_page_state_convert+0x4c8/0x640 [] submit_bio+0x53/0xd0 [] radix_tree_gang_lookup_tag+0x43/0x60 [] find_get_pages_tag+0x32/0x70 [] linvfs_writepage+0x54/0xf0 [] mpage_writepages+0x241/0x390 [] linvfs_writepage+0x0/0xf0 [] linvfs_write_inode+0x2e/0x60 [] do_writepages+0x29/0x40 [] __sync_single_inode+0x5e/0x210 [] __writeback_single_inode+0x6f/0x140 [] dm_table_any_congested+0x14/0x60 [dm_mod] [] sync_sb_inodes+0x1ad/0x2b0 [] writeback_inodes+0xcb/0xe0 [] wb_kupdate+0xbb/0x130 [] pdflush+0x0/0x30 [] __pdflush+0xc0/0x1b0 [] pdflush+0x1e/0x30 [] wb_kupdate+0x0/0x130 [] kthread+0xa7/0xb0 [] kthread+0x0/0xb0 [] kernel_thread_helper+0x5/0x18 1 warning and 1 error issued. Results may not be reliable. --UugvWAfsgieZRqgk-- From owner-linux-xfs@oss.sgi.com Wed Sep 7 08:14:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Sep 2005 08:14:30 -0700 (PDT) Received: from zero.voxel.net (zero.voxel.net [209.123.232.253]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j87FEJiL001036 for ; Wed, 7 Sep 2005 08:14:20 -0700 Received: from [192.168.1.211] (d66-222-167-155.abhsia.telus.net [66.222.167.155]) by zero.voxel.net (Postfix) with ESMTP id C5C7F24AE18 for ; Wed, 7 Sep 2005 11:11:45 -0400 (EDT) Subject: large number of user quotas From: Matthew Kent To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Wed, 07 Sep 2005 09:11:29 -0600 Message-Id: <1126105889.6043.17.camel@fuego> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 6076 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mkent@magoazul.com Precedence: bulk X-list: linux-xfs Content-Length: 1181 Lines: 34 Well I don't know what my other email accounts problem is with this list, and I don't see any moderation so I'm assuming its just not making it through, but forgive me if you end up with 3 copies of this message... Hello list, Couple questions regarding quotas I couldn't find in the archives. I'm looking at implementing user quotas for > 1 million accounts and I've read in the XFS for Linux Administration guide: "In addition, on XFS filesystems there is no limit to the number of accounts and there is little performance penalty for large numbers of users." but I'm not sure if >1 million accounts falls into the "large number of users" category or "thats far too many to ever work efficiently". Also, it seems in my limited testing that whats reported by repquota isn't in real time when I fill up one of my account quotas, I'm assuming the quota data is being updated at some sort of interval? Is this configurable? And if anyone can point me to a more in depth description of how quotas are implemented than the XFS admin guide, but higher level than poking through the code, I'd be very grateful. Thanks. -- Matthew Kent http://magoazul.com From owner-linux-xfs@oss.sgi.com Wed Sep 7 10:48:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Sep 2005 10:48:35 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j87HmHiL014489 for ; Wed, 7 Sep 2005 10:48:17 -0700 Received: from c-66-30-115-133.hsd1.ma.comcast.net ([66.30.115.133]) by comcast.net (sccrmhc13) with ESMTP id <20050907174536013004uahae>; Wed, 7 Sep 2005 17:45:36 +0000 Received: from c-66-30-115-133.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j87HjZh2001949 for ; Wed, 7 Sep 2005 13:45:35 -0400 (EDT) (envelope-from rodrigc@c-66-30-115-133.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j87HjZGC001948 for linux-xfs@oss.sgi.com; Wed, 7 Sep 2005 13:45:35 -0400 (EDT) (envelope-from rodrigc) Date: Wed, 7 Sep 2005 13:45:35 -0400 From: Craig Rodrigues To: linux-xfs@oss.sgi.com Subject: Warnings when compiling xfs_macros.c Message-ID: <20050907174535.GA1850@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: 6077 X-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: 3034 Lines: 80 Hi, I am trying to eliminate compilation errors when compiling XFS code on FreeBSD. I've gotten rid of most of them, but am having problems with xfs_macros.c. The FreeBSD kernel build adds the flag -Wmissing-prototypes, and I am getting lots of warnings like this: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wpointer-arith -Winline -Wcast-qual -ffo rmat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/a ltq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/ xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param in line-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/gnu/fs/xfs/xfs_macros.c /usr/src/sys/gnu/fs/xfs/xfs_macros.c:2234: warning: no previous prototype for 'xlog_grant_add_space' /usr/src/sys/gnu/fs/xfs/xfs_macros.c:2242: warning: no previous prototype for 'xlog_grant_sub_space' I see that in xfs_macros.c, we have: #if XFS_WANT_FUNCS_C || (XFS_WANT_SPACE_C && XFSSO_XLOG_GRANT_ADD_SPACE) void xlog_grant_add_space(xlog_t *log, int bytes, int type) { XLOG_GRANT_ADD_SPACE(log, bytes, type); } #endif #if XFS_WANT_FUNCS_C || (XFS_WANT_SPACE_C && XFSSO_XLOG_GRANT_SUB_SPACE) void xlog_grant_sub_space(xlog_t *log, int bytes, int type) { XLOG_GRANT_SUB_SPACE(log, bytes, type); } #endif Would it be acceptable if I submitted a patch which told gcc to shut up by doing something like this in the header file: ==== //depot/projects/freebsd/kern/xfs/xfs_log_priv.h#9 - /opt/home/rodrigc/xfs/project/xfs_log_priv.h ==== --- /tmp/tmp.1941.0 Wed Sep 7 13:44:47 2005 +++ /opt/home/rodrigc/xfs/project/xfs_log_priv.h Wed Sep 7 13:42:47 2005 @@ -126,8 +126,11 @@ ((i) >> 24) #endif -#if XFS_WANT_FUNCS || (XFS_WANT_SPACE && XFSSO_XLOG_GRANT_SUB_SPACE) +#if XFS_WANT_FUNCS || XFS_WANT_FUNCS_C || (XFS_WANT_SPACE && XFSSO_XLOG_GRANT_SUB_SPACE) void xlog_grant_sub_space(struct log *log, int bytes, int type); +#endif + +#if XFS_WANT_FUNCS || (XFS_WANT_SPACE && XFSSO_XLOG_GRANT_SUB_SPACE) #define XLOG_GRANT_SUB_SPACE(log,bytes,type) \ xlog_grant_sub_space(log,bytes,type) #else @@ -148,8 +151,13 @@ } \ } #endif -#if XFS_WANT_FUNCS || (XFS_WANT_SPACE && XFSSO_XLOG_GRANT_ADD_SPACE) + + +#if XFS_WANT_FUNCS || XFS_WANT_FUNCS_C || (XFS_WANT_SPACE && XFSSO_XLOG_GRANT_ADD_SPACE) void xlog_grant_add_space(struct log *log, int bytes, int type); +#endif + +#if XFS_WANT_FUNCS || (XFS_WANT_SPACE && XFSSO_XLOG_GRANT_ADD_SPACE) #define XLOG_GRANT_ADD_SPACE(log,bytes,type) \ xlog_grant_add_space(log,bytes,type) #else -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs@oss.sgi.com Wed Sep 7 11:23:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Sep 2005 11:23:47 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j87INYiL016957 for ; Wed, 7 Sep 2005 11:23:37 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.52 #1 (Red Hat Linux)) id 1ED4Xc-0003QH-36; Wed, 07 Sep 2005 19:21:00 +0100 Date: Wed, 7 Sep 2005 19:21:00 +0100 From: Christoph Hellwig To: Craig Rodrigues Cc: linux-xfs@oss.sgi.com Subject: Re: Warnings when compiling xfs_macros.c Message-ID: <20050907182059.GA13074@infradead.org> References: <20050907174535.GA1850@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050907174535.GA1850@crodrigues.org> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6078 X-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@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 513 Lines: 13 On Wed, Sep 07, 2005 at 01:45:35PM -0400, Craig Rodrigues wrote: > Hi, > > I am trying to eliminate compilation errors when compiling > XFS code on FreeBSD. I've gotten rid of most of them, > but am having problems with xfs_macros.c. > The FreeBSD kernel build adds the flag -Wmissing-prototypes, > and I am getting lots of warnings like this: xfs_macros.c is a mess. If you want to do a service to everyone kill it and the surrounding machinery and just leave the macros, without the out of line instances. From owner-linux-xfs@oss.sgi.com Wed Sep 7 11:48:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Sep 2005 11:48:25 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j87ImHiL019059 for ; Wed, 7 Sep 2005 11:48:18 -0700 Received: from c-66-30-115-133.hsd1.ma.comcast.net ([66.30.115.133]) by comcast.net (rwcrmhc13) with ESMTP id <2005090718454301500j47pce>; Wed, 7 Sep 2005 18:45:43 +0000 Received: from c-66-30-115-133.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j87Ijgdh002341; Wed, 7 Sep 2005 14:45:42 -0400 (EDT) (envelope-from rodrigc@c-66-30-115-133.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j87Ijg6E002340; Wed, 7 Sep 2005 14:45:42 -0400 (EDT) (envelope-from rodrigc) Date: Wed, 7 Sep 2005 14:45:42 -0400 From: Craig Rodrigues To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com Subject: Re: Warnings when compiling xfs_macros.c Message-ID: <20050907184542.GA2316@crodrigues.org> References: <20050907174535.GA1850@crodrigues.org> <20050907182059.GA13074@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050907182059.GA13074@infradead.org> User-Agent: Mutt/1.5.9i X-archive-position: 6079 X-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: 734 Lines: 19 On Wed, Sep 07, 2005 at 07:21:00PM +0100, Christoph Hellwig wrote: > xfs_macros.c is a mess. If you want to do a service to everyone > kill it and the surrounding machinery and just leave the macros, > without the out of line instances. I don't like xfs_macros.c either, but my understanding was that it still needs to be around, so as not to diverge from the Irix code. At least that is my understanding based on reading this thread: http://oss.sgi.com/archives/linux-xfs/2004-01/msg00187.html My proposed patch would not disturb the status quo (however distasteful), and get things to compile with -Wmissing-prototypes, which is used in the FreeBSD kernel compilation flags. -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs@oss.sgi.com Wed Sep 7 17:01:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Sep 2005 17:01:40 -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 j8801ZiL014647 for ; Wed, 7 Sep 2005 17:01:36 -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 JAA17775; Thu, 8 Sep 2005 09:58:48 +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 j87Nwwkt4666414; Thu, 8 Sep 2005 09:58:58 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j87Nwr1r4663652; Thu, 8 Sep 2005 09:58:53 +1000 (EST) Date: Thu, 8 Sep 2005 09:58:53 +1000 From: Nathan Scott To: Matthew Kent Cc: linux-xfs@oss.sgi.com Subject: Re: large number of user quotas Message-ID: <20050908095853.E4583139@wobbly.melbourne.sgi.com> References: <1126105889.6043.17.camel@fuego> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1126105889.6043.17.camel@fuego>; from mkent@magoazul.com on Wed, Sep 07, 2005 at 09:11:29AM -0600 X-archive-position: 6080 X-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: 1979 Lines: 46 On Wed, Sep 07, 2005 at 09:11:29AM -0600, Matthew Kent wrote: > Well I don't know what my other email accounts problem is with this > list, and I don't see any moderation so I'm assuming its just not making > it through, but forgive me if you end up with 3 copies of this > message... Yeah, it may not be just you, I've noticed some mails from linux-xfs not being delivered to me in the last few days (but they do show up in the archive on oss). *shrug* ... Russell/Trev, any ideas? > but I'm not sure if >1 million accounts falls into the "large number of > users" category or "thats far too many to ever work efficiently". It should be fine, report back if not and it should get some attention. > Also, it seems in my limited testing that whats reported by repquota > isn't in real time when I fill up one of my account quotas, I'm assuming > the quota data is being updated at some sort of interval? Is this > configurable? Well, thats the good old delayed-allocate-space-is-not-allocated-yet problem ... the repquota code is only reporting on space that has actually been allocated. I have a patch lying around someplace that implements the Q_SYNC quotactl for XFS, such that the filesystem being reported on will have delalloc data flushed just prior to querying. It seems to resolve the problem, I just need to find some time to tidy it up, get it reviewed and merge it in. > And if anyone can point me to a more in depth description of how quotas > are implemented than the XFS admin guide, but higher level than poking > through the code, I'd be very grateful. If you have a fairly recent version of xfsprogs, not too long ago we added an extensive xfs_quota(8) man page which has the sort of information you are looking for. In older versions of xfsprogs there was a /usr/share/doc/xfsprogs/README.quota (actual pathname may vary depending on Linux distro) which has a subset of that, but should also answer your questions I think. HTH. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Sep 7 17:41:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Sep 2005 17:41:23 -0700 (PDT) Received: from isp.becroft.co.nz (isp.becroft.co.nz [202.89.33.33]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j880fDiL017191 for ; Wed, 7 Sep 2005 17:41:15 -0700 Received: from [10.10.10.10] (gateway.quickcircuit.co.nz [210.55.214.217]) by isp.becroft.co.nz (8.12.10/8.12.9) with ESMTP id j880cYsl021896 for ; Thu, 8 Sep 2005 12:38:35 +1200 Subject: XFS and LVM2 snapshot with external log problem From: Mario Becroft To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Private site Message-Id: <1126139914.23525.47.camel@server.ak.quickcircuit.co.nz> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 08 Sep 2005 12:38:34 +1200 Content-Transfer-Encoding: 7bit X-Scanned-By: milter-spamc/0.20.282 (isp.becroft.co.nz [202.89.33.33]); Thu, 08 Sep 2005 12:38:38 +1200 X-archive-position: 6081 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mb@gem.win.co.nz Precedence: bulk X-list: linux-xfs Content-Length: 4952 Lines: 143 Hello, I am using XFS on LVM2 and I have a problem creating snapshots. I will only be mounting the snapshot read-only, and when the XFS filesystem is frozen, the log is flushed (is this true?), so I believe I should not need to snapshot the log, only the data device. Problem: if I try to mount the filesystem without specifying a logdev= option, even with ro,norecovery, mount complains with error 990. So I created a dummy log filled with 0's to use when mounting read-only snapshots. Strange thing: if the dummy log device is read only, mount complains, even though I am specifying the ro option. So I had to make the dummy log device writable--but I note that XFS never actually writes anything to it. This approach sort of works, but if files are being modified when the snapshot is made, they can be corrupt in the snapshot. So I guess the filesystem is not being frozen properly, or else freezing does not completely flush the log, and so I would need to snapshot the log too (but that seems silly). Anyway, I cannot snapshot the log, because there is no way to atomically freeze the filesystem, create two snapshots (log and data device) and then unfreeze. I tried using xfs_freeze to do this, but then lvcreate hangs, as described elsewhere on linux-lvm. Can anyone shed some light on these problems? Any suggestions will be much appreciated. For reference, I am using kernel 2.6.12.5 on AMD64, device-mapper 1.01.04. and LVM2 2.01.09, which I believe are the latest stable versions. I am about to try kernel 2.6.13. The commands I use to create and mount the snapshot are, for example: mkdir -p /export/home_backup lvcreate -L4G -s -pr -nhome_backup /dev/vg0/home mount -t xfs -o nouuid,ro,norecovery,logdev=/dev/log0/dummy_log /dev/vg0/home_backup /export/home_backup The original filesystem that I am trying to make a snapshot of is mounted like this: mount -t xfs -o logbufs=8,logdev=/dev/log0/homelog /dev/vg0/home /export/home Further information: # lvdisplay /dev/vg0/home --- Logical volume --- LV Name /dev/vg0/home VG Name vg0 LV UUID hegvc2-MIwz-iSmN-m2af-LObQ-pfVp-A3UlWy LV Write Access read/write LV Status available # open 1 LV Size 32.00 GB Current LE 8192 Segments 2 Allocation inherit Read ahead sectors 0 Block device 253:0 # xfs_info /export/home meta-data=/export/home isize=256 agcount=18, agsize=491520 blks = sectsz=512 data = bsize=4096 blocks=8388608, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =external bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # vgdisplay --- Volume group --- VG Name vg0 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 124 VG Access read/write VG Status resizable MAX LV 0 Cur LV 5 Open LV 4 Max PV 0 Cur PV 1 Act PV 1 VG Size 223.52 GB PE Size 4.00 MB Total PE 57221 Alloc PE / Size 29440 / 115.00 GB Free PE / Size 27781 / 108.52 GB VG UUID N0Vkgh-i7Zn-ohXQ-M64S-GQxa-bncH-JWPxGG --- Volume group --- VG Name log0 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 15 VG Access read/write VG Status resizable MAX LV 0 Cur LV 4 Open LV 3 Max PV 0 Cur PV 1 Act PV 1 VG Size 16.85 GB PE Size 4.00 MB Total PE 4314 Alloc PE / Size 128 / 512.00 MB Free PE / Size 4186 / 16.35 GB VG UUID vDyLlP-dwfW-9Nj5-dmHh-Ya7O-zUAo-81rUf9 # pvdisplay --- Physical volume --- PV Name /dev/md20 VG Name vg0 PV Size 223.52 GB / not usable 0 Allocatable yes PE Size (KByte) 4096 Total PE 57221 Free PE 27781 Allocated PE 29440 PV UUID f47Jdk-arEl-RpRL-MI7f-E6H4-sVSL-xVK4CC --- Physical volume --- PV Name /dev/md11 VG Name log0 PV Size 16.85 GB / not usable 0 Allocatable yes PE Size (KByte) 4096 Total PE 4314 Free PE 4186 Allocated PE 128 PV UUID pFQgKc-RrM1-M5Ui-ChnC-t3Md-Qo0E-nqu9oW -- Mario Becroft From owner-linux-xfs@oss.sgi.com Wed Sep 7 21:19:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Sep 2005 21:21:01 -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 j884JpiL031909 for ; Wed, 7 Sep 2005 21:19:52 -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 j884HEfE4654150; Thu, 8 Sep 2005 14:17:15 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j884HA3t4756210; Thu, 8 Sep 2005 14:17:10 +1000 (AEST) Date: Thu, 8 Sep 2005 14:17:10 +1000 From: Tim Shimmin To: Craig Rodrigues Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: Warnings when compiling xfs_macros.c Message-ID: <20050908141710.R4874818@boing.melbourne.sgi.com> References: <20050907174535.GA1850@crodrigues.org> <20050907182059.GA13074@infradead.org> <20050907184542.GA2316@crodrigues.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: <20050907184542.GA2316@crodrigues.org>; from rodrigc@crodrigues.org on Wed, Sep 07, 2005 at 02:45:42PM -0400 X-archive-position: 6082 X-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: 1144 Lines: 27 On Wed, Sep 07, 2005 at 02:45:42PM -0400, Craig Rodrigues wrote: > On Wed, Sep 07, 2005 at 07:21:00PM +0100, Christoph Hellwig wrote: > > xfs_macros.c is a mess. If you want to do a service to everyone > > kill it and the surrounding machinery and just leave the macros, > > without the out of line instances. > > I don't like xfs_macros.c either, but my understanding > was that it still needs to be around, so as not to diverge > from the Irix code. At least that is my understanding > based on reading this thread: > http://oss.sgi.com/archives/linux-xfs/2004-01/msg00187.html > Yeah, add me to the list of people who don't like xfs_macros.c. If you can come up with a patch that is not too ridiculously intrusive then I'd welcome it and push it into IRIX (we certainly do put code from Linux back into IRIX). I just haven't looked into the scope of the changes that it would cause. > My proposed patch would not disturb the status quo (however distasteful), > and get things to compile with -Wmissing-prototypes, which is > used in the FreeBSD kernel compilation flags. > I understand that you might not want to do the above. --Tim From owner-linux-xfs@oss.sgi.com Wed Sep 7 22:46:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Sep 2005 22:46:34 -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 j885kTiL006511 for ; Wed, 7 Sep 2005 22:46:30 -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 PAA25445; Thu, 8 Sep 2005 15:43:50 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4E0B449BFAB7; Thu, 8 Sep 2005 15:43:49 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 942400 - fix mainline -Wundef warnings Message-Id: <20050908054349.4E0B449BFAB7@chook.melbourne.sgi.com> Date: Thu, 8 Sep 2005 15:43:49 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6083 X-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: 1481 Lines: 28 Cleanup some -Wundef flag warnings in the endian macros (thanks Christoph). Date: Thu Sep 8 15:41:42 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:23771a xfs_log_priv.h - 1.107 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h xfs_arch.h - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_arch.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h xfs_inode_item.c - 1.120 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.c.diff?r1=text&tr1=1.120&r2=text&tr2=1.119&f=h xfs_bmap_btree.h - 1.68 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.h.diff?r1=text&tr1=1.68&r2=text&tr2=1.67&f=h xfs_bmap_btree.c - 1.147 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.147&r2=text&tr2=1.146&f=h xfs_dir_leaf.h - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.h.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h linux-2.6/xfs_ksyms.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h linux-2.4/xfs_ksyms.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h From owner-linux-xfs@oss.sgi.com Thu Sep 8 01:54:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Sep 2005 01:54:47 -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 j888saiL025103 for ; Thu, 8 Sep 2005 01:54:37 -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 j888pxfE4946744; Thu, 8 Sep 2005 18:51:59 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j888puYn3553634; Thu, 8 Sep 2005 18:51:56 +1000 (AEST) Date: Thu, 8 Sep 2005 18:51:56 +1000 From: Tim Shimmin To: rodrigc@crodrigues.org Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: Warnings when compiling xfs_macros.c Message-ID: <20050908185156.A4874818@boing.melbourne.sgi.com> References: <20050907174535.GA1850@crodrigues.org> <20050907182059.GA13074@infradead.org> <20050907184542.GA2316@crodrigues.org> <20050908141710.R4874818@boing.melbourne.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: <20050908141710.R4874818@boing.melbourne.sgi.com>; from tes@sgi.com on Thu, Sep 08, 2005 at 02:17:10PM +1000 X-archive-position: 6084 X-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: 1232 Lines: 26 On Thu, Sep 08, 2005 at 02:17:10PM +1000, Tim Shimmin wrote: > On Wed, Sep 07, 2005 at 02:45:42PM -0400, Craig Rodrigues wrote: > > On Wed, Sep 07, 2005 at 07:21:00PM +0100, Christoph Hellwig wrote: > > > xfs_macros.c is a mess. If you want to do a service to everyone > > > kill it and the surrounding machinery and just leave the macros, > > > without the out of line instances. > > > > I don't like xfs_macros.c either, but my understanding > > was that it still needs to be around, so as not to diverge > > from the Irix code. At least that is my understanding > > based on reading this thread: > > http://oss.sgi.com/archives/linux-xfs/2004-01/msg00187.html > > > Yeah, add me to the list of people who don't like xfs_macros.c. And to the list of people who don't like macro concatenation. > If you can come up with a patch that is not too ridiculously > intrusive then I'd welcome it and push it into IRIX (we certainly > do put code from Linux back into IRIX). Okay, I realise this last statement could be misinterpreted :) What I meant to say was that we do put back XFS code into IRIX that we wrote ourselves (SGI) and initially put into Linux; or XFS code where the author has assigned copyright over to SGI. --Tim From owner-linux-xfs@oss.sgi.com Thu Sep 8 04:00:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Sep 2005 04:00:31 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j88B0JiL005267 for ; Thu, 8 Sep 2005 04:00:24 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.52 #1 (Red Hat Linux)) id 1EDK6D-0001Wx-46; Thu, 08 Sep 2005 11:57:45 +0100 Date: Thu, 8 Sep 2005 11:57:45 +0100 From: Christoph Hellwig To: Craig Rodrigues Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: Warnings when compiling xfs_macros.c Message-ID: <20050908105745.GA5847@infradead.org> References: <20050907174535.GA1850@crodrigues.org> <20050907182059.GA13074@infradead.org> <20050907184542.GA2316@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050907184542.GA2316@crodrigues.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 6085 X-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@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 897 Lines: 18 On Wed, Sep 07, 2005 at 02:45:42PM -0400, Craig Rodrigues wrote: > On Wed, Sep 07, 2005 at 07:21:00PM +0100, Christoph Hellwig wrote: > > xfs_macros.c is a mess. If you want to do a service to everyone > > kill it and the surrounding machinery and just leave the macros, > > without the out of line instances. > > I don't like xfs_macros.c either, but my understanding > was that it still needs to be around, so as not to diverge > from the Irix code. At least that is my understanding > based on reading this thread: > http://oss.sgi.com/archives/linux-xfs/2004-01/msg00187.html That was about changing them to functions, which is a) an intrusive change and b) very debatable. Just leave the macros and remove the whole expand the macros to out of line functions alternatively logic. If one of them is to big we can change it to a function call later more easily after this initial change. From owner-linux-xfs@oss.sgi.com Thu Sep 8 07:11:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Sep 2005 07:12:03 -0700 (PDT) Received: from MAIL01HQ.adic.com (webmail.adic.com [63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j88EBoiL022112 for ; Thu, 8 Sep 2005 07:11:50 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 07:09:15 -0700 Message-ID: <43204609.60203@xfs.org> Date: Thu, 08 Sep 2005 09:09:13 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: Craig Rodrigues , linux-xfs@oss.sgi.com Subject: Re: Warnings when compiling xfs_macros.c References: <20050907174535.GA1850@crodrigues.org> <20050907182059.GA13074@infradead.org> <20050907184542.GA2316@crodrigues.org> <20050908105745.GA5847@infradead.org> In-Reply-To: <20050908105745.GA5847@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2005 14:09:15.0188 (UTC) FILETIME=[E510A740:01C5B47E] X-archive-position: 6086 X-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: 1949 Lines: 46 Christoph Hellwig wrote: > On Wed, Sep 07, 2005 at 02:45:42PM -0400, Craig Rodrigues wrote: > >>On Wed, Sep 07, 2005 at 07:21:00PM +0100, Christoph Hellwig wrote: >> >>>xfs_macros.c is a mess. If you want to do a service to everyone >>>kill it and the surrounding machinery and just leave the macros, >>>without the out of line instances. >> >>I don't like xfs_macros.c either, but my understanding >>was that it still needs to be around, so as not to diverge >>from the Irix code. At least that is my understanding >>based on reading this thread: >>http://oss.sgi.com/archives/linux-xfs/2004-01/msg00187.html > > > That was about changing them to functions, which is a) an intrusive > change and b) very debatable. Just leave the macros and remove the > whole expand the macros to out of line functions alternatively logic. > If one of them is to big we can change it to a function call later > more easily after this initial change. > I can give you some history on this if it helps There were a couple of reasons for the functions vs macros thing (it predates me too, so don't blame me for the code ;-). 1. Being able to compile as functions meant breakpoints could be used in the code. I do not remember the last time that happened. 2. There were some Irix platforms with more limited kernel address spaces, for these, a tradeoff was made between speed (inline code via a macro), and the space it used. Apart from embedded systems which might want to use XFS for some reason, I suspect this is no longer an issue, I do not have a good feel for what the smallest XFS code size vs the biggest might be. If someone converts all the code to plain macros, I suggest you look carefully at the ones which default to being functions, these are probably the main culprits when it comes to code bloat. With today's fast cpus, keeping them as functions might still be worth while from a code size point of view. Steve From owner-linux-xfs@oss.sgi.com Thu Sep 8 07:17:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Sep 2005 07:17:31 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j88EHOiL022787 for ; Thu, 8 Sep 2005 07:17:25 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.52 #1 (Red Hat Linux)) id 1EDNAt-0002Qq-6d; Thu, 08 Sep 2005 15:14:47 +0100 Date: Thu, 8 Sep 2005 15:14:47 +0100 From: Christoph Hellwig To: Steve Lord Cc: Christoph Hellwig , Craig Rodrigues , linux-xfs@oss.sgi.com Subject: Re: Warnings when compiling xfs_macros.c Message-ID: <20050908141447.GA9279@infradead.org> References: <20050907174535.GA1850@crodrigues.org> <20050907182059.GA13074@infradead.org> <20050907184542.GA2316@crodrigues.org> <20050908105745.GA5847@infradead.org> <43204609.60203@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43204609.60203@xfs.org> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6087 X-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@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 1467 Lines: 33 On Thu, Sep 08, 2005 at 09:09:13AM -0500, Steve Lord wrote: > I can give you some history on this if it helps > > There were a couple of reasons for the functions vs macros thing (it > predates me too, so don't blame me for the code ;-). > > 1. Being able to compile as functions meant breakpoints could be > used in the code. I do not remember the last time that happened. Note that recent gdb (with DWARF2 support) allow stepping through macros, and they'll probably allow breakpoints aswell (not sure though) > 2. There were some Irix platforms with more limited kernel address > spaces, for these, a tradeoff was made between speed (inline code > via a macro), and the space it used. Apart from embedded systems > which might want to use XFS for some reason, I suspect this is no > longer an issue, I do not have a good feel for what the smallest > XFS code size vs the biggest might be. > > If someone converts all the code to plain macros, I suggest you look > carefully at the ones which default to being functions, these are > probably the main culprits when it comes to code bloat. With today's > fast cpus, keeping them as functions might still be worth while > from a code size point of view. Keeping those in their current from makes sense indeed. Long-term it would also be nice to lose the horrible upper-case names for these that are now functions, but that's a completely unrelated cleanup. > > Steve ---end quoted text--- From owner-linux-xfs@oss.sgi.com Thu Sep 8 07:37:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Sep 2005 07:37:44 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j88EbdiL024073 for ; Thu, 8 Sep 2005 07:37:39 -0700 Received: from c-66-30-115-133.hsd1.ma.comcast.net ([66.30.115.133]) by comcast.net (rwcrmhc12) with ESMTP id <2005090814350301400ap42oe>; Thu, 8 Sep 2005 14:35:04 +0000 Received: from c-66-30-115-133.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j88EZ0YT048074 for ; Thu, 8 Sep 2005 10:35:00 -0400 (EDT) (envelope-from rodrigc@c-66-30-115-133.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j88EZ0xT048073 for linux-xfs@oss.sgi.com; Thu, 8 Sep 2005 10:35:00 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 8 Sep 2005 10:35:00 -0400 From: Craig Rodrigues To: linux-xfs@oss.sgi.com Subject: Re: Warnings when compiling xfs_macros.c Message-ID: <20050908143500.GA48023@crodrigues.org> References: <20050907174535.GA1850@crodrigues.org> <20050907182059.GA13074@infradead.org> <20050907184542.GA2316@crodrigues.org> <20050908105745.GA5847@infradead.org> <43204609.60203@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43204609.60203@xfs.org> User-Agent: Mutt/1.5.9i X-archive-position: 6088 X-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: 4727 Lines: 110 On Thu, Sep 08, 2005 at 09:09:13AM -0500, Steve Lord wrote: > If someone converts all the code to plain macros, I suggest you look > carefully at the ones which default to being functions, these are > probably the main culprits when it comes to code bloat. With today's > fast cpus, keeping them as functions might still be worth while > from a code size point of view. Well, this type of code cleanup is probably a good thing to do, but is not what I want to tackle yet for my short-term goal of getting xfs_macros.c to compile without warning if -Wmissing-prototypes is added to the gcc flags (as is done during a FreeBSD kernel build). For example, for this warning: /usr/src/sys/gnu/fs/xfs/xfs_macros.c:2242: warning: no previous prototype for 'xlog_grant_sub_space' In xfs_log_priv.h, the prototype is defined as: #if XFS_WANT_FUNCS || (XFS_WANT_SPACE && XFSSO_XLOG_GRANT_SUB_SPACE) void xlog_grant_sub_space(struct log *log, int bytes, int type); #define XLOG_GRANT_SUB_SPACE(log,bytes,type) \ xlog_grant_sub_space(log,bytes,type) #else #define XLOG_GRANT_SUB_SPACE(log,bytes,type) \ { \ if (type == 'w') { \ (log)->l_grant_write_bytes -= (bytes); \ if ((log)->l_grant_write_bytes < 0) { \ (log)->l_grant_write_bytes += (log)->l_logsize; \ (log)->l_grant_write_cycle--; \ } \ } else { \ (log)->l_grant_reserve_bytes -= (bytes); \ if ((log)->l_grant_reserve_bytes < 0) { \ (log)->l_grant_reserve_bytes += (log)->l_logsize;\ (log)->l_grant_reserve_cycle--; \ } \ } \ } #endif And in xfs_macros.c, we have: #if XFS_WANT_FUNCS_C || (XFS_WANT_SPACE_C && XFSSO_XLOG_GRANT_SUB_SPACE) void xlog_grant_sub_space(xlog_t *log, int bytes, int type) { XLOG_GRANT_SUB_SPACE(log, bytes, type); } #endif What I am finding, is that when DEBUG is defined, XFS_WANT_FUNCS_C is defined, but XFS_WANT_FUNCS is not defined due to these lines in xfs_macros.h: #define XFS_WANT_FUNCS_C \ (!defined(_STANDALONE) && defined(DEBUG)) #define XFS_WANT_FUNCS (XFS_WANT_FUNCS_C && !defined(XFS_MACRO_C)) Consequently, when xfs_macros.c is compiled, the function is compiled in the .c file, but the function protototype is not visiable in the .h file, so -Wmissing-prototypes will cause a warning. I "fixed" this by doing this in xfs_log_priv.h: #if XFS_WANT_FUNCS || XFS_WANT_FUNCS_C || (XFS_WANT_SPACE && XFSSO_XLOG_GRANT_SU B_SPACE) void xlog_grant_sub_space(struct log *log, int bytes, int type); #endif #if XFS_WANT_FUNCS || (XFS_WANT_SPACE && XFSSO_XLOG_GRANT_SUB_SPACE) #define XLOG_GRANT_SUB_SPACE(log,bytes,type) \ xlog_grant_sub_space(log,bytes,type) #else #define XLOG_GRANT_SUB_SPACE(log,bytes,type) \ { \ if (type == 'w') { \ (log)->l_grant_write_bytes -= (bytes); \ if ((log)->l_grant_write_bytes < 0) { \ (log)->l_grant_write_bytes += (log)->l_logsize; \ (log)->l_grant_write_cycle--; \ } \ } else { \ (log)->l_grant_reserve_bytes -= (bytes); \ if ((log)->l_grant_reserve_bytes < 0) { \ (log)->l_grant_reserve_bytes += (log)->l_logsize;\ (log)->l_grant_reserve_cycle--; \ } \ } \ } #endif This allowed me to compile xfs_macros.c without errors. Is this an acceptable "fix" to submit back to linux-xfs? It preserves the status quo as much as possible. I had to do this in every header file which has a prototype for a function in xfs_macros.c. -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs@oss.sgi.com Thu Sep 8 07:41:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Sep 2005 07:41:41 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j88EfWiL024956 for ; Thu, 8 Sep 2005 07:41:33 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.52 #1 (Red Hat Linux)) id 1EDNYI-0002Zg-11; Thu, 08 Sep 2005 15:38:58 +0100 Date: Thu, 8 Sep 2005 15:38:57 +0100 From: Christoph Hellwig To: Craig Rodrigues Cc: linux-xfs@oss.sgi.com Subject: Re: Warnings when compiling xfs_macros.c Message-ID: <20050908143857.GA9861@infradead.org> References: <20050907174535.GA1850@crodrigues.org> <20050907182059.GA13074@infradead.org> <20050907184542.GA2316@crodrigues.org> <20050908105745.GA5847@infradead.org> <43204609.60203@xfs.org> <20050908143500.GA48023@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050908143500.GA48023@crodrigues.org> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6089 X-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@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 1014 Lines: 19 On Thu, Sep 08, 2005 at 10:35:00AM -0400, Craig Rodrigues wrote: > On Thu, Sep 08, 2005 at 09:09:13AM -0500, Steve Lord wrote: > > If someone converts all the code to plain macros, I suggest you look > > carefully at the ones which default to being functions, these are > > probably the main culprits when it comes to code bloat. With today's > > fast cpus, keeping them as functions might still be worth while > > from a code size point of view. > > Well, this type of code cleanup is probably a good thing to do, > but is not what I want to tackle yet for my short-term goal > of getting xfs_macros.c to compile without warning if > -Wmissing-prototypes is added to the gcc flags (as is done > during a FreeBSD kernel build). But we're not really looking for half-backed things. -Wmissing-prototypes is a rather stupid warnings extension, and if you care for it you'll have to deal with it in your tree. If you on the other hands do a cleanup that fixes your problems as side-effects that's of course fine. From owner-linux-xfs@oss.sgi.com Thu Sep 8 08:27:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Sep 2005 08:28:00 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j88FRsiL002369 for ; Thu, 8 Sep 2005 08:27:54 -0700 Received: from c-66-30-115-133.hsd1.ma.comcast.net ([66.30.115.133]) by comcast.net (rwcrmhc11) with ESMTP id <2005090815251801300b3rsbe>; Thu, 8 Sep 2005 15:25:19 +0000 Received: from c-66-30-115-133.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j88FPEsg048422; Thu, 8 Sep 2005 11:25:14 -0400 (EDT) (envelope-from rodrigc@c-66-30-115-133.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j88FPD6a048421; Thu, 8 Sep 2005 11:25:13 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 8 Sep 2005 11:25:13 -0400 From: Craig Rodrigues To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com Subject: Re: Warnings when compiling xfs_macros.c Message-ID: <20050908152513.GA48410@crodrigues.org> References: <20050907174535.GA1850@crodrigues.org> <20050907182059.GA13074@infradead.org> <20050907184542.GA2316@crodrigues.org> <20050908105745.GA5847@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050908105745.GA5847@infradead.org> User-Agent: Mutt/1.5.9i X-archive-position: 6090 X-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: 568 Lines: 15 On Thu, Sep 08, 2005 at 11:57:45AM +0100, Christoph Hellwig wrote: > That was about changing them to functions, which is a) an intrusive > change and b) very debatable. Just leave the macros and remove the > whole expand the macros to out of line functions alternatively logic. > If one of them is to big we can change it to a function call later > more easily after this initial change. I don't really follow what you are looking for. Can you take one or two functions in xfs_macros.c and post an example patch? -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs@oss.sgi.com Thu Sep 8 10:07:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Sep 2005 10:08:00 -0700 (PDT) Received: from zero.voxel.net (zero.voxel.net [209.123.232.253]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j88H7tiL009231 for ; Thu, 8 Sep 2005 10:07:55 -0700 Received: from [192.168.1.211] (d66-222-167-155.abhsia.telus.net [66.222.167.155]) by zero.voxel.net (Postfix) with ESMTP id B65D224AE1D for ; Thu, 8 Sep 2005 13:05:19 -0400 (EDT) Subject: xfs and an iscsi hba From: Matthew Kent To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Thu, 08 Sep 2005 11:05:00 -0600 Message-Id: <1126199101.6037.21.camel@fuego> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 6091 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mkent@magoazul.com Precedence: bulk X-list: linux-xfs Content-Length: 407 Lines: 13 Sorry one last question and this may be an ignorant one, but I'm pretty green with iscsi. I know there are difficulties with the current stable iscsi software initiator (4.0.2) for linux and XFS (http://marc.theaimsgroup.com/?l=linux-xfs&m=109334402602841&w=2) but for all intents and purposes should XFS run properly over an HBA? Thanks again, -- Matthew Kent http://magoazul.com From owner-linux-xfs@oss.sgi.com Thu Sep 8 13:21:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Sep 2005 13:21:57 -0700 (PDT) Received: from flyingAngel.upjs.sk (gate.rudna.net [195.122.192.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j88KLjiL025870 for ; Thu, 8 Sep 2005 13:21:46 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 905F81004AA; Thu, 8 Sep 2005 22:18:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 8D709180122 for ; Thu, 8 Sep 2005 22:18:44 +0200 (CEST) Date: Thu, 8 Sep 2005 22:18:44 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: Corruption of in-memory data detected. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6092 X-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 Content-Length: 998 Lines: 18 Helo. I switched from older SGI CVS kernel (2.6.12) to current SGI CVS kernel on two systems (i386 and x86_64). But after some time ( <12 hours) on both systems appeared "Corruption of in-memory data detected." error. I attached /var/log/messages log from i386 system. In both cases I was unable to umount FS nor did clear shutdown. Both systems are workstation with very little load. Sep 7 00:08:26 alien kernel: Filesystem "hda10": xfs_iflush: Bad inode 34351857 magic number 0x2f6c, ptr 0xcc580100 Sep 7 00:08:26 alien kernel: xfs_force_shutdown(hda10,0x8) called from line 3294 of file fs/xfs/xfs_inode.c. Return address = 0xc02350fc Sep 7 00:08:26 alien kernel: Filesystem "hda10": Corruption of in-memory data detected. Shutting down filesystem: hda10 Sep 7 00:08:26 alien kernel: Please umount the filesystem, and rectify the problem(s) Sep 7 00:09:28 alien kernel: xfs_force_shutdown(hda10,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc02350fc jan -- From owner-linux-xfs@oss.sgi.com Fri Sep 9 11:03:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Sep 2005 11:03:30 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j89I3QiL018412 for ; Fri, 9 Sep 2005 11:03:26 -0700 Received: (qmail invoked by alias); 09 Sep 2005 18:00:48 -0000 Received: from G180d.g.pppool.de (EHLO [192.168.10.11]) [80.185.24.13] by mail.gmx.net (mp015) with SMTP; 09 Sep 2005 20:00:48 +0200 X-Authenticated: #2986359 Message-ID: <4321CDDD.8010607@gmx.net> Date: Fri, 09 Sep 2005 20:01:01 +0200 From: evilninja User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Jan Derfinak CC: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-archive-position: 6096 X-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: 1201 Lines: 24 Jan Derfinak schrieb: > Helo. > > I switched from older SGI CVS kernel (2.6.12) to current SGI CVS kernel on > two systems (i386 and x86_64). But after some time ( <12 hours) on both > systems appeared "Corruption of in-memory data detected." error. I attached > /var/log/messages log from i386 system. In both cases I was unable to umount FS > nor did clear shutdown. Both systems are workstation with very little load. > > Sep 7 00:08:26 alien kernel: Filesystem "hda10": xfs_iflush: Bad inode 34351857 magic number 0x2f6c, ptr 0xcc580100 > Sep 7 00:08:26 alien kernel: xfs_force_shutdown(hda10,0x8) called from line 3294 of file fs/xfs/xfs_inode.c. Return address = 0xc02350fc > Sep 7 00:08:26 alien kernel: Filesystem "hda10": Corruption of in-memory data detected. Shutting down filesystem: hda10 ...and when you switch back to 2.6.12 it does not happen again? did you run memtest86+ overnight? i don't know about the xfs cvs repos of the kernel, but perhaps you can narrow it down a little bit (if xfs' cvs tree is in heavy flux, then this could be difficult, especially when the error occurs after 12h...) -- BOFH excuse #210: We didn't pay the Internet bill and it's been cut off. From owner-linux-xfs@oss.sgi.com Fri Sep 9 13:00:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Sep 2005 13:00:47 -0700 (PDT) Received: from flyingAngel.upjs.sk (gate.rudna.net [195.122.192.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j89K0giL000310 for ; Fri, 9 Sep 2005 13:00:42 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 2BA611004A4; Fri, 9 Sep 2005 21:57:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 2740118011D; Fri, 9 Sep 2005 21:57:50 +0200 (CEST) Date: Fri, 9 Sep 2005 21:57:50 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: evilninja Cc: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: <4321CDDD.8010607@gmx.net> Message-ID: References: <4321CDDD.8010607@gmx.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168429056-920372145-1126295870=:8548" X-archive-position: 6098 X-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 Content-Length: 14101 Lines: 248 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --168429056-920372145-1126295870=:8548 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 9 Sep 2005, evilninja wrote: > Jan Derfinak schrieb: > > Helo. > > > > I switched from older SGI CVS kernel (2.6.12) to current SGI CVS kernel on > > two systems (i386 and x86_64). But after some time ( <12 hours) on both > > systems appeared "Corruption of in-memory data detected." error. I attached > > /var/log/messages log from i386 system. In both cases I was unable to umount FS > > nor did clear shutdown. Both systems are workstation with very little load. > > > > Sep 7 00:08:26 alien kernel: Filesystem "hda10": xfs_iflush: Bad inode 34351857 magic number 0x2f6c, ptr 0xcc580100 > > Sep 7 00:08:26 alien kernel: xfs_force_shutdown(hda10,0x8) called from line 3294 of file fs/xfs/xfs_inode.c. Return address = 0xc02350fc > > Sep 7 00:08:26 alien kernel: Filesystem "hda10": Corruption of in-memory data detected. Shutting down filesystem: hda10 > > ...and when you switch back to 2.6.12 it does not happen again? did you 2.6.12 (SGI-XFS CVS-2005-06-14_05:00_UTC with ACLs, no debug enabled) is fine. I returned back to this kernel because I had another incident on my /home partition. 2.6.13 from SGI CVS seems to be dangerous for me. > run memtest86+ overnight? i don't know about the xfs cvs repos of the Do you realy think that memory break on two different machines just after switch to 2.6.13 kernel? But ok I will do it this night. > kernel, but perhaps you can narrow it down a little bit (if xfs' cvs tree > is in heavy flux, then this could be difficult, especially when the error > occurs after 12h...) The kernel is SGI-XFS CVS-2005-09-07_05:00_UTC. Partition /dev/hda10 is mounted with ihashsize=64433,noikeep,logbufs=8. /home with noikeep,logbufs=8. I attached kernel config but it is similiar to 2.6.12 working config. One more notice: I tried to use CONFIG_KEXEC on x86_64 and kernel could not recognize XFS superblock. I didn't try it on i386. jan -- --168429056-920372145-1126295870=:8548 Content-Type: APPLICATION/x-bzip2; name="config.bz2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="config.bz2" QlpoOTFBWSZTWfamP60ACXPfgGAQWOf/+j////C////gYChcAAAHd487sChq d73eNCkQkQpvmVXZ7d1zQABHcyiSlOXShhF27Yrm1VV2bsFDQKBQGxgWyzSd aA7drPva7WNHpk7aSK+773qdvreTNr696T5x4aCAEaABNCBE2pkageUepoDT amhoDTQmgEJiBNTTSp+in6RPUAAYQ0ekMnqBkmiNAmjCJlPU2k8U8o9PSepP KbSAejJNpHqaCTSSQBNJqfqaJPUHknqG1AAAaD1AZAEiUZEMjIEyn6pjIJoA AaANDIACRCEAmQQIapR+SIyMQBkGgAZDr+Z3fH6R/81aorUWHJnyWw1qqFat o2m5lVHKVqpWqgsWNaFXVDBmJmUUoyoH1RHnDEPX462iFaL9TLH59f51yypt 8XGVLFmtUmJjDjAAMunZJgoqs3MPp20bN1Vo1H4p8XGDvb9pnYJ28XYxOqCy iqzERFlQqS2xZmXDLRgFGiT3auhNDmZigoi3ByC5lKoq2iMCiVrMaMuWOSxb iOs0jqyrq3MQuKp5pXE75ZFiwNmsVTTJVy4xGuDRFAFIpp0alltCsta6luSw oz2pJMZpWBUmhKWiOMW5mBCKVrKxUVOGi4ktrqyjiVIqhWAYMkRJjEVrWYwF CIygEUCT2pCYYrFIMW6ploGZXEHHMoM2mY43WUy20uCFVEYqkwtBoplVcyl9 2taETSsomNKYLDEWSXDKYVyJmFWed1pUXhhs61kuUxJIoFSFzDKpcqYOKY4l MzMZmJg0xVURS+qmIprRmSFLUHGlzk4mmrrLVTFEeOY5V1ZXLYi4Xhqmassm MAHMaZjjjCpMwzN2jBwtlLU0scuW1VyRMyuIlSVKyLUwqvOM9/5U3GjVBWux FrZis038jokFIyoPNNdMy9Ka0be9Fk+EruEAACCPqt5ruP8aNn/xRkkhu1l9 3sfyVKG+kkGd/C6PH8YN90A9ELDNTuyy2sOPRAruuK2m87VVfA6IZU8U+fw0 hidbga3RCRfVAcTDG1bZAxoystfpdjM0omz3v95aaMPxB/rI+m7ZZnzGR1Y5 wtmOEGlheYfolTQwSvOGfWs2+jrV/KNkD15cPI8sfxL8/Pn0cdiJfKnJ7/C+ hnJ7UtOu/CaHVRkakhwpk49GuvRW/cspS2i1j70WbfXP0btVXk0bVyBIvCOC xJONmKHTmYqcXtutmjfnjpEnBVp9/2biulelHMlO546f162lS7ccze2tmxDF dyOMGYYO+WcdkaVr42u/gb6Lox4RJJpFh/xv0+lYzr9Yyf9LAyreDoyyVhb4 IzFPrKgwpk5804z4XdM5pW5wg+q7mzZy/j2uv1nFmHeMMa55R6v2LTWOvQSP C7p014hSxnWX4Mut2g7YOTSi9KddiptfXQHgtO2Lq8vNyo4OcxIWwx4vG2Iy 3RmOCN5bojNNZZ7Kpg+I/uzfVz8Jxj4M7hsUSDMxNQrhO9+C0r18V07Nm/Tq d1nbfiBW4TVXYNHCiLsnsPs+tshY9GspR8W9PR4gvRW669+8Niq8y+duWlxT 1B9hpleXi3luRijTfS7JlZvbWKUPLdrOnjd4K2FdaYu6LfkroWOPBYOSDcs3 4QWLrdO9J17WZV5tSeh6Jzd4Za1DAutKI7Kx6QSbEfojo9Xzg2Y5nVN3+NoW FH6UwE7VxWW4l9M5ZYLFrse1DxdXjBmGjq6tqcJ83JlU8q3z6HGE4b4iK+Xv w9v2+v9eqL7utfZ81JJJIFsWuVmy19tUseRYB1c3yCfyfGSSSQH9/h8vwhaD BmLzhmwXqfK6/R8DCXJ885hYcv5+lrpcsNkW1JNu37rWfsjgCACABH40ZWAF 6EN7cDNCO6xozMb7aBLiwrCWHoX7pdmPT/V9cN652EbkjFwb56dvarEc2eCv H4+tGmw3C6oGy/l6dOHBTKZKqOYZMlOj5xBNg5zigHOJm11tdnZE3ZeKGZXV u7dc7+/hssNLNh43KPL90v9LSpE6Zz+2gk5igky2krTpq/7pT/Ct6nFv2b1c jlKKIYE5Vc2bdfNrbHRU5b6GeXgJ7noc7uLmNFVMsPZwpHx6mcCRp9oGX+fr /f7uuRkRbx19ns13ETNxh7refNJHHTpYEGLemiDz6i+N/MMky7QSrB5n6ScY iMYd52t0O2E1PBQtz3ZYNtIcxwHjP+jdWMvGj4W4OmptusvyUZ5FsqPh5a8u jy8aeTvH4XqegjoSdNK78YntQaezv7C7aAQFC8soAAaqFIW5uwO8TGXfyIWD C9rkmeHh99bBKogYOVuwpY7MxDjgGRid996Z3UlvAI7ZkSatHwDP28WwBED8 fJ/i7PXXdKcDCIGzM9BLC6IiBfo2lTjolr3r12FGB6PaQs4kxjRcKLZ4ZIXQ Uqalh5zQdIThb82rrPHOxhgrjAHLiUcUuXE44bbxlqke+nw/thVtcMfcZPAD fSKcIIsc1MAghgYQTBgE1rub7OznPZ0isQxE5qFL0PVaVeE2lJnS2aa+x1kq JE9AjBazTa3STcQxiLBsU7MY3NH196zOL+DzKR6lLenZERIICax2V+7Nuy4o OayIlTfch9/E1n6W7CKHbboC0B7Z/l53qK1vNvWZz1/NaHSPOR/MRRnnNsnj gfPmcR5NsP++XpIc/zp61X0LJuf+qEgE620a87wACcKgQiBCTLG3SNPYIn6e gBVtw74bA6qwcTpceDLoYwbLwchsEIhivUyBA9YBfGSJfDNje+rWW40mAXx9 LD+TI/NvqORv44ALcY/UeEE8XP86rszZlXKxxtPxWW7awTanxZw/Hnw17fbS UUh27PEGh2nGl7LdPdk3HNt+x80Paz02NRAXNdjGf5Kfj6+ohjnA2sFb2XG4 rS1caPHeukuLy6s/PJunrhxbj32Ojychm9llCyWQceFbtDWEmvV8Yic3uaft fNnKnR1kYjiiQVxY3Vt1txjdOfGf533WaPxcmEuEsXfHNy9E4HVHHjC8N5in eLGMXaXsOCTab36z2wwgO/a99jEXwg7fTl4aDVkEbNsHd7NndHuOM80NpiPV PS68Slt8YpLBI3Put7yborjPJ561nrvvekfTbHKnG2no26xnuva3Sl7xjlWy OWkeln63iz4vtayy7rOU2fXQVfr0q3Odzium3z2xhfalT5lkM+DyvL3h9L+u s9uV4gq+LPNp9n410i2fjGHfr5afFvmXVVcVp4dj1lxh7TRM9pBd3Y1+xNaR 65U6X91SnGuJzRjrMw/lmOUwl4MoLhp69ocedInOyxVRRZq7Ky56gPhApJcC QmNYD0x3e7gy1+15fNdGTEzFCSgsICjID/nSEgVUKkJIzatkLSQa62QoQxEL RKo0YxQsEoaqqK3tAWiPbqNfUHnMm2P4uo+ZEiUFYSMMCUZUOQr7Jipk3PN0 jphZ2Zf8Ln4rGiQm0anNAbZ+JAGS+NSNintqOE+SjcVq6q4cpnrXe4xKOhTZ 1LTNRecBlT2Jou/S88biLsFBNW4I1JOQqKR2l8AGNEnm9TWCBjx7+2TKTUep uvJgZadLcCeics0YNhl9745EuOJ1/M6bcFERNcFF2Xo05FHX2kJKrt5RYNim dGHSOGd7IgO+zOE2HBt3VNMEG5Y3t3gRB6utwVsYYLuyodqKGT5GCOvJmYEg RLm1dj5yrYr35vBe2qFdOPSVhYkHmaYGFHr49w9N5mLmf5rPXS8svaF6j1Jx KiyaAC4NcPvqKOz/J3VzB3dj6Zq5Z4iAFkezSUDAE8vO9k59Uk4IHdqCyB3Y Qnkk/L6QPh96aNr7JaMQNI7zyMobVN9cRCRIMaBwYj7JCZQi10pCd97PYYrN gpGL5LzpCzpJ1sOHHb3YVN6VareIutnULSohRFoIDf75Z6C8Ky5TwszJRHR1 NSqw9ZuJA6ilFykW07iKOqym9ww96IjD4BcYQoLbzcDBeVtGxrJUUVRVDmB2 EHrCCTHN+104dtpMAYxXqeHbrDAYpWIgRnkbsQVR4zSRSTo3eCsmAs8r394s o9XHrrd2PZ3P4ikURgKxYLAFRiyCgqgwVUiyKoskVBkQggoxVUBQiyCgxQFi LEWCgiKoKgqigjFEGLBIKiLFVRCIJAYKoiKkUREQFBUQWMQQUSLFkkGKMgqq iIiCwRBUEigpBFBUFgxUioiQUWKAgsRRGEFgqsWSKMYCKjEQVRBjERZEWIig xUS0sUVUVXYoUUJFhFCIIJCDFRBZEZAWAIwQYMVixBikUFUViggwVBigxFSK MYxUkFFJBZEUBUERREBEYkViIxjAVRBEEGFA8mTsnR3MkpbiSZEmGDaFJ0Fp XXmMLo2kEv0yWBxyXBAZQ4k5tpKmI2e3jDtAYgswh7Shc7fFrq7gqhag15vW Kloki2ei41L4KIxvFOjJAQQ0sQm3+JGBQyAmEenZODntN9Z55RPByFzlR4X9 L8m9DA5GK5onUzGxT7s4HFkFCBVpk8NHm6RtKdtLbDWNrNhfSys3kbP/sKBw wL9XwRnuu81mFEd+OH1rRRJqMhmBXaQqmHxUIJAdEM3lXZKSGoqBt/jLzvpp f2YAoaGNJa5rVmt/cNMOooQNRWrTgk1pAscsJFrmtERQ5AISsC3H1ftK2+rm Jo7DBeVEIu8zREfeRHjMIRun+dVXFM2ZOkHdo8uc4Sh/DQbMRw0RiBREO2uK R3YdMLNIvMA17OEtajukHOO/I+I8d3zzjEpLx0pEnm3xtYP2aemCLiLyftsA BAEWj9DBnehXLtt4ZsCmK1gCrvQyytjIuXn4jjhpyo9PnNdZuxdAH38xWm+V YyU3K8RH73b2Y4uJRnZllGWOMZsJL3O7SxcGGUIC3Nw/CAkWqzYqg4YKBxbL 1mizDNSkk4+9fUkRxBoUzQ4FGnsJ3mJ39dRp5e2g1DTjIDPOC0kd0ymUEexX o8Eguu2RgQjS+dueZKCqx+djI1ywSq7sgQpyxPqY2SigrsDTUMhIQUzZdPa9 YI+LrQrNbdZbc2nWFD8arLOGQAjQFBCVvWpm/Dhb3L/itFRrEFgj67cbHhHP c9Wd3NFjzNiNCvc8npnlnZ19L069TJz605+Sc5hzpYCyCKMnJAsvOmQTGwBr V8jlJvLyyBA1OV8OP3OEJiawqBaCRfNwVMZO9nUntNX6xXZqrYJw7+c7rF7t wF9ZaqEmmiRnpcOp98kF59CB2GNTiDHcxJqT8YPq8WutASBIMZ100/q3mkF6 tkr2Wk7fFWSZJPt6o7NAxr8GUAHtpAZM3YLteNHu7u+iC0EaJafexDFuMuLB dLKF29bu1asugZXk01NUCKajExdZ2R4Gcsza4aXNlhBDABs7tAewfpywalp5 vnSjJ+GlTOfXrBWG329ePjo2VRGkQN144rYP14hFdfNwW1y7OB10AUkl1n0E Cn9TcsEC/UjZDhcwleGI38VgxC9TC3yiwSaZJpgFSSQ5uDARgKQAUJBQhIoE 4pAJUBSdGSEhWBAiySQQQJ7GQkhxhzMRFHj3OGXRksugtttDw8qTn3aSPPwm G9iVgV5FaZ/ClK0W0nI1IzOyIfms6jdPDJBXRUAUMJQrcQCDMDzechtsiHF/ E+a7jn7wWwWyv75EfqxGUDjWNQrKg3QA2VOkpQ+RysY2M8FFDuuWerIVw9RA LkUhz7G5zNU5eSrgg6mchesG+6OPWkhtEmfAvnILUlJQuc0IIKZHG/uxwdzR sSvqEJEUZKop+uozMrAFW2bV5sdIXvECUn5NaoB5OIAgCIC7QR4WGggVRk1X tuyJZry1BIITKXpQ46SzwAcNHZ0TKEP23Yata4ucnarHTyYI97QDDEde37xn l4c5R3iG8gtZsbGuQkHYUexGvHtaxuXnOvjeld2tC9RB6YCDc8hDCBwatLsH MbWjA2yz2Hklzrn0SZBIE1RnCVDprIIn0GFrtvmXjNqBdCG3xXvdZRtYFFpC wMtFjFfOG8zF6XbgV3o16fy0QPKrKrPlsuFCibIYHNmjIsqda2syITMr11Mx Koj3gdefgePdoThnC+t6vQyb8a2+Q1uSTeqSBIJsyqfQkBR+zKeoNCYVUdNI ydbU7V1EANw9PqvtzYOXhbsSS1d4ehHCzHWPR9lC0Kxpc99W8D76zwLGys34 ux1AJVS9nSjiLpY3+ucju31bIf4DQa3MFbm+0+lePbqhg6kMcWEUQEBSa80G XplrkPhEFUPuJ8l3AP6f525OdOfqtdDu76dGbQkmVu/L5Ju8UqmhE/IVNFqw q02TvqUWhFSOR1th+02v0ysbzqkpEoiBjEmA+MJMFp3We/vlW8Tnn3sattLh oTYOZkMUmB7GosRvmfOGh4KhytROz7TXfkD6R0vvlklvkVqlmxEI6IQoce3Z kGrBRW1YNuUcWte9qyKx/iPh5F9mZXsjb2xM6G3ih6Qs2Ngm20NjY9PzO1oM knecyfhnZCJITHUcSnQwhPLDLIzppnVArZozWqlCgqrn7uqjoXG+txq4EjX4 2C4dd1C9ZTkzmb6ehxBcpfhgYevc7SHDmvVT5aR2Ns9284rFw7lbHFlYy9R1 3y0KXJRH8doXytTu1KXlhPdh+d51ut8gijtSlTaHlBeuV9NIz5rOXcceW/DI bhyUyrOAtsXkbOO+cIw5sjMpTQZRapi9yFizhUhKGhKzSFFMx435VvWgLa1R bKsrNJNpA2m0CbCUJBIFkshAZzMEa70pb47anQYqJYCKeptakWsk+3aJ1T6F KQPBjUsQ2lAhEQvdzTRDIukWqgkNVE7wwsWbc9dvu+MRA7QfIYpSQdkGuP2H 7c51S+32ZfnTLW3hCc+nCt8FObfoN/CWQfiRnqSzMEI9mTI0vhajeFRURBtb Rwhzad6+dYJHnQIITGoswrdUoiP95Fnp5nXlQnB1MnTDRhKOrdQ85wyaiox3 PvrvrDBIEgjYcHOIRoNK7e8K1Gju8uOMaGj2Wp0ucGt6gMu3BlENC9BR4z8q jfCBGyS66XWpX4rdh0rKyXZGC3g6Pham+tZSX5sWkqNVfg7vNC+sw8X1S858 igrTZevcwLRvqD3ai8QwY5cMTZ9JOE/412mi5brqatNTZ7exU+e3zzR76357 ND9X6dHyZ6lrtKQJPSYh6SgpsZDUU992obIiLrXnmxTRXGuvi1n5ZD1dMIj8 Ofxb7qlwxJviVDKhJWzIY0dzZfZPYPMQXkLfVl4PlE3vLnS6NMtNIPeoY1Yy sYsQwEyhd8T5TyhuItgnBIV1AcZQZVA+PLg0viWURnhCtfOPzSDaRXLlLjOB tLJr8sFo1lpkT887TWdSzubW2ZgJSF9GD2yOwxo6EDBZBPGc/K7VFo5wKNKa vJzk7xBAREkXQqpZhyy+vCAD7V5HX2DXG/CFELWeWtyhFmGyYfEOLeL2Kcsy mIgIfm/L7qY4tfKIbghBpr8SFModTEgPG7oF9RroR781ObOY6kUG+y4wtHGx 7spKS3e9AUJoO9zQKDqpOOFkpQX3gskr3WezNrjQaygIEkZcPBJEIu5SlxfA LufFqzSY9vxBWeJN6wPVPKzuBd0S08Rqg4YG9f1KdFks4OayZIPT6ke2zG6h wM7s2vBBxeHcaLD1IQUxMsopYNl26YaWeXPeG/a4Em2m9AFPL8bAT5UY60YK U0Z2CS7RvvWLzZhxF9sSEz7GVFrzbUtzkHBwBlOPlgIuN2BSKhZhZ3mDOc3C 5OFLIpK6KGSmze21BBIkYLH4huhlaFW7CzIR/K11q8TB08uaLpBWrITbGIQp 7Tua1W1lmFoSWWUGO5b3o9w/+dEyDEYYkjxML0z82/M6RBzR0VZHBy7rAl7l UErx4+JQkUaihIRBvnj1XphoyHjpmZUIsmQy5sB7MIe9jKLhnomdyRGiWQI0 aQGtN6R7Sgyr/Dbr+X9sZZQvthuwEjISpkeBeoJnpoESsqn4Ndxwk0FgUDnW rv07wJswrryFMGQZVXMlJGkSqU+wnYYvVnOh1vLjw3QlaZwyGGWbdi2xy6yj 7a9llCDTfvbRHThuWJDpkPZ0Dsw0Yl0yhnwPEmsIUMzgQ2VXbFBQEXCMSMdz igzIJO5IeXr14HThctymOW+d3Lru2T2kHq4diO0cfVB+FB3YDIrUvfpjppCt HMuMWp8zIGm0hictIcyWvAUXatoDFvFJskisNnfI6AVjGCG6U8zgAq0QKXzO lfML3VUADM2lR4DNatxPoqjyUaOZa6gQbVQTagPVJFJMnLQIIE5mHYV0eG1W U9go76ybWAw1AXOolcYnCRDanqwyi8EO5PZZBEjhe0abVl2y1lWKxDWpr0cM f5z7d8oBZI8j7ZCGxNoNzy+IIvZfWOz2R4gNwK9mJNDLUNJQKqy+72wESZeK MgxMlAFVGOe9zA/znLefOoNpmexKJ84S73NlKF4f1ooV2Bm1kHmSVtULZETr l6JFrBjOjbEQMQwKC6myhpK2xhkYhIInLFQy46IjDx3FJzoNKDNTwv264w04 r8dKjINjrNSyutlEQwLNIeRAKGiqcPLGy+A18l7WFBAcc3qVOA/gbeetdjMy ZUE3OVPve1/QK3I2W8iUaQp4ZZoQoaSUjEH5zSgIhQ1dYrfJb4fjJjDKu4Zz ZJd6gFr6XjICibNMpbPioGyglqSDjBtvjtesr8Oml5ZfQgOOYWrlxvCosWkJ akJa1YGmBKwRWEETtHpnbfDPG70Tp6MbzyJEURCRVtjCSXuV7CdRaSG1vrE6 KmGfQfsKDt56KJev2H5Rm7H3IZkHn6nc9IrrZ7B1YzbXXyqfVz2uAIgw+nzd 9Lmqw9L7HbVh0SURNXRpmkhiS7u96F96Zsngji7v0ZWivYT7joCUHJUMsrm3 oH9bX3tINnq/hQRKZ62t72qEZvi6NwilPgo5sLVuAiFrGQ+GRRchvpEa0Wzh UsXnnPBQKyfYaCvgDj5yYerfKivZGhkqSLr6EKhhzy1s3OvTryXI7V5E5SQY DAJwLS/m1kcx9d/qULP37GbW9jy/dcawauWFb716mJzTvrrfWdcCMhbHscJG g9bWgGkCpcS1NHSQk9rSVUGV7cFcM8NVDhJJadrqSmZO+kJIbKptJadpe10x bk1gApFavaKGQb6VWJZKRBQeAcGS6R9J3CIJel78V2ET7qcxwbR1Ha+ner/Z I6EwETqZm8yAJzMdzAaFqEkNtM0ZraUR4NXR4SDk3zvki3meHCRn50H1tvpN OcHhAjtUJQ2wbA67a3yfU9piLSLVjiPTEWXvk7UdvEfD5ZYviTcz6kwD9/GA JoxqVnBFiAxNPvtCvq5aBxtrzYPLTlvKMa9qdWWUqBdntVIlyx+4BNEmZEcX UTIHg6s6f63j7iDuzb7cL21ytUzMqIiJ74y6fqwecop9PKz98uYsix9ZkBXy aMb7cr3VrZmHbfC+/V1rkJb6p40bM1aA+coOWLBi8gkPbH5iiG8o0Ph54xVR UXeli80gbulJjx57GTyQD5eRr1eTKePGKyDftzhVpu59UWaEA4yk7NKOzh6w Q8qjkE88bVGVgN3c19Z/lWWS2hYGLBXiJ7KowN1XemHwbJPZmtw2Kq81uEGm zJFrtkdNJQZBK3u2d+AJU47rIAJOqHIPBtpuGHBSvTOj1mswecrs5KUD6a+X H649+LI1MkQIzLQcu1Rg17a+bIjwHe1clt5VMh+3MCQu25850hcAksbSAg6K HfkwKbLTtPLGahvTTOKUvFj67PUy66miym/StoiF5pq29dneqzYKDIwb7uwQ V4UIiquzZD58sFLk7V0r898LnzAd7ldxV33pa0BhhxafejZ6de8nvU5bMKx2 Wt80t9VRMFKz8LgxuoMv/bOfl3r43jPGeqjEkQnxsw7VSSbyqHnITcBeJPR9 jfvKduzVTUZk5sA0k7Ukhae3fqi+5HXIoFdzxCBHCvtLAG0NhLUJXM87Sq7d 8tKMdr1G/q2/DOMxl/T2R7kVPNRZgiBBc6lHPIEKKucWmvSE38NRZ42ASeub sLSn6xLZdOpdyl2UHPIAFdpDbSofeQ6dXOyulnx0pLkXs7pVVmVIxWfQcRmv S9pV1851lpoz9caFnu4POdqPBz3mcoF3aQkNrrjIyvvgbII8Ggp0lSQ4ETyo e92Gs2tmQmSbgZVG1WjWaN0VMjiCRgZIRduuJCxzS4YpoQ10SgWgWW/lPDb3 Hz2j5/E5r+m0B+YtZYhO/TBJqdM1jh/YnEPrmYG0rCMZigvs4kMOYOsUqpvH 63VfT9c8DZbw0VsrOg9ug1LqNjMor+P0qxXsXP1/CBuv+DC0iDT7VwlJSMWC /X7rxjeKd1AvMWkJyIkgPBUkFQtSxJJVUPiB9pIxlngmTqkLpoCb3Tk/dz41 kQaI0tqpR8br7SIUnb6Lx/qrxN6S/eVioQ5L+F/LzDAgEoWKymDvNZfaz/hn 1+U7pEq5LbDonXpA9Dkm66WQYA+6mQLMx3UFhnXcJ7nmMCiKgZ33FgLF9Aqh DCOCE4slD/p57rAsMWbQZeVDXNoEae8I36gzEy8BulJJA3zZue/5AymkL6Nj 4BSRYoRV4cp6yQ191OtQ026YN6jTa/b/t+37BjUxNYN84kEmQh53+6+1XG5C yDmBTXurZ1J2ADfVC3XYiIBKe8S5djDzNtjVatdURw63F/ThTLJirMyvxhqa bSLm93huaHnxIABFfMhlnZB3lfkyE7NkENJF2SAbXIfbv2c5wawy9xohIDXQ h249/wJPKOSHkLVV5xmbVUg0B/lX4Va4BA4xH71xg4KHPmQeVtmc/yAISIyQ ID1B/o3N/RB7TwrnFlFdoXy1WVhSNWGiIRiDEtpsh3LkBIWle9sI0sNpEGIg z/qm2kkkgmqQU8SoqKWmUWbcNU5S35c7HWHPd4hvwo5/rmJh+qh0EtAxMjl7 3sDbALXecHEQaWvNC+N7xGq9j0T38qUjjBCliz7WAAIa1hRrW0KMvGcuRza0 k5DIc9SqIbrX1KQCFz31CBClEwJITKofjLJCbVhpWK0KWJsY20+QqM1Mb9vl 26p3hz1klYeL0vVwYfPNt8nmnHh63Y93zKxQYxQlK7M4R/DbI0aj3sJGEgT3 jKYn9/2r7XtEND+Psue90kVE8n0beO2srwmYLnCmjHbYzS1VKrf7+2cXVKr2 gAEHkdWj4XR4oZmT+1pJJIO78OtsLl8e25eq4Rszz9iInUQjNTDQJGqSBgJI WTBCULTQzVVMR1/ng2ukRERAFEiKI6zao8yxzSGwEGvI3xVFxg2tkEv/gjWw Ck8BgHIqiCV2aoBnZJvnE6R6VdHHyZE/txlx3d1l53K/4aFvZtP9xHgDdo4F baFrBsTaY0DYllChSxzGzlhl/bxYKqfjr7WC1XrggeDQi2UUpIKp52XOhd+s pS4exkuroN9lXlEIA2abr+ThbqCubgaNThjxICif8XckU4UJD2pj+tA= --168429056-920372145-1126295870=:8548-- From owner-linux-xfs@oss.sgi.com Fri Sep 9 13:17:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Sep 2005 13:17:07 -0700 (PDT) Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j89KH3iL002337 for ; Fri, 9 Sep 2005 13:17:04 -0700 Received: from exmbx01sj.global.cadence.com (exmbx01sj.Cadence.COM [158.140.128.146]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id NAA00967; Fri, 9 Sep 2005 13:11:53 -0700 (PDT) Received: from rcsr10.cadence.com ([158.140.30.61]) by exmbx01sj.global.cadence.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 13:14:25 -0700 Subject: Re: Corruption of in-memory data detected. From: Chris Croswhite Reply-To: csc@cadence.com To: Jan Derfinak Cc: evilninja , linux-xfs@oss.sgi.com In-Reply-To: References: <4321CDDD.8010607@gmx.net> Content-Type: text/plain Organization: Cadence Design Systems Message-Id: <1126296865.16932.71.camel@rcsr10.cadence.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Fri, 09 Sep 2005 13:14:25 -0700 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2005 20:14:25.0405 (UTC) FILETIME=[12FC32D0:01C5B57B] X-Received: By mailgate.Cadence.COM as NAA00967 at Fri Sep 9 13:11:53 2005 X-archive-position: 6099 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: csc@cadence.com Precedence: bulk X-list: linux-xfs Content-Length: 213 Lines: 8 This also happens on i386 (ran into the problem last evening). > One more notice: I tried to use CONFIG_KEXEC on x86_64 and kernel could not > recognize XFS superblock. I didn't try it on i386. > > jan > > -- From owner-linux-xfs@oss.sgi.com Fri Sep 9 14:56:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Sep 2005 14:56:20 -0700 (PDT) Received: from omx2.sgi.com ([192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j89LuEiL009992 for ; Fri, 9 Sep 2005 14:56: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 j89NswJQ026928 for ; Fri, 9 Sep 2005 16:54:58 -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 j89LrQsL21510389; Fri, 9 Sep 2005 16:53:27 -0500 (CDT) Message-ID: <43220456.80304@sgi.com> Date: Fri, 09 Sep 2005 16:53:26 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jan Derfinak CC: evilninja , linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. References: <4321CDDD.8010607@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6101 X-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: 286 Lines: 9 Jan Derfinak wrote: > Do you realy think that memory break on two different machines just after > switch to 2.6.13 kernel? But ok I will do it this night. You're right, these messages don't often indicate bad memory. Worth ruling out though, I suppose, if you have the time. -Eric From owner-linux-xfs@oss.sgi.com Fri Sep 9 15:11:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Sep 2005 15:11:07 -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 j89MB4iL011951 for ; Fri, 9 Sep 2005 15:11:04 -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 j89M8SxT000556 for ; Fri, 9 Sep 2005 17:08:28 -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 j89M8RsL21516346; Fri, 9 Sep 2005 17:08:27 -0500 (CDT) Message-ID: <432207DB.9000800@sgi.com> Date: Fri, 09 Sep 2005 17:08:27 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: csc@cadence.com CC: Jan Derfinak , evilninja , linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. References: <4321CDDD.8010607@gmx.net> <1126296865.16932.71.camel@rcsr10.cadence.com> In-Reply-To: <1126296865.16932.71.camel@rcsr10.cadence.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6102 X-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: 750 Lines: 25 Chris Croswhite wrote: > This also happens on i386 (ran into the problem last evening). > >>One more notice: I tried to use CONFIG_KEXEC on x86_64 and kernel could not >>recognize XFS superblock. I didn't try it on i386. Hm, how do you hit the problem? [root@lite ~]# zcat /proc/config.gz | grep KEXEC CONFIG_KEXEC=y [root@lite ~]# mount | grep xfs /dev/sda1 on /mnt/sda1 type xfs (rw) [root@lite ~]# dmesg | grep -i xfs SGI XFS with ACLs, security attributes, realtime, large block numbers, dmapi support, no debug enabled SGI XFS Quota Management subsystem XFS mounting filesystem sda1 Ending clean XFS mount for filesystem: sda1 I'm not up to speed on KEXEC. Did you do anything other than build with it on to hit the problem? :) -Eric From owner-linux-xfs@oss.sgi.com Fri Sep 9 15:35:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Sep 2005 15:35:17 -0700 (PDT) Received: from flyingAngel.upjs.sk (gate.rudna.net [195.122.192.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j89MZAiL013890 for ; Fri, 9 Sep 2005 15:35:10 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id AEA291004A0; Sat, 10 Sep 2005 00:32:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 53D31180122; Sat, 10 Sep 2005 00:32:15 +0200 (CEST) Date: Sat, 10 Sep 2005 00:32:12 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Eric Sandeen Cc: csc@cadence.com, evilninja , linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: <432207DB.9000800@sgi.com> Message-ID: References: <4321CDDD.8010607@gmx.net> <1126296865.16932.71.camel@rcsr10.cadence.com> <432207DB.9000800@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6103 X-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 Content-Length: 728 Lines: 25 On Fri, 9 Sep 2005, Eric Sandeen wrote: > Chris Croswhite wrote: > > This also happens on i386 (ran into the problem last evening). > > > > > One more notice: I tried to use CONFIG_KEXEC on x86_64 and kernel could > > > not > > > recognize XFS superblock. I didn't try it on i386. > > Hm, how do you hit the problem? Kernel: XFS_VERSION_STRING "SGI-XFS CVS-2005-09-07_05:00_UTC" I have / on ext3 and all other partitions on xfs. During boot, kernel mounted / and printed "XFS: bad magic number". I extended line 211 in xfs_mount.c to print sbp->sb_magicnum and it was 0. > I'm not up to speed on KEXEC. Did you do anything other than build with it on > to hit the problem? :) No, I could not boot with kexec. jan -- From owner-linux-xfs@oss.sgi.com Sat Sep 10 07:51:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Sep 2005 07:51: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 j8AEpIiL032079 for ; Sat, 10 Sep 2005 07:51:19 -0700 Received: (qmail invoked by alias); 10 Sep 2005 14:48:41 -0000 Received: from G1e23.g.pppool.de (EHLO [192.168.10.11]) [80.185.30.35] by mail.gmx.net (mp002) with SMTP; 10 Sep 2005 16:48:41 +0200 X-Authenticated: #2986359 Message-ID: <4322F25E.7000704@gmx.net> Date: Sat, 10 Sep 2005 16:49:02 +0200 From: evilninja User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. References: <4321CDDD.8010607@gmx.net> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-archive-position: 6107 X-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: 611 Lines: 17 Jan Derfinak schrieb: > 2.6.12 (SGI-XFS CVS-2005-06-14_05:00_UTC with ACLs, no debug enabled) is > fine. I returned back to this kernel because I had another incident on my > /home partition. 2.6.13 from SGI CVS seems to be dangerous for me. a lot things happened from 2005-06-14 to 2.6.13. did you try a stock 2.6.13 from kernel.org? if stock 2.6.13 does not crash, maybe we could look at the diff to the current 2.6.13-CVS from sgi.... out of curiosity: why are you running a SGI-CVS kernel anyway? what am i missing with a stock kernel? -- BOFH excuse #337: the butane lighter causes the pincushioning From owner-linux-xfs@oss.sgi.com Sat Sep 10 12:11:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Sep 2005 12:11:49 -0700 (PDT) Received: from flyingAngel.upjs.sk (gate.rudna.net [195.122.192.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8AJBgiL019488 for ; Sat, 10 Sep 2005 12:11:43 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 9A5ED1004A0; Sat, 10 Sep 2005 21:08:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 977DC180122; Sat, 10 Sep 2005 21:08:48 +0200 (CEST) Date: Sat, 10 Sep 2005 21:08:48 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: evilninja Cc: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: <4322F25E.7000704@gmx.net> Message-ID: References: <4321CDDD.8010607@gmx.net> <4322F25E.7000704@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6108 X-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 Content-Length: 461 Lines: 17 On Sat, 10 Sep 2005, evilninja wrote: Hello. > > out of curiosity: why are you running a SGI-CVS kernel anyway? what am i > missing with a stock kernel? kdb, some important fixes. I just downloaded vanilla 2.6.13 and it seems that for example "TAKE 941429 - Retry linux inode cacech lookup if we found a stale inode" is not there. It is simpler to use SGI CVS tree than patch vanilla tree. And my long-term experience is that SGI tree is stable. jan -- From owner-linux-xfs@oss.sgi.com Sat Sep 10 12:13:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Sep 2005 12:13:24 -0700 (PDT) Received: from flyingAngel.upjs.sk (gate.rudna.net [195.122.192.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8AJDKiL019877 for ; Sat, 10 Sep 2005 12:13:20 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id A98021004A0; Sat, 10 Sep 2005 21:10:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id A6AF6180122; Sat, 10 Sep 2005 21:10:29 +0200 (CEST) Date: Sat, 10 Sep 2005 21:10:29 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Eric Sandeen Cc: evilninja , linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: <43220456.80304@sgi.com> Message-ID: References: <4321CDDD.8010607@gmx.net> <43220456.80304@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6109 X-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 Content-Length: 396 Lines: 15 On Fri, 9 Sep 2005, Eric Sandeen wrote: > Jan Derfinak wrote: > > Do you realy think that memory break on two different machines just after > > switch to 2.6.13 kernel? But ok I will do it this night. > > You're right, these messages don't often indicate bad memory. Worth ruling > out though, I suppose, if you have the time. Memory is OK. Overnight memtest ended without errors. jan -- From owner-linux-xfs@oss.sgi.com Sat Sep 10 15:01:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Sep 2005 15:01:24 -0700 (PDT) Received: from flyingAngel.upjs.sk (gate.rudna.net [195.122.192.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8AM1HiL002111 for ; Sat, 10 Sep 2005 15:01:18 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 40EFD1004A0; Sat, 10 Sep 2005 23:58:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 2A249180122 for ; Sat, 10 Sep 2005 23:58:25 +0200 (CEST) Date: Sat, 10 Sep 2005 23:58:24 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. In-Reply-To: Message-ID: References: <4321CDDD.8010607@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-archive-position: 6110 X-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 Content-Length: 635 Lines: 26 On Fri, 9 Sep 2005, Jan Derfinak wrote: > One more notice: I tried to use CONFIG_KEXEC on x86_64 and kernel could not > recognize XFS superblock. I didn't try it on i386. One more notice again: I played a little with xfs_db trying to find something wrong on my FS and I found that 'frag' command doesn't work: x86_64: xfsprogs-2.6.29 # xfs_db -r -c frag /dev/hda9 Segmentation fault # xfs_db -r -c frag /dev/hdb1 xfs_db: out of memory # xfs_db -r -c frag /dev/hdc5 Segmentation fault i386: xfsprogs-2.6.37 # xfs_db -r -c frag /dev/hda10 Segmentation fault How safe is 'noikeep' options? Can it be cause of instability? jan -- From owner-linux-xfs@oss.sgi.com Sat Sep 10 17:58:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Sep 2005 17:58:15 -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 j8B0w9iL016627 for ; Sat, 10 Sep 2005 17:58:10 -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 j8B0thJJ028371 for ; Sat, 10 Sep 2005 20:55:44 -0400 X-ORBL: [67.124.117.85] Received: from stupidest.org (adsl-67-124-117-85.dsl.snfc21.pacbell.net [67.124.117.85]) by pimout1-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j8B0tUom191124; Sat, 10 Sep 2005 20:55:31 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 11AA3528F22; Sat, 10 Sep 2005 17:55:30 -0700 (PDT) Date: Sat, 10 Sep 2005 17:55:30 -0700 From: Chris Wedgwood To: Jan Derfinak Cc: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data detected. Message-ID: <20050911005529.GA12552@taniwha.stupidest.org> References: <4321CDDD.8010607@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 6111 X-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: 252 Lines: 7 On Sat, Sep 10, 2005 at 11:58:24PM +0200, Jan Derfinak wrote: > How safe is 'noikeep' options? Can it be cause of instability? I've used it on multiple machines with multiple filesystems each for a long time now (basically since it first appeared). From owner-linux-xfs@oss.sgi.com Mon Sep 12 09:46:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 09:46:28 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8CGkLiL023836 for ; Mon, 12 Sep 2005 09:46:22 -0700 Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j8CGheZx014528 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 12 Sep 2005 18:43:40 +0200 (CEST) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EErP9-0002da-Vo for linux-xfs@oss.sgi.com; Mon, 12 Sep 2005 18:43:40 +0200 Date: Mon, 12 Sep 2005 18:43:39 +0200 From: Nicolas Kowalski To: linux-xfs@oss.sgi.com Subject: Speed up xfsdump ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Mon, 12 Sep 2005 18:43:40 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 6117 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 1510 Lines: 67 Hello, I am testing the backup of a new SCSI-attached RAID5 SATA array on a SDLT320 tape drive, using xfsdump 2.2.27. I noticed that xfsdump is "much" slower than tar of cpio, and I would like to know if I can do anything to speed up things. NB: I used kernels 2.4.31 and 2.6.12.3, and did not see a noticable difference using the one or the other. I tried the ihashsize mount option (when using 2.6.x kernel), and approximatively got the same results. 1) First, the testbed The storage is a ~1.5TB array, that I partially filled with the some contents of our user homes. The 'df' and 'df -i' commands shows the following: # df /dev/sda1 /dev/sda1 1463454592 29337040 1434117552 3% /raid # df -i /dev/sda1 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 1444198400 526803 1443671597 1% /raid The filesystem is completely inactive during the tests. The SDLT320 drive is 25MB/s capable (tested by pulling a big 500MB tar file with dd on the tape). 2) The tests 2.a) xfsdump command used: xfsdump -J - /raid | dd obs=64k of=/dev/nst0 dd shows: 5985202 bytes/sec I also tested with a 1M blocksize, and did not get a much better number (6052963). 2.b) tar command used: tar cf - /raid | dd obs=64k of=/dev/nst0 dd shows: 16518724 bytes/sec 2.c) cpio command used: find /raid -xdev -print0 | cpio -0 -H newc -o \ | dd obs=64k of=/dev/nst0 dd shows: 15911069 bytes/sec 3) Any tips to speed up xfsdump ? Thanks, -- Nicolas From owner-linux-xfs@oss.sgi.com Mon Sep 12 10:00:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 10:00:07 -0700 (PDT) Received: from aaa.dreamhost.com (aaa.dreamhost.com [64.111.107.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8CH02iL025575 for ; Mon, 12 Sep 2005 10:00:02 -0700 Received: from [10.2.255.6] (unknown [208.51.196.2]) by aaa.dreamhost.com (Postfix) with ESMTP id 1064914F73 for ; Mon, 12 Sep 2005 09:57:25 -0700 (PDT) Message-ID: <4325B3C1.20506@delusion.com> Date: Mon, 12 Sep 2005 09:58:41 -0700 From: Deanan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: fresh xfs vs used xfs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6118 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: delusion@delusion.com Precedence: bulk X-list: linux-xfs Content-Length: 365 Lines: 15 Hi, I'm seeing some strange things happen that i can't really explain. I'm using the XFS with SLES 9 and 2.6.5-7.97 on x86_64. I'm filling up 6TB in one shot with 16mb files. When I delete the directory that contains all the files and then go back the to refill the directory again, I get performance problems. Is this a problem with the logs? Thanks, Deanan From owner-linux-xfs@oss.sgi.com Mon Sep 12 10:02:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 10:02:39 -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 j8CH2XiL026219 for ; Mon, 12 Sep 2005 10:02:33 -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 j8CFujdp004445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Sep 2005 10:56:47 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.4/8.13.4/Submit) with ESMTP id j8CFujjR004442; Mon, 12 Sep 2005 10:56:45 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Mon, 12 Sep 2005 10:56:45 -0500 (EST) From: Lonni J Friedman To: Nicolas Kowalski cc: linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? 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]); Mon, 12 Sep 2005 10:56:47 -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: 6119 X-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: 275 Lines: 10 On Mon, 12 Sep 2005, Nicolas Kowalski wrote: > 3) Any tips to speed up xfsdump ? more RAM? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Mon Sep 12 10:06:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 10:06:52 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8CH6miL026762 for ; Mon, 12 Sep 2005 10:06:48 -0700 Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j8CH45V2019422 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 12 Sep 2005 19:04:05 +0200 (CEST) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EEriv-0003PB-Bn for linux-xfs@oss.sgi.com; Mon, 12 Sep 2005 19:04:05 +0200 Date: Mon, 12 Sep 2005 19:04:05 +0200 From: Nicolas Kowalski To: linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Mon, 12 Sep 2005 19:04:05 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 6120 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 304 Lines: 13 On Mon, 12 Sep 2005, Lonni J Friedman wrote: > On Mon, 12 Sep 2005, Nicolas Kowalski wrote: > > 3) Any tips to speed up xfsdump ? > > more RAM? I should have mentionned it: the server has 512MB of RAM, and during the tests, no relevant swap was used, so I guess it's not the problem... -- Nicolas From owner-linux-xfs@oss.sgi.com Mon Sep 12 10:29:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 10:29:55 -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 j8CHThiL028398 for ; Mon, 12 Sep 2005 10:29:46 -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 j8CHR6xT024640 for ; Mon, 12 Sep 2005 12:27:06 -0500 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j8CHR5DN15556385; Mon, 12 Sep 2005 12:27:05 -0500 (CDT) Message-ID: <4325BA69.4070709@sgi.com> Date: Mon, 12 Sep 2005 12:27:05 -0500 From: Bill Kendall User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Kowalski CC: linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6121 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1781 Lines: 72 On 09/12/05 11:43, Nicolas Kowalski wrote: > Hello, > > I am testing the backup of a new SCSI-attached RAID5 SATA array on a > SDLT320 tape drive, using xfsdump 2.2.27. > > I noticed that xfsdump is "much" slower than tar of cpio, and I would > like to know if I can do anything to speed up things. > > NB: I used kernels 2.4.31 and 2.6.12.3, and did not see a noticable > difference using the one or the other. I tried the ihashsize mount > option (when using 2.6.x kernel), and approximatively got the same > results. > > > 1) First, the testbed > > The storage is a ~1.5TB array, that I partially filled with the some > contents of our user homes. The 'df' and 'df -i' commands shows the > following: > > # df /dev/sda1 > /dev/sda1 1463454592 29337040 1434117552 3% /raid > > # df -i /dev/sda1 > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/sda1 1444198400 526803 1443671597 1% /raid > > The filesystem is completely inactive during the tests. > > The SDLT320 drive is 25MB/s capable (tested by pulling a big 500MB tar > file with dd on the tape). > > > 2) The tests > > 2.a) xfsdump > > command used: xfsdump -J - /raid | dd obs=64k of=/dev/nst0 > > dd shows: 5985202 bytes/sec > > I also tested with a 1M blocksize, and did not get a much better number > (6052963). > > > 2.b) tar > > command used: tar cf - /raid | dd obs=64k of=/dev/nst0 > > dd shows: 16518724 bytes/sec > > > 2.c) cpio > > command used: find /raid -xdev -print0 | cpio -0 -H newc -o \ > | dd obs=64k of=/dev/nst0 > > dd shows: 15911069 bytes/sec > > > 3) Any tips to speed up xfsdump ? > > > Thanks, Try the dump this way and see if performance improves: xfsdump -J -f /dev/nst0 -b 1048576 -d 8192 /raid Bill From owner-linux-xfs@oss.sgi.com Mon Sep 12 10:42:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 10:42:45 -0700 (PDT) Received: from web34114.mail.mud.yahoo.com (web34114.mail.mud.yahoo.com [66.163.178.112]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j8CHgYiL029310 for ; Mon, 12 Sep 2005 10:42:35 -0700 Received: (qmail 2328 invoked by uid 60001); 12 Sep 2005 17:39:56 -0000 Message-ID: <20050912173956.2326.qmail@web34114.mail.mud.yahoo.com> Received: from [66.192.136.58] by web34114.mail.mud.yahoo.com via HTTP; Mon, 12 Sep 2005 10:39:56 PDT X-RocketYMMF: thebs413 Date: Mon, 12 Sep 2005 10:39:56 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: Speed up xfsdump ? To: Nicolas Kowalski , linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 6122 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Content-Length: 1285 Lines: 44 Nicolas Kowalski wrote: > 2) The tests > 2.a) xfsdump > command used: xfsdump -J - /raid | dd obs=64k of=/dev/nst0 > dd shows: 5985202 bytes/sec > I also tested with a 1M blocksize, and did not get a much > better number (6052963). Hmmm, are you trying to use "dd" as a buffering program? I think there are far better programs to do such. Heck, what do you get if you just use "-f /dev/nst0" directory by xfsdump? I don't think you need an external buffering program _unless_ you are streaming to a remote tape device. > 2.b) tar > command used: tar cf - /raid | dd obs=64k of=/dev/nst0 > dd shows: 16518724 bytes/sec Remember that tar's default blocking is 10KiB. So consider using a multiple of 10KiB instead of 64KiB. > 2.c) cpio > command used: find /raid -xdev -print0 | cpio -0 -H newc -o > \| dd obs=64k of=/dev/nst0 > dd shows: 15911069 bytes/sec And cpio's default blocking is 5KiB. > 3) Any tips to speed up xfsdump ? Again, what does this give you? xfsdump -J -f /dev/nst0 /raid Unless your tape device is remote, you shouldn't need to buffer with an external program. -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) From owner-linux-xfs@oss.sgi.com Mon Sep 12 10:43:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 10:44:48 -0700 (PDT) Received: from socceraccess.com ([219.129.102.240]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j8CHhKiL029508; Mon, 12 Sep 2005 10:43:22 -0700 Message-ID: Date: Mon, 12 Sep 2005 15:33:22 -0900 From: "reuben tissot" User-Agent: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 To: "Cleo Dent" Cc: , , , , , , Subject: Fw: SS Tudors and Worldtime PatekPhilippe, all you can choose. Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 6123 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tilton@socceraccess.com Precedence: bulk X-list: linux-xfs Content-Length: 836 Lines: 20 International tracking shipment! Select one of our tiptop selections on Tag HHeuer. Even brand symbol & serial number is very classic. This best collection is at the fraction of fee. You've already paid for the bluestone glass dial. Show off with studded diamonds on pure golden watcch. http://uk.geocities.com/Arron_Suing/?su=yykexys "one for harry . . ." said slughorn, dividing a second bottle between two mugs, ". . . and one for me. well" - he raised his mug high - "to aragog." wordlessly, harry pulled the fake locket from his pocket, opened it, and passed it to ron. the full story could wait. ... it did not matter tonight. . nothing mattered except the end, the end of their pointless adventure, the end of dumbledore's life. . . . "i'm stationed in hogsmeade now, to give the school extra protection," said tonks. From owner-linux-xfs@oss.sgi.com Mon Sep 12 10:45:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 10:45:10 -0700 (PDT) Received: from web34104.mail.mud.yahoo.com (web34104.mail.mud.yahoo.com [66.163.178.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j8CHj1iL030047 for ; Mon, 12 Sep 2005 10:45:01 -0700 Received: (qmail 51327 invoked by uid 60001); 12 Sep 2005 17:42:23 -0000 Message-ID: <20050912174223.51325.qmail@web34104.mail.mud.yahoo.com> Received: from [66.192.136.58] by web34104.mail.mud.yahoo.com via HTTP; Mon, 12 Sep 2005 10:42:23 PDT X-RocketYMMF: thebs413 Date: Mon, 12 Sep 2005 10:42:23 -0700 (PDT) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: Speed up xfsdump ? To: Bill Kendall , Nicolas Kowalski Cc: linux-xfs@oss.sgi.com In-Reply-To: <4325BA69.4070709@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 6124 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Content-Length: 650 Lines: 21 Bill Kendall wrote: > Try the dump this way and see if performance improves: > xfsdump -J -f /dev/nst0 -b 1048576 -d 8192 /raid Agreed. Play with the blocking/buffering options of xfsdump itself. Again (I know, I'm repeating myself), there is no reason to use an external buffering program to a local tape device. Only if you are streaming to an external device do you need to pipe through a buffering program on the other size (where the tape device is local). -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) From owner-linux-xfs@oss.sgi.com Mon Sep 12 10:49:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 10:50: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 j8CHnpiL030898 for ; Mon, 12 Sep 2005 10:49:52 -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 j8CHlDxT027985 for ; Mon, 12 Sep 2005 12:47:13 -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 j8CHlCsL21581641; Mon, 12 Sep 2005 12:47:13 -0500 (CDT) Message-ID: <4325BF20.7080304@sgi.com> Date: Mon, 12 Sep 2005 12: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: Deanan CC: linux-xfs@oss.sgi.com Subject: Re: fresh xfs vs used xfs References: <4325B3C1.20506@delusion.com> In-Reply-To: <4325B3C1.20506@delusion.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6125 X-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: 1218 Lines: 34 Deanan wrote: > Hi, > > I'm seeing some strange things happen that i can't really explain. > I'm using the XFS with SLES 9 and 2.6.5-7.97 on x86_64. > > I'm filling up 6TB in one shot with 16mb files. When I delete the > directory that contains all the files and then go back the to refill > the directory again, I get performance problems. This may have to do with inode clusters left on-disk after you delete the associated files. Although xfs creates inode clusters dynamically, by default it does not delete them dynamically. You might try mounting with the noikeep option to delete the inode clusters - however, a comment in the code still says that this may have some issues, so tread carefully. Another thought is that since you are on a box which can handle 64-bit inodes, turn on the inode64 mount option; this will allow inode numbers to grow to 64 bits, and cause inodes & data to be allocated more uniformly across the filesystem. Note, however, that an xfs filesystem with 64-bit inodes will have trouble on a 32-bit kernel (if you boot 32-bit kernels on the box, or if you were to move the storage to a 32-bit box). -Eric > Is this a problem with the logs? > > Thanks, > > Deanan > From owner-linux-xfs@oss.sgi.com Mon Sep 12 15:51:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 15:51:35 -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 j8CMp9iL019974 for ; Mon, 12 Sep 2005 15:51:22 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA25697; Tue, 13 Sep 2005 08:48:19 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j8CMm724705219; Tue, 13 Sep 2005 08:48:07 +1000 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j8CMm5TV704580; Tue, 13 Sep 2005 08:48:05 +1000 (EST) Date: Tue, 13 Sep 2005 08:48:05 +1000 From: David Chinner To: Deanan Cc: linux-xfs@oss.sgi.com Subject: Re: fresh xfs vs used xfs Message-ID: <20050912224805.GA685356@melbourne.sgi.com> References: <4325B3C1.20506@delusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4325B3C1.20506@delusion.com> User-Agent: Mutt/1.4.1i X-archive-position: 6126 X-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: 728 Lines: 25 On Mon, Sep 12, 2005 at 09:58:41AM -0700, Deanan wrote: > Hi, > > I'm seeing some strange things happen that i can't really explain. > I'm using the XFS with SLES 9 and 2.6.5-7.97 on x86_64. > > I'm filling up 6TB in one shot with 16mb files. When I delete the > directory that contains all the files and then go back the to refill > the directory again, I get performance problems. Can you be more precise about what your performance problem is and how you are reproducing it? BTW, if you are using the cfq elevator, what happens if you "echo 128 > /sys/block/sdXX/queue/nr_requests" for each block device that makes up your filesystem? Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Mon Sep 12 17:21:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 17:21:52 -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 j8D0LjiL028619 for ; Mon, 12 Sep 2005 17:21:46 -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 KAA27553 for ; Tue, 13 Sep 2005 10:19:06 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id E5C7749BFB19; Tue, 13 Sep 2005 10:19:05 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - blktrace kernel update Message-Id: <20050913001905.E5C7749BFB19@chook.melbourne.sgi.com> Date: Tue, 13 Sep 2005 10:19:05 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6127 X-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: 1839 Lines: 41 Relayfs rmdir ENOTEMPTY fix, ACKed by Tom Zanussi. Date: Tue Sep 6 09:02:26 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: zanussi@us.ibm.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:23730a split-patches/relayfs-rmdir-fix - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/relayfs-rmdir-fix split-patches/series - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h fs/relayfs/inode.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/relayfs/inode.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Merge up to rev 0x5 of block trace patches, to match current tools. Date: Tue Sep 13 10:18:31 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: axboe@suse.de 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:23797a split-patches/blktrace-rev5 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/blktrace-rev5 split-patches/series - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h drivers/block/blktrace.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/blktrace.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/blktrace.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/blktrace.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/blktrace-rev3 - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/blktrace-rev3.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs@oss.sgi.com Mon Sep 12 19:41:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Sep 2005 19:41:48 -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 j8D2fciL003430 for ; Mon, 12 Sep 2005 19:41:39 -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 j8D2ctfE5114123; Tue, 13 Sep 2005 12:38:56 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j8D2crl44701372; Tue, 13 Sep 2005 12:38:53 +1000 (AEST) Date: Tue, 13 Sep 2005 12:38:53 +1000 From: Tim Shimmin To: "Bryan J. Smith" Cc: Bill Kendall , Nicolas Kowalski , linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? Message-ID: <20050913123852.Z4874818@boing.melbourne.sgi.com> References: <4325BA69.4070709@sgi.com> <20050912174223.51325.qmail@web34104.mail.mud.yahoo.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: <20050912174223.51325.qmail@web34104.mail.mud.yahoo.com>; from b.j.smith@ieee.org on Mon, Sep 12, 2005 at 10:42:23AM -0700 X-archive-position: 6128 X-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: 1957 Lines: 41 On Mon, Sep 12, 2005 at 10:42:23AM -0700, Bryan J. Smith wrote: > Bill Kendall wrote: > > Try the dump this way and see if performance improves: > > xfsdump -J -f /dev/nst0 -b 1048576 -d 8192 /raid > > Agreed. Play with the blocking/buffering options of xfsdump > itself. > My 2 cents FWIW. The -d 8192 means that the media files are around 8192Mb i.e. they are big and should be less of them. Each media file is a contained unit and repeats a header with directories and inode map, and that is why having fewer media files will mean less data to dump (and less redundancy). One can also use the -S option to use just one media file. If one actually dumps to a file or stdout then it always uses one media file as I guess it thinks the redundancy for tape is not needed. Unfortunately AFAIK, the threaded part of xfsdump on Linux is not there (it is on IRIX with sprocs). What this means is that one can not specify multiple tape devices, and also that a helper thread which operates on a ring buffer (defaults to 3 bufs - number changed by -Y and pinned by -P) is not used to separately talk to the device. So I was going to mention its benefit and then realised it wasn't on Linux. Sorry. Another note is that Kai Makisara (st driver guy) once mentioned (6/Apr/2004) that larger buffer sizes are not necessarily a good thing: "The other problem is that you probably would like to use direct transfers between the xfsdump/xfsrestore buffer and the drive instead of using the "bounce" buffer in the driver. This is not possible unless the tape requests are small enough for the SCSI adapter. In your case the limit is 96 pages. You can try to increase this limit but it is not a general solution. I would recommend xfsdump/xfsrestore to use smaller requests if possible. 64 pages of 4 kB would make 256 kB. Using this request size should not limit throughput even with the fastest tape drives." --Tim From owner-linux-xfs@oss.sgi.com Tue Sep 13 01:47:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Sep 2005 01:47:51 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8D8lfiL029833 for ; Tue, 13 Sep 2005 01:47:46 -0700 Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j8D8is34004726 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 13 Sep 2005 10:44:54 +0200 (CEST) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EF6PO-00080I-OG for linux-xfs@oss.sgi.com; Tue, 13 Sep 2005 10:44:54 +0200 Date: Tue, 13 Sep 2005 10:44:54 +0200 From: Nicolas Kowalski To: linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? In-Reply-To: <4325BA69.4070709@sgi.com> Message-ID: References: <4325BA69.4070709@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Tue, 13 Sep 2005 10:44:54 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 6129 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 622 Lines: 27 On Mon, 12 Sep 2005, Bill Kendall wrote: > On 09/12/05 11:43, Nicolas Kowalski wrote: > > > > 2) The tests > > > > 2.a) xfsdump > > > > command used: xfsdump -J - /raid | dd obs=64k of=/dev/nst0 > > > > dd shows: 5985202 bytes/sec > > > Try the dump this way and see if performance improves: > > xfsdump -J -f /dev/nst0 -b 1048576 -d 8192 /raid Using this exact command line (plus '-p 300' to see the status) does not improve the speed. At the end, xfsdump shows me: xfsdump: dump size (non-dir files) : 28364433152 bytes xfsdump: dump complete: 4746 seconds elapsed This gives 5976492 bytes/sec. -- Nicolas From owner-linux-xfs@oss.sgi.com Tue Sep 13 04:09:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Sep 2005 04:09:57 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8DB9qiL012501 for ; Tue, 13 Sep 2005 04:09:53 -0700 Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j8DB76hU011252 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 13 Sep 2005 13:07:06 +0200 (CEST) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EF8d0-0002l0-2o for linux-xfs@oss.sgi.com; Tue, 13 Sep 2005 13:07:06 +0200 Date: Tue, 13 Sep 2005 13:07:06 +0200 From: Nicolas Kowalski To: linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? In-Reply-To: <20050913123852.Z4874818@boing.melbourne.sgi.com> Message-ID: References: <4325BA69.4070709@sgi.com> <20050912174223.51325.qmail@web34104.mail.mud.yahoo.com> <20050913123852.Z4874818@boing.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Tue, 13 Sep 2005 13:07:06 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 6130 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 749 Lines: 31 On Tue, 13 Sep 2005, Tim Shimmin wrote: > On Mon, Sep 12, 2005 at 10:42:23AM -0700, Bryan J. Smith wrote: > > Bill Kendall wrote: > > > Try the dump this way and see if performance improves: > > > xfsdump -J -f /dev/nst0 -b 1048576 -d 8192 /raid > > > > Agreed. Play with the blocking/buffering options of xfsdump > > itself. > > My 2 cents FWIW. [...] Using your tips, I also tested with this: xfsdump -J -f /dev/nst0 -S -p 300 -b 262144 /raid At the end, I have: xfsdump: dump size (non-dir files) : 28364432208 bytes xfsdump: dump complete: 4643 seconds elapsed This gives : 6109074 bytes/sec So the results are almost identical whatever blocksize or number of dump files are specified to xfsdump... -- Nicolas From owner-linux-xfs@oss.sgi.com Tue Sep 13 06:28:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Sep 2005 06:29:07 -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 j8DDSniL024187 for ; Tue, 13 Sep 2005 06:28:49 -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 j8DDQAxT018733 for ; Tue, 13 Sep 2005 08:26:10 -0500 Received: from [192.168.0.101] (cf-vpn-sw-corp-64-80.corp.sgi.com [134.15.64.80]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j8DDQ9DN15593367; Tue, 13 Sep 2005 08:26:09 -0500 (CDT) Message-ID: <4326D34C.9010404@sgi.com> Date: Tue, 13 Sep 2005 08:25:32 -0500 From: Bill Kendall User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Kowalski CC: linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? References: <4325BA69.4070709@sgi.com> <20050912174223.51325.qmail@web34104.mail.mud.yahoo.com> <20050913123852.Z4874818@boing.melbourne.sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6131 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1074 Lines: 41 Nicolas Kowalski wrote: > On Tue, 13 Sep 2005, Tim Shimmin wrote: > > >>On Mon, Sep 12, 2005 at 10:42:23AM -0700, Bryan J. Smith wrote: >> >>>Bill Kendall wrote: >>> >>>>Try the dump this way and see if performance improves: >>>>xfsdump -J -f /dev/nst0 -b 1048576 -d 8192 /raid >>> >>>Agreed. Play with the blocking/buffering options of xfsdump >>>itself. >> >>My 2 cents FWIW. > > > [...] > > Using your tips, I also tested with this: > > xfsdump -J -f /dev/nst0 -S -p 300 -b 262144 /raid > > At the end, I have: > > xfsdump: dump size (non-dir files) : 28364432208 bytes > xfsdump: dump complete: 4643 seconds elapsed > > This gives : 6109074 bytes/sec > > So the results are almost identical whatever blocksize or number of > dump files are specified to xfsdump... > It might be helpful to determine if xfsdump is slow because of the way it's interacting with the tape drive, or if it's just slow in general on your filesystem. Try using "-f /dev/null" and see how it performs. You don't need to specify -d/-S or -b in this case. Bill From owner-linux-xfs@oss.sgi.com Tue Sep 13 08:45:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Sep 2005 08:45:27 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8DFjIiL002769 for ; Tue, 13 Sep 2005 08:45:18 -0700 Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j8DFgUpn022185 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 13 Sep 2005 17:42:31 +0200 (CEST) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EFCvW-0000wN-S4 for linux-xfs@oss.sgi.com; Tue, 13 Sep 2005 17:42:30 +0200 Date: Tue, 13 Sep 2005 17:42:30 +0200 From: Nicolas Kowalski To: linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? In-Reply-To: <4326D34C.9010404@sgi.com> Message-ID: References: <4325BA69.4070709@sgi.com> <20050912174223.51325.qmail@web34104.mail.mud.yahoo.com> <20050913123852.Z4874818@boing.melbourne.sgi.com> <4326D34C.9010404@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Tue, 13 Sep 2005 17:42:31 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 6132 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 1246 Lines: 42 On Tue, 13 Sep 2005, Bill Kendall wrote: > It might be helpful to determine if xfsdump is slow because of the way > it's interacting with the tape drive, or if it's just slow in general > on your filesystem. Try using "-f /dev/null" and see how it performs. > You don't need to specify -d/-S or -b in this case. I guess it's not related to the interaction between xfsdump and the tape drive: in my initial tests, I used dd to write on the tape. Here is the result you asked for: # xfsdump -J -p 300 -f /dev/null /raid It gives me: xfsdump: dump size (non-dir files) : 29369583312 bytes xfsdump: dump complete: 4557 seconds elapsed So an average of 64444938 bytes/sec. Not much better than when writing to tape... PS: as an additional test, on the same array/server, I created an ext3 filesystem, pushed the same files than for the XFS/xfsdump tests, and ran a dump session: # dump -0 -a -f /dev/nst0 /raid I finally got this: DUMP: 30325260 blocks (29614.51MB) on 1 volume(s) DUMP: finished in 1792 seconds, throughput 16922 kBytes/sec DUMP: Date of this level 0 dump: Tue Sep 13 14:34:57 2005 DUMP: Date this dump completed: Tue Sep 13 15:23:06 2005 DUMP: Average transfer rate: 16903 kB/s -- Nicolas From owner-linux-xfs@oss.sgi.com Tue Sep 13 09:38:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Sep 2005 09:38:46 -0700 (PDT) Received: from twinlark.arctic.org (twinlark.arctic.org [207.7.145.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8DGcaiL005828 for ; Tue, 13 Sep 2005 09:38:36 -0700 Received: (qmail 21533 invoked from network); 13 Sep 2005 16:35:57 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by 127.0.0.1 with ESMTPS (AES256-SHA); 13 Sep 2005 16:35:57 -0000 Date: Tue, 13 Sep 2005 09:35:57 -0700 (PDT) From: dean gaudet To: Nicolas Kowalski cc: linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? In-Reply-To: Message-ID: References: <4325BA69.4070709@sgi.com> <20050912174223.51325.qmail@web34104.mail.mud.yahoo.com> <20050913123852.Z4874818@boing.melbourne.sgi.com> <4326D34C.9010404@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6133 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dean-list-linux-xfs@arctic.org Precedence: bulk X-list: linux-xfs Content-Length: 573 Lines: 14 On Tue, 13 Sep 2005, Nicolas Kowalski wrote: > PS: as an additional test, on the same array/server, I created an ext3 > filesystem, pushed the same files than for the XFS/xfsdump tests, > and ran a dump session: if the xfs filesystem was created "live" and had files added/deleted along the way it's likely to be more fragmented than a freshly created ext3 filesystem which had a bunch of files copied to it right after being created... one more test you might want to do is a fresh xfs fs which you populate the same way you populated the ext3 fs. -dean From owner-linux-xfs@oss.sgi.com Tue Sep 13 09:50:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Sep 2005 09:50:55 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8DGokiL006759 for ; Tue, 13 Sep 2005 09:50:47 -0700 Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j8DGm3Rv008570 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 13 Sep 2005 18:48:03 +0200 (CEST) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EFDwx-0002YK-0s for linux-xfs@oss.sgi.com; Tue, 13 Sep 2005 18:48:03 +0200 Date: Tue, 13 Sep 2005 18:48:02 +0200 From: Nicolas Kowalski To: linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? In-Reply-To: Message-ID: References: <4325BA69.4070709@sgi.com> <20050912174223.51325.qmail@web34104.mail.mud.yahoo.com> <20050913123852.Z4874818@boing.melbourne.sgi.com> <4326D34C.9010404@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Tue, 13 Sep 2005 18:48:03 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 6134 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 792 Lines: 21 On Tue, 13 Sep 2005, dean gaudet wrote: > On Tue, 13 Sep 2005, Nicolas Kowalski wrote: > > > PS: as an additional test, on the same array/server, I created an ext3 > > filesystem, pushed the same files than for the XFS/xfsdump > > tests, and ran a dump session: > > if the xfs filesystem was created "live" and had files added/deleted > along the way it's likely to be more fragmented than a freshly created > ext3 filesystem which had a bunch of files copied to it right after > being created... one more test you might want to do is a fresh xfs fs > which you populate the same way you populated the ext3 fs. That's what I do: all my tests with xfsdump are done on a newly created/populated filesystem, so that fragmentation does not "corrupt" my results. -- Nicolas From owner-linux-xfs@oss.sgi.com Wed Sep 14 00:09:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Sep 2005 00:09:29 -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 j8E79GiL016326 for ; Wed, 14 Sep 2005 00:09:17 -0700 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 07156E623; Wed, 14 Sep 2005 09:06:37 +0200 (CEST) To: Tim Shimmin Cc: Bill Kendall , Nicolas Kowalski , linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? References: <4325BA69.4070709@sgi.com> <20050912174223.51325.qmail@web34104.mail.mud.yahoo.com> <20050913123852.Z4874818@boing.melbourne.sgi.com> From: Andi Kleen Date: 14 Sep 2005 09:06:32 +0200 In-Reply-To: <20050913123852.Z4874818@boing.melbourne.sgi.com> 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: 6138 X-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: 321 Lines: 11 Tim Shimmin writes: > is not needed. > Unfortunately AFAIK, the threaded part of xfsdump on Linux is > not there (it is on IRIX with sprocs). I remember looking at the code some time ago. It shouldn't be that hard to port to pthreads shouldn't it? Any specific reason that hasn't been done yet? -Andi From owner-linux-xfs@oss.sgi.com Wed Sep 14 06:49:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Sep 2005 06:49:11 -0700 (PDT) Received: from mail.mcvn.no-ip.com (user134.res131.jtibs.net [82.112.131.134] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8EDmviM024215 for ; Wed, 14 Sep 2005 06:49:00 -0700 Received: from hp1 ([192.168.0.1]) by mail.mcvn.no-ip.com (Merak 5.8.4) with SMTP id A0HI5 for ; Wed, 14 Sep 2005 14:46:11 +0100 Message-ID: <000b01c5b932$a9cbdb60$0100a8c0@hp1> From: "Jan M" To: Subject: xfs: Cannot establish any listening sockets Date: Wed, 14 Sep 2005 14:46:09 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6141 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jan.m@acu.no-ip.com Precedence: bulk X-list: linux-xfs Content-Length: 526 Lines: 19 Hi, System ran perfectly. Xfs started ok. Ran out of space on /. Copied /usr to /drv2/usr (cp -rp). Renamed /usr /oldusr. Created symbolic link /usr to /drv2/usr. Now have 1.4gb spare. Everything else seems to boot ok but the X Font Server fails to start - syslog reports: Cannot establish any listening sockets. The usual reason seems to be another instance running. Not so in this case. SAMBA works so presumably it can establish listening sockets. Any clues? Thanks, Jan [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Sep 14 07:01:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Sep 2005 07:01:23 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8EE19iL025090 for ; Wed, 14 Sep 2005 07:01:10 -0700 Received: from [194.173.12.131] (helo=[192.10.98.53]) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML2ov-1EFXmN3kqp-0003wF; Wed, 14 Sep 2005 15:58:27 +0200 Message-ID: <43282C83.7080407@gmx.net> Date: Wed, 14 Sep 2005 15:58:27 +0200 From: Klaus Strebel User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Jan M CC: linux-xfs@oss.sgi.com Subject: Re: xfs: Cannot establish any listening sockets References: <000b01c5b932$a9cbdb60$0100a8c0@hp1> In-Reply-To: <000b01c5b932$a9cbdb60$0100a8c0@hp1> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:8a7df7300d3d15a4f701302fdde7adf9 X-archive-position: 6142 X-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: 880 Lines: 31 Jan M schrieb: > Hi, > > System ran perfectly. Xfs started ok. > > Ran out of space on /. Copied /usr to /drv2/usr (cp -rp). Renamed /usr /oldusr. Created symbolic link /usr to /drv2/usr. Now have 1.4gb spare. > > Everything else seems to boot ok but the X Font Server fails to start - syslog reports: Cannot establish any listening sockets. > > The usual reason seems to be another instance running. Not so in this case. SAMBA works so presumably it can establish listening sockets. > > Any clues? strace your X font server, then you might see, what goes wrong. Perhaps, xfs refuses to start through symlinks ? Btw. this mailing list is abourt the SGI-XFS filesystem ;-). Ciao Klaus -- 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 Wed Sep 14 07:10:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Sep 2005 07:10:17 -0700 (PDT) Received: from mail.mcvn.no-ip.com (user134.res131.jtibs.net [82.112.131.134] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8EEA2iM026155 for ; Wed, 14 Sep 2005 07:10:03 -0700 Received: from hp1 ([192.168.0.1]) by mail.mcvn.no-ip.com (Merak 5.8.4) with SMTP id A0HI5; Wed, 14 Sep 2005 15:07:21 +0100 Message-ID: <001001c5b935$9f7ea6d0$0100a8c0@hp1> From: "Jan M" To: "Klaus Strebel" Cc: References: <000b01c5b932$a9cbdb60$0100a8c0@hp1> <43282C83.7080407@gmx.net> Subject: Re: xfs: Cannot establish any listening sockets Date: Wed, 14 Sep 2005 15:07:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-archive-position: 6143 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jan.m@acu.no-ip.com Precedence: bulk X-list: linux-xfs Content-Length: 1194 Lines: 50 Thanks. Oops. Sorry. Jan ----- Original Message ----- From: "Klaus Strebel" To: "Jan M" Cc: Sent: Wednesday, September 14, 2005 2:58 PM Subject: Re: xfs: Cannot establish any listening sockets > Jan M schrieb: > > Hi, > > > > System ran perfectly. Xfs started ok. > > > > Ran out of space on /. Copied /usr to /drv2/usr (cp -rp). Renamed /usr /oldusr. Created symbolic link /usr to /drv2/usr. Now have 1.4gb spare. > > > > Everything else seems to boot ok but the X Font Server fails to start - syslog reports: Cannot establish any listening sockets. > > > > The usual reason seems to be another instance running. Not so in this case. SAMBA works so presumably it can establish listening sockets. > > > > Any clues? > strace your X font server, then you might see, what goes wrong. Perhaps, > xfs refuses to start through symlinks ? > > Btw. this mailing list is abourt the SGI-XFS filesystem ;-). > > Ciao > Klaus > > -- > 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 Wed Sep 14 23:36:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Sep 2005 23:36:15 -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 j8F6ZwiL001489 for ; Wed, 14 Sep 2005 23:36:01 -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 j8F6XBfE4879884; Thu, 15 Sep 2005 16:33:12 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j8F6X7xo5030696; Thu, 15 Sep 2005 16:33:07 +1000 (AEST) Date: Thu, 15 Sep 2005 16:33:07 +1000 From: Tim Shimmin To: Andi Kleen Cc: Bill Kendall , Nicolas Kowalski , linux-xfs@oss.sgi.com Subject: Re: Speed up xfsdump ? - threading Message-ID: <20050915163307.F4726795@boing.melbourne.sgi.com> References: <4325BA69.4070709@sgi.com> <20050912174223.51325.qmail@web34104.mail.mud.yahoo.com> <20050913123852.Z4874818@boing.melbourne.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: ; from ak@suse.de on Wed, Sep 14, 2005 at 09:06:32AM +0200 X-archive-position: 6144 X-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: 675 Lines: 21 Hi Andi, On Wed, Sep 14, 2005 at 09:06:32AM +0200, Andi Kleen wrote: > Tim Shimmin writes: > > is not needed. > > Unfortunately AFAIK, the threaded part of xfsdump on Linux is > > not there (it is on IRIX with sprocs). > > I remember looking at the code some time ago. It shouldn't > be that hard to port to pthreads shouldn't it? > > Any specific reason that hasn't been done yet? > Sorry, I never looked into it and the person who did look into the work/issues involved, at the time we did the port, is on holiday. Since the port I believe it's been revisited but I'm not working on dump anymore, so I can't say :) (Sorry for the non-answer;-) --Tim From owner-linux-xfs@oss.sgi.com Thu Sep 15 04:34:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 04:34: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 j8FBYOiL026965 for ; Thu, 15 Sep 2005 04:34:24 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j8FDY2HO002326 for ; Thu, 15 Sep 2005 06:34:03 -0700 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j8FBYKAQ54953490 for ; Thu, 15 Sep 2005 04:34:20 -0700 (PDT) X-ASG-Debug-ID: 1126783902-16003-16-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id D5468D1AA72A for ; Thu, 15 Sep 2005 04:31:42 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j8FBVe8J023429; Thu, 15 Sep 2005 06:31:41 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j8FBVcgi023421; Thu, 15 Sep 2005 06:31:38 -0500 Date: Thu, 15 Sep 2005 06:31:38 -0500 From: Christoph Hellwig Message-Id: <200509151131.j8FBVcgi023421@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com X-ASG-Orig-Subj: TAKE 942609 - only mark buffers done when all pages are uptodate Subject: TAKE 942609 - only mark buffers done when all pages are uptodate X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.3977 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6145 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 657 Lines: 18 in addition replace PBF_NONE with an inverted PBF_DONE, so it's like all the other flags. Date: Thu Sep 15 04:31:27 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: nathans, kenmcd The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:199136a fs/xfs/linux-2.6/xfs_buf.h - 1.109 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.109&r2=text&tr2=1.108&f=h fs/xfs/linux-2.6/xfs_buf.c - 1.208 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.208&r2=text&tr2=1.207&f=h From owner-linux-xfs@oss.sgi.com Thu Sep 15 04:54:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 04:54:34 -0700 (PDT) Received: from mail.opoint.com (admin.opoint.com [193.90.144.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j8FBsNiL028227 for ; Thu, 15 Sep 2005 04:54:25 -0700 Received: (qmail 29111 invoked from network); 15 Sep 2005 11:51:36 -0000 Received: from gw.opoint.no (HELO ?192.168.1.15?) (193.90.144.146) by mail.opoint.com with SMTP; 15 Sep 2005 11:51:36 -0000 Message-ID: <43296048.5020904@opoint.com> Date: Thu, 15 Sep 2005 13:51:36 +0200 From: Joakim Tysseng User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS lockup on 2.6.12-1.1376_FC3smp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6146 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joakim.tysseng@opoint.com Precedence: bulk X-list: linux-xfs Content-Length: 891 Lines: 31 Hi, I'm experiencing a serious problem with XFS on 2.6.12-1.1376_FC3smp The filesystem locks up (no write possible, mysql won't shut down, impossible to reboot machine from console) while running MySQL under a high load. The only error messages I can find are: thales kernel: allocation failed: out of vmalloc space - use vmalloc= to increase size. thales kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250 I've tried increasing /proc/sys/vm/min_free_kbytes to 16386 without success. Any ideas? Where should I start looking, what logs, programs/tests can i run? The problem does not appear immediately, the shortest time from reboot to failure has been 4 hours. Machine config: Dell 6650 / 4 x P4 Xeon with 12GB ram. 1.5T SCSI disk array / PW220S / Perc 4/DC running XFS on top of LVM. (also posted to linux-kernel) -- Sincerely, Joakim Tysseng From owner-linux-xfs@oss.sgi.com Thu Sep 15 05:22:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 05:22:18 -0700 (PDT) Received: from mail.maxer.hu (maxer.hu [212.92.23.144]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8FCMAiL030128 for ; Thu, 15 Sep 2005 05:22:11 -0700 Received: from catv-50637b3a.catv.broadband.hu ([80.99.123.58] helo=blehel.) by mail.maxer.hu (Exim 4.50) with esmtpsa (lehel@pmc-services.hu) (cypher TLS-1.0:RSA_ARCFOUR_MD5:16) id 1EFsi8-0003qv-JS for linux-xfs@oss.sgi.com; Thu, 15 Sep 2005 14:19:28 +0200 From: Lehel Bernadt To: linux-xfs@oss.sgi.com Subject: quota problem - incorrect space/inode usage Date: Thu, 15 Sep 2005 14:19:11 +0200 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200509151419.11313.lehel@pmc-services.hu> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 6147 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lehel@pmc-services.hu Precedence: bulk X-list: linux-xfs Content-Length: 1519 Lines: 41 Kernel is 2.6.13.1 with grsecurity patch: $ repquota /var ... user1 -- 18014398509479036 0 0 18446744073709551586 0 0 user2 -- 18014398509481896 0 0 0 0 0 ... Only a few users have this problem, they either have space misreported, or both space and inode. There are some for which only the home dir exists, nothing else. Even if I move their files to another partition, the repquota output for /var remains the same. The numbers look like 2^54 minus some small value (this value seemingly doesn't correspond to the real usage). $ xfs_info /var meta-data=/var isize=256 agcount=28, agsize=1048560 blks = sectsz=512 data = bsize=4096 blocks=28812560, imaxpct=25 = sunit=16 swidth=32 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=14080, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=131072 blocks=0, rtextents=0 $ mount ... /dev/md2 on /var type xfs (rw,usrquota,grpquota) ... For these users I had to disable quota because otherwise they cannot do anything. Other problem is that the number of misreported users is slowly increasing. So when users are created everything is ok, and then at one moment space/inode usage turns into this huge value. I would appreciate any help. Thanks, Lehel From owner-linux-xfs@oss.sgi.com Thu Sep 15 06:25:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 06:26:06 -0700 (PDT) Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8FDPuiL001623 for ; Thu, 15 Sep 2005 06:25:56 -0700 Received: (qmail 31334 invoked by uid 514); 15 Sep 2005 15:23:15 +0200 Received: from 62.37.217.2 by txori (envelope-from , uid 513) with qmail-scanner-1.25-st-qms (clamdscan: 0.86.1/974. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.217.2):SA:0(-2.2/5.0):. Processed in 1.944588 secs); 15 Sep 2005 13:23:15 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via txori X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.217.2):SA:0(-2.2/5.0):. Processed in 1.944588 secs Process 31323) Received: from 62-37-217-2.mad1.adsl.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.217.2) by mail.rentalia.net with SMTP; 15 Sep 2005 15:23:13 +0200 Message-ID: <432975BA.2080907@rentalia.com> Date: Thu, 15 Sep 2005 15:23:06 +0200 From: Ruben Rubio Rey User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6148 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: linux-xfs Content-Length: 32057 Lines: 597 Hi, I have a server that has an error. I have written to Linux Kernel Mailing List and they told me that the problem is that I have a heavily fragmented file in an XFS filesystem and I should run xfs_fsr to solve the problem. Is that correct? Any other ideas? Thanks in advance Complete error: Sep 13 08:39:34 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:34 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:34 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:34 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:34 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:34 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:34 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:34 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:34 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:34 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:34 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:34 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:34 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:34 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:34 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:34 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:34 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:34 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:34 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:34 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:34 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:34 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:34 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:34 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:34 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:34 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:34 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:34 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:35 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:35 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:35 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:35 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:35 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:35 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:35 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:35 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:35 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:35 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:35 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:35 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:35 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:35 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:35 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:35 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:35 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:35 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:35 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:35 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:35 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:35 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:35 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:35 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:35 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:35 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:35 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:35 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:35 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:35 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:35 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:35 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:35 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:35 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:35 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:35 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:35 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:35 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:36 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:36 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:36 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:36 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:36 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:36 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:36 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:36 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:36 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:36 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:36 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:36 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:36 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:36 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:36 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:36 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:36 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:36 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:36 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:36 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:36 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:36 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:36 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:36 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:36 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:36 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:36 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:36 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:36 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:37 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:37 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:37 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:37 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:37 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:37 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:37 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:37 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:37 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:37 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:37 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:37 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:37 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:37 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:37 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:37 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:37 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:37 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:37 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:37 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:37 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:37 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:37 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:37 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:37 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:37 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:37 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:37 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:37 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:37 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:37 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:37 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:37 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:38 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:38 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:38 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:38 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:38 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:38 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:38 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:38 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:38 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:38 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:38 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:38 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:38 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:38 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:38 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:38 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:38 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:38 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:38 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:38 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:38 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:38 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:38 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:38 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:38 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:38 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:38 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:39 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:39 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:39 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:39 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:39 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:39 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:39 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:39 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:39 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:39 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:39 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:39 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:39 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:39 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:39 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:39 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:39 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:39 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:39 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:39 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:39 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:39 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:39 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:39 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:39 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:39 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:39 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:39 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:39 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:39 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:39 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:39 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:39 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:39 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:39 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:39 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:40 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:40 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:40 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:40 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:40 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:40 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:40 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:40 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:40 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:40 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:40 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:40 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:40 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:40 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:40 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:40 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:40 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:40 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:40 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:40 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:40 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:40 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:40 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:40 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:40 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:40 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:41 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:41 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:41 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:41 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:41 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:41 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:41 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:41 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:41 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:41 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:41 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:41 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:41 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:41 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:41 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:41 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:41 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:41 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:41 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:41 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:41 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:41 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:41 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:41 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:41 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:41 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:41 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:41 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:41 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:41 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:41 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:41 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:41 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:41 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:41 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:41 txori kernel: possible deadlock in kmem_alloc (mode:0x50) From owner-linux-xfs@oss.sgi.com Thu Sep 15 06:36:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 06:36:23 -0700 (PDT) Received: from mail1.dulles.sv.int (office.servervault.com [216.12.128.136]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8FDaHiL002379 for ; Thu, 15 Sep 2005 06:36:18 -0700 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: XFS problem Date: Thu, 15 Sep 2005 09:33:36 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS problem Thread-Index: AcW5+LRiDcvQ7jqJReCq172wwtVPlgAAVTyQ From: "Piszcz, Justin" To: "Ruben Rubio Rey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8FDaIiL002382 X-archive-position: 6149 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@servervault.com Precedence: bulk X-list: linux-xfs Content-Length: 32331 Lines: 670 What does xfs_db -c frag -r /dev/ say? -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Ruben Rubio Rey Sent: Thursday, September 15, 2005 9:23 AM To: linux-xfs@oss.sgi.com Subject: XFS problem Hi, I have a server that has an error. I have written to Linux Kernel Mailing List and they told me that the problem is that I have a heavily fragmented file in an XFS filesystem and I should run xfs_fsr to solve the problem. Is that correct? Any other ideas? Thanks in advance Complete error: Sep 13 08:39:34 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:34 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:34 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:34 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:34 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:34 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:34 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:34 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:34 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:34 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:34 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:34 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:34 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:34 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:34 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:34 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:34 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:34 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:34 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:34 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:34 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:34 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:34 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:34 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:34 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:34 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:34 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:34 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:35 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:35 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:35 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:35 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:35 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:35 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:35 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:35 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:35 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:35 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:35 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:35 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:35 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:35 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:35 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:35 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:35 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:35 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:35 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:35 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:35 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:35 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:35 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:35 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:35 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:35 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:35 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:35 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:35 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:35 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:35 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:35 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:35 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:35 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:35 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:35 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:35 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:35 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:36 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:36 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:36 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:36 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:36 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:36 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:36 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:36 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:36 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:36 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:36 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:36 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:36 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:36 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:36 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:36 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:36 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:36 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:36 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:36 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:36 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:36 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:36 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:36 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:36 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:36 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:36 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:36 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:36 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:37 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:37 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:37 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:37 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:37 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:37 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:37 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:37 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:37 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:37 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:37 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:37 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:37 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:37 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:37 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:37 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:37 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:37 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:37 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:37 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:37 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:37 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:37 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:37 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:37 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:37 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:37 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:37 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:37 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:37 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:37 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:37 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:37 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:38 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:38 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:38 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:38 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:38 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:38 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:38 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:38 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:38 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:38 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:38 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:38 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:38 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:38 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:38 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:38 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:38 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:38 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:38 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:38 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:38 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:38 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:38 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:38 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:38 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:38 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:38 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:39 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:39 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:39 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:39 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:39 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:39 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:39 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:39 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:39 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:39 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:39 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:39 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:39 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:39 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:39 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:39 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:39 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:39 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:39 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:39 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:39 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:39 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:39 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:39 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:39 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:39 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:39 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:39 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:39 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:39 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:39 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:39 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:39 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:39 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:39 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:39 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:40 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:40 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:40 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:40 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:40 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:40 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:40 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:40 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:40 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:40 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:40 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:40 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:40 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:40 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:40 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:40 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:40 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:40 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:40 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:40 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:40 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:40 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:40 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:40 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:40 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:40 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:41 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:41 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:41 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:41 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:41 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:41 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:41 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:41 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:41 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:41 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:41 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:41 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:41 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:41 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:41 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:41 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:41 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:41 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:41 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:41 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:41 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:41 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:41 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:41 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:41 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:41 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:41 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:41 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:41 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:41 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:41 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:41 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:41 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:41 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:41 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:41 txori kernel: possible deadlock in kmem_alloc (mode:0x50) From owner-linux-xfs@oss.sgi.com Thu Sep 15 06:43:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 06:44:02 -0700 (PDT) Received: from mail1.dulles.sv.int (office.servervault.com [216.12.128.136]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8FDhliL003092 for ; Thu, 15 Sep 2005 06:43:48 -0700 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: XFS problem Date: Thu, 15 Sep 2005 09:41:06 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS problem Thread-Index: AcW5+ugv7qx3DkS4SUqnb7yxPUdRhQAABTUA From: "Piszcz, Justin" To: "Ruben" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8FDhmiL003095 X-archive-position: 6150 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@servervault.com Precedence: bulk X-list: linux-xfs Content-Length: 33562 Lines: 762 Well that rules out the fragmentation problem. What I would do is the following: 1) Backup all of your data elsewhere. 2) Install/compile run 2.6.13.1 if possible. 3) Run xfs_repair on the file system and hope it fixes it. Any other suggestions? Justin. -----Original Message----- From: Ruben [mailto:ruben@rentalia.com] Sent: Thursday, September 15, 2005 9:39 AM To: Piszcz, Justin Subject: Re: XFS problem root@txori:~$ xfs_db -c frag -r /dev/cciss/c0d0p3 actual 731957, ideal 692973, fragmentation factor 5.33% Piszcz, Justin wrote: >What does xfs_db -c frag -r /dev/ say? > > >-----Original Message----- >From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] >On Behalf Of Ruben Rubio Rey >Sent: Thursday, September 15, 2005 9:23 AM >To: linux-xfs@oss.sgi.com >Subject: XFS problem > >Hi, > >I have a server that has an error. > >I have written to Linux Kernel Mailing List and they told me that the >problem is that I have a heavily fragmented file in an XFS filesystem >and I should run xfs_fsr to solve the problem. > >Is that correct? >Any other ideas? > >Thanks in advance > >Complete error: > >Sep 13 08:39:34 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:34 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:34 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:34 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:34 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:34 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:34 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:34 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:34 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:34 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:34 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:34 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:34 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:34 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:34 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:34 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:34 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:34 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:34 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:34 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:34 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:34 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:34 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:34 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:34 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:34 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:34 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:34 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:35 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:35 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:35 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:35 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:35 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:35 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:35 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:35 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:35 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:35 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:35 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:35 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:35 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:35 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:35 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:35 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:35 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:35 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:35 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:35 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:35 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:35 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:35 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:35 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:35 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:35 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:35 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:35 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:35 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:35 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:35 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:35 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:35 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:35 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:35 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:35 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:35 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:35 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:36 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:36 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:36 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:36 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:36 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:36 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:36 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:36 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:36 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:36 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:36 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:36 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:36 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:36 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:36 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:36 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:36 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:36 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:36 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:36 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:36 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:36 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:36 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:36 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:36 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:36 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:36 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:36 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:36 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:37 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:37 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:37 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:37 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:37 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:37 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:37 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:37 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:37 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:37 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:37 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:37 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:37 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:37 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:37 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:37 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:37 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:37 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:37 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:37 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:37 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:37 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:37 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:37 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:37 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:37 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:37 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:37 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:37 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:37 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:37 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:37 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:37 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:38 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:38 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:38 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:38 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:38 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:38 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:38 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:38 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:38 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:38 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:38 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:38 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:38 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:38 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:38 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:38 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:38 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:38 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:38 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:38 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:38 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:38 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:38 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:38 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:38 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:38 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:38 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:39 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:39 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:39 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:39 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:39 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:39 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:39 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:39 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:39 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:39 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:39 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:39 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:39 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:39 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:39 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:39 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:39 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:39 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:39 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:39 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:39 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:39 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:39 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:39 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:39 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:39 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:39 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:39 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:39 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:39 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:39 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:39 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:39 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:39 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:39 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:39 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:40 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:40 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:40 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:40 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:40 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:40 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:40 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:40 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:40 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:40 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:40 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:40 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:40 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:40 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:40 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:40 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:40 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:40 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:40 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:40 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:40 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:40 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:40 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:40 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:40 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:40 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:41 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:41 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:41 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:41 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:41 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:41 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:41 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:41 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:41 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:41 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:41 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:41 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:41 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:41 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:41 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:41 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:41 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:41 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:41 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:41 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:41 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:41 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:41 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:41 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:41 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:41 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:41 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:41 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:41 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:41 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:41 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:41 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:41 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:41 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:41 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:41 txori kernel: possible deadlock in kmem_alloc >(mode:0x50) > > > > > > > > From owner-linux-xfs@oss.sgi.com Thu Sep 15 06:51:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 06:51:26 -0700 (PDT) Received: from mail1.dulles.sv.int (office.servervault.com [216.12.128.136]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8FDpHiL004185 for ; Thu, 15 Sep 2005 06:51:17 -0700 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: XFS problem Date: Thu, 15 Sep 2005 09:48:33 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS problem Thread-Index: AcW5+LRiDcvQ7jqJReCq172wwtVPlgAAz6SQ From: "Piszcz, Justin" To: "Ruben Rubio Rey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8FDpHiL004189 X-archive-position: 6151 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@servervault.com Precedence: bulk X-list: linux-xfs Content-Length: 32620 Lines: 676 Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 I also had page allocation failures at one point, it was do to the TX segmentation offload settings on my NIC, do you use an Intel gigabit nic by any chance or what version of the kernel? I remember a certain version of the kernel doing this as well. -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Ruben Rubio Rey Sent: Thursday, September 15, 2005 9:23 AM To: linux-xfs@oss.sgi.com Subject: XFS problem Hi, I have a server that has an error. I have written to Linux Kernel Mailing List and they told me that the problem is that I have a heavily fragmented file in an XFS filesystem and I should run xfs_fsr to solve the problem. Is that correct? Any other ideas? Thanks in advance Complete error: Sep 13 08:39:34 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:34 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:34 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:34 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:34 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:34 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:34 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:34 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:34 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:34 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:34 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:34 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:34 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:34 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:34 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:34 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:34 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:34 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:34 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:34 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:34 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:34 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:34 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:34 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:34 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:34 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:34 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:34 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:35 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:35 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:35 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:35 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:35 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:35 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:35 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:35 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:35 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:35 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:35 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:35 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:35 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:35 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:35 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:35 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:35 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:35 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:35 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:35 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:35 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:35 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:35 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:35 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:35 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:35 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:35 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:35 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:35 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:35 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:35 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:35 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:35 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:35 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:35 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:35 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:35 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:35 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:35 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:36 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:36 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:36 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:36 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:36 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:36 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:36 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:36 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:36 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:36 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:36 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:36 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:36 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:36 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:36 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:36 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:36 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:36 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:36 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:36 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:36 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:36 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:36 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:36 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:36 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:36 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:36 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:36 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:36 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:37 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:37 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:37 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:37 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:37 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:37 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:37 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:37 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:37 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:37 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:37 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:37 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:37 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:37 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:37 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:37 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:37 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:37 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:37 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:37 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:37 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:37 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:37 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:37 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:37 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:37 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:37 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:37 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:37 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:37 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:37 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:37 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:37 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:37 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:38 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:38 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:38 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:38 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:38 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:38 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:38 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:38 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:38 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:38 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:38 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:38 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:38 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:38 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:38 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:38 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:38 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:38 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:38 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:38 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:38 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:38 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:38 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:38 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:38 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:38 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:38 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:38 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:39 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:39 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:39 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:39 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:39 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:39 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:39 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:39 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:39 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:39 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:39 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:39 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:39 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:39 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:39 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:39 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:39 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:39 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:39 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:39 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:39 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:39 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:39 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:39 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:39 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:39 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:39 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:39 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:39 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:39 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:39 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:39 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:39 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:39 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:39 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:39 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:40 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:40 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:40 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:40 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:40 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:40 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:40 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:40 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:40 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:40 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:40 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:40 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:40 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:40 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:40 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:40 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:40 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:40 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:40 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:40 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:40 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:40 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:40 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:40 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:40 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:40 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:40 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. order:4, mode:0x50 Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 Sep 13 08:39:41 txori kernel: [<021409c6>] cache_alloc_refill+0x165/0x19d Sep 13 08:39:41 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 Sep 13 08:39:41 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] Sep 13 08:39:41 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] Sep 13 08:39:41 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc [xfs] Sep 13 08:39:41 txori kernel: [<82901912>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] Sep 13 08:39:41 txori kernel: [<828fed42>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] Sep 13 08:39:41 txori kernel: [<828fc7b4>] xfs_bmap_add_extent+0x146/0x399 [xfs] Sep 13 08:39:41 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] Sep 13 08:39:41 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] Sep 13 08:39:41 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 Sep 13 08:39:41 txori kernel: [<82926bdf>] xfs_iomap_write_delay+0x628/0x702 [xfs] Sep 13 08:39:41 txori kernel: [<8292ad03>] xlog_state_get_iclog_space+0x163/0x172 [xfs] Sep 13 08:39:41 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a [xfs] Sep 13 08:39:41 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] Sep 13 08:39:41 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] Sep 13 08:39:41 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] Sep 13 08:39:41 txori kernel: [<8294005f>] linvfs_get_block_core+0x6b/0x257 [xfs] Sep 13 08:39:41 txori kernel: [<02139c3f>] find_or_create_page+0x18/0x72 Sep 13 08:39:41 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 Sep 13 08:39:41 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 Sep 13 08:39:41 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 [xfs] Sep 13 08:39:41 txori kernel: [<0215664f>] __block_prepare_write+0x15d/0x3e4 Sep 13 08:39:41 txori kernel: [<02156f61>] block_prepare_write+0x16/0x23 Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:41 txori kernel: [<82940578>] linvfs_prepare_write+0x12/0x16 [xfs] Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 [xfs] Sep 13 08:39:41 txori kernel: [<0213b3c8>] generic_file_buffered_write+0x1b5/0x4ae Sep 13 08:39:41 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 [xfs] Sep 13 08:39:41 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 [xfs] Sep 13 08:39:41 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] Sep 13 08:39:41 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] Sep 13 08:39:41 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 Sep 13 08:39:41 txori kernel: [<8293a4d9>] xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] Sep 13 08:39:41 txori kernel: [<0211deca>] autoremove_wake_function+0x0/0x2d Sep 13 08:39:41 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 Sep 13 08:39:41 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 Sep 13 08:39:41 txori kernel: possible deadlock in kmem_alloc (mode:0x50) From owner-linux-xfs@oss.sgi.com Thu Sep 15 07:13:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 07:14:00 -0700 (PDT) Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8FEDliL006103 for ; Thu, 15 Sep 2005 07:13:48 -0700 Received: (qmail 1889 invoked by uid 514); 15 Sep 2005 16:11:07 +0200 Received: from 62.37.217.2 by txori (envelope-from , uid 513) with qmail-scanner-1.25-st-qms (clamdscan: 0.86.1/974. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.217.2):SA:0(-2.2/5.0):. Processed in 3.124561 secs); 15 Sep 2005 14:11:07 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via txori X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.217.2):SA:0(-2.2/5.0):. Processed in 3.124561 secs Process 1881) Received: from 62-37-217-2.mad1.adsl.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.217.2) by mail.rentalia.net with SMTP; 15 Sep 2005 16:11:04 +0200 Message-ID: <432980F1.8080609@rentalia.com> Date: Thu, 15 Sep 2005 16:10:57 +0200 From: Ruben Rubio Rey User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS problem References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6153 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: linux-xfs Content-Length: 33707 Lines: 694 Piszcz, Justin wrote: >Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 > >I also had page allocation failures at one point, it was do to the TX >segmentation offload settings on my NIC, do you use an Intel gigabit nic >by any chance or what version of the kernel? I remember a certain >version of the kernel doing this as well. > > >-----Original Message----- >From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] >On Behalf Of Ruben Rubio Rey >Sent: Thursday, September 15, 2005 9:23 AM >To: linux-xfs@oss.sgi.com >Subject: XFS problem > >Hi, > >I have a server that has an error. > >I have written to Linux Kernel Mailing List and they told me that the >problem is that I have a heavily fragmented file in an XFS filesystem >and I should run xfs_fsr to solve the problem. > >Is that correct? >Any other ideas? > >Thanks in advance > >Complete error: > >Sep 13 08:39:34 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:34 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:34 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:34 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:34 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:34 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:34 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:34 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:34 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:34 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:34 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:34 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:34 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:34 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:34 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:34 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:34 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:34 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:34 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:34 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:34 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:34 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:34 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:34 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:34 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:34 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:34 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:34 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:35 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:35 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:35 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:35 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:35 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:35 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:35 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:35 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:35 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:35 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:35 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:35 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:35 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:35 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:35 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:35 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:35 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:35 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:35 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:35 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:35 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:35 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:35 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:35 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:35 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:35 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:35 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:35 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:35 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:35 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:35 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:35 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:35 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:35 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:35 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:35 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:35 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:35 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:36 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:36 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:36 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:36 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:36 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:36 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:36 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:36 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:36 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:36 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:36 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:36 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:36 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:36 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:36 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:36 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:36 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:36 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:36 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:36 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:36 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:36 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:36 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:36 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:36 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:36 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:36 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:36 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:36 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:37 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:37 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:37 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:37 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:37 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:37 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:37 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:37 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:37 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:37 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:37 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:37 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:37 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:37 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:37 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:37 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:37 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:37 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:37 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:37 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:37 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:37 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:37 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:37 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:37 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:37 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:37 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:37 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:37 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:37 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:37 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:37 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:37 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:38 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:38 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:38 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:38 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:38 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:38 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:38 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:38 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:38 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:38 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:38 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:38 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:38 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:38 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:38 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:38 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:38 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:38 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:38 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:38 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:38 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:38 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:38 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:38 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:38 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:38 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:38 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:39 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:39 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:39 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:39 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:39 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:39 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:39 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:39 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:39 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:39 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:39 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:39 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:39 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:39 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:39 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:39 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:39 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:39 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:39 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:39 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:39 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:39 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:39 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:39 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:39 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:39 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:39 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:39 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:39 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:39 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:39 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:39 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:39 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:39 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:39 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:39 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:40 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:40 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:40 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:40 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:40 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:40 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:40 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:40 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:40 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:40 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:40 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:40 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:40 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:40 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:40 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:40 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:40 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:40 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:40 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:40 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:40 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:40 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:40 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:40 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:40 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:40 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:41 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:41 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:41 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:41 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:41 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:41 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:41 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:41 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:41 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:41 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:41 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:41 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:41 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:41 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:41 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:41 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:41 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:41 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:41 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:41 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:41 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:41 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:41 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:41 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:41 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:41 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:41 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:41 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:41 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:41 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:41 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:41 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:41 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:41 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:41 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:41 txori kernel: possible deadlock in kmem_alloc >(mode:0x50) > > > > > > My NIC is 02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10) 02:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10) Kernel 2.6.9-1.667smp But i dont think here is the problem. We have another servers similar in hardware and software and there is only one with the problem. Any other ideas? From owner-linux-xfs@oss.sgi.com Thu Sep 15 07:26:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 07:26:48 -0700 (PDT) Received: from mail1.dulles.sv.int (office.servervault.com [216.12.128.136]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8FEQbiL007313 for ; Thu, 15 Sep 2005 07:26:37 -0700 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: XFS problem Date: Thu, 15 Sep 2005 10:23:56 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS problem Thread-Index: AcW5/2fe9OvcVG5PSJ244N437OAvXgAAXYYg From: "Piszcz, Justin" To: "Ruben Rubio Rey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8FEQciL007315 X-archive-position: 6154 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@servervault.com Precedence: bulk X-list: linux-xfs Content-Length: 34161 Lines: 772 Your applications, ie: perl should not be giving page allocation failures; this is usually the fault of the kernel/TSO on your NIC. This is your first problem. Second, you need to run xfs_repair (after backing up your data). -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Ruben Rubio Rey Sent: Thursday, September 15, 2005 10:11 AM To: linux-xfs@oss.sgi.com Subject: Re: XFS problem Piszcz, Justin wrote: >Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 > >I also had page allocation failures at one point, it was do to the TX >segmentation offload settings on my NIC, do you use an Intel gigabit nic >by any chance or what version of the kernel? I remember a certain >version of the kernel doing this as well. > > >-----Original Message----- >From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] >On Behalf Of Ruben Rubio Rey >Sent: Thursday, September 15, 2005 9:23 AM >To: linux-xfs@oss.sgi.com >Subject: XFS problem > >Hi, > >I have a server that has an error. > >I have written to Linux Kernel Mailing List and they told me that the >problem is that I have a heavily fragmented file in an XFS filesystem >and I should run xfs_fsr to solve the problem. > >Is that correct? >Any other ideas? > >Thanks in advance > >Complete error: > >Sep 13 08:39:34 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:34 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:34 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:34 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:34 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:34 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:34 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:34 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:34 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:34 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:34 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:34 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:34 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:34 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:34 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:34 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:34 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:34 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:34 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:34 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:34 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:34 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:34 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:34 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:34 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:34 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:34 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:34 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:35 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:35 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:35 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:35 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:35 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:35 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:35 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:35 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:35 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:35 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:35 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:35 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:35 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:35 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:35 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:35 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:35 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:35 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:35 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:35 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:35 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:35 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:35 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:35 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:35 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:35 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:35 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:35 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:35 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:35 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:35 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:35 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:35 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:35 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:35 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:35 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:35 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:35 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:35 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:35 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:36 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:36 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:36 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:36 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:36 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:36 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:36 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:36 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:36 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:36 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:36 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:36 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:36 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:36 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:36 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:36 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:36 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:36 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:36 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:36 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:36 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:36 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:36 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:36 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:36 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:36 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:36 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:36 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:36 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:36 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:36 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:36 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:36 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:36 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:36 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:36 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:36 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:36 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:36 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:36 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:36 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:36 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:36 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:36 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:37 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:37 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:37 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:37 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:37 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:37 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:37 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:37 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:37 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:37 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:37 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:37 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:37 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:37 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:37 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:37 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:37 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:37 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:37 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:37 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:37 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:37 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:37 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:37 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:37 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:37 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:37 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:37 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:37 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:37 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:37 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:37 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:37 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:37 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:37 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:37 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:37 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:37 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:37 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:37 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:37 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:37 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:37 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:37 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:37 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:38 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:38 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:38 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:38 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:38 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:38 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:38 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:38 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:38 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:38 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:38 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:38 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:38 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:38 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:38 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:38 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:38 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:38 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:38 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:38 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:38 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:38 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:38 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:38 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:38 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:38 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:38 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:38 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:38 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:38 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:38 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:38 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:38 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:38 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:38 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:38 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:38 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:38 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:38 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:38 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:38 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:38 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:39 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:39 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:39 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:39 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:39 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:39 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:39 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:39 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:39 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:39 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:39 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:39 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:39 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:39 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:39 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:39 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:39 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:39 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:39 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:39 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:39 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:39 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:39 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:39 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:39 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:39 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:39 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:39 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:39 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:39 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:39 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:39 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:39 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:39 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:39 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:39 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:39 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:39 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:39 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:39 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:39 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:39 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:39 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:39 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:39 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:40 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:40 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:40 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:40 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:40 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:40 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:40 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:40 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:40 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:40 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:40 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:40 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:40 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:40 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:40 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:40 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:40 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:40 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:40 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:40 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:40 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:40 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:40 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:40 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:40 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:40 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:40 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:40 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:40 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:40 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:40 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:40 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:40 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:40 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:40 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:40 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:40 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:40 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:40 txori kernel: perl5.8.5: page allocation failure. >order:4, mode:0x50 >Sep 13 08:39:40 txori kernel: [<0213d396>] __alloc_pages+0x28b/0x298 >Sep 13 08:39:40 txori kernel: [<0213d3bb>] __get_free_pages+0x18/0x24 >Sep 13 08:39:40 txori kernel: [<0213fc88>] kmem_getpages+0x1c/0xbb >Sep 13 08:39:40 txori kernel: [<021407d9>] cache_grow+0xae/0x136 >Sep 13 08:39:41 txori kernel: [<021409c6>] >cache_alloc_refill+0x165/0x19d >Sep 13 08:39:41 txori kernel: [<02140d9d>] __kmalloc+0x76/0x88 >Sep 13 08:39:41 txori kernel: [<8293ee20>] kmem_alloc+0x50/0x9e [xfs] >Sep 13 08:39:41 txori kernel: [<8293eef0>] kmem_realloc+0x17/0x52 [xfs] >Sep 13 08:39:41 txori kernel: [<82924188>] xfs_iext_realloc+0xc9/0xdc >[xfs] >Sep 13 08:39:41 txori kernel: [<82901912>] >xfs_bmap_insert_exlist+0x22/0x77 [xfs] >Sep 13 08:39:41 txori kernel: [<828fed42>] >xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] >Sep 13 08:39:41 txori kernel: [<828fc7b4>] >xfs_bmap_add_extent+0x146/0x399 [xfs] >Sep 13 08:39:41 txori kernel: [<829039bc>] xfs_bmapi+0xb00/0x12bf [xfs] >Sep 13 08:39:41 txori kernel: [<829031e2>] xfs_bmapi+0x326/0x12bf [xfs] >Sep 13 08:39:41 txori kernel: [<021398ef>] wake_up_page+0x9/0x29 >Sep 13 08:39:41 txori kernel: [<82926bdf>] >xfs_iomap_write_delay+0x628/0x702 [xfs] >Sep 13 08:39:41 txori kernel: [<8292ad03>] >xlog_state_get_iclog_space+0x163/0x172 [xfs] >Sep 13 08:39:41 txori kernel: [<82925b32>] xfs_imap_to_bmap+0x2a/0x28a >[xfs] >Sep 13 08:39:41 txori kernel: [<82925fcc>] xfs_iomap+0x23a/0x3ec [xfs] >Sep 13 08:39:41 txori kernel: [<82926076>] xfs_iomap+0x2e4/0x3ec [xfs] >Sep 13 08:39:41 txori kernel: [<82945e39>] xfs_bmap+0x1a/0x1e [xfs] >Sep 13 08:39:41 txori kernel: [<8294005f>] >linvfs_get_block_core+0x6b/0x257 [xfs] >Sep 13 08:39:41 txori kernel: [<02139c3f>] >find_or_create_page+0x18/0x72 >Sep 13 08:39:41 txori kernel: [<022b7b17>] __cond_resched+0x14/0x39 >Sep 13 08:39:41 txori kernel: [<02156002>] set_bh_page+0x2c/0x34 >Sep 13 08:39:41 txori kernel: [<8294025e>] linvfs_get_block+0x13/0x17 >[xfs] >Sep 13 08:39:41 txori kernel: [<0215664f>] >__block_prepare_write+0x15d/0x3e4 >Sep 13 08:39:41 txori kernel: [<02156f61>] >block_prepare_write+0x16/0x23 >Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:41 txori kernel: [<82940578>] >linvfs_prepare_write+0x12/0x16 [xfs] >Sep 13 08:39:41 txori kernel: [<8294024b>] linvfs_get_block+0x0/0x17 >[xfs] >Sep 13 08:39:41 txori kernel: [<0213b3c8>] >generic_file_buffered_write+0x1b5/0x4ae >Sep 13 08:39:41 txori kernel: [<8290e4ed>] xfs_da_brelse+0x73/0x92 >[xfs] >Sep 13 08:39:41 txori kernel: [<828f7400>] xfs_attr_leaf_get+0x4b/0x82 >[xfs] >Sep 13 08:39:41 txori kernel: [<82945a87>] xfs_write+0x622/0x982 [xfs] >Sep 13 08:39:41 txori kernel: [<8294230d>] linvfs_write+0x6f/0x77 [xfs] >Sep 13 08:39:41 txori kernel: [<02153d7b>] do_sync_write+0x97/0xc9 >Sep 13 08:39:41 txori kernel: [<8293a4d9>] >xfs_inactive_free_eofblocks+0xd2/0x210 [xfs] >Sep 13 08:39:41 txori kernel: [<0211deca>] >autoremove_wake_function+0x0/0x2d >Sep 13 08:39:41 txori kernel: [<02153e63>] vfs_write+0xb6/0xe2 >Sep 13 08:39:41 txori kernel: [<02153f2d>] sys_write+0x3c/0x62 >Sep 13 08:39:41 txori kernel: possible deadlock in kmem_alloc >(mode:0x50) > > > > > > My NIC is 02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10) 02:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10) Kernel 2.6.9-1.667smp But i dont think here is the problem. We have another servers similar in hardware and software and there is only one with the problem. Any other ideas? From owner-linux-xfs@oss.sgi.com Thu Sep 15 08:11:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 08:11:17 -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 j8FFB1iL009952 for ; Thu, 15 Sep 2005 08:11:01 -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 j8FHAUUC030147 for ; Thu, 15 Sep 2005 10:10:31 -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 j8FF78DN15697371; Thu, 15 Sep 2005 10:07:08 -0500 (CDT) Message-ID: <43298E1B.60805@sgi.com> Date: Thu, 15 Sep 2005 10:07:07 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Piszcz, Justin" CC: Ruben , linux-xfs@oss.sgi.com Subject: Re: XFS problem References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6155 X-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: 545 Lines: 16 Piszcz, Justin wrote: > Well that rules out the fragmentation problem. Not necessarily, a single highly fragmented file could cause this problem. In other words, the problem is not with average fragmentation on the filesystem, the problem is with highly fragmented individual files. Do you know which file might be getting accessed when you get these errors? And as a starting point - do you have large files downloaded via bittorrent somewhere? :) You can run xfs_bmap -v on any suspect files to see how many extents they have. -Eric From owner-linux-xfs@oss.sgi.com Thu Sep 15 09:15:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 09:15:58 -0700 (PDT) Received: from aaa.dreamhost.com (aaa.dreamhost.com [64.111.107.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8FGFpiL017547 for ; Thu, 15 Sep 2005 09:15:51 -0700 Received: from [10.2.255.6] (unknown [208.51.196.2]) by aaa.dreamhost.com (Postfix) with ESMTP id C5A5A14D24; Thu, 15 Sep 2005 09:12:59 -0700 (PDT) Message-ID: <43299DDA.9060305@delusion.com> Date: Thu, 15 Sep 2005 09:14:18 -0700 From: Deanan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner Cc: linux-xfs@oss.sgi.com, sandeen@sgi.com Subject: Re: fresh xfs vs used xfs References: <4325B3C1.20506@delusion.com> <20050912224805.GA685356@melbourne.sgi.com> In-Reply-To: <20050912224805.GA685356@melbourne.sgi.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6156 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: delusion@delusion.com Precedence: bulk X-list: linux-xfs Content-Length: 1767 Lines: 61 Hi Dave & Eric,

Basically I'm trying to write 16MB files at about 400MB/s. The bandwidth
to disk is about 550MB/s so I have a little overhead. On the first pass
writing the files I can make it all the way through the 5.5TB with no problems.
After deleteing the files and starting the second pass, I start seeing delays
in the writes that add up and eventually I run out of buffers.

Unfortunately, I don't have any more info other that the writes start to take
longer.

The nr_requests is already at 128. Should I try something higher?

I'm trying Eric's suggestions now also.

Cheers,

Deanan


On Mon, Sep 12, 2005 at 09:58:41AM -0700, Deanan wrote:
  
Hi,

I'm seeing some strange things happen that i can't really explain.
I'm using the XFS with SLES 9 and 2.6.5-7.97 on x86_64.

I'm filling up 6TB in one shot with 16mb files. When I delete the
directory that contains all the files and then go back the to refill
the directory again, I get performance problems.
    

Can you be more precise about what your performance problem is and
how you are reproducing it?

BTW, if you are using the cfq elevator, what happens if you
"echo 128 > /sys/block/sdXX/queue/nr_requests" for each block device
that makes up your filesystem?

Cheers,

Dave.

From owner-linux-xfs@oss.sgi.com Thu Sep 15 19:30:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 19:30: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 j8G2UFiL032748 for ; Thu, 15 Sep 2005 19:30: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 MAA29224; Fri, 16 Sep 2005 12:27:29 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 8DE4749BFB01; Fri, 16 Sep 2005 12:27:28 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 942528 - unsigned quota IDs Message-Id: <20050916022728.8DE4749BFB01@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 12:27:28 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6157 X-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: 772 Lines: 18 Fix signedness issues in dquot ID handling, allowing uids/gids above MAXINT Date: Fri Sep 16 12:26:56 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23828a xfs_quota.h - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_quota.h.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h quota/xfs_qm_syscalls.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h quota/xfs_dquot.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h From owner-linux-xfs@oss.sgi.com Thu Sep 15 19:34:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 19:34: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 j8G2YliL000854 for ; Thu, 15 Sep 2005 19:34:47 -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 MAA29431; Fri, 16 Sep 2005 12:32:02 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 5A7A849BFB01; Fri, 16 Sep 2005 12:32:02 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 942815 - delalloc vs quota reporting Message-Id: <20050916023202.5A7A849BFB01@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 12:32:02 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6158 X-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: 1680 Lines: 30 Provide a mechiansm for flushing delalloc before quota reporting. Date: Fri Sep 16 12:31:35 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:23829a xfs_vfsops.c - 1.473 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.473&r2=text&tr2=1.472&f=h xfs_mount.h - 1.202 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.202&r2=text&tr2=1.201&f=h quota/xfs_qm_syscalls.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h linux-2.6/xfs_fs_subr.c - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_fs_subr.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h linux-2.6/xfs_super.c - 1.344 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.344&r2=text&tr2=1.343&f=h linux-2.4/xfs_fs_subr.c - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_fs_subr.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h linux-2.4/xfs_super.c - 1.313 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.313&r2=text&tr2=1.312&f=h linux-2.6/xfs_ksyms.c - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h linux-2.4/xfs_ksyms.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h From owner-linux-xfs@oss.sgi.com Thu Sep 15 20:36:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 20:36:55 -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 j8G3ajiL008707 for ; Thu, 15 Sep 2005 20:36:46 -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 NAA00598; Fri, 16 Sep 2005 13:33:59 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 6277E49BFB01; Fri, 16 Sep 2005 13:33:58 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 942818 - Allow swidth to be exposed to userspace via stat(2) Message-Id: <20050916033358.6277E49BFB01@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 13:33:58 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 6159 X-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: 2009 Lines: 43 Introduce two new mount options (nolargeio/largeio) to allow filesystems to expose the filesystem stripe width in stat(2) rather than the page cache size. This allows applications requiring high bandwidth to easily determine the optimum I/O size for the underlying filesystem. The default is to report the page cache size (i.e. "nolargeio"). Date: Fri Sep 16 13:32:17 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/xfs-linux Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23830a xfs_vnodeops.c - 1.651 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.651&r2=text&tr2=1.650&f=h - Clean up prefered I/O size selection. xfs_vfsops.c - 1.474 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.474&r2=text&tr2=1.473&f=h xfs_clnt.h - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_clnt.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h - Introduce prefered I/O size mount option selection. xfs_mount.h - 1.203 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.203&r2=text&tr2=1.202&f=h - Introduce prefered I/O size mount option selection and calculation. linux-2.6/xfs_vnode.c - 1.133 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h linux-2.6/xfs_super.c - 1.345 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.345&r2=text&tr2=1.344&f=h linux-2.4/xfs_vnode.c - 1.133 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.c.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h linux-2.4/xfs_super.c - 1.314 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.314&r2=text&tr2=1.313&f=h - Set inode block size to the preferred size for the filesystem From owner-linux-xfs@oss.sgi.com Thu Sep 15 20:41:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 20:41:50 -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 j8G3fgiL009306 for ; Thu, 15 Sep 2005 20:41: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 NAA00660; Fri, 16 Sep 2005 13:38:57 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 86BA149BFB01; Fri, 16 Sep 2005 13:38:57 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 942818 - Allow swidth to be exposed to userspace via stat(2) Message-Id: <20050916033857.86BA149BFB01@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 13:38:57 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 6160 X-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: 484 Lines: 14 Date: Fri Sep 16 13:37:27 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: 2.6.x-xfs-melb:linux:23831a Documentation/filesystems/xfs.txt - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/filesystems/xfs.txt.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - Document largeio/nolargeio mount options. From owner-linux-xfs@oss.sgi.com Thu Sep 15 20:46:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 20:46:29 -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 j8G3kJiL009877 for ; Thu, 15 Sep 2005 20:46:20 -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 NAA00724; Fri, 16 Sep 2005 13:43:35 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 448DF49BFB01; Fri, 16 Sep 2005 13:43:35 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 942818 - Allow swidth to be exposed to userspace via stat(2) Message-Id: <20050916034335.448DF49BFB01@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 13:43:35 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 6161 X-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: 484 Lines: 14 Date: Fri Sep 16 13:43:02 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.4.x-xfs Inspected by: nathans 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:23832a Documentation/filesystems/xfs.txt - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/filesystems/xfs.txt.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h - Document largeio/nolargeio mount options. From owner-linux-xfs@oss.sgi.com Thu Sep 15 22:40:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 22:40:20 -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 j8G5eEiL017777 for ; Thu, 15 Sep 2005 22:40:15 -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 PAA02774; Fri, 16 Sep 2005 15:37:27 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id A705949BFB01; Fri, 16 Sep 2005 15:37:26 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 941645 - attr2 format Message-Id: <20050916053726.A705949BFB01@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 15:37:26 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6162 X-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: 3380 Lines: 67 Move some code around to prepare for the upcoming extended attributes format change (attr2). Date: Fri Sep 16 15:12:04 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23833a xfs_da_btree.c - 1.154 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.154&r2=text&tr2=1.153&f=h xfs_attr_leaf.h - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.h.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h xfs_attr_leaf.c - 1.81 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.81&r2=text&tr2=1.80&f=h xfs_attr.c - 1.121 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.121&r2=text&tr2=1.120&f=h Ondisk format extension for extended attributes (attr2). Basically, the data/attr forks now grow up/down from either end of the literal area, rather than dividing the literal area into two chunks and growing both upward. Means we can now make much more efficient use of the attribute space, incl. fitting DMF attributes inline in 256 byte inodes, and large jumps in dbench3 performance numbers. It is self enabling, but can be forced on/off via the attr2/noattr2 mount options. Date: Fri Sep 16 15:36:03 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23834a xfs_macros.c - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_macros.c.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h xfs_sb.h - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_sb.h.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h xfs_fs.h - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fs.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h xfs_dir.c - 1.161 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir.c.diff?r1=text&tr1=1.161&r2=text&tr2=1.160&f=h xfs_vfsops.c - 1.475 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.475&r2=text&tr2=1.474&f=h xfs_mount.c - 1.360 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.360&r2=text&tr2=1.359&f=h xfs_attr_leaf.h - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.h.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h xfs_attr_leaf.c - 1.82 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.82&r2=text&tr2=1.81&f=h xfs_types.h - 1.77 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_types.h.diff?r1=text&tr1=1.77&r2=text&tr2=1.76&f=h xfs_fsops.c - 1.104 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.104&r2=text&tr2=1.103&f=h xfs_bmap.h - 1.88 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.h.diff?r1=text&tr1=1.88&r2=text&tr2=1.87&f=h xfs_bmap.c - 1.328 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.328&r2=text&tr2=1.327&f=h xfs_attr.c - 1.122 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.122&r2=text&tr2=1.121&f=h From owner-linux-xfs@oss.sgi.com Thu Sep 15 23:00:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 23:00:50 -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 j8G60fiL019156 for ; Thu, 15 Sep 2005 23:00:42 -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 PAA03124; Fri, 16 Sep 2005 15:57:55 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 99A6F49BFB01; Fri, 16 Sep 2005 15:57:53 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 941645 - attr2 format (really) Message-Id: <20050916055753.99A6F49BFB01@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 15:57:53 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6163 X-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: 2520 Lines: 47 [Ugh, apply the patch _before_ checkin, dopey] Ondisk format extension for extended attributes (attr2). Basically, the data/attr forks now grow up/down from either end of the literal area, rather than dividing the literal area into two chunks and growing both upward. Means we can now make much more efficient use of the attribute space, incl. fitting DMF attributes inline in 256 byte inodes, and large jumps in dbench3 performance numbers. It is self enabling, but can be forced on/off via the attr2/noattr2 mount options. Date: Fri Sep 16 15:56:47 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23835a xfs_macros.c - 1.59 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_macros.c.diff?r1=text&tr1=1.59&r2=text&tr2=1.58&f=h xfs_sb.h - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_sb.h.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h xfs_fs.h - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fs.h.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h xfs_dir.c - 1.162 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir.c.diff?r1=text&tr1=1.162&r2=text&tr2=1.161&f=h xfs_vfsops.c - 1.476 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.476&r2=text&tr2=1.475&f=h xfs_mount.c - 1.361 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.361&r2=text&tr2=1.360&f=h xfs_attr_leaf.h - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.h.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h xfs_attr_leaf.c - 1.83 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.83&r2=text&tr2=1.82&f=h xfs_types.h - 1.78 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_types.h.diff?r1=text&tr1=1.78&r2=text&tr2=1.77&f=h xfs_fsops.c - 1.105 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h xfs_bmap.h - 1.89 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.h.diff?r1=text&tr1=1.89&r2=text&tr2=1.88&f=h xfs_bmap.c - 1.329 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.329&r2=text&tr2=1.328&f=h xfs_attr.c - 1.123 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h From owner-linux-xfs@oss.sgi.com Thu Sep 15 23:26:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 23:26:10 -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 j8G6Q0iL021039 for ; Thu, 15 Sep 2005 23:26:01 -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 QAA03686; Fri, 16 Sep 2005 16:23:14 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 8987349BFB01; Fri, 16 Sep 2005 16:23:14 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 941645 - xfs_db expert mode attr commands Message-Id: <20050916062314.8987349BFB01@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 16:23:14 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6164 X-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: 2850 Lines: 46 Add xfs_db expert mode commands for set/remove of extended attributes. Date: Fri Sep 16 16:22:50 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:23838a xfsprogs/db/attrset.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/attrset.h xfsprogs/db/attrset.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/attrset.c xfsprogs/libxfs/xfs_attr.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_attr.c xfsprogs/db/Makefile - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/Makefile.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/db/command.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/command.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/include/xfs_dir.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/libxfs.h - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h xfsprogs/include/Makefile - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/Makefile.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h xfsprogs/include/xfs_dir2.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/libxfs/rdwr.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/rdwr.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h xfsprogs/libxfs/xfs_da_btree.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_da_btree.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfsprogs/libxfs/xfs.h - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs.h.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h xfsprogs/libxfs/init.c - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/init.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h xfsprogs/libxfs/Makefile - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/Makefile.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/libxfs/xfs_attr_leaf.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_attr_leaf.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/libxfs/util.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/util.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/libxfs/xfs_bmap.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_bmap.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h From owner-linux-xfs@oss.sgi.com Thu Sep 15 23:32:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 23:33:07 -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 j8G6WviL021804 for ; Thu, 15 Sep 2005 23:32:58 -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 QAA03854; Fri, 16 Sep 2005 16:30:11 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 7FD8C49BFB01; Fri, 16 Sep 2005 16:30:10 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 941645 - attr2 userspace support Message-Id: <20050916063010.7FD8C49BFB01@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 16:30:10 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6165 X-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: 2884 Lines: 44 Support for updated inline extended attributes format (attr2). Date: Fri Sep 16 16:29:52 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:23839a xfsprogs/db/sb.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/sb.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/mkfs/maxtrres.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/maxtrres.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/xfs_sb.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_sb.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/include/xfs_fs.h - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_fs.h.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h xfsprogs/include/libxfs.h - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h xfsprogs/include/xfs_attr_leaf.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_attr_leaf.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/include/xfs_types.h - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_types.h.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h xfsprogs/include/xfs_bmap.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_bmap.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/repair/dinode.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/dinode.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsprogs/libxfs/xfs.h - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h xfsprogs/libxfs/xfs_dir.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/libxfs/xfs_mount.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_mount.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h xfsprogs/libxfs/xfs_attr_leaf.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_attr_leaf.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/libxfs/xfs_bmap.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_bmap.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfsprogs/libxfs/xfs_alloc_btree.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_alloc_btree.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/libxfs/xfs_attr.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_attr.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs@oss.sgi.com Thu Sep 15 23:37:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 23:37: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 j8G6bniL022472 for ; Thu, 15 Sep 2005 23:37:50 -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 QAA03966; Fri, 16 Sep 2005 16:35:04 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 6745849BFB03; Fri, 16 Sep 2005 16:35:04 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 942528 - userspace quota id sign fixes Message-Id: <20050916063504.6745849BFB03@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 16:35:04 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6166 X-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: 18 Resolve quota-related uid/gid signedness issues in userspace tools. Date: Fri Sep 16 16:34:41 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:23841a xfsprogs/db/dquot.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/dquot.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/db/check.c - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/check.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h xfsprogs/include/xfs_quota.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_quota.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h From owner-linux-xfs@oss.sgi.com Thu Sep 15 23:41:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Sep 2005 23:41:59 -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 j8G6fliL023128 for ; Thu, 15 Sep 2005 23:41:48 -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 QAA04036 for ; Fri, 16 Sep 2005 16:39:06 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 2EBFE49BFB01; Fri, 16 Sep 2005 16:39:06 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - bump xfsprogs version Message-Id: <20050916063906.2EBFE49BFB01@chook.melbourne.sgi.com> Date: Fri, 16 Sep 2005 16:39:06 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6167 X-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: 749 Lines: 18 Update xfsprogs version to 2.7.0. Date: Fri Sep 16 16:38:53 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:23842a xfsprogs/VERSION - 1.132 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h xfsprogs/doc/CHANGES - 1.176 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.176&r2=text&tr2=1.175&f=h xfsprogs/debian/changelog - 1.119 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.119&r2=text&tr2=1.118&f=h From owner-linux-xfs@oss.sgi.com Fri Sep 16 01:56:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Sep 2005 01:56:32 -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 j8G8uSiL006577 for ; Fri, 16 Sep 2005 01:56:29 -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 j8G8rR1A026367 for ; Fri, 16 Sep 2005 04:53:27 -0400 X-ORBL: [67.124.117.85] Received: from stupidest.org (adsl-67-124-117-85.dsl.snfc21.pacbell.net [67.124.117.85]) by pimout3-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j8G8rcLL134834; Fri, 16 Sep 2005 04:53:38 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id BC90B528F26; Fri, 16 Sep 2005 01:53:37 -0700 (PDT) Date: Fri, 16 Sep 2005 01:53:37 -0700 From: Chris Wedgwood To: Ruben Rubio Rey Cc: linux-xfs@oss.sgi.com Subject: Re: XFS problem Message-ID: <20050916085337.GA15123@taniwha.stupidest.org> References: <432975BA.2080907@rentalia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432975BA.2080907@rentalia.com> X-archive-position: 6168 X-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: 533 Lines: 13 On Thu, Sep 15, 2005 at 03:23:06PM +0200, Ruben Rubio Rey wrote: > Sep 13 08:39:34 txori kernel: perl5.8.5: page allocation failure. > order:4, mode:0x50 if this is reproducable i would strace perl when it's doing whatever causes this and see if it is related to a single file or group of files then as eric suggested look at those with xfs_bmap -v if they are really badly fragmented (p2p applications tend to so this) then xfs_fsr filename1 [filename2 [...]] should address that assuming your not down to the wire on freespace From owner-linux-xfs@oss.sgi.com Fri Sep 16 04:16:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Sep 2005 04:17:03 -0700 (PDT) Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8GBGtiL016676 for ; Fri, 16 Sep 2005 04:16:55 -0700 Received: (qmail 15455 invoked by uid 514); 16 Sep 2005 13:14:14 +0200 Received: from 62.37.217.2 by txori (envelope-from , uid 513) with qmail-scanner-1.25-st-qms (clamdscan: 0.86.1/974. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.217.2):SA:0(-2.2/5.0):. Processed in 0.436648 secs); 16 Sep 2005 11:14:14 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via txori X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.217.2):SA:0(-2.2/5.0):. Processed in 0.436648 secs Process 15446) Received: from 62-37-217-2.mad1.adsl.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.217.2) by mail.rentalia.net with SMTP; 16 Sep 2005 13:14:13 +0200 Message-ID: <432AA8FF.4080809@rentalia.com> Date: Fri, 16 Sep 2005 13:14:07 +0200 From: Ruben Rubio Rey User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6169 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: linux-xfs Content-Length: 787 Lines: 22 There is not p2p ... its web + mail server. The error is not reproducable (its on random days at random hours) :( At the moment,i m trying to find the what file is (its hard) ... But im going to prepare another server in order to move all information and run xfs_repair and xfs_fsr commands. That shoud fix it... > Sep 13 08:39:34 txori kernel: perl5.8.5: page allocation failure. > order:4, mode:0x50 if this is reproducable i would strace perl when it's doing whatever causes this and see if it is related to a single file or group of files then as eric suggested look at those with xfs_bmap -v if they are really badly fragmented (p2p applications tend to so this) then xfs_fsr filename1 [filename2 [...]] should address that assuming your not down to the wire on freespace From owner-linux-xfs@oss.sgi.com Fri Sep 16 14:22:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Sep 2005 14:22:50 -0700 (PDT) Received: from raad.intranet ([212.76.85.247]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8GLMaiL012116 for ; Fri, 16 Sep 2005 14:22:42 -0700 Received: from localhost (ws3.intranet [10.0.0.3]) by raad.intranet (8.8.7/8.8.7) with ESMTP id AAA01821; Sat, 17 Sep 2005 00:19:25 +0300 From: Al Boldi To: linux-fsdevel@vger.kernel.org Subject: Re: Good, recent FS comparison? Date: Sat, 17 Sep 2005 00:17:08 +0300 User-Agent: KMail/1.5 Cc: Linux RAID Mailing List , linux-xfs@oss.sgi.com References: <6d5bedd8050915131148b8108a@mail.gmail.com> <432A37BF.7060305@dtbb.net> In-Reply-To: <432A37BF.7060305@dtbb.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200509162258.37730.a1426z@gawab.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 6172 X-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: 1036 Lines: 25 Tyler wrote: > Ewan Grantham wrote: > >I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was > >prepared to follow my normal pattern of installing ext3 as the > >filesystem. However, I saw the interview with Hans Reiser about > >ReiserFS4, and am now wondering if reiser has really improved enough > >to use it, or if ext3 is still the way to go? > > You'd be best off trying some tests of your own, using files of the size > and quantity you expect to use on a regular basis. I would consider > ext3, xfs, and reiser3/4... and run some tests with them. We've had > really good luck using XFS on large raids, I personally had a bad > experience with reiserfs 3, it lost data on a USB based drive, as if it > were never even there, even after trying the recovery tools. Don't touch anything that doesn't do ordered-mode journaling, especially if you use raid, unless your data-consistency requirements don't require this. XFS is best, but does not support ordered-mode. reiser4 is still new. ext3 is rock-solid! -- Al From owner-linux-xfs@oss.sgi.com Sun Sep 18 02:16:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 18 Sep 2005 02:16:15 -0700 (PDT) Received: from smtp-01.primus.ca (mail.tor.primus.ca [216.254.136.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8I9G6iL023284 for ; Sun, 18 Sep 2005 02:16:09 -0700 Received: from [216.86.99.21] (helo=[192.168.0.28]) by smtp-01.primus.ca with esmtpa (Exim 4.50) id 1EGvEg-0001rg-5t; Sun, 18 Sep 2005 05:13:23 -0400 Received: from 127.0.0.1 (AVG SMTP 7.0.344 [267.11.1]); Sun, 18 Sep 2005 02:15:16 -0700 Message-ID: <432D3024.3080302@dtbb.net> Date: Sun, 18 Sep 2005 02:15:16 -0700 From: Tyler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en To: Al Boldi CC: linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com Subject: Re: Good, recent FS comparison? References: <6d5bedd8050915131148b8108a@mail.gmail.com> <432A37BF.7060305@dtbb.net> <200509162258.37730.a1426z@gawab.com> In-Reply-To: <200509162258.37730.a1426z@gawab.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 6177 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pml@dtbb.net Precedence: bulk X-list: linux-xfs Content-Length: 1642 Lines: 54 Al Boldi wrote: >Tyler wrote: > > >>Ewan Grantham wrote: >> >> >>>I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was >>>prepared to follow my normal pattern of installing ext3 as the >>>filesystem. However, I saw the interview with Hans Reiser about >>>ReiserFS4, and am now wondering if reiser has really improved enough >>>to use it, or if ext3 is still the way to go? >>> >>> >>You'd be best off trying some tests of your own, using files of the size >>and quantity you expect to use on a regular basis. I would consider >>ext3, xfs, and reiser3/4... and run some tests with them. We've had >>really good luck using XFS on large raids, I personally had a bad >>experience with reiserfs 3, it lost data on a USB based drive, as if it >>were never even there, even after trying the recovery tools. >> >> > >Don't touch anything that doesn't do ordered-mode journaling, especially if >you use raid, unless your data-consistency requirements don't require this. > >XFS is best, but does not support ordered-mode. >reiser4 is still new. >ext3 is rock-solid! > >-- >Al > >- >To unsubscribe from this list: send the line "unsubscribe linux-raid" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html > > Al... you've given us some "do's" .. can you give us some "why's" to go along with them? :) I would appreciate a run-down with some more specific info as to what/why. Thanks, Tyler. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.1/104 - Release Date: 9/16/2005 From owner-linux-xfs@oss.sgi.com Sun Sep 18 04:32:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 18 Sep 2005 04:32:41 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8IBWWiL003336 for ; Sun, 18 Sep 2005 04:32:32 -0700 Received: by zproxy.gmail.com with SMTP id r28so6136nza for ; Sun, 18 Sep 2005 04:29:49 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AtM6DNeZz2AwunmIt9um9rAhENJL+cQ0WTu43vsvfCPkN55roELCiNxbwDKvM2uuzhnMUpdLUFL7mehnjphXOLQK4goRxDKnFoaCjTGuQ4vyDUcRfhOIWQD6sGHoDK1JQ/IkgMNbCv7v9OPHaa+Tl2U08bO5zoNKjJU1s2TVgpk= Received: by 10.54.37.21 with SMTP id k21mr514754wrk; Sun, 18 Sep 2005 04:29:49 -0700 (PDT) Received: by 10.54.122.11 with HTTP; Sun, 18 Sep 2005 04:29:49 -0700 (PDT) Message-ID: <5d96567b05091804291a451796@mail.gmail.com> Date: Sun, 18 Sep 2005 14:29:49 +0300 From: "Raz Ben-Jehuda(caro)" Reply-To: raziebe@gmail.com To: Tyler Subject: Re: Good, recent FS comparison? Cc: Al Boldi , linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com In-Reply-To: <432D3024.3080302@dtbb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6d5bedd8050915131148b8108a@mail.gmail.com> <432A37BF.7060305@dtbb.net> <200509162258.37730.a1426z@gawab.com> <432D3024.3080302@dtbb.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8IBWXiL003338 X-archive-position: 6178 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 2032 Lines: 67 what is ordered mode that xfs doesn't support ? On 9/18/05, Tyler wrote: > > Al Boldi wrote: > > >Tyler wrote: > > > > > >>Ewan Grantham wrote: > >> > >> > >>>I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was > >>>prepared to follow my normal pattern of installing ext3 as the > >>>filesystem. However, I saw the interview with Hans Reiser about > >>>ReiserFS4, and am now wondering if reiser has really improved enough > >>>to use it, or if ext3 is still the way to go? > >>> > >>> > >>You'd be best off trying some tests of your own, using files of the size > >>and quantity you expect to use on a regular basis. I would consider > >>ext3, xfs, and reiser3/4... and run some tests with them. We've had > >>really good luck using XFS on large raids, I personally had a bad > >>experience with reiserfs 3, it lost data on a USB based drive, as if it > >>were never even there, even after trying the recovery tools. > >> > >> > > > >Don't touch anything that doesn't do ordered-mode journaling, especially if > >you use raid, unless your data-consistency requirements don't require this. > > > >XFS is best, but does not support ordered-mode. > >reiser4 is still new. > >ext3 is rock-solid! > > > >-- > >Al > > > >- > >To unsubscribe from this list: send the line "unsubscribe linux-raid" in > >the body of a message to majordomo@vger.kernel.org > >More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > Al... you've given us some "do's" .. can you give us some "why's" to go > along with them? :) I would appreciate a run-down with some more > specific info as to what/why. > > Thanks, > Tyler. > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.344 / Virus Database: 267.11.1/104 - Release Date: 9/16/2005 > > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Raz From owner-linux-xfs@oss.sgi.com Sun Sep 18 09:37:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 18 Sep 2005 09:37:23 -0700 (PDT) Received: from mx1.cc.ksu.edu (mx1.cc.ksu.edu [129.130.12.165]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8IGbFiL027285 for ; Sun, 18 Sep 2005 09:37:15 -0700 Received: from unix2.cc.ksu.edu (unix2.cc.ksu.edu [129.130.12.4]) by mx1.cc.ksu.edu (8.12.11/8.12.11) with ESMTP id j8IGY9Fl025260; Sun, 18 Sep 2005 11:34:09 -0500 (CDT) Received: from localhost (matts@localhost) by unix2.cc.ksu.edu (8.11.6+Sun/8.11.6) with ESMTP id j8IGY3O13969; Sun, 18 Sep 2005 11:34:07 -0500 (CDT) X-Authentication-Warning: unix2.cc.ksu.edu: matts owned process doing -bs Date: Sun, 18 Sep 2005 11:34:02 -0500 (CDT) From: Matt Stegman X-X-Sender: matts@unix2.cc.ksu.edu To: Tyler cc: Al Boldi , , Linux RAID Mailing List , Subject: Re: Good, recent FS comparison? In-Reply-To: <432D3024.3080302@dtbb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6179 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matts@ksu.edu Precedence: bulk X-list: linux-xfs Content-Length: 1250 Lines: 34 This has been discussed on the mailing list before. Quick rundown: "Ordered mode" means that a file's metadata isn't written until after the file's data. On XFS, which doesn't use ordered mode, under certain circumstances you may see files which are the correct size, with correct times, etc, but with only null bytes for the data. In my experience it's not that big a deal; I can almost always easily recreate data which could be lost by being written out just before a crash or power loss. I put important systems on an UPS and use stable kernels, and I've never personally seen the null data problem. Currently, I believe only ext3 and reiserfs support ordered mode. I'm not sure if reiser4's journaling is ordered or not. -- Matt Stegman On Sun, 18 Sep 2005, Tyler wrote: > > Al Boldi wrote: > > >Don't touch anything that doesn't do ordered-mode journaling, especially if > >you use raid, unless your data-consistency requirements don't require this. > > > >XFS is best, but does not support ordered-mode. > >reiser4 is still new. > >ext3 is rock-solid! > > > > Al... you've given us some "do's" .. can you give us some "why's" to go > along with them? :) I would appreciate a run-down with some more > specific info as to what/why. From owner-linux-xfs@oss.sgi.com Sun Sep 18 11:57:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 18 Sep 2005 11:57:19 -0700 (PDT) Received: from imo-m28.mx.aol.com (imo-m28.mx.aol.com [64.12.137.9]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8IIuxiL007113 for ; Sun, 18 Sep 2005 11:57:11 -0700 Received: from AndyLiebman@aol.com by imo-m28.mx.aol.com (mail_out_v38_r5.5.) id 4.77.4de7d03f (4238) for ; Sun, 18 Sep 2005 14:54:11 -0400 (EDT) From: AndyLiebman@aol.com Message-ID: <77.4de7d03f.305f11d3@aol.com> Date: Sun, 18 Sep 2005 14:54:11 EDT Subject: XFS filesystem died Looking for Help To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 Security Edition for Windows sub 2340 X-archive-position: 6180 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 42553 Lines: 887 To the xfs list: I would be gateful if somebody who is knowledgeable about using XFS_REPAIR could give me a phone call. I will be happy to phone you back immediately. Today's date is September 18, 2005. It is 2:15 pm in Boston, Massachusetts -- USA. I can be reached at +1 617-906-5534 I have an 8.6 TB XFS filesystem that will no longer mount. Running xfs_repair with the -n flag suggests that I will lose some 60,000 files during the recovery process. I understand that the "-n" flag doesn't let xfs actually repair anything, so the situation may not be as bad as it looks. But I want to be very conservative in taking actions -- so as not to make the situation worse. I cannot mount the filesystem at all at this point. See below for /var/log/messages output and output of xfs_repair -n. I have tried to mount the filesystem "read only" and that did not succeed. I got an "unknown error 990" message. In a little while, I am going to try to mount the file system with "mount -t xfs -o,ro,norecovery" to see if that works. If I can see my data, I will copy the most important files to a backup RAID (but we're talking about almost 8 TB of data so backup isn't all that feasible -- except on another large storage system). The files are video clips from video tapes, so they can be recaptured over the course of the next week. But obviously it would be best to recover the files -- at least as many as possible. At some point today or tomorrow I need to attempt to use "xfs_repair" for real. I do not pretend to understand the many options for running "xfs_repair" (for instance, using the "-L" flag to destroy what may be a corrupted journal). I am hoping to speak with someone who really understands xfs_repair and who can help me do the right thing. Thanks for your attention. Andy Liebman Sep 18 06:30:02 localhost kernel: SGI XFS with ACLs, large block numbers, no debug enabled Sep 18 06:30:02 localhost kernel: SGI XFS Quota Management subsystem Sep 18 06:30:02 localhost kernel: XFS mounting filesystem md0 Sep 18 06:30:02 localhost kernel: Starting XFS recovery on filesystem: md0 (dev: md0) Sep 18 06:30:03 localhost kernel: Filesystem "md0": xfs_inode_recover: Bad inode magic number, dino ptr = 0xf589c000, dino bp = 0xf5e88d80, ino = 1024 Sep 18 06:30:03 localhost kernel: Filesystem "md0": XFS internal error xlog_recover_do_inode_trans(1) at line 2366 of file fs/xfs/xfs_log_recover.c. Caller 0xf8e2bb66 Sep 18 06:30:03 localhost kernel: [dump_stack+30/32] dump_stack+0x1e/0x20 Sep 18 06:30:03 localhost kernel: [] dump_stack+0x1e/0x20 Sep 18 06:30:03 localhost kernel: [pg0+949674680/1069028352] xlog_recover_do_inode_trans+0x61d/0xa14 [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949676902/1069028352] xlog_recover_do_trans+0xee/0x16c [xfs] Sep 18 06:30:03 localhost kernel: [] xlog_recover_do_trans+0xee/0x16c [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949677222/1069028352] xlog_recover_commit_trans+0x39/0x49 [xfs] Sep 18 06:30:03 localhost kernel: [] xlog_recover_commit_trans+0x39/0x49 [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949677645/1069028352] xlog_recover_process_data+0x179/0x216 [xfs] Sep 18 06:30:03 localhost kernel: [] xlog_recover_process_data+0x179/0x216 [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949681414/1069028352] xlog_do_recovery_pass+0x264/0xa66 [xfs] Sep 18 06:30:03 localhost kernel: [] xlog_do_recovery_pass+0x264/0xa66 [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949683614/1069028352] xlog_do_log_recovery+0x96/0xcd [xfs] Sep 18 06:30:03 localhost kernel: [] xlog_do_log_recovery+0x96/0xcd [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949683723/1069028352] xlog_do_recover+0x36/0x167 [xfs] Sep 18 06:30:03 localhost kernel: [] xlog_do_recover+0x36/0x167 [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949684249/1069028352] xlog_recover+0xdd/0xee [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949648021/1069028352] xfs_log_mount+0x99/0x10d [xfs] Sep 18 06:30:03 localhost kernel: [] xfs_log_mount+0x99/0x10d [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949690549/1069028352] xfs_mountfs+0x8b8/0xdb9 [xfs] Sep 18 06:30:03 localhost kernel: [] xfs_mountfs+0x8b8/0xdb9 [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949721052/1069028352] xfs_mount+0x293/0x44e [xfs] Sep 18 06:30:03 localhost kernel: [] xfs_mount+0x293/0x44e [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949801272/1069028352] vfs_mount+0x34/0x36 [xfs] Sep 18 06:30:03 localhost kernel: [] vfs_mount+0x34/0x36 [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949801272/1069028352] vfs_mount+0x34/0x36 [xfs] Sep 18 06:30:03 localhost kernel: [] vfs_mount+0x34/0x36 [xfs] Sep 18 06:30:03 localhost kernel: [pg0+949800828/1069028352] linvfs_fill_super+0xa2/0x1f9 [xfs] Sep 18 06:30:03 localhost kernel: [] linvfs_fill_super+0xa2/0x1f9 [xfs] Sep 18 06:30:03 localhost kernel: [get_sb_bdev+223/326] get_sb_bdev+0xdf/0x146 Sep 18 06:30:03 localhost kernel: [] get_sb_bdev+0xdf/0x146 Sep 18 06:30:03 localhost kernel: [pg0+949801217/1069028352] linvfs_get_sb+0x2e/0x31 [xfs] Sep 18 06:30:03 localhost kernel: [] linvfs_get_sb+0x2e/0x31 [xfs] Sep 18 06:30:03 localhost kernel: [do_kern_mount+94/223] do_kern_mount+0x5e/0xdf Sep 18 06:30:03 localhost kernel: [] do_kern_mount+0x5e/0xdf Sep 18 06:30:03 localhost kernel: [do_new_mount+141/210] do_new_mount+0x8d/0xd2 Sep 18 06:30:03 localhost kernel: [] do_new_mount+0x8d/0xd2 Sep 18 06:30:03 localhost kernel: [do_mount+351/398] do_mount+0x15f/0x18e Sep 18 06:30:03 localhost kernel: [] do_mount+0x15f/0x18e Sep 18 06:30:03 localhost kernel: [sys_mount+151/243] sys_mount+0x97/0xf3 Sep 18 06:30:03 localhost kernel: [] sys_mount+0x97/0xf3 Sep 18 06:30:03 localhost kernel: [sysenter_past_esp+82/117] sysenter_past_esp+0x52/0x75 Sep 18 06:30:03 localhost kernel: [] sysenter_past_esp+0x52/0x75 Sep 18 06:30:03 localhost kernel: XFS: log mount/recovery failed: error 990 Sep 18 06:30:03 localhost kernel: XFS: log mount failed This is the output of xfs_repair -v -n /dev/md0 [root@localhost tmp]# xfs_repair -v -n /dev/md0 Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... bad magic # 0x6aa329ac for agf 0 bad version # -1717446215 for agf 0 bad sequence # -721268204 for agf 0 bad length 219034402 for agf 0, should be 67136832 flfirst 1145126800 in agf 0 too large (max = 128) fllast 395644629 in agf 0 too large (max = 128) would reset bad agf for ag 0 bad uncorrected agheader 0, skipping ag... root inode chunk not found Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 bad magic number 0x2436 on inode 1024 bad version number 0x22 on inode 1024 bad (negative) size -788050656964214279 on inode 1024 bad magic number 0x0 on inode 1025 bad version number 0x0 on inode 1025 bad (negative) size -1960603558521597416 on inode 1025 bad magic number 0x9327 on inode 1026 bad version number 0x41 on inode 1026 bad (negative) size -3472137684348818111 on inode 1026 bad magic number 0xc4de on inode 1027 bad version number 0xffffffc1 on inode 1027 bad (negative) size -2130840477456551144 on inode 1027 bad magic number 0x4003 on inode 1028 bad version number 0xc on inode 1028 bad inode format in inode 1028 bad magic number 0xf7f2 on inode 1029 bad version number 0xfffffffe on inode 1029 bad inode format in inode 1029 bad magic number 0x6961 on inode 1030 bad version number 0xffffffe1 on inode 1030 bad (negative) size -7380789008451297772 on inode 1030 bad magic number 0x9327 on inode 1031 bad version number 0x41 on inode 1031 bad (negative) size -8696201346726994109 on inode 1031 bad magic number 0xa49e on inode 1032 bad version number 0xffffffaf on inode 1032 bad (negative) size -2642757456120159323 on inode 1032 bad magic number 0x418e on inode 1033 bad version number 0xffffffc6 on inode 1033 bad (negative) size -8651267474280648990 on inode 1033 bad magic number 0xea9b on inode 1034 bad version number 0xffffffca on inode 1034 bad (negative) size -3932713499750014692 on inode 1034 bad magic number 0x1800 on inode 1035 bad version number 0x0 on inode 1035 bad (negative) size -7906418442983962984 on inode 1035 bad magic number 0x9327 on inode 1036 bad version number 0x41 on inode 1036 bad (negative) size -7466448649638312435 on inode 1036 bad magic number 0xd0f7 on inode 1037 bad version number 0xffffff95 on inode 1037 bad inode format in inode 1037 bad magic number 0x4184 on inode 1038 bad version number 0xffffffa1 on inode 1038 bad (negative) size -9095552344739778464 on inode 1038 bad magic number 0xaff1 on inode 1039 bad version number 0x73 on inode 1039 bad inode format in inode 1039 bad magic number 0xb6e on inode 1040 bad version number 0x11 on inode 1040 bad (negative) size -5298170723441323857 on inode 1040 bad magic number 0x9327 on inode 1041 bad version number 0x41 on inode 1041 bad (negative) size -1366174249712460861 on inode 1041 bad magic number 0xad3c on inode 1042 bad version number 0xffffffff on inode 1042 bad inode format in inode 1042 bad magic number 0x408a on inode 1043 bad version number 0xffffff82 on inode 1043 bad (negative) size -1702045918539022144 on inode 1043 bad magic number 0xe53e on inode 1044 bad version number 0x6e on inode 1044 bad (negative) size -2631521295149829243 on inode 1044 bad magic number 0x0 on inode 1045 bad version number 0x0 on inode 1045 bad magic number 0x9327 on inode 1046 bad version number 0x41 on inode 1046 bad (negative) size -8802099146986797165 on inode 1046 bad magic number 0x52a7 on inode 1047 bad version number 0xffffffe6 on inode 1047 bad (negative) size -5329830732041940903 on inode 1047 bad magic number 0x4002 on inode 1048 bad version number 0x10 on inode 1048 bad (negative) size -8598636382813711820 on inode 1048 bad magic number 0xef5a on inode 1049 bad version number 0xffffffa8 on inode 1049 bad inode format in inode 1049 bad magic number 0x8e96 on inode 1050 bad version number 0x0 on inode 1050 bad magic number 0x9327 on inode 1051 bad version number 0x40 on inode 1051 bad (negative) size -2112454663103904228 on inode 1051 bad magic number 0x0 on inode 1052 bad version number 0xfffffff7 on inode 1052 bad inode format in inode 1052 bad magic number 0x3f81 on inode 1053 bad version number 0xffffffef on inode 1053 bad (negative) size -4187195460867715355 on inode 1053 bad magic number 0x77f8 on inode 1054 bad version number 0x2c on inode 1054 bad (negative) size -2102966023921337306 on inode 1054 bad magic number 0xc078 on inode 1055 bad version number 0x76 on inode 1055 bad inode format in inode 1055 bad magic number 0x9327 on inode 1056 bad version number 0x3f on inode 1056 bad inode format in inode 1056 bad magic number 0x82fa on inode 1057 bad version number 0xffffff91 on inode 1057 bad (negative) size -6412281444445454336 on inode 1057 bad magic number 0x3f04 on inode 1058 bad version number 0xffffff81 on inode 1058 bad magic number 0x7ace on inode 1059 bad version number 0xffffff82 on inode 1059 bad inode format in inode 1059 bad magic number 0x2fb0 on inode 1060 bad version number 0x3d on inode 1060 bad (negative) size -1762423703876559058 on inode 1060 bad magic number 0x9327 on inode 1061 bad version number 0x3e on inode 1061 bad inode format in inode 1061 bad magic number 0x2008 on inode 1062 bad version number 0x12 on inode 1062 bad (negative) size -1 on inode 1062 bad magic number 0xfffe on inode 1063 bad version number 0xffffffff on inode 1063 bad (negative) size -72057594037993473 on inode 1063 bad magic number 0xa33d on inode 1064 bad version number 0x42 on inode 1064 bad (negative) size -2918795080466962986 on inode 1064 bad magic number 0xc160 on inode 1065 bad version number 0x0 on inode 1065 bad (negative) size -4080261262397655296 on inode 1065 bad magic number 0x9337 on inode 1066 bad version number 0xffffffce on inode 1066 bad inode format in inode 1066 bad magic number 0x8961 on inode 1067 bad version number 0x76 on inode 1067 bad inode format in inode 1067 bad magic number 0x2aaf on inode 1068 bad version number 0x7e on inode 1068 bad (negative) size -3301521345761378304 on inode 1068 bad magic number 0xa9b9 on inode 1069 bad version number 0x40 on inode 1069 bad inode format in inode 1069 bad magic number 0xa345 on inode 1070 bad version number 0xffffff8e on inode 1070 bad inode format in inode 1070 bad magic number 0x9337 on inode 1071 bad version number 0xffffffc9 on inode 1071 bad (negative) size -1968915434361906559 on inode 1071 bad magic number 0x7c87 on inode 1072 bad version number 0x65 on inode 1072 bad (negative) size -5283829021148599841 on inode 1072 bad magic number 0x4082 on inode 1073 bad version number 0x40 on inode 1073 bad inode format in inode 1073 bad magic number 0xe5ef on inode 1074 bad version number 0xffffffaf on inode 1074 bad (negative) size -3500512286775403683 on inode 1074 bad magic number 0x44b6 on inode 1075 bad version number 0xffffff8b on inode 1075 bad (negative) size -8659754392112581116 on inode 1075 bad magic number 0x9337 on inode 1076 bad version number 0xffffffcb on inode 1076 bad inode format in inode 1076 bad magic number 0xa757 on inode 1077 bad version number 0x78 on inode 1077 bad (negative) size -3485268153676921960 on inode 1077 bad magic number 0x418a on inode 1078 bad version number 0x1e on inode 1078 bad inode format in inode 1078 bad magic number 0x64cb on inode 1079 bad version number 0xffffffd5 on inode 1079 bad (negative) size -7120277533416900356 on inode 1079 bad magic number 0x0 on inode 1080 bad version number 0x0 on inode 1080 bad (negative) size -8580949382977800829 on inode 1080 bad magic number 0x9337 on inode 1081 bad version number 0xffffffac on inode 1081 bad inode format in inode 1081 bad magic number 0x9702 on inode 1082 bad version number 0x6b on inode 1082 bad inode format in inode 1082 bad magic number 0x4101 on inode 1083 bad version number 0xffffff94 on inode 1083 bad inode format in inode 1083 bad magic number 0xcbc9 on inode 1084 bad version number 0xffffff85 on inode 1084 bad inode format in inode 1084 bad magic number 0xa75c on inode 1085 bad version number 0x3d on inode 1085 bad inode format in inode 1085 bad magic number 0x9337 on inode 1086 bad version number 0xffffffaf on inode 1086 bad (negative) size -8448536876806716733 on inode 1086 bad magic number 0xf704 on inode 1087 bad version number 0xffffffe4 on inode 1087 bad (negative) size -2980672623141970876 on inode 1087 bad magic number 0x2436 on inode 1024, would reset magic number bad version number 0x22 on inode 1024, would reset version number bad (negative) size -788050656964214279 on inode 1024 would clear root inode 1024 bad magic number 0x0 on inode 1025, would reset magic number bad version number 0x0 on inode 1025, would reset version number bad (negative) size -1960603558521597416 on inode 1025 would clear realtime bitmap inode 1025 bad magic number 0x9327 on inode 1026, would reset magic number bad version number 0x41 on inode 1026, would reset version number bad (negative) size -3472137684348818111 on inode 1026 would clear realtime summary inode 1026 bad magic number 0xc4de on inode 1027, would reset magic number bad version number 0xffffffc1 on inode 1027, would reset version number bad (negative) size -2130840477456551144 on inode 1027 would have cleared inode 1027 bad magic number 0x4003 on inode 1028, would reset magic number bad version number 0xc on inode 1028, would reset version number bad inode format in inode 1028 would have cleared inode 1028 bad magic number 0xf7f2 on inode 1029, would reset magic number bad version number 0xfffffffe on inode 1029, would reset version number bad inode format in inode 1029 would have cleared inode 1029 bad magic number 0x6961 on inode 1030, would reset magic number bad version number 0xffffffe1 on inode 1030, would reset version number bad (negative) size -7380789008451297772 on inode 1030 would have cleared inode 1030 bad magic number 0x9327 on inode 1031, would reset magic number bad version number 0x41 on inode 1031, would reset version number bad (negative) size -8696201346726994109 on inode 1031 would have cleared inode 1031 bad magic number 0xa49e on inode 1032, would reset magic number bad version number 0xffffffaf on inode 1032, would reset version number bad (negative) size -2642757456120159323 on inode 1032 would have cleared inode 1032 bad magic number 0x418e on inode 1033, would reset magic number bad version number 0xffffffc6 on inode 1033, would reset version number bad (negative) size -8651267474280648990 on inode 1033 would have cleared inode 1033 bad magic number 0xea9b on inode 1034, would reset magic number bad version number 0xffffffca on inode 1034, would reset version number bad (negative) size -3932713499750014692 on inode 1034 would have cleared inode 1034 bad magic number 0x1800 on inode 1035, would reset magic number bad version number 0x0 on inode 1035, would reset version number bad (negative) size -7906418442983962984 on inode 1035 would have cleared inode 1035 bad magic number 0x9327 on inode 1036, would reset magic number bad version number 0x41 on inode 1036, would reset version number bad (negative) size -7466448649638312435 on inode 1036 would have cleared inode 1036 bad magic number 0xd0f7 on inode 1037, would reset magic number bad version number 0xffffff95 on inode 1037, would reset version number bad inode format in inode 1037 would have cleared inode 1037 bad magic number 0x4184 on inode 1038, would reset magic number bad version number 0xffffffa1 on inode 1038, would reset version number bad (negative) size -9095552344739778464 on inode 1038 would have cleared inode 1038 bad magic number 0xaff1 on inode 1039, would reset magic number bad version number 0x73 on inode 1039, would reset version number bad inode format in inode 1039 would have cleared inode 1039 bad magic number 0xb6e on inode 1040, would reset magic number bad version number 0x11 on inode 1040, would reset version number bad (negative) size -5298170723441323857 on inode 1040 would have cleared inode 1040 bad magic number 0x9327 on inode 1041, would reset magic number bad version number 0x41 on inode 1041, would reset version number bad (negative) size -1366174249712460861 on inode 1041 would have cleared inode 1041 bad magic number 0xad3c on inode 1042, would reset magic number bad version number 0xffffffff on inode 1042, would reset version number bad inode format in inode 1042 would have cleared inode 1042 bad magic number 0x408a on inode 1043, would reset magic number bad version number 0xffffff82 on inode 1043, would reset version number bad (negative) size -1702045918539022144 on inode 1043 would have cleared inode 1043 bad magic number 0xe53e on inode 1044, would reset magic number bad version number 0x6e on inode 1044, would reset version number bad (negative) size -2631521295149829243 on inode 1044 would have cleared inode 1044 bad magic number 0x0 on inode 1045, would reset magic number bad version number 0x0 on inode 1045, would reset version number bad magic number 0x9327 on inode 1046, would reset magic number bad version number 0x41 on inode 1046, would reset version number bad (negative) size -8802099146986797165 on inode 1046 would have cleared inode 1046 bad magic number 0x52a7 on inode 1047, would reset magic number bad version number 0xffffffe6 on inode 1047, would reset version number bad (negative) size -5329830732041940903 on inode 1047 would have cleared inode 1047 bad magic number 0x4002 on inode 1048, would reset magic number bad version number 0x10 on inode 1048, would reset version number bad (negative) size -8598636382813711820 on inode 1048 would have cleared inode 1048 bad magic number 0xef5a on inode 1049, would reset magic number bad version number 0xffffffa8 on inode 1049, would reset version number bad inode format in inode 1049 would have cleared inode 1049 bad magic number 0x8e96 on inode 1050, would reset magic number bad version number 0x0 on inode 1050, would reset version number bad magic number 0x9327 on inode 1051, would reset magic number bad version number 0x40 on inode 1051, would reset version number bad (negative) size -2112454663103904228 on inode 1051 would have cleared inode 1051 bad magic number 0x0 on inode 1052, would reset magic number bad version number 0xfffffff7 on inode 1052, would reset version number bad inode format in inode 1052 would have cleared inode 1052 bad magic number 0x3f81 on inode 1053, would reset magic number bad version number 0xffffffef on inode 1053, would reset version number bad (negative) size -4187195460867715355 on inode 1053 would have cleared inode 1053 bad magic number 0x77f8 on inode 1054, would reset magic number bad version number 0x2c on inode 1054, would reset version number bad (negative) size -2102966023921337306 on inode 1054 would have cleared inode 1054 bad magic number 0xc078 on inode 1055, would reset magic number bad version number 0x76 on inode 1055, would reset version number bad inode format in inode 1055 would have cleared inode 1055 bad magic number 0x9327 on inode 1056, would reset magic number bad version number 0x3f on inode 1056, would reset version number bad inode format in inode 1056 would have cleared inode 1056 bad magic number 0x82fa on inode 1057, would reset magic number bad version number 0xffffff91 on inode 1057, would reset version number bad (negative) size -6412281444445454336 on inode 1057 would have cleared inode 1057 bad magic number 0x3f04 on inode 1058, would reset magic number bad version number 0xffffff81 on inode 1058, would reset version number bad non-zero extent size value 3934249903 for non-realtime inode 1058, would reset to zero size of socket inode 1058 != 0 (1515187944509808892 bytes) would have cleared inode 1058 bad magic number 0x7ace on inode 1059, would reset magic number bad version number 0xffffff82 on inode 1059, would reset version number bad inode format in inode 1059 would have cleared inode 1059 bad magic number 0x2fb0 on inode 1060, would reset magic number bad version number 0x3d on inode 1060, would reset version number bad (negative) size -1762423703876559058 on inode 1060 would have cleared inode 1060 bad magic number 0x9327 on inode 1061, would reset magic number bad version number 0x3e on inode 1061, would reset version number bad inode format in inode 1061 would have cleared inode 1061 bad magic number 0x2008 on inode 1062, would reset magic number bad version number 0x12 on inode 1062, would reset version number bad (negative) size -1 on inode 1062 would have cleared inode 1062 bad magic number 0xfffe on inode 1063, would reset magic number bad version number 0xffffffff on inode 1063, would reset version number bad (negative) size -72057594037993473 on inode 1063 would have cleared inode 1063 bad magic number 0xa33d on inode 1064, would reset magic number bad version number 0x42 on inode 1064, would reset version number bad (negative) size -2918795080466962986 on inode 1064 would have cleared inode 1064 bad magic number 0xc160 on inode 1065, would reset magic number bad version number 0x0 on inode 1065, would reset version number bad (negative) size -4080261262397655296 on inode 1065 would have cleared inode 1065 bad magic number 0x9337 on inode 1066, would reset magic number bad version number 0xffffffce on inode 1066, would reset version number bad inode format in inode 1066 would have cleared inode 1066 bad magic number 0x8961 on inode 1067, would reset magic number bad version number 0x76 on inode 1067, would reset version number bad inode format in inode 1067 would have cleared inode 1067 bad magic number 0x2aaf on inode 1068, would reset magic number bad version number 0x7e on inode 1068, would reset version number bad (negative) size -3301521345761378304 on inode 1068 would have cleared inode 1068 bad magic number 0xa9b9 on inode 1069, would reset magic number bad version number 0x40 on inode 1069, would reset version number bad inode format in inode 1069 would have cleared inode 1069 bad magic number 0xa345 on inode 1070, would reset magic number bad version number 0xffffff8e on inode 1070, would reset version number bad inode format in inode 1070 would have cleared inode 1070 bad magic number 0x9337 on inode 1071, would reset magic number bad version number 0xffffffc9 on inode 1071, would reset version number bad (negative) size -1968915434361906559 on inode 1071 would have cleared inode 1071 bad magic number 0x7c87 on inode 1072, would reset magic number bad version number 0x65 on inode 1072, would reset version number bad (negative) size -5283829021148599841 on inode 1072 would have cleared inode 1072 bad magic number 0x4082 on inode 1073, would reset magic number bad version number 0x40 on inode 1073, would reset version number bad inode format in inode 1073 would have cleared inode 1073 bad magic number 0xe5ef on inode 1074, would reset magic number bad version number 0xffffffaf on inode 1074, would reset version number bad (negative) size -3500512286775403683 on inode 1074 would have cleared inode 1074 bad magic number 0x44b6 on inode 1075, would reset magic number bad version number 0xffffff8b on inode 1075, would reset version number bad (negative) size -8659754392112581116 on inode 1075 would have cleared inode 1075 bad magic number 0x9337 on inode 1076, would reset magic number bad version number 0xffffffcb on inode 1076, would reset version number bad inode format in inode 1076 would have cleared inode 1076 bad magic number 0xa757 on inode 1077, would reset magic number bad version number 0x78 on inode 1077, would reset version number bad (negative) size -3485268153676921960 on inode 1077 would have cleared inode 1077 bad magic number 0x418a on inode 1078, would reset magic number bad version number 0x1e on inode 1078, would reset version number bad inode format in inode 1078 would have cleared inode 1078 bad magic number 0x64cb on inode 1079, would reset magic number bad version number 0xffffffd5 on inode 1079, would reset version number bad (negative) size -7120277533416900356 on inode 1079 would have cleared inode 1079 bad magic number 0x0 on inode 1080, would reset magic number bad version number 0x0 on inode 1080, would reset version number bad (negative) size -8580949382977800829 on inode 1080 would have cleared inode 1080 bad magic number 0x9337 on inode 1081, would reset magic number bad version number 0xffffffac on inode 1081, would reset version number bad inode format in inode 1081 would have cleared inode 1081 bad magic number 0x9702 on inode 1082, would reset magic number bad version number 0x6b on inode 1082, would reset version number bad inode format in inode 1082 would have cleared inode 1082 bad magic number 0x4101 on inode 1083, would reset magic number bad version number 0xffffff94 on inode 1083, would reset version number bad inode format in inode 1083 would have cleared inode 1083 bad magic number 0xcbc9 on inode 1084, would reset magic number bad version number 0xffffff85 on inode 1084, would reset version number bad inode format in inode 1084 would have cleared inode 1084 bad magic number 0xa75c on inode 1085, would reset magic number bad version number 0x3d on inode 1085, would reset version number bad inode format in inode 1085 would have cleared inode 1085 bad magic number 0x9337 on inode 1086, would reset magic number bad version number 0xffffffaf on inode 1086, would reset version number bad (negative) size -8448536876806716733 on inode 1086 would have cleared inode 1086 bad magic number 0xf704 on inode 1087, would reset magic number bad version number 0xffffffe4 on inode 1087, would reset version number bad (negative) size -2980672623141970876 on inode 1087 would have cleared inode 1087 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... root inode would be lost - check for inodes claiming duplicate blocks... - agno = 0 bad magic number 0x2436 on inode 1024, would reset magic number bad version number 0x22 on inode 1024, would reset version number bad (negative) size -788050656964214279 on inode 1024 would clear root inode 1024 bad magic number 0x0 on inode 1025, would reset magic number bad version number 0x0 on inode 1025, would reset version number bad (negative) size -1960603558521597416 on inode 1025 would clear realtime bitmap inode 1025 bad magic number 0x9327 on inode 1026, would reset magic number bad version number 0x41 on inode 1026, would reset version number bad (negative) size -3472137684348818111 on inode 1026 would clear realtime summary inode 1026 bad magic number 0xc4de on inode 1027, would reset magic number bad version number 0xffffffc1 on inode 1027, would reset version number bad (negative) size -2130840477456551144 on inode 1027 would have cleared inode 1027 bad magic number 0x4003 on inode 1028, would reset magic number bad version number 0xc on inode 1028, would reset version number bad inode format in inode 1028 would have cleared inode 1028 bad magic number 0xf7f2 on inode 1029, would reset magic number bad version number 0xfffffffe on inode 1029, would reset version number bad inode format in inode 1029 would have cleared inode 1029 bad magic number 0x6961 on inode 1030, would reset magic number bad version number 0xffffffe1 on inode 1030, would reset version number bad (negative) size -7380789008451297772 on inode 1030 would have cleared inode 1030 bad magic number 0x9327 on inode 1031, would reset magic number bad version number 0x41 on inode 1031, would reset version number bad (negative) size -8696201346726994109 on inode 1031 would have cleared inode 1031 bad magic number 0xa49e on inode 1032, would reset magic number bad version number 0xffffffaf on inode 1032, would reset version number bad (negative) size -2642757456120159323 on inode 1032 would have cleared inode 1032 bad magic number 0x418e on inode 1033, would reset magic number bad version number 0xffffffc6 on inode 1033, would reset version number bad (negative) size -8651267474280648990 on inode 1033 would have cleared inode 1033 bad magic number 0xea9b on inode 1034, would reset magic number bad version number 0xffffffca on inode 1034, would reset version number bad (negative) size -3932713499750014692 on inode 1034 would have cleared inode 1034 bad magic number 0x1800 on inode 1035, would reset magic number bad version number 0x0 on inode 1035, would reset version number bad (negative) size -7906418442983962984 on inode 1035 would have cleared inode 1035 bad magic number 0x9327 on inode 1036, would reset magic number bad version number 0x41 on inode 1036, would reset version number bad (negative) size -7466448649638312435 on inode 1036 would have cleared inode 1036 bad magic number 0xd0f7 on inode 1037, would reset magic number bad version number 0xffffff95 on inode 1037, would reset version number bad inode format in inode 1037 would have cleared inode 1037 bad magic number 0x4184 on inode 1038, would reset magic number bad version number 0xffffffa1 on inode 1038, would reset version number bad (negative) size -9095552344739778464 on inode 1038 would have cleared inode 1038 bad magic number 0xaff1 on inode 1039, would reset magic number bad version number 0x73 on inode 1039, would reset version number bad inode format in inode 1039 would have cleared inode 1039 bad magic number 0xb6e on inode 1040, would reset magic number bad version number 0x11 on inode 1040, would reset version number bad (negative) size -5298170723441323857 on inode 1040 would have cleared inode 1040 bad magic number 0x9327 on inode 1041, would reset magic number bad version number 0x41 on inode 1041, would reset version number bad (negative) size -1366174249712460861 on inode 1041 would have cleared inode 1041 bad magic number 0xad3c on inode 1042, would reset magic number bad version number 0xffffffff on inode 1042, would reset version number bad inode format in inode 1042 would have cleared inode 1042 bad magic number 0x408a on inode 1043, would reset magic number bad version number 0xffffff82 on inode 1043, would reset version number bad (negative) size -1702045918539022144 on inode 1043 would have cleared inode 1043 bad magic number 0xe53e on inode 1044, would reset magic number bad version number 0x6e on inode 1044, would reset version number bad (negative) size -2631521295149829243 on inode 1044 would have cleared inode 1044 bad magic number 0x0 on inode 1045, would reset magic number bad version number 0x0 on inode 1045, would reset version number bad magic number 0x9327 on inode 1046, would reset magic number bad version number 0x41 on inode 1046, would reset version number bad (negative) size -8802099146986797165 on inode 1046 would have cleared inode 1046 bad magic number 0x52a7 on inode 1047, would reset magic number bad version number 0xffffffe6 on inode 1047, would reset version number bad (negative) size -5329830732041940903 on inode 1047 would have cleared inode 1047 bad magic number 0x4002 on inode 1048, would reset magic number bad version number 0x10 on inode 1048, would reset version number bad (negative) size -8598636382813711820 on inode 1048 would have cleared inode 1048 bad magic number 0xef5a on inode 1049, would reset magic number bad version number 0xffffffa8 on inode 1049, would reset version number bad inode format in inode 1049 would have cleared inode 1049 bad magic number 0x8e96 on inode 1050, would reset magic number bad version number 0x0 on inode 1050, would reset version number bad magic number 0x9327 on inode 1051, would reset magic number bad version number 0x40 on inode 1051, would reset version number bad (negative) size -2112454663103904228 on inode 1051 would have cleared inode 1051 bad magic number 0x0 on inode 1052, would reset magic number bad version number 0xfffffff7 on inode 1052, would reset version number bad inode format in inode 1052 would have cleared inode 1052 bad magic number 0x3f81 on inode 1053, would reset magic number bad version number 0xffffffef on inode 1053, would reset version number bad (negative) size -4187195460867715355 on inode 1053 would have cleared inode 1053 bad magic number 0x77f8 on inode 1054, would reset magic number bad version number 0x2c on inode 1054, would reset version number bad (negative) size -2102966023921337306 on inode 1054 would have cleared inode 1054 bad magic number 0xc078 on inode 1055, would reset magic number bad version number 0x76 on inode 1055, would reset version number bad inode format in inode 1055 would have cleared inode 1055 bad magic number 0x9327 on inode 1056, would reset magic number bad version number 0x3f on inode 1056, would reset version number bad inode format in inode 1056 would have cleared inode 1056 bad magic number 0x82fa on inode 1057, would reset magic number bad version number 0xffffff91 on inode 1057, would reset version number bad (negative) size -6412281444445454336 on inode 1057 would have cleared inode 1057 bad magic number 0x3f04 on inode 1058, would reset magic number bad version number 0xffffff81 on inode 1058, would reset version number bad non-zero extent size value 3934249903 for non-realtime inode 1058, would reset to zero size of socket inode 1058 != 0 (1515187944509808892 bytes) would have cleared inode 1058 bad magic number 0x7ace on inode 1059, would reset magic number bad version number 0xffffff82 on inode 1059, would reset version number bad inode format in inode 1059 would have cleared inode 1059 bad magic number 0x2fb0 on inode 1060, would reset magic number bad version number 0x3d on inode 1060, would reset version number bad (negative) size -1762423703876559058 on inode 1060 would have cleared inode 1060 bad magic number 0x9327 on inode 1061, would reset magic number bad version number 0x3e on inode 1061, would reset version number bad inode format in inode 1061 would have cleared inode 1061 bad magic number 0x2008 on inode 1062, would reset magic number bad version number 0x12 on inode 1062, would reset version number bad (negative) size -1 on inode 1062 would have cleared inode 1062 bad magic number 0xfffe on inode 1063, would reset magic number bad version number 0xffffffff on inode 1063, would reset version number bad (negative) size -72057594037993473 on inode 1063 would have cleared inode 1063 bad magic number 0xa33d on inode 1064, would reset magic number bad version number 0x42 on inode 1064, would reset version number bad (negative) size -2918795080466962986 on inode 1064 would have cleared inode 1064 bad magic number 0xc160 on inode 1065, would reset magic number bad version number 0x0 on inode 1065, would reset version number bad (negative) size -4080261262397655296 on inode 1065 would have cleared inode 1065 bad magic number 0x9337 on inode 1066, would reset magic number bad version number 0xffffffce on inode 1066, would reset version number bad inode format in inode 1066 would have cleared inode 1066 bad magic number 0x8961 on inode 1067, would reset magic number bad version number 0x76 on inode 1067, would reset version number bad inode format in inode 1067 would have cleared inode 1067 bad magic number 0x2aaf on inode 1068, would reset magic number bad version number 0x7e on inode 1068, would reset version number bad (negative) size -3301521345761378304 on inode 1068 would have cleared inode 1068 bad magic number 0xa9b9 on inode 1069, would reset magic number bad version number 0x40 on inode 1069, would reset version number bad inode format in inode 1069 would have cleared inode 1069 bad magic number 0xa345 on inode 1070, would reset magic number bad version number 0xffffff8e on inode 1070, would reset version number bad inode format in inode 1070 would have cleared inode 1070 bad magic number 0x9337 on inode 1071, would reset magic number bad version number 0xffffffc9 on inode 1071, would reset version number bad (negative) size -1968915434361906559 on inode 1071 would have cleared inode 1071 bad magic number 0x7c87 on inode 1072, would reset magic number bad version number 0x65 on inode 1072, would reset version number bad (negative) size -5283829021148599841 on inode 1072 would have cleared inode 1072 bad magic number 0x4082 on inode 1073, would reset magic number bad version number 0x40 on inode 1073, would reset version number bad inode format in inode 1073 would have cleared inode 1073 bad magic number 0xe5ef on inode 1074, would reset magic number bad version number 0xffffffaf on inode 1074, would reset version number bad (negative) size -3500512286775403683 on inode 1074 would have cleared inode 1074 bad magic number 0x44b6 on inode 1075, would reset magic number bad version number 0xffffff8b on inode 1075, would reset version number bad (negative) size -8659754392112581116 on inode 1075 would have cleared inode 1075 bad magic number 0x9337 on inode 1076, would reset magic number bad version number 0xffffffcb on inode 1076, would reset version number bad inode format in inode 1076 would have cleared inode 1076 bad magic number 0xa757 on inode 1077, would reset magic number bad version number 0x78 on inode 1077, would reset version number bad (negative) size -3485268153676921960 on inode 1077 would have cleared inode 1077 bad magic number 0x418a on inode 1078, would reset magic number bad version number 0x1e on inode 1078, would reset version number bad inode format in inode 1078 would have cleared inode 1078 bad magic number 0x64cb on inode 1079, would reset magic number bad version number 0xffffffd5 on inode 1079, would reset version number bad (negative) size -7120277533416900356 on inode 1079 would have cleared inode 1079 bad magic number 0x0 on inode 1080, would reset magic number bad version number 0x0 on inode 1080, would reset version number bad (negative) size -8580949382977800829 on inode 1080 would have cleared inode 1080 bad magic number 0x9337 on inode 1081, would reset magic number bad version number 0xffffffac on inode 1081, would reset version number bad inode format in inode 1081 would have cleared inode 1081 bad magic number 0x9702 on inode 1082, would reset magic number bad version number 0x6b on inode 1082, would reset version number bad inode format in inode 1082 would have cleared inode 1082 bad magic number 0x4101 on inode 1083, would reset magic number bad version number 0xffffff94 on inode 1083, would reset version number bad inode format in inode 1083 would have cleared inode 1083 bad magic number 0xcbc9 on inode 1084, would reset magic number bad version number 0xffffff85 on inode 1084, would reset version number bad inode format in inode 1084 would have cleared inode 1084 bad magic number 0xa75c on inode 1085, would reset magic number bad version number 0x3d on inode 1085, would reset version number bad inode format in inode 1085 would have cleared inode 1085 bad magic number 0x9337 on inode 1086, would reset magic number bad version number 0xffffffaf on inode 1086, would reset version number bad (negative) size -8448536876806716733 on inode 1086 would have cleared inode 1086 bad magic number 0xf704 on inode 1087, would reset magic number bad version number 0xffffffe4 on inode 1087, would reset version number bad (negative) size -2980672623141970876 on inode 1087 would have cleared inode 1087 - agno = 1 Then there is a list of some 60,000 inodes/files that would be cleared. From owner-linux-xfs@oss.sgi.com Sun Sep 18 17:12:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 18 Sep 2005 17:12: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 j8J0CZiL001488 for ; Sun, 18 Sep 2005 17:12: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 KAA02089; Mon, 19 Sep 2005 10:09:42 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 0F3BF49BFB28; Mon, 19 Sep 2005 10:09:40 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Cc: rodrigc@crodrigues.org Subject: TAKE 941645 - const attr parameters Message-Id: <20050919000940.0F3BF49BFB28@chook.melbourne.sgi.com> Date: Mon, 19 Sep 2005 10:09:40 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6181 X-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: 1225 Lines: 25 Make some extended attributes routines take const parameters, for the FreeBSD porters. Date: Mon Sep 19 10:09:01 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: felixb,rodrigc@crodrigues.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23845a xfs_da_btree.c - 1.155 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.155&r2=text&tr2=1.154&f=h xfs_da_btree.h - 1.59 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.h.diff?r1=text&tr1=1.59&r2=text&tr2=1.58&f=h xfs_attr.c - 1.124 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h xfs_attr.h - 1.33 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.h.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h linux-2.6/xfs_vnode.h - 1.110 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.110&r2=text&tr2=1.109&f=h linux-2.4/xfs_vnode.h - 1.103 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.103&r2=text&tr2=1.102&f=h From owner-linux-xfs@oss.sgi.com Mon Sep 19 02:45:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Sep 2005 02:45:11 -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 j8J9j7iL015589 for ; Mon, 19 Sep 2005 02:45:08 -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 j8J9gZJH029293 for ; Mon, 19 Sep 2005 05:42:35 -0400 X-ORBL: [67.124.117.85] Received: from stupidest.org (adsl-67-124-117-85.dsl.snfc21.pacbell.net [67.124.117.85]) by pimout1-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j8J9gFOF229890; Mon, 19 Sep 2005 05:42:15 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 8D236528F27; Mon, 19 Sep 2005 02:42:14 -0700 (PDT) Date: Mon, 19 Sep 2005 02:42:14 -0700 From: Chris Wedgwood To: Ruben Rubio Rey Cc: linux-xfs@oss.sgi.com Subject: Re: XFS problem Message-ID: <20050919094214.GB2660@taniwha.stupidest.org> References: <432AA8FF.4080809@rentalia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432AA8FF.4080809@rentalia.com> X-archive-position: 6183 X-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: 692 Lines: 24 On Fri, Sep 16, 2005 at 01:14:07PM +0200, Ruben Rubio Rey wrote: > There is not p2p ... its web + mail server. did you run very low on space or out completely for a while? > The error is not reproducable (its on random days at random hours) :( fsr the entire fs then i guess > At the moment,i m trying to find the what file is (its hard) ... find path/to/files -type f -print0 | xargs -r0 xfs_bmap -v > foo and eyeball foo; grep for "largenumber:" or similar > But im going to prepare another server in order to move all > information and run xfs_repair and xfs_fsr commands. That shoud fix > it... xfs_repair shouldn't matter xfs_fsr should be pretty safe if you see how it works From owner-linux-xfs@oss.sgi.com Mon Sep 19 03:01:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Sep 2005 03:01:52 -0700 (PDT) Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8JA1biL017269 for ; Mon, 19 Sep 2005 03:01:37 -0700 Received: (qmail 15652 invoked by uid 514); 19 Sep 2005 11:58:53 +0200 Received: from 62.37.217.2 by txori (envelope-from , uid 513) with qmail-scanner-1.25-st-qms (clamdscan: 0.86.1/974. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.217.2):SA:0(-2.2/5.0):. Processed in 1.465834 secs); 19 Sep 2005 09:58:53 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via txori X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.217.2):SA:0(-2.2/5.0):. Processed in 1.465834 secs Process 15643) Received: from 62-37-217-2.mad1.adsl.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.217.2) by mail.rentalia.net with SMTP; 19 Sep 2005 11:58:52 +0200 Message-ID: <432E8BD5.5090101@rentalia.com> Date: Mon, 19 Sep 2005 11:58:45 +0200 From: Ruben User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: linux-xfs@oss.sgi.com Subject: Re: XFS problem References: <432AA8FF.4080809@rentalia.com> <20050919094214.GB2660@taniwha.stupidest.org> In-Reply-To: <20050919094214.GB2660@taniwha.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6184 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: linux-xfs Content-Length: 952 Lines: 53 Chris Wedgwood wrote: >On Fri, Sep 16, 2005 at 01:14:07PM +0200, Ruben Rubio Rey wrote: > > > >>There is not p2p ... its web + mail server. >> >> > >did you run very low on space or out completely for a while? > > No. Fresh install few weeks ago. > > >>The error is not reproducable (its on random days at random hours) :( >> >> > >fsr the entire fs then i guess > >At the moment,i m trying to find the what file is (its hard) ... > > > >find path/to/files -type f -print0 | xargs -r0 xfs_bmap -v > foo > > > I think I have found it, but anyway tomorrow morning, when the server its not busy, i ll execute the command. >and eyeball foo; grep for "largenumber:" or similar > > > >>But im going to prepare another server in order to move all >>information and run xfs_repair and xfs_fsr commands. That shoud fix >>it... >> >> > >xfs_repair shouldn't matter > >xfs_fsr should be pretty safe if you see how it works > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 19 03:08:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Sep 2005 03:08:48 -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 j8JA8diL020404 for ; Mon, 19 Sep 2005 03:08:40 -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 j8JA5Y1A017578 for ; Mon, 19 Sep 2005 06:05:34 -0400 X-ORBL: [67.124.117.85] Received: from stupidest.org (adsl-67-124-117-85.dsl.snfc21.pacbell.net [67.124.117.85]) by pimout3-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j8JA5lDZ030384; Mon, 19 Sep 2005 06:05:47 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id B1BA0528F26; Mon, 19 Sep 2005 03:05:46 -0700 (PDT) Date: Mon, 19 Sep 2005 03:05:46 -0700 From: Chris Wedgwood To: Ruben Cc: linux-xfs@oss.sgi.com Subject: Re: XFS problem Message-ID: <20050919100546.GA3384@taniwha.stupidest.org> References: <432AA8FF.4080809@rentalia.com> <20050919094214.GB2660@taniwha.stupidest.org> <432E8BD5.5090101@rentalia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432E8BD5.5090101@rentalia.com> X-archive-position: 6185 X-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: 253 Lines: 9 On Mon, Sep 19, 2005 at 11:58:45AM +0200, Ruben wrote: > No. Fresh install few weeks ago. Check logfiles and mbox files. When you have lots of files that grow slowly over time in the same directory you tend to get the allocated blocks intermingled. From owner-linux-xfs@oss.sgi.com Mon Sep 19 03:10:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Sep 2005 03:10:19 -0700 (PDT) Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8JAA9iL020809 for ; Mon, 19 Sep 2005 03:10:10 -0700 Received: (qmail 16938 invoked by uid 514); 19 Sep 2005 12:07:26 +0200 Received: from 62.37.217.2 by txori (envelope-from , uid 513) with qmail-scanner-1.25-st-qms (clamdscan: 0.86.1/974. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.217.2):SA:0(-2.2/5.0):. Processed in 1.54635 secs); 19 Sep 2005 10:07:26 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via txori X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.217.2):SA:0(-2.2/5.0):. Processed in 1.54635 secs Process 16929) Received: from 62-37-217-2.mad1.adsl.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.217.2) by mail.rentalia.net with SMTP; 19 Sep 2005 12:07:24 +0200 Message-ID: <432E8DD5.9060809@rentalia.com> Date: Mon, 19 Sep 2005 12:07:17 +0200 From: Ruben User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: linux-xfs@oss.sgi.com Subject: Re: XFS problem References: <432AA8FF.4080809@rentalia.com> <20050919094214.GB2660@taniwha.stupidest.org> <432E8BD5.5090101@rentalia.com> <20050919100546.GA3384@taniwha.stupidest.org> In-Reply-To: <20050919100546.GA3384@taniwha.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: linux-xfs Content-Length: 1986 Lines: 37 This is the log file created by qmail, that works with perl. File size 77 Mb. Could be this one? xfs_bmap -v /var/spool/qmailscan/qms-events.log 0: [0..7]: 130556232..130556239 15 (1243032..1243039) 8 1: [8..15]: 130556272..130556279 15 (1243072..1243079) 8 2: [16..23]: 130556296..130556303 15 (1243096..1243103) 8 3: [24..31]: 130556312..130556319 15 (1243112..1243119) 8 4: [32..39]: 130556336..130556343 15 (1243136..1243143) 8 5: [40..47]: 130556256..130556263 15 (1243056..1243063) 8 6: [48..55]: 130556504..130556511 15 (1243304..1243311) 8 7: [56..63]: 130556848..130556855 15 (1243648..1243655) 8 8: [64..71]: 130556880..130556887 15 (1243680..1243687) 8 9: [72..79]: 130556904..130556911 15 (1243704..1243711) 8 10: [80..87]: 130556928..130556935 15 (1243728..1243735) 8 11: [88..95]: 130556952..130556959 15 (1243752..1243759) 8 12: [96..103]: 130556976..130556983 15 (1243776..1243783) 8 13: [104..111]: 130557000..130557007 15 (1243800..1243807) 8 ..... [CONTINUE] .... 3749: [157360..157383]: 87417744..87417767 10 (1208944..1208967) 24 3750: [157384..157399]: 87417824..87417839 10 (1209024..1209039) 16 3751: [157400..157407]: 87417856..87417863 10 (1209056..1209063) 8 3752: [157408..157431]: 87417872..87417895 10 (1209072..1209095) 24 3753: [157432..157439]: 87417904..87417911 10 (1209104..1209111) 8 3754: [157440..157447]: 87417920..87417927 10 (1209120..1209127) 8 3755: [157448..157479]: 87417936..87417967 10 (1209136..1209167) 32 3756: [157480..157487]: 87417976..87417983 10 (1209176..1209183) 8 3757: [157488..157495]: 87418000..87418007 10 (1209200..1209207) 8 3758: [157496..157559]: 87418104..87418167 10 (1209304..1209367) 64 3759: [157560..157679]: 87418320..87418439 10 (1209520..1209639) 120 From owner-linux-xfs@oss.sgi.com Mon Sep 19 03:27:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Sep 2005 03:27:41 -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 j8JARaiL022207 for ; Mon, 19 Sep 2005 03:27:36 -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 j8JAOV1A023518 for ; Mon, 19 Sep 2005 06:24:31 -0400 X-ORBL: [67.124.117.85] Received: from stupidest.org (adsl-67-124-117-85.dsl.snfc21.pacbell.net [67.124.117.85]) by pimout3-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j8JAOpnF329262; Mon, 19 Sep 2005 06:24:52 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id C46AC528F26; Mon, 19 Sep 2005 03:24:51 -0700 (PDT) Date: Mon, 19 Sep 2005 03:24:51 -0700 From: Chris Wedgwood To: Ruben Cc: linux-xfs@oss.sgi.com Subject: Re: XFS problem Message-ID: <20050919102454.GA3720@taniwha.stupidest.org> References: <432AA8FF.4080809@rentalia.com> <20050919094214.GB2660@taniwha.stupidest.org> <432E8BD5.5090101@rentalia.com> <20050919100546.GA3384@taniwha.stupidest.org> <432E8DD5.9060809@rentalia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432E8DD5.9060809@rentalia.com> X-archive-position: 6187 X-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: 348 Lines: 11 On Mon, Sep 19, 2005 at 12:07:17PM +0200, Ruben wrote: > Could be this one? Yes, it might be (I've seen much worse). Run xfs_fsr over that and you'll see quiet a difference. If the file changes whilst xfs_fsr is running (as can happen with logs) then no reorganization will occur and you will have to retry (ideally with the logging stopped). From owner-linux-xfs@oss.sgi.com Mon Sep 19 06:46:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Sep 2005 06:46: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 j8JDkYiL003493 for ; Mon, 19 Sep 2005 06:46:34 -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 j8JDhoxT020728 for ; Mon, 19 Sep 2005 08:43:50 -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 j8JDhhsS88226176; Mon, 19 Sep 2005 06:43:46 -0700 (PDT) Message-ID: <432EC08F.1010407@sgi.com> Date: Mon, 19 Sep 2005 08:43:43 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruben CC: Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: XFS problem References: <432AA8FF.4080809@rentalia.com> <20050919094214.GB2660@taniwha.stupidest.org> <432E8BD5.5090101@rentalia.com> <20050919100546.GA3384@taniwha.stupidest.org> <432E8DD5.9060809@rentalia.com> In-Reply-To: <432E8DD5.9060809@rentalia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6188 X-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: 2443 Lines: 49 Ruben wrote: > This is the log file created by qmail, that works with perl. File size > 77 Mb. > > Could be this one? sure could be :) Ouch, those are single filesystem blocks in each extent, in the beginning of the file. As Chris suggests, if there are, for example, 2 logs growing in that same dir, they may well get interleaved with each other. It might be simplest to just rotate this log more often so that even if it's highly fragmented, it still won't have too many extents total. -Eric > > xfs_bmap -v /var/spool/qmailscan/qms-events.log > > 0: [0..7]: 130556232..130556239 15 (1243032..1243039) 8 > 1: [8..15]: 130556272..130556279 15 (1243072..1243079) 8 > 2: [16..23]: 130556296..130556303 15 (1243096..1243103) 8 > 3: [24..31]: 130556312..130556319 15 (1243112..1243119) 8 > 4: [32..39]: 130556336..130556343 15 (1243136..1243143) 8 > 5: [40..47]: 130556256..130556263 15 (1243056..1243063) 8 > 6: [48..55]: 130556504..130556511 15 (1243304..1243311) 8 > 7: [56..63]: 130556848..130556855 15 (1243648..1243655) 8 > 8: [64..71]: 130556880..130556887 15 (1243680..1243687) 8 > 9: [72..79]: 130556904..130556911 15 (1243704..1243711) 8 > 10: [80..87]: 130556928..130556935 15 (1243728..1243735) 8 > 11: [88..95]: 130556952..130556959 15 (1243752..1243759) 8 > 12: [96..103]: 130556976..130556983 15 (1243776..1243783) 8 > 13: [104..111]: 130557000..130557007 15 (1243800..1243807) 8 > > ..... [CONTINUE] .... > > 3749: [157360..157383]: 87417744..87417767 10 (1208944..1208967) 24 > 3750: [157384..157399]: 87417824..87417839 10 (1209024..1209039) 16 > 3751: [157400..157407]: 87417856..87417863 10 (1209056..1209063) 8 > 3752: [157408..157431]: 87417872..87417895 10 (1209072..1209095) 24 > 3753: [157432..157439]: 87417904..87417911 10 (1209104..1209111) 8 > 3754: [157440..157447]: 87417920..87417927 10 (1209120..1209127) 8 > 3755: [157448..157479]: 87417936..87417967 10 (1209136..1209167) 32 > 3756: [157480..157487]: 87417976..87417983 10 (1209176..1209183) 8 > 3757: [157488..157495]: 87418000..87418007 10 (1209200..1209207) 8 > 3758: [157496..157559]: 87418104..87418167 10 (1209304..1209367) 64 > 3759: [157560..157679]: 87418320..87418439 10 (1209520..1209639) 120 > From owner-linux-xfs@oss.sgi.com Tue Sep 20 00:23:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Sep 2005 00:23:29 -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 j8K7NIiL012751 for ; Tue, 20 Sep 2005 00:23:19 -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 RAA08849; Tue, 20 Sep 2005 17:20:29 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id D220D49BFB1F; Tue, 20 Sep 2005 17:20:29 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 925163 - buffered read speed bump Message-Id: <20050920072029.D220D49BFB1F@chook.melbourne.sgi.com> Date: Tue, 20 Sep 2005 17:20:29 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6190 X-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: 1563 Lines: 29 Improve buffered read throughput by removing unnecessary timer calls that showed in kernel profiles. Date: Tue Sep 20 17:19: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:23861a xfs_inode.c - 1.418 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.418&r2=text&tr2=1.417&f=h linux-2.6/xfs_lrw.c - 1.227 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.227&r2=text&tr2=1.226&f=h linux-2.6/xfs_vnode.h - 1.111 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.111&r2=text&tr2=1.110&f=h linux-2.6/xfs_iops.c - 1.227 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.227&r2=text&tr2=1.226&f=h linux-2.6/xfs_iops.h - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.h.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h linux-2.4/xfs_vnode.h - 1.104 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.104&r2=text&tr2=1.103&f=h linux-2.4/xfs_iops.c - 1.211 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.211&r2=text&tr2=1.210&f=h linux-2.4/xfs_iops.h - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h From owner-linux-xfs@oss.sgi.com Tue Sep 20 00:27:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Sep 2005 00:27:07 -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 j8K7QwiL013457 for ; Tue, 20 Sep 2005 00:26:59 -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 RAA08938; Tue, 20 Sep 2005 17:24:10 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 1ACD649BFB1C; Tue, 20 Sep 2005 17:24:10 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 942984 - /proc/mounts and external devices Message-Id: <20050920072410.1ACD649BFB1C@chook.melbourne.sgi.com> Date: Tue, 20 Sep 2005 17:24:10 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6191 X-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: 1025 Lines: 23 Track external log/realtime device names for correct reporting in /proc/mounts. Date: Tue Sep 20 17:23:40 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:23862a xfs_log.c - 1.309 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.309&r2=text&tr2=1.308&f=h xfs_log_recover.c - 1.299 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.299&r2=text&tr2=1.298&f=h xfs_vfsops.c - 1.477 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.477&r2=text&tr2=1.476&f=h xfs_mount.h - 1.205 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.205&r2=text&tr2=1.204&f=h xfs_mount.c - 1.362 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.362&r2=text&tr2=1.361&f=h From owner-linux-xfs@oss.sgi.com Tue Sep 20 00:19:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Sep 2005 00:19: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 j8K7JgiL012381 for ; Tue, 20 Sep 2005 00:19: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 RAA08606; Tue, 20 Sep 2005 17:16:52 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 40EA849BFB1C; Tue, 20 Sep 2005 17:16:51 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 942986 - minor header tweaks Message-Id: <20050920071651.40EA849BFB1C@chook.melbourne.sgi.com> Date: Tue, 20 Sep 2005 17:16:51 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6189 X-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: 1972 Lines: 43 Fix up an internal sort function name collision issue. Date: Tue Sep 20 17:12:39 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan,sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23859a xfs_dir2_block.c - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_block.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h xfs_dir_leaf.c - 1.125 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.c.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h xfs_acl.c - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h xfs_attr_leaf.c - 1.84 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h linux-2.6/xfs_linux.h - 1.132 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h linux-2.4/xfs_linux.h - 1.143 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.143&r2=text&tr2=1.142&f=h Remove a null CELL macro and its one caller, not useful to anyone. Date: Tue Sep 20 17:16:30 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen,felixb The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23860a xfs_rename.c - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rename.c.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h linux-2.6/xfs_linux.h - 1.133 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h linux-2.4/xfs_linux.h - 1.144 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.144&r2=text&tr2=1.143&f=h From owner-linux-xfs@oss.sgi.com Tue Sep 20 00:45:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Sep 2005 00:45:20 -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 j8K7jEiL015371 for ; Tue, 20 Sep 2005 00:45:15 -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 RAA09406; Tue, 20 Sep 2005 17:42:25 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id AD8AA49BFB1F; Tue, 20 Sep 2005 17:42:25 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 942984 - xfs_growfs vs /etc/mtab Message-Id: <20050920074225.AD8AA49BFB1F@chook.melbourne.sgi.com> Date: Tue, 20 Sep 2005 17:42:25 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6192 X-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: 1862 Lines: 51 Switch to using /proc/self/mounts instead of /etc/mtab now this has all we need. Date: Tue Sep 20 17:33:58 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:23863a xfsprogs/growfs/xfs_growfs.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/growfs/xfs_growfs.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h xfsprogs/libxcmd/paths.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxpaths.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Fix strtok botch which prevented extraction of rtdev name. Date: Tue Sep 20 17:36:23 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:23864a xfsprogs/libxcmd/paths.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxpaths.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h Bump version number for xfsprogs. Date: Tue Sep 20 17:41:17 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:23865a xfsprogs/VERSION - 1.133 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h xfsprogs/doc/CHANGES - 1.177 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.177&r2=text&tr2=1.176&f=h xfsprogs/debian/changelog - 1.120 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.120&r2=text&tr2=1.119&f=h From owner-linux-xfs@oss.sgi.com Tue Sep 20 12:37:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Sep 2005 12:37:29 -0700 (PDT) Received: from mxsf13.cluster1.charter.net (mxsf13.cluster1.charter.net [209.225.28.213]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8KJbKiL002063 for ; Tue, 20 Sep 2005 12:37:21 -0700 Received: from mxip17a.cluster1.charter.net (mxip17a.cluster1.charter.net [209.225.28.147]) by mxsf13.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j8KJYY3G027238 for ; Tue, 20 Sep 2005 15:34:35 -0400 Received: from 24-196-226-167.dhcp.gwnt.ga.charter.com (HELO [192.168.0.8]) (24.196.226.167) by mxip17a.cluster1.charter.net with ESMTP; 20 Sep 2005 15:34:36 -0400 X-IronPort-AV: i="3.97,127,1125892800"; d="scan'208"; a="1574209841:sNHT14276192" Message-ID: <433064AF.1030705@charter.net> Date: Tue, 20 Sep 2005 15:36:15 -0400 From: "Jeffrey B. Layton" Reply-To: laytonjb@charter.net User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Sorry for the bother - Max File System Limit on Linux 2.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6193 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: laytonjb@charter.net Precedence: bulk X-list: linux-xfs Content-Length: 380 Lines: 14 Everyone, I'm really sorry to ask this on the list but I need a definitive answer. I was looking on the XFS website to find the maximum File System size for XFS with a 2.6 Linux kernel (2.6.10+). According to the XFS website it's 9 million TB but I thought there was a limitation in the kernel somewhere that limited it to 16 TB. Can someone help answer this? Thanks! Jeff From owner-linux-xfs@oss.sgi.com Tue Sep 20 12:44:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Sep 2005 12:44:46 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8KJiYiL003467 for ; Tue, 20 Sep 2005 12:44:34 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.52 #1 (Red Hat Linux)) id 1EHnzx-00033N-IV; Tue, 20 Sep 2005 20:41:49 +0100 Date: Tue, 20 Sep 2005 20:41:49 +0100 From: Christoph Hellwig To: "Jeffrey B. Layton" Cc: linux-xfs@oss.sgi.com Subject: Re: Sorry for the bother - Max File System Limit on Linux 2.6 Message-ID: <20050920194149.GA11707@infradead.org> References: <433064AF.1030705@charter.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433064AF.1030705@charter.net> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 6194 X-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@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 696 Lines: 23 On Tue, Sep 20, 2005 at 03:36:15PM -0400, Jeffrey B. Layton wrote: > Everyone, > > I'm really sorry to ask this on the list but I need > a definitive answer. I was looking on the XFS website > to find the maximum File System size for XFS with > a 2.6 Linux kernel (2.6.10+). According to the XFS > website it's 9 million TB but I thought there was a > limitation in the kernel somewhere that limited it > to 16 TB. Can someone help answer this? 16TB is the limit on 32bit platforms. On 64bit platorms the theoretical size is virtually unlimited, although you will run into various scalability limits in the hundrets of terra bytes range. > > Thanks! > > Jeff > > ---end quoted text--- From owner-linux-xfs@oss.sgi.com Tue Sep 20 14:05:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Sep 2005 14:05:15 -0700 (PDT) Received: from halifax.chebucto.ns.ca (chebucto.ns.Ca [192.75.95.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8KL52iL014779 for ; Tue, 20 Sep 2005 14:05:02 -0700 Received: from Dyip-175.chebucto.ns.Ca ([192.75.95.175]:58403 "EHLO cerberus.cwmannwn.nowhere" smtp-auth: TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by halifax.chebucto.ns.ca with ESMTP id S10806AbVITVAo (ORCPT ); Tue, 20 Sep 2005 18:00:44 -0300 Date: Tue, 20 Sep 2005 18:00:37 -0300 (ADT) From: "George N. White III" X-X-Sender: gwhite@cerberus.cwmannwn.nowhere Reply-To: "George N. White III" To: Matt Stegman cc: Al Boldi , linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com Subject: Re: Good, recent FS comparison? In-Reply-To: Message-ID: References: <432D3024.3080302@dtbb.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aa056@chebucto.ns.ca Precedence: bulk X-list: linux-xfs Content-Length: 1749 Lines: 39 On Sun, 18 Sep 2005, Matt Stegman wrote: > This has been discussed on the mailing list before. Quick rundown: > > "Ordered mode" means that a file's metadata isn't written until after the > file's data. On XFS, which doesn't use ordered mode, under certain > circumstances you may see files which are the correct size, with correct > times, etc, but with only null bytes for the data. Another way to look at this: in some case, e.g., transaction processing, the priority is to make sure no data are lost. The opposite situation is where you have large volumes of data coming in, e.g., remote sensing, rendering farms, big numerical simulations. If something breaks you are losing data until the system is back. With XFS you have a consistent filesystem immediately, but you may want to look carefully at the files being written when the problem occurred. > In my experience it's not that big a deal; I can almost always easily > recreate data which could be lost by being written out just before a crash > or power loss. I put important systems on an UPS and use stable kernels, > and I've never personally seen the null data problem. Clients and other data sources like satellite dishes often break at inconvenient times. Write a large structured file like hdf from an NFS client and pull the network plug or turn off the client when the client job finishes but before the data has all been written. You should endup with a consistent filesystem but a sparse file. > Currently, I believe only ext3 and reiserfs support ordered mode. I'm not > sure if reiser4's journaling is ordered or not. I don't thnk you can make a blanket statement -- different horses for different courses. -- George N. White III From owner-linux-xfs@oss.sgi.com Tue Sep 20 23:31:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Sep 2005 23:36:35 -0700 (PDT) Received: from dvd-a-day.every1.net ([219.133.112.208]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j8L6VEiL030751; Tue, 20 Sep 2005 23:31:16 -0700 Message-ID: <7A5B2C63.75E0617@dvd-a-day.every1.net> Date: Wed, 21 Sep 2005 04:10:22 -0300 Reply-To: "nestor priddy" From: "nestor priddy" User-Agent: eGroups Message Poster MIME-Version: 1.0 To: "Lucius Loque" , , , , , , , Subject: catch a great time. top deals on luxury watches. literature Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 6197 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: karoline@dvd-a-day.every1.net Precedence: bulk X-list: linux-xfs Content-Length: 209 Lines: 12 Neida: http://uk.geocities.com/medassault/?You¡¯ll_love_them fjx dancedance - ooh -'Til the break of day. examenyear etirtnoc fmake sz03 etatimil dhiga Title: Does Your Mother Know (By ABBA) Verse 1 From owner-linux-xfs@oss.sgi.com Wed Sep 21 00:43:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Sep 2005 00:43:41 -0700 (PDT) Received: from spider.geoforce.com.tw (60-248-174-131.HINET-IP.hinet.net [60.248.174.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8L7hTiL011731 for ; Wed, 21 Sep 2005 00:43:36 -0700 Received: from michael (220-134-86-155.HINET-IP.hinet.net [220.134.86.155]) (authenticated bits=0) by spider.geoforce.com.tw (8.12.10/8.12.10) with ESMTP id j8L7wrKK005786 for ; Wed, 21 Sep 2005 15:58:54 +0800 Message-Id: <200509210758.j8L7wrKK005786@spider.geoforce.com.tw> From: "Michael Hsieh" To: Subject: xfs 1.2 can't mount my promise sata raid filesystem- Plesae help Date: Wed, 21 Sep 2005 15:41:34 +0800 MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Importance: High Thread-Index: AcW+f9wF5iHPNQt/THKzfpEx+pZ19A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Geoforce-MailScanner-Information: Please contact the ISP for more information X-Geoforce-MailScanner: Found to be clean X-MailScanner-From: michael@geoforce.com.tw Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6199 X-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@geoforce.com.tw Precedence: bulk X-list: linux-xfs Content-Length: 1270 Lines: 56 Dear All, I appreciate anyone can help. I use xfs 1.2 (little old I know) to make a new xfs filesystem on new raid. #/sbin/mkfs -t xfs -f /dev/sdc1 meta-data=/dev/sdc1 isize=256 agcount=232, agsize=1048576 blks data = bsize=4096 blocks=242420834, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=29592, version=1 = sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 [root@mod:/home/michael]# mount -t xfs /dev/sdc1 /content4 mount: wrong fs type, bad option, bad superblock on /dev/sdc1, or too many mounted file systems I can't mount the filesystem and got error. I tried to make a ext3 filesystem, it works.. Can anyone help? Thanks. Michael /usr/sbin/xfs_logprint -t /dev/sdc1 xfs_logprint: data device: 0x821 log device: 0x821 daddr: 973078560 length: 236736 log tail: 2 head: 2 state: [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Sep 21 01:13:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Sep 2005 01:13:13 -0700 (PDT) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8L8D5iL015156 for ; Wed, 21 Sep 2005 01:13:05 -0700 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id j8L8AHWK025983; Wed, 21 Sep 2005 01:10:17 -0700 Message-ID: <43311567.3060208@tlinx.org> Date: Wed, 21 Sep 2005 01:10:15 -0700 From: "Linda A. Walsh" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en, en_US MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Austin Gonyou Subject: Re: file system defragmentation References: <43128F82.4010004@tlinx.org> <4312913F.6040205@coremetrics.com> In-Reply-To: <4312913F.6040205@coremetrics.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6201 X-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@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 8625 Lines: 178 Sorry for the long delay in answering, I must have missed this coming in, but yes, you are right...if you have 1 gigantic file that grows fragmented over time (while not regularly running fsr), you might have a highly fragmented file even though the % of fragmented files would read "low". (I think that is what you were saying in addition to mentioning the concept of many small individual files that could raise a fragmentation number). However, if one were to run 'fsr' daily and if there was a large enough blank contiguous area on the disk to hold the multi-Gig file, fsr would still unfold it; in fact, that was why it was created: given xfs's delayed allocation (even slightly more so on it's native IRIX, _I believe_), it was originally designed without "fsr" because it was thought it wouldn't really be likely to need it. The file system was designed for to handle large recording sessions and large files of streaming media such as live audio and video feed -- which used to be one of SGI's target customers. This is 2nd hand, so I may have some details off, but the way I heard it was that one customer came up with an unplanned scenario where they would do something like recording different parts of weekly shows interwoven throughout a day and throughout a week. Even with delayed writes, one can only delay so long, and, perhaps, while producing multiple programs, there would still be a limit to system memory to buffer multiple feeds in memory before a write to disk would be forced. I think this was back in the mid 90's (?), so bandwidth and main memory were more limited as well. Thus 'xfs_fsr' was born to re-arrange the data portions of files to re-optimize streaming performance. Now admittedly, I don't know what happens with DBMS files that are 'locked'. Since "xfs_fsr" can be run by any user that has read/write access to the specified file it wouldn't appear to need or use any extra privileges so DBMS files that remain locked 24 hours/day but grow slowly over time could, theoretically, become highly internally fragmented. I'm not sure how one would easily work around that problem -- especially in the case of locked records of a database that could be getting updated in real-time. It would likely be "best" to allocate/create the DBMS files to max size they will be allowed to grow, before putting them into use, make sure they are defragmented before using, then use them in place. If you can't predict the maximum file size, then one may have to periodically checkpoint a database, make a copy of the database, defragment the new copy, (since xfs_fsr allows defragmenting by file), then temporarily lock the database and update the new copy with all the changes since the copy was made (perhaps some sort of database journal can be started after the checkpoint that can be replayed on the new copy? Guess it depends on the app). As far as *many* small files. XFS may have some mixed performance characteristics on those. Some small amount of file data or directory information, I believe, may be stored internal to an inode, but that is very limited and I don't know when XFS makes use of that feature -- it might be symlink data or stuff like that only. Dunno. I have seen (and experienced) bad performance for "removing" large numbers of files on XFS. It is probably better than when first ported to Linux, but I believe it's still a noticable slow spot. It _could_ be (guess), that when a file is deleted, and the space is released, the file subsystem attempts to merge the free space released with adjacent blocks of free space -- doing this recursively over each block of space released so that the resulting free space results in the fewest number of "extents" (variable sized allocation units) possible. While this creates a performance penalty for file deletes, it has the effect of automatically coalescing freespace automatically into large segments that can be quickly allocated when needed for streaming 'write' performance. With the delayed write feature of XFS, it can allow the file subsystem to choose a more optimally sized free "extent" on write, rather than allocating single blocks on a first free, first allocated basis as is common in other file systems). I.e. if I already have buffered 256K in memory for a file that is still being written to, XFS could choose a 512K extent that may be followed by other large, contiguous free extents, vs. if I have written a file and closed it for writing, say using cp, and it was a 23.5K file, it would be able to know an extent size between 16-31K might be an exact fit or it could split a 32+K size extent and create a left-over 8K extent. Either way, it would quickly find a contiguous free block of space for the file and not use the fragmentation-prone approach of allocating the first-free blocks first. I guess I've been pretty impressed with the XFS design strategy -- especially considering it's well over 10 years old -- supporting low level fragmentation in _most_ cases w/o needing "fsr" (stock IRIX release was configured to run it *weekly*), one of the first file systems I was exposed to that provided journaling and eliminated my long fsck waits. It also reduced format time on a multi Gig volume from large fractions of an hour to some number of seconds. It was designed with extended attributes, allowing both system and user-level attribute space/file, special "real-time" recording zones that can allow for faster access than going through the file system and it's hierachy and allocation mechanism might allow, supporting detailed layout specification to optimal tune RAID performance on generic hardware, and other features we take for granted in a modern file system. I think it's sorta neat that things that might normally need a data-block under other file systems, like "symlink" data, I believe, is actually stored in the inode. That's gotta reduce large numbers of single, "allocation-unit" sized junks that would be necessary in other filesystems. While their IRIX systems were up to 1024 cpu's/node (one OS image) about 3-4 years ago, they had to play catchup with the Intel Itanium architecture but seem to have gotten up to speed there as well delivering a 10,240 processor system (I'm guessing 10-OS-node cluster, but dunno, maybe they were able to do some custom config -- never can tell what some of the SGI engineers might come up with. There are still some damn smart engineers there, even though many were lost over the past several years due to layoffs and attrition as new management was brought in to 'control' costs by increased scrutiny and critical review/control of the creative process...er... I shouldn't have said that last part. Nope...Forget I said anything. Bad habit I have of saying a bit too much sometimes. On that note...time to shut up...would like to minimize foot-in mouth disease...:-) Linda On Sunday, August 28th (more than 3 weeks ago), Austin Gonyou wrote: > I believe in the FAQ/man-info page for xfs_fsr, it refers to the fact > that it will only work on file data and that the percent of frag is a > factor of the size of files, number of inodes, and number of files. > > This is important because if you run a mail/news/file server of some > sort, and you have *high* frag, then there's probably a performance > problem there. > If you have large files, say, 2GB files, and have tons of them, (read > RDBMS), then each file if it were fragged, would yield a higher amount > of fragmentation per file. Just remember that when using FSR. ;) > > Austin > > Linda A. Walsh wrote: > >> XFS_FSR has been very stable -- I've been running it since before >> xfs was merged into the kernel. >> >> I have the following file, named "fsr" in my /etc/cron.daily: >> fsr: >> #!/bin/bash >> /usr/sbin/xfs_fsr >> ---- >> I would think /bin/sh or /bin/sh would work equally well. >> >> _File_ fragmentation is a virtual non-issue on my disks, however, >> xfs_fsr only works on my file data. It doesn't work >> on directory data. On a 118G partition nearing 79% capacity, >> printing the defragmentation data from xfs_db: >> >> files: >> actual 316870, ideal 316652, fragmentation factor 0.07% >> >> directories: >> actual 2538, ideal 1330, fragmentation factor 47.60% >> >> I don't know about other data types (attr, symlink, quota, >> realtime, realtime control) as I don't believe I have >> any of those types on my volumes...But, hey, file fragmentation >> seems to be handled! :-) >> >> Linda >> >> >> Fong Vang wrote: >> >> >This is very useful. Thank you. How stable is xfs_fsr? >> > >> > From owner-linux-xfs@oss.sgi.com Wed Sep 21 03:33:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Sep 2005 03:33:39 -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 j8LAXViL032252 for ; Wed, 21 Sep 2005 03:33:32 -0700 Received: from hastur.corp.sgi.com (hastur.corp.sgi.com [198.149.32.33]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j8LAUkxT006291 for ; Wed, 21 Sep 2005 05:30:46 -0500 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by hastur.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j8LAAOeS194865814 for ; Wed, 21 Sep 2005 03:10:24 -0700 (PDT) X-ASG-Debug-ID: 1127297450-20627-13-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id C3DF6664B74 for ; Wed, 21 Sep 2005 03:10:50 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j8LAAmjZ006514; Wed, 21 Sep 2005 05:10:49 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j8LAAksn006513; Wed, 21 Sep 2005 05:10:46 -0500 Date: Wed, 21 Sep 2005 05:10:46 -0500 From: Christoph Hellwig Message-Id: <200509211010.j8LAAksn006513@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com X-ASG-Orig-Subj: TAKE 919278 - Fix xfs_db build with GCC 4.x Subject: TAKE 919278 - Fix xfs_db build with GCC 4.x X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.4118 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6202 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 467 Lines: 15 Date: Wed Sep 21 03:10:36 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:199496a xfsprogs/db/attrset.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/attrset.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - include some headers to avoid arrays of incomplete type in prototype warning From owner-linux-xfs@oss.sgi.com Wed Sep 21 03:57:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Sep 2005 03:57:52 -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 j8LAviiL002607 for ; Wed, 21 Sep 2005 03:57:44 -0700 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j8LBvDoF003707 for ; Wed, 21 Sep 2005 04:57:13 -0700 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j8LAf12Z268971393 for ; Wed, 21 Sep 2005 03:41:01 -0700 (PDT) X-ASG-Debug-ID: 1127299258-7806-52-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id A9272D022C2A for ; Wed, 21 Sep 2005 03:40:58 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j8LAeuE7019125; Wed, 21 Sep 2005 05:40:57 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j8LAet1q019121; Wed, 21 Sep 2005 05:40:55 -0500 Date: Wed, 21 Sep 2005 05:40:55 -0500 From: Christoph Hellwig Message-Id: <200509211040.j8LAet1q019121@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com X-ASG-Orig-Subj: TAKE 919278 - remove unused struct xfs_ail_ticket Subject: TAKE 919278 - remove unused struct xfs_ail_ticket X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.4118 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 384 Lines: 13 Date: Wed Sep 21 03:40:45 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:199498a fs/xfs/xfs_trans.h - 1.133 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.h.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h From owner-linux-xfs@oss.sgi.com Wed Sep 21 05:07:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Sep 2005 05:08:09 -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 j8LC7wiL015183 for ; Wed, 21 Sep 2005 05:07:58 -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 j8LD7R21018949 for ; Wed, 21 Sep 2005 06:07:27 -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 j8LC4BsS90628376; Wed, 21 Sep 2005 05:04:12 -0700 (PDT) Message-ID: <43314C3B.6060209@sgi.com> Date: Wed, 21 Sep 2005 07:04:11 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hsieh CC: linux-xfs@oss.sgi.com Subject: Re: xfs 1.2 can't mount my promise sata raid filesystem- Plesae help References: <200509210758.j8L7wrKK005786@spider.geoforce.com.tw> In-Reply-To: <200509210758.j8L7wrKK005786@spider.geoforce.com.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6204 X-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: 271 Lines: 11 Michael Hsieh wrote: > [root@mod:/home/michael]# mount -t xfs /dev/sdc1 /content4 > > mount: wrong fs type, bad option, bad superblock on /dev/sdc1, > > or too many mounted file systems Look at your system logs to get the real error as reported by XFS. -Eric From owner-linux-xfs@oss.sgi.com Wed Sep 21 08:40:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Sep 2005 08:40:23 -0700 (PDT) Received: from mail.shareable.org (mail.shareable.org [81.29.64.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8LFdxiL006870 for ; Wed, 21 Sep 2005 08:40:00 -0700 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j8LFb46K020150; Wed, 21 Sep 2005 16:37:04 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j8LFb32i020147; Wed, 21 Sep 2005 16:37:03 +0100 Date: Wed, 21 Sep 2005 16:37:03 +0100 From: Jamie Lokier To: Al Boldi Cc: linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com Subject: Re: Good, recent FS comparison? Message-ID: <20050921153703.GB19896@mail.shareable.org> References: <6d5bedd8050915131148b8108a@mail.gmail.com> <432A37BF.7060305@dtbb.net> <200509162258.37730.a1426z@gawab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509162258.37730.a1426z@gawab.com> User-Agent: Mutt/1.4.1i X-archive-position: 6205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: linux-xfs Content-Length: 348 Lines: 12 Al Boldi wrote: > ext3 is rock-solid! If only. Recently I had a system come up after a power cycle with a directory where reading any file in that directory gives an I/O error. The disk is fine, and it's using ext3 in ordered mode, with IDE write-caching disabled to be sure. So while ext3 is good, I'm not convinced it's rock solid. -- Jamie From owner-linux-xfs@oss.sgi.com Wed Sep 21 14:39:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Sep 2005 14:39:11 -0700 (PDT) Received: from raad.intranet ([212.76.84.84]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8LLcwiL013981 for ; Wed, 21 Sep 2005 14:39:03 -0700 Received: from localhost (ws159a.intranet [10.0.1.159]) by raad.intranet (8.8.7/8.8.7) with ESMTP id AAA25774; Thu, 22 Sep 2005 00:35:31 +0300 From: Al Boldi To: Jamie Lokier Subject: Re: Good, recent FS comparison? Date: Thu, 22 Sep 2005 00:34:42 +0300 User-Agent: KMail/1.5 Cc: linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com References: <6d5bedd8050915131148b8108a@mail.gmail.com> <200509162258.37730.a1426z@gawab.com> <20050921153703.GB19896@mail.shareable.org> In-Reply-To: <20050921153703.GB19896@mail.shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509220034.42284.a1426z@gawab.com> X-archive-position: 6206 X-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: 388 Lines: 16 Jamie Lokier wrote: > Al Boldi wrote: > > ext3 is rock-solid! > > If only. Recently I had a system come up after a power cycle with a > directory where reading any file in that directory gives an I/O error. > The disk is fine, and it's using ext3 in ordered mode, with IDE > write-caching disabled to be sure. 2.4 or 2.6? In 2.4 try a reboot and force an fsck before mounting. -- Al From owner-linux-xfs@oss.sgi.com Thu Sep 22 04:41:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 04:41:46 -0700 (PDT) Received: from mailscan1.ella.no (mailscan1.ella.no [212.4.36.12]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8MBfaiL022145 for ; Thu, 22 Sep 2005 04:41:37 -0700 Received: from mailscan1.ella.no (localhost.ella.no [127.0.0.1]) by localhost.mailscan1.ella.no (Postfix) with ESMTP id EE331114EF9 for ; Thu, 22 Sep 2005 13:38:50 +0200 (CEST) Received: from exsrv.ENITSOR.ELLA.NO (exsrv.enitsor.ella.no [212.4.32.2]) by mailscan1.ella.no (Postfix) with ESMTP id CD4C2114839 for ; Thu, 22 Sep 2005 13:38:50 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 MIME-Version: 1.0 Subject: XFS on 6TB systems Date: Thu, 22 Sep 2005 13:38:50 +0200 Message-ID: <901EF07474352B4687748ADCF6560C380152123B@exsrv.ENITSOR.ELLA.NO> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS on 6TB systems Thread-Index: AcW/ajPmrNgtqf/jQ0yOdGNZPNLpaQ== From: "Thor Eivind Brantzeg" To: Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Thor.Eivind.Brantzeg@ella.no Precedence: bulk X-list: linux-xfs Content-Length: 1366 Lines: 48 Hi. Ive created 2 6TB partitions on our new SAN Eonstore boxes using XFS linux-2.6.12 as the FS. Ive used parted to do the partitioning and guid as the partitiontable type. (mbr = <2TB) ELLA-Gentoo-scsi-test mnt # cat /proc/partitions major minor #blocks name 3 0 195360984 hda 3 1 56196 hda1 3 2 987997 hda2 3 3 194314207 hda3 8 0 5856660480 sda 8 1 5856660446 sda1 8 16 5856660480 sdb 8 17 5856660446 sdb1 1. Problem 1 is that i have problem umounting 1 of the mounts. Is there a way to safely umount an XFS FS when there is no usage at all? ELLA-Gentoo-scsi-test mnt # umount -f /mnt/EONSTORE2 umount2: Device or resource busy umount: /mnt/EONSTORE2: device is busy umount2: Device or resource busy umount: /mnt/EONSTORE2: device is busy 2. Problem 2 is that i cannot get any of the XFS utils to work with Problem i have is all the utilities for xfs doesnt work at all: ELLA-Gentoo-scsi-test mnt # xfs_check /dev/sda1 xfs_check: /dev/sda1 is invalid (cannot read first 512 bytes) Another problem i get is that when i do a xfs_repair i get a segfault. Its running on a P4 IA32 machine with Linux 2.6.12 kernel with Lageblockdevice support. ------------------------------------------------------------------------ ----------- TEB [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Sep 22 04:43:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 04:43:45 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8MBhaiL022748 for ; Thu, 22 Sep 2005 04:43:38 -0700 Received: from gateway-att.yingternet.com (c-24-126-232-43.hsd1.ca.comcast.net [24.126.232.43]) by ying.yingternet.com (Postfix) with ESMTP id 646A43000AD for ; Thu, 22 Sep 2005 04:41:37 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id 178A8204C18 for ; Thu, 22 Sep 2005 04:40:43 -0700 (PDT) Message-ID: <43329839.2070005@yingternet.com> Date: Thu, 22 Sep 2005 19:40:41 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: howto preallocate to minimize fragmentation X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6209 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 510 Lines: 20 Hi there, we are storing realtime streaming data (multiple/random writes) in our Linux system with XFS filesystem and suffering from heavy fragementation (> 90%) . I am wondering what's the best way to reallocate files (say 2GB files) before using the file system. we are creating the 'quick' sparse file like the following: (is this cause the problem?) /bin/dd if=/dev/zero of=/mnt/file.ivf bs=1M seek=2000000 count=1 We are using Linux 2.6.x kernel with XFS filesystem can anyone help? Thanks, -Ying From owner-linux-xfs@oss.sgi.com Thu Sep 22 05:00:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 05:01:05 -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 j8MC0siL024611 for ; Thu, 22 Sep 2005 05:00:54 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 61B3DC1A215B for ; Thu, 22 Sep 2005 19:57:27 +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 6D948C1A2151 for ; Thu, 22 Sep 2005 19:57:06 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 71BF116AF997E; Thu, 22 Sep 2005 19:57:03 +0800 (PHT) Date: Thu, 22 Sep 2005 19:57:03 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: XFS on 6TB systems Message-ID: <20050922115703.GE2476@free.net.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <901EF07474352B4687748ADCF6560C380152123B@exsrv.ENITSOR.ELLA.NO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <901EF07474352B4687748ADCF6560C380152123B@exsrv.ENITSOR.ELLA.NO> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.9i X-archive-position: 6210 X-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: 877 Lines: 25 On Thu, Sep 22, 2005 at 01:38:50PM +0200, Thor Eivind Brantzeg wrote: > Hi. Ive created 2 6TB partitions on our new SAN Eonstore boxes using > XFS linux-2.6.12 as the FS. ... > Its running on a P4 IA32 machine with Linux 2.6.12 kernel with > Lageblockdevice support. Please see a recent thread in the archives that discusses a limitation when it comes to running the XFS userland utilities on a 32-bit architecture to repair multi-terabyte filesystems due to a per-process memory limit imposed by the architecture. Here are some links to help you out: http://archives.free.net.ph/message/20050808.092527.0dc40a3e.en.html http://archives.free.net.ph/message/20050809.020823.21ffe4a1.en.html Good luck. --> 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 Thu Sep 22 05:07:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 05:07:47 -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 j8MC7fiL025662 for ; Thu, 22 Sep 2005 05:07:41 -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 j8MD7JCn023289 for ; Thu, 22 Sep 2005 06:07:19 -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 j8MC4ssS90823728; Thu, 22 Sep 2005 05:04:55 -0700 (PDT) Message-ID: <43329DE6.8060407@sgi.com> Date: Thu, 22 Sep 2005 07:04:54 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thor Eivind Brantzeg CC: linux-xfs@oss.sgi.com Subject: Re: XFS on 6TB systems References: <901EF07474352B4687748ADCF6560C380152123B@exsrv.ENITSOR.ELLA.NO> In-Reply-To: <901EF07474352B4687748ADCF6560C380152123B@exsrv.ENITSOR.ELLA.NO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6211 X-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: 1058 Lines: 31 Thor Eivind Brantzeg wrote: > 1. Problem 1 is that i have problem umounting 1 of the mounts. Is there > a way to safely umount an XFS FS when there is no usage at all? > > ELLA-Gentoo-scsi-test mnt # umount -f /mnt/EONSTORE2 > umount2: Device or resource busy > umount: /mnt/EONSTORE2: device is busy > umount2: Device or resource busy > umount: /mnt/EONSTORE2: device is busy samba? nfs? something is using it... maybe fuser will tell you? > 2. Problem 2 is that i cannot get any of the XFS utils to work with > > Problem i have is all the utilities for xfs doesnt work at all: > > ELLA-Gentoo-scsi-test mnt # xfs_check /dev/sda1 > xfs_check: /dev/sda1 is invalid (cannot read first 512 bytes) strace xfs_check & see what syscall fails, and see if there are any system messages. > Another problem i get is that when i do a xfs_repair i get a segfault. this may be an issue with the memory requirements of repair - you could gdb the corefile to see why it segfaulted. be sure you have the latest userspace, too, just for starters. -Eric From owner-linux-xfs@oss.sgi.com Thu Sep 22 05:12:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 05:12:13 -0700 (PDT) Received: from mailscan1.ella.no (mailscan1.ella.no [212.4.36.12]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8MCC4iL026332 for ; Thu, 22 Sep 2005 05:12:05 -0700 Received: from mailscan1.ella.no (localhost.ella.no [127.0.0.1]) by localhost.mailscan1.ella.no (Postfix) with ESMTP id 9699E16B573 for ; Thu, 22 Sep 2005 14:09:16 +0200 (CEST) Received: from exsrv.ENITSOR.ELLA.NO (exsrv.enitsor.ella.no [212.4.32.2]) by mailscan1.ella.no (Postfix) with ESMTP id 73EC516B46B for ; Thu, 22 Sep 2005 14:09:16 +0200 (CEST) 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: SV: XFS on 6TB systems Date: Thu, 22 Sep 2005 14:09:16 +0200 Message-ID: <901EF07474352B4687748ADCF6560C380152123E@exsrv.ENITSOR.ELLA.NO> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS on 6TB systems Thread-Index: AcW/bdvST2UH13hjRviwxcxqIJi0FwAAA8pA From: "Thor Eivind Brantzeg" To: "Eric Sandeen" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8MCC5iL026337 X-archive-position: 6212 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Thor.Eivind.Brantzeg@ella.no Precedence: bulk X-list: linux-xfs Content-Length: 1904 Lines: 63 Thx m8 for responding: ELLA-Gentoo-scsi-test mnt # emerge -s xfsprogs Searching... [ Results for search key : xfsprogs ] [ Applications found : 1 ] * sys-fs/xfsprogs Latest version available: 2.6.25 Latest version installed: 2.6.25 Size of downloaded files: 830 kB Homepage: http://oss.sgi.com/projects/xfs/ Description: xfs filesystem utilities License: LGPL-2.1 We are using FTP only as NAS service. Sctrace is an unknown command on my plattform.. Ill try to find a package that contains it.. ------------------------------------------------------------------------ ----------- Thor Eivind C. Brantzeg -----Opprinnelig melding----- Fra: Eric Sandeen [mailto:sandeen@sgi.com] Sendt: 22. september 2005 14:05 Til: Thor Eivind Brantzeg Kopi: linux-xfs@oss.sgi.com Emne: Re: XFS on 6TB systems Thor Eivind Brantzeg wrote: > 1. Problem 1 is that i have problem umounting 1 of the mounts. Is > there a way to safely umount an XFS FS when there is no usage at all? > > ELLA-Gentoo-scsi-test mnt # umount -f /mnt/EONSTORE2 > umount2: Device or resource busy > umount: /mnt/EONSTORE2: device is busy > umount2: Device or resource busy > umount: /mnt/EONSTORE2: device is busy samba? nfs? something is using it... maybe fuser will tell you? > 2. Problem 2 is that i cannot get any of the XFS utils to work with > > Problem i have is all the utilities for xfs doesnt work at all: > > ELLA-Gentoo-scsi-test mnt # xfs_check /dev/sda1 > xfs_check: /dev/sda1 is invalid (cannot read first 512 bytes) strace xfs_check & see what syscall fails, and see if there are any system messages. > Another problem i get is that when i do a xfs_repair i get a segfault. this may be an issue with the memory requirements of repair - you could gdb the corefile to see why it segfaulted. be sure you have the latest userspace, too, just for starters. -Eric From owner-linux-xfs@oss.sgi.com Thu Sep 22 05:17:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 05:17:17 -0700 (PDT) Received: from mail.shareable.org (mail.shareable.org [81.29.64.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8MCHBiL027320 for ; Thu, 22 Sep 2005 05:17:12 -0700 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j8MCEN6K030218; Thu, 22 Sep 2005 13:14:23 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j8MCENCU030216; Thu, 22 Sep 2005 13:14:23 +0100 Date: Thu, 22 Sep 2005 13:14:23 +0100 From: Jamie Lokier To: Al Boldi Cc: linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com Subject: Re: Good, recent FS comparison? Message-ID: <20050922121423.GA30182@mail.shareable.org> References: <6d5bedd8050915131148b8108a@mail.gmail.com> <200509162258.37730.a1426z@gawab.com> <20050921153703.GB19896@mail.shareable.org> <200509220034.42284.a1426z@gawab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509220034.42284.a1426z@gawab.com> User-Agent: Mutt/1.4.1i X-archive-position: 6213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: linux-xfs Content-Length: 649 Lines: 24 Al Boldi wrote: > Jamie Lokier wrote: > > Al Boldi wrote: > > > ext3 is rock-solid! > > > > If only. Recently I had a system come up after a power cycle with a > > directory where reading any file in that directory gives an I/O error. > > The disk is fine, and it's using ext3 in ordered mode, with IDE > > write-caching disabled to be sure. > > 2.4 or 2.6? > > In 2.4 try a reboot and force an fsck before mounting. 2.4.26, uclinux - it's an embedded device. Doing an fsck before mounting would be an unacceptable boot-time delay. Why do you suggest that, specifically for 2.4? Is there a known problem with 2.4 and ext3? Thanks, -- Jamie From owner-linux-xfs@oss.sgi.com Thu Sep 22 05:25:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 05:26:05 -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 j8MCPsiL028625 for ; Thu, 22 Sep 2005 05:25:54 -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 j8MDPV9l026077 for ; Thu, 22 Sep 2005 06:25:31 -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 j8MCN7sS90864630; Thu, 22 Sep 2005 05:23:07 -0700 (PDT) Message-ID: <4332A22B.6070708@sgi.com> Date: Thu, 22 Sep 2005 07:23:07 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ying-Hung Chen CC: linux-xfs@oss.sgi.com Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> In-Reply-To: <43329839.2070005@yingternet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6214 X-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: 694 Lines: 23 Ying-Hung Chen wrote: > Hi there, > > we are storing realtime streaming data (multiple/random writes) in our > Linux system with XFS filesystem and suffering from heavy fragementation > (> 90%) . I am wondering what's the best way to reallocate files (say > 2GB files) before using the file system. > > we are creating the 'quick' sparse file like the following: (is this > cause the problem?) > > /bin/dd if=/dev/zero of=/mnt/file.ivf bs=1M seek=2000000 count=1 > > We are using Linux 2.6.x kernel with XFS filesystem > > can anyone help? See the xfsctl man page from xfsprogs, specifically XFS_IOC_RESVSP creating a sparse file will not help with fragmentation, unfortunately. -Eric From owner-linux-xfs@oss.sgi.com Thu Sep 22 07:32:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 07:32:35 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8MEWKiL006692 for ; Thu, 22 Sep 2005 07:32:20 -0700 Received: from gateway-att.yingternet.com (c-24-126-232-43.hsd1.ca.comcast.net [24.126.232.43]) by ying.yingternet.com (Postfix) with ESMTP id 14CD73000AD; Thu, 22 Sep 2005 07:30:28 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id 55A70204C18; Thu, 22 Sep 2005 07:29:33 -0700 (PDT) Message-ID: <4332BFCC.8050803@yingternet.com> Date: Thu, 22 Sep 2005 22:29:32 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com, Ying-Hung Chen Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> In-Reply-To: <4332A22B.6070708@sgi.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 800 Lines: 24 > > See the xfsctl man page from xfsprogs, specifically XFS_IOC_RESVSP > > creating a sparse file will not help with fragmentation, unfortunately. > Hello again, Thanks for the info, here are more specifics on what we are trying to do: we have 200GB of harddive and would like to create 90-95 of 'video' file, each with 2GBs (data will be writting to each file continuesly, just like a tape). and we are hoping that if can write to the same physical place all the time, there won't be any fragmentation problem.... we are wondering if there are any xfs parameters we can do (e.g. volumes groups?) for the above to 'gaurantee' the best layout since we are not going to create/delete files once created all those Video files, all we are doing are overwriting files continuesly. Thanks, -Ying From owner-linux-xfs@oss.sgi.com Thu Sep 22 07:42:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 07:43:04 -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 j8MEguiL009268 for ; Thu, 22 Sep 2005 07:42:59 -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 j8MFgYDr017307 for ; Thu, 22 Sep 2005 08:42:34 -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 j8MEe9sL22106611; Thu, 22 Sep 2005 09:40:09 -0500 (CDT) Message-ID: <4332C248.70503@sgi.com> Date: Thu, 22 Sep 2005 09:40:08 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ying-Hung Chen CC: linux-xfs@oss.sgi.com Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> In-Reply-To: <4332BFCC.8050803@yingternet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6216 X-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: 1173 Lines: 31 Ying-Hung Chen wrote: >>See the xfsctl man page from xfsprogs, specifically XFS_IOC_RESVSP >> >>creating a sparse file will not help with fragmentation, unfortunately. >> > > > Hello again, > > Thanks for the info, here are more specifics on what we are trying to do: > > we have 200GB of harddive and would like to create 90-95 of 'video' > file, each with 2GBs (data will be writting to each file continuesly, > just like a tape). and we are hoping that if can write to the same > physical place all the time, there won't be any fragmentation problem.... > > we are wondering if there are any xfs parameters we can do (e.g. volumes > groups?) for the above to 'gaurantee' the best layout since we are not > going to create/delete files once created all those Video files, all we > are doing are overwriting files continuesly. pre-allocation before writing would still be your best bet. If you pre-allocate on a fresh fs before writing, you should get very large extents. Other things you could try; if you put each file in its own dir, it will tend to go into its own allocation group. You could make the filesystem with allocation groups sized at 2GB -Eric From owner-linux-xfs@oss.sgi.com Thu Sep 22 07:59:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 07:59:47 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8MExhiL012260 for ; Thu, 22 Sep 2005 07:59:43 -0700 Received: from gateway-att.yingternet.com (c-24-126-232-43.hsd1.ca.comcast.net [24.126.232.43]) by ying.yingternet.com (Postfix) with ESMTP id BA1A03000AD; Thu, 22 Sep 2005 07:57:50 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id 1DF76204C18; Thu, 22 Sep 2005 07:56:56 -0700 (PDT) Message-ID: <4332C636.9070509@yingternet.com> Date: Thu, 22 Sep 2005 22:56:54 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> In-Reply-To: <4332C248.70503@sgi.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 679 Lines: 21 > pre-allocation before writing would still be your best bet. If you > pre-allocate on a fresh fs before writing, you should get very large > extents. does this mean, if I create a 2GB file via dd (not sparse file), when i 'overwrite' to the same file, it will stay there? (same physical place) > > Other things you could try; if you put each file in its own dir, it will > tend to go into its own allocation group. > > You could make the filesystem with allocation groups sized at 2GB > I just thought of wild idea... since i am creating 90 files, what if i just create 90 allocation group via -d agcount=90, does this make sense or it won't work at all? Thanks, -Ying From owner-linux-xfs@oss.sgi.com Thu Sep 22 08:07:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 08:07:44 -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 j8MF7diL013342 for ; Thu, 22 Sep 2005 08:07:39 -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 j8MF4rxT011181 for ; Thu, 22 Sep 2005 10:04:53 -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 j8MF4qsL22109416; Thu, 22 Sep 2005 10:04:52 -0500 (CDT) Message-ID: <4332C813.2000702@sgi.com> Date: Thu, 22 Sep 2005 10:04:51 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ying-Hung Chen CC: linux-xfs@oss.sgi.com Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> In-Reply-To: <4332C636.9070509@yingternet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6218 X-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: 954 Lines: 30 Ying-Hung Chen wrote: >>pre-allocation before writing would still be your best bet. If you >>pre-allocate on a fresh fs before writing, you should get very large >>extents. > > > does this mean, if I create a 2GB file via dd (not sparse file), when i > 'overwrite' to the same file, it will stay there? (same physical place) Depends on if you truncate it before you re-write to it, I think. But don't use dd - use xfs's preallocation calls, it will be MUCH more efficient. >>Other things you could try; if you put each file in its own dir, it will >>tend to go into its own allocation group. >> >>You could make the filesystem with allocation groups sized at 2GB >> > > > I just thought of wild idea... since i am creating 90 files, what if i > just create 90 allocation group via -d agcount=90, does this make sense > or it won't work at all? well, give it a shot. But I'd try the preallocation calls first - that's what they are for. -Eric From owner-linux-xfs@oss.sgi.com Thu Sep 22 08:34:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 08:34:48 -0700 (PDT) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j8MFYaiL024904 for ; Thu, 22 Sep 2005 08:34:37 -0700 Received: (qmail 44237 invoked from network); 22 Sep 2005 15:31:50 -0000 Received: from unknown (HELO ?192.168.68.38?) (a?ho@rogers.com@69.199.166.249 with plain) by smtp102.rog.mail.re2.yahoo.com with SMTP; 22 Sep 2005 15:31:50 -0000 Message-ID: <4332CE65.2000500@animezone.org> Date: Thu, 22 Sep 2005 11:31:49 -0400 From: Andrew Ho User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050729 X-Accept-Language: en-us, en, zh-hk, zh-cn MIME-Version: 1.0 To: Ying-Hung Chen CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> In-Reply-To: <4332C636.9070509@yingternet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrewho@animezone.org Precedence: bulk X-list: linux-xfs Content-Length: 1490 Lines: 53 Ying-Hung Chen wrote: >>pre-allocation before writing would still be your best bet. If you >>pre-allocate on a fresh fs before writing, you should get very large >>extents. >> >> > >does this mean, if I create a 2GB file via dd (not sparse file), when i >'overwrite' to the same file, it will stay there? (same physical place) > > >>Other things you could try; if you put each file in its own dir, it will >>tend to go into its own allocation group. >> >>You could make the filesystem with allocation groups sized at 2GB >> >> >> > >I just thought of wild idea... since i am creating 90 files, what if i >just create 90 allocation group via -d agcount=90, does this make sense >or it won't work at all? > >Thanks, > >-Ying > > > > From reading your emails, I don't think that it is the problem of the fragmentation. I understand that we don't need to defragment the filesystem while we are working on the unix/linux. I don't need to deframentation a raid drive, which the size is 2TB, with XFS filesystem. I guess while you played your video file, which was 2GB. Your video images were not smoothly shown on the player. It gave you an impression that there was a problem on the filesystem. I don't know whether your 200GB drive is an ATA, SATA or SCSI drive. A fast SCSI drive is the best drive for the video stream. If you can stipe several SCSI drives into a volume, and the performance will be improved. I hope that I can help you to solve your problem. Andrew From owner-linux-xfs@oss.sgi.com Thu Sep 22 08:37:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 08:37:22 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8MFbHiL025464 for ; Thu, 22 Sep 2005 08:37:18 -0700 Received: from gateway-att.yingternet.com (c-24-126-232-43.hsd1.ca.comcast.net [24.126.232.43]) by ying.yingternet.com (Postfix) with ESMTP id 2275F3000AD; Thu, 22 Sep 2005 08:35:25 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id 346EC204C18; Thu, 22 Sep 2005 08:34:30 -0700 (PDT) Message-ID: <4332CF04.2060604@yingternet.com> Date: Thu, 22 Sep 2005 23:34:28 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Ho Cc: Eric Sandeen , linux-xfs@oss.sgi.com, Ying-Hung Chen Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> <4332CE65.2000500@animezone.org> In-Reply-To: <4332CE65.2000500@animezone.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 360 Lines: 13 > > I guess while you played your video file, which was 2GB. Your video > images were not smoothly > shown on the player. It gave you an impression that there was a problem > on the filesystem. > actually, performance is the problem got my attention, and when i run xfs_db and check the fragmentation, its well over 95% on one 200GB partition...... -Ying From owner-linux-xfs@oss.sgi.com Thu Sep 22 08:42:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 08:42:27 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8MFgNiL026264 for ; Thu, 22 Sep 2005 08:42:24 -0700 Received: from gateway-att.yingternet.com (c-24-126-232-43.hsd1.ca.comcast.net [24.126.232.43]) by ying.yingternet.com (Postfix) with ESMTP id 889D23000AD; Thu, 22 Sep 2005 08:40:31 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id 101B8204C18; Thu, 22 Sep 2005 08:39:37 -0700 (PDT) Message-ID: <4332D037.6080501@yingternet.com> Date: Thu, 22 Sep 2005 23:39:35 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com, Ying-Hung Chen Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> <4332C813.2000702@sgi.com> In-Reply-To: <4332C813.2000702@sgi.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 484 Lines: 23 > > Depends on if you truncate it before you re-write to it, I think. > > But don't use dd - use xfs's preallocation calls, it will be MUCH more > efficient. > okay, I'll give it a try tomorrow, just want to make sure, int xfsctl (const char *path, int fd, int cmd, void *ptr); path is actually the filename right? and fd is the FILE* where I open the filename correct? I'll be using XFS_IOC_RESVSP, and pass in xfs_flock64_t structure as the final argument? Thanks, -Ying From owner-linux-xfs@oss.sgi.com Thu Sep 22 08:48:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 08:48: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 j8MFmpiL027185 for ; Thu, 22 Sep 2005 08:48:51 -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 j8MGmTsv027908 for ; Thu, 22 Sep 2005 09:48:29 -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 j8MFj2sL22113739; Thu, 22 Sep 2005 10:45:03 -0500 (CDT) Message-ID: <4332D17E.6060608@sgi.com> Date: Thu, 22 Sep 2005 10:45:02 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ying-Hung Chen CC: Andrew Ho , linux-xfs@oss.sgi.com Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> <4332CE65.2000500@animezone.org> <4332CF04.2060604@yingternet.com> In-Reply-To: <4332CF04.2060604@yingternet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6222 X-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: 1384 Lines: 53 Ying-Hung Chen wrote: >>I guess while you played your video file, which was 2GB. Your video >>images were not smoothly >>shown on the player. It gave you an impression that there was a problem >>on the filesystem. >> > > > actually, performance is the problem got my attention, and when i run > xfs_db and check the fragmentation, its well over 95% on one 200GB > partition...... run xfs_bmap on a few files, and see how bad it really is. That number can be misleading, sometimes. but preallocation is an easy way to mitigate any fragmentation problems. something like this: int main(int argc, char **argv) { int fd, err; xfs_flock64_t fl; fl.l_whence = 0; fl.l_start = 1; fl.l_len = (off64_t)(20 * 1024 * 1024); /* 20M */ if(argc != 2) return fprintf(stderr, "Filename expected.\n"), 1; fd = open(argv[1], O_RDWR|O_CREAT, 0666); if (fd < 0) { perror("open: "); printf("open of file %s failed\n", argv[1]); exit(1); } err = xfsctl(argv[1], fd, XFS_IOC_RESVSP64, &fl); if (err < 0) { perror("allocsp: "); printf("XFS_IOC_RESVSP64 failed\n"); close(fd); exit(1); } close(fd); return 0; } -Eric From owner-linux-xfs@oss.sgi.com Thu Sep 22 15:27:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 15:27:24 -0700 (PDT) Received: from flyingAngel.upjs.sk (gate.rudna.net [195.122.192.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8MMREiL000391 for ; Thu, 22 Sep 2005 15:27:15 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 72E78100127; Fri, 23 Sep 2005 00:23:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 70EDC180122 for ; Fri, 23 Sep 2005 00:23:59 +0200 (CEST) Date: Fri, 23 Sep 2005 00:23:59 +0200 (CEST) From: Jan Derfinak To: linux-xfs@oss.sgi.com Subject: xfs_repair: dinode.c:2436: process_dinode_int: Assertion `err == 0' failed. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6223 X-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 Content-Length: 7136 Lines: 206 Hello. I controled my FS's with "xfs_repair -n" to be sure that they are error free. Everything is OK but FS on disk hda9. I can do clean mount and umount of hda9. xfs_check do not notice any errors. But output of xfs_repair: # xfs_repair -n /dev/hda9 Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... block (0,223632) multiply claimed by bno space tree, state - 1 block (1,223632) multiply claimed by bno space tree, state - 1 block (2,223632) multiply claimed by bno space tree, state - 1 block (4,223632) multiply claimed by bno space tree, state - 1 block (8,223632) multiply claimed by bno space tree, state - 1 block (9,223632) multiply claimed by bno space tree, state - 1 block (10,223632) multiply claimed by bno space tree, state - 1 block (11,223632) multiply claimed by bno space tree, state - 1 block (13,223632) multiply claimed by bno space tree, state - 1 block (14,223632) multiply claimed by bno space tree, state - 1 block (15,223632) multiply claimed by bno space tree, state - 1 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 data fork in ino 16152860 claims free block 1010064 - agno = 4 data fork in ino 16791313 claims free block 1534352 - agno = 5 - agno = 6 data fork in ino 25176869 claims free block 1796496 data fork in ino 25176898 claims free block 2058640 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 data fork in ino 53909610 claims free block 3369360 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 data fork in regular inode 16152860 claims used block 1010064 would have cleared inode 16152860 - agno = 4 data fork in regular inode 16791313 claims used block 1534352 would have cleared inode 16791313 entry "140_4023.JPG" at block 0 offset 2376 in directory inode 17462732 referenc es free inode 16791313 would clear inode number in entry at offset 2376... - agno = 5 - agno = 6 data fork in regular inode 25176869 claims used block 1796496 would have cleared inode 25176869 data fork in regular inode 25176898 claims used block 2058640 would have cleared inode 25176898 entry "del8s.jpg" at block 0 offset 1392 in directory inode 26502965 references free inode 25176869 would clear inode number in entry at offset 1392... entry "Rea4s.JPG" at block 0 offset 2088 in directory inode 26502965 references free inode 25176898 would clear inode number in entry at offset 2088... - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 data fork in regular inode 53909610 claims used block 3369360 would have cleared inode 53909610 - agno = 13 - agno = 14 - agno = 15 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... Segmentation fault # xfs_repair /dev/hda9 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... block (0,223632) multiply claimed by bno space tree, state - 1 block (1,223632) multiply claimed by bno space tree, state - 1 block (2,223632) multiply claimed by bno space tree, state - 1 block (4,223632) multiply claimed by bno space tree, state - 1 block (8,223632) multiply claimed by bno space tree, state - 1 block (9,223632) multiply claimed by bno space tree, state - 1 block (10,223632) multiply claimed by bno space tree, state - 1 block (11,223632) multiply claimed by bno space tree, state - 1 block (13,223632) multiply claimed by bno space tree, state - 1 block (14,223632) multiply claimed by bno space tree, state - 1 block (15,223632) multiply claimed by bno space tree, state - 1 - 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 data fork in ino 16152860 claims free block 1010064 - agno = 4 data fork in ino 16791313 claims free block 1534352 - agno = 5 - agno = 6 data fork in ino 25176869 claims free block 1796496 data fork in ino 25176898 claims free block 2058640 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 data fork in ino 53909610 claims free block 3369360 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 data fork in regular inode 16152860 claims used block 1010064 xfs_repair: dinode.c:2436: process_dinode_int: Assertion `err == 0' failed. # xfs_info /mnt/mnt meta-data=/dev/hda9 isize=256 agcount=16, agsize=223633 blks = sectsz=512 data = bsize=4096 blocks=3578128, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # xfs_db /dev/hda9 xfs_db> inode 16152860 xfs_db> print core.magic = 0x494e core.mode = 0100644 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 1 core.uid = 500 core.gid = 500 core.flushiter = 5 core.atime.sec = Thu Aug 11 23:12:14 2005 core.atime.nsec = 855897961 core.mtime.sec = Thu Aug 11 23:12:14 2005 core.mtime.nsec = 856897741 core.ctime.sec = Thu Aug 11 23:12:14 2005 core.ctime.nsec = 856897741 core.size = 5898 core.nblocks = 2 core.extsize = 0 core.nextents = 1 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 = 1 next_unlinked = null u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,1010063,2,0] Xfs_repair is from xfsprogs-2.7.1. Computer is amd64 with 512M memory and kernel SGI-XFS CVS-2005-09-21_05:00_UTC with ACLs, large block/inode numbers, no debug enabled. Is it bug in xfs_repair? How can I repair this FS? Should I delete inode with xfs_db? Can you write me how? jan -- From owner-linux-xfs@oss.sgi.com Thu Sep 22 17:22:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 17:22:09 -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 j8N0M6iL014461 for ; Thu, 22 Sep 2005 17:22:06 -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 j8N1LlMr002139 for ; Thu, 22 Sep 2005 18:21:48 -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 j8N0JJDN16200628; Thu, 22 Sep 2005 19:19:19 -0500 (CDT) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j8N0JILL8233583; Thu, 22 Sep 2005 19:19:19 -0500 (CDT) Subject: Re: xfs_repair: dinode.c:2436: process_dinode_int: Assertion `err == 0' failed. From: Russell Cattelan To: Jan Derfinak Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Sep 2005 19:19:18 -0500 Message-Id: <1127434758.12309.36.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4-3.1.102mdk Content-Transfer-Encoding: 7bit X-archive-position: 6224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 7642 Lines: 212 On Fri, 2005-09-23 at 00:23 +0200, Jan Derfinak wrote: > Hello. > > I controled my FS's with "xfs_repair -n" to be sure that they are error > free. Everything is OK but FS on disk hda9. I can do clean mount and umount > of hda9. xfs_check do not notice any errors. But output of xfs_repair: > # xfs_repair -n /dev/hda9 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - scan filesystem freespace and inode maps... > block (0,223632) multiply claimed by bno space tree, state - 1 > block (1,223632) multiply claimed by bno space tree, state - 1 > block (2,223632) multiply claimed by bno space tree, state - 1 > block (4,223632) multiply claimed by bno space tree, state - 1 > block (8,223632) multiply claimed by bno space tree, state - 1 > block (9,223632) multiply claimed by bno space tree, state - 1 > block (10,223632) multiply claimed by bno space tree, state - 1 > block (11,223632) multiply claimed by bno space tree, state - 1 > block (13,223632) multiply claimed by bno space tree, state - 1 > block (14,223632) multiply claimed by bno space tree, state - 1 > block (15,223632) multiply claimed by bno space tree, state - 1 > - found root inode chunk > Phase 3 - for each AG... > - scan (but don't clear) agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > data fork in ino 16152860 claims free block 1010064 > - agno = 4 > data fork in ino 16791313 claims free block 1534352 > - agno = 5 > - agno = 6 > data fork in ino 25176869 claims free block 1796496 > data fork in ino 25176898 claims free block 2058640 > - agno = 7 > - agno = 8 > - agno = 9 > - agno = 10 > - agno = 11 > - agno = 12 > data fork in ino 53909610 claims free block 3369360 > - agno = 13 > - agno = 14 > - agno = 15 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > data fork in regular inode 16152860 claims used block 1010064 > would have cleared inode 16152860 > - agno = 4 > data fork in regular inode 16791313 claims used block 1534352 > would have cleared inode 16791313 > entry "140_4023.JPG" at block 0 offset 2376 in directory inode 17462732 > referenc > es free inode 16791313 > would clear inode number in entry at offset 2376... > - agno = 5 > - agno = 6 > data fork in regular inode 25176869 claims used block 1796496 > would have cleared inode 25176869 > data fork in regular inode 25176898 claims used block 2058640 > would have cleared inode 25176898 > entry "del8s.jpg" at block 0 offset 1392 in directory inode 26502965 > references > free inode 25176869 > would clear inode number in entry at offset 1392... > entry "Rea4s.JPG" at block 0 offset 2088 in directory inode 26502965 > references > free inode 25176898 > would clear inode number in entry at offset 2088... > - agno = 7 > - agno = 8 > - agno = 9 > - agno = 10 > - agno = 11 > - agno = 12 > data fork in regular inode 53909610 claims used block 3369360 > would have cleared inode 53909610 > - agno = 13 > - agno = 14 > - agno = 15 > No modify flag set, skipping phase 5 > Phase 6 - check inode connectivity... > Segmentation fault > > # xfs_repair /dev/hda9 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > block (0,223632) multiply claimed by bno space tree, state - 1 > block (1,223632) multiply claimed by bno space tree, state - 1 > block (2,223632) multiply claimed by bno space tree, state - 1 > block (4,223632) multiply claimed by bno space tree, state - 1 > block (8,223632) multiply claimed by bno space tree, state - 1 > block (9,223632) multiply claimed by bno space tree, state - 1 > block (10,223632) multiply claimed by bno space tree, state - 1 > block (11,223632) multiply claimed by bno space tree, state - 1 > block (13,223632) multiply claimed by bno space tree, state - 1 > block (14,223632) multiply claimed by bno space tree, state - 1 > block (15,223632) multiply claimed by bno space tree, state - 1 > - 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 > data fork in ino 16152860 claims free block 1010064 > - agno = 4 > data fork in ino 16791313 claims free block 1534352 > - agno = 5 > - agno = 6 > data fork in ino 25176869 claims free block 1796496 > data fork in ino 25176898 claims free block 2058640 > - agno = 7 > - agno = 8 > - agno = 9 > - agno = 10 > - agno = 11 > - agno = 12 > data fork in ino 53909610 claims free block 3369360 > - agno = 13 > - agno = 14 > - agno = 15 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - clear lost+found (if it exists) ... > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > data fork in regular inode 16152860 claims used block 1010064 > xfs_repair: dinode.c:2436: process_dinode_int: Assertion `err == 0' failed. > > # xfs_info /mnt/mnt > meta-data=/dev/hda9 isize=256 agcount=16, agsize=223633 blks > = sectsz=512 > data = bsize=4096 blocks=3578128, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=2560, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > # xfs_db /dev/hda9 > xfs_db> inode 16152860 > xfs_db> print > core.magic = 0x494e > core.mode = 0100644 > core.version = 1 > core.format = 2 (extents) > core.nlinkv1 = 1 > core.uid = 500 > core.gid = 500 > core.flushiter = 5 > core.atime.sec = Thu Aug 11 23:12:14 2005 > core.atime.nsec = 855897961 > core.mtime.sec = Thu Aug 11 23:12:14 2005 > core.mtime.nsec = 856897741 > core.ctime.sec = Thu Aug 11 23:12:14 2005 > core.ctime.nsec = 856897741 > core.size = 5898 > core.nblocks = 2 > core.extsize = 0 > core.nextents = 1 > 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 = 1 > next_unlinked = null > u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,1010063,2,0] > > Xfs_repair is from xfsprogs-2.7.1. Computer is amd64 with 512M memory and > kernel SGI-XFS CVS-2005-09-21_05:00_UTC with ACLs, large block/inode > numbers, no debug enabled. > > Is it bug in xfs_repair? probably no > How can I repair this FS? run xfs_repair without -n > Should I delete inode > with xfs_db? Can you write me how? > > jan > From owner-linux-xfs@oss.sgi.com Thu Sep 22 17:58:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 17:58: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 j8N0wHiL017750 for ; Thu, 22 Sep 2005 17:58: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 KAA29037 for ; Fri, 23 Sep 2005 10:55:27 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id C8FDC49BFAF1; Fri, 23 Sep 2005 10:55:25 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 943122 - mongo header update Message-Id: <20050923005525.C8FDC49BFAF1@chook.melbourne.sgi.com> Date: Fri, 23 Sep 2005 10:55:25 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6225 X-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: 46269 Lines: 685 Remove xfs_macros.c, xfs_macros.h, rework headers a whole lot. Ended up switching all to inlines/macros - the variants that were expanded as functions already, weren't helping... [NON-DEBUG BEFORE] 8:23 fsgqa@bruce ~/isms/xfs-linux 108> size xfs.o text data bss dec hex filename 519344 4479 1208 525031 802e7 xfs.o [NON-DEBUG AFTER] 20:46 fsgqa@bruce ~/isms/xfs-linux 124> size xfs.o text data bss dec hex filename 514137 4447 1208 519792 7ee70 xfs.o Date: Fri Sep 23 10:42:42 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan,hch,overby,tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23901a xfsidbg.c - 1.283 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.283&r2=text&tr2=1.282&f=h xfs_log.c - 1.310 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.310&r2=text&tr2=1.309&f=h xfs_inum.h - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inum.h.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h xfs_ialloc.h - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h xfs_ialloc.c - 1.181 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.181&r2=text&tr2=1.180&f=h xfs_ag.h - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ag.h.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h xfs_rw.h - 1.76 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rw.h.diff?r1=text&tr1=1.76&r2=text&tr2=1.75&f=h xfs_rw.c - 1.391 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rw.c.diff?r1=text&tr1=1.391&r2=text&tr2=1.390&f=h xfs_extfree_item.c - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.c.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h xfs_buf_item.c - 1.153 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.c.diff?r1=text&tr1=1.153&r2=text&tr2=1.152&f=h xfs_trans_inode.c - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_inode.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h xfs_attr_sf.h - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_sf.h.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h xfs_log_priv.h - 1.108 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.108&r2=text&tr2=1.107&f=h xfs_da_btree.c - 1.156 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.156&r2=text&tr2=1.155&f=h xfs_da_btree.h - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.h.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h xfs.h - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h xfs_bit.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bit.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfs_sb.h - 1.64 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_sb.h.diff?r1=text&tr1=1.64&r2=text&tr2=1.63&f=h xfs_trans_ail.c - 1.75 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_ail.c.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h xfs_vnodeops.c - 1.652 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.652&r2=text&tr2=1.651&f=h xfs_dir2_block.c - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_block.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h xfs_dir2_block.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_block.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfs_dir.c - 1.163 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir.c.diff?r1=text&tr1=1.163&r2=text&tr2=1.162&f=h xfs_rtalloc.c - 1.95 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.95&r2=text&tr2=1.94&f=h xfs_itable.c - 1.130 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.130&r2=text&tr2=1.129&f=h xfs_ialloc_btree.h - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfs_ialloc_btree.c - 1.79 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.c.diff?r1=text&tr1=1.79&r2=text&tr2=1.78&f=h xfs_dmapi.c - 1.132 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dmapi.c.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h xfs_inode_item.c - 1.121 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.c.diff?r1=text&tr1=1.121&r2=text&tr2=1.120&f=h xfs_inode_item.h - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h xfs_iocore.c - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iocore.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h xfs_log_recover.c - 1.300 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.300&r2=text&tr2=1.299&f=h xfs_trans_item.c - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_item.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h xfs_vfsops.c - 1.478 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.478&r2=text&tr2=1.477&f=h xfs_dfrag.c - 1.49 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dfrag.c.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h xfs_iget.c - 1.207 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.207&r2=text&tr2=1.206&f=h xfs_bmap_btree.h - 1.69 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.h.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h xfs_bmap_btree.c - 1.148 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.148&r2=text&tr2=1.147&f=h xfs_dir2_sf.h - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.h.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h xfs_dir2_sf.c - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h xfs_dir_leaf.c - 1.126 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h xfs_dir_leaf.h - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.h.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h xfs_mount.h - 1.206 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.206&r2=text&tr2=1.205&f=h xfs_mount.c - 1.363 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.363&r2=text&tr2=1.362&f=h xfs_btree.c - 1.111 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.c.diff?r1=text&tr1=1.111&r2=text&tr2=1.110&f=h xfs_btree.h - 1.59 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.h.diff?r1=text&tr1=1.59&r2=text&tr2=1.58&f=h xfs_dir2_data.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_data.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfs_dir2_data.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_data.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfs_acl.c - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.c.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h xfs_trans_extfree.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_extfree.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h xfs_inode.c - 1.419 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.419&r2=text&tr2=1.418&f=h xfs_inode.h - 1.203 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.203&r2=text&tr2=1.202&f=h xfs_dir2_trace.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_trace.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h xfs_qmops.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_qmops.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfs_dir2_leaf.c - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h xfs_dir2_leaf.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfs_attr_leaf.h - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.h.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h xfs_attr_leaf.c - 1.85 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h xfs_trans.c - 1.165 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.165&r2=text&tr2=1.164&f=h xfs_trans.h - 1.134 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.h.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h xfs_error.c - 1.51 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.c.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h xfs_error.h - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.h.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h xfs_utils.c - 1.67 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.c.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h xfs_dir_sf.h - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_sf.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfs_alloc.c - 1.175 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.175&r2=text&tr2=1.174&f=h xfs_fsops.c - 1.106 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.106&r2=text&tr2=1.105&f=h xfs_dmops.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dmops.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfs_bmap.h - 1.90 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.h.diff?r1=text&tr1=1.90&r2=text&tr2=1.89&f=h xfs_bmap.c - 1.330 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.330&r2=text&tr2=1.329&f=h xfs_alloc_btree.h - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfs_alloc_btree.c - 1.83 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.c.diff?r1=text&tr1=1.83&r2=text&tr2=1.82&f=h xfs_trans_buf.c - 1.122 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_buf.c.diff?r1=text&tr1=1.122&r2=text&tr2=1.121&f=h xfs_dir2_node.c - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_node.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h xfs_dir2_node.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_node.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfs_rename.c - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rename.c.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h xfs_attr.c - 1.125 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h xfs_dir2.c - 1.51 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2.c.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h xfs_dinode.h - 1.75 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dinode.h.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h quota/xfs_trans_dquot.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_trans_dquot.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h quota/xfs_qm_bhv.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_bhv.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h quota/xfs_qm_stats.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_stats.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h quota/xfs_qm_syscalls.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h quota/xfs_dquot_item.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot_item.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h quota/xfs_dquot.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h quota/xfs_qm.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h xfs_refcache.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_refcache.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Makefile-linux-2.6 - 1.198 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.6.diff?r1=text&tr1=1.198&r2=text&tr2=1.197&f=h Makefile-linux-2.4 - 1.211 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.4.diff?r1=text&tr1=1.211&r2=text&tr2=1.210&f=h xfs_iomap.c - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h linux-2.6/xfs_lrw.h - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.h.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h linux-2.6/xfs_lrw.c - 1.228 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.228&r2=text&tr2=1.227&f=h linux-2.6/xfs_ioctl.c - 1.124 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h linux-2.6/xfs_vfs.c - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.c.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h linux-2.6/xfs_file.c - 1.126 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h linux-2.6/xfs_super.c - 1.346 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.346&r2=text&tr2=1.345&f=h linux-2.6/xfs_iops.c - 1.228 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.228&r2=text&tr2=1.227&f=h linux-2.6/xfs_aops.c - 1.96 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.96&r2=text&tr2=1.95&f=h linux-2.6/xfs_sysctl.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h linux-2.4/xfs_lrw.h - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h linux-2.4/xfs_lrw.c - 1.223 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.c.diff?r1=text&tr1=1.223&r2=text&tr2=1.222&f=h linux-2.4/xfs_ioctl.c - 1.120 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.120&r2=text&tr2=1.119&f=h linux-2.4/xfs_vfs.c - 1.59 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.c.diff?r1=text&tr1=1.59&r2=text&tr2=1.58&f=h linux-2.4/xfs_file.c - 1.117 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_file.c.diff?r1=text&tr1=1.117&r2=text&tr2=1.116&f=h linux-2.4/xfs_super.c - 1.315 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.315&r2=text&tr2=1.314&f=h linux-2.4/xfs_iops.c - 1.212 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.212&r2=text&tr2=1.211&f=h linux-2.4/xfs_aops.c - 1.92 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.92&r2=text&tr2=1.91&f=h linux-2.4/xfs_sysctl.c - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_sysctl.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h linux-2.6/xfs_ksyms.c - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h linux-2.4/xfs_ksyms.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h quota/xfs_qm_ksyms.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_ksyms.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h Remove xfs_macros.c, xfs_macros.h, rework headers a whole lot. Date: Fri Sep 23 10:43:37 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan,hch,overby,tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23902a xfs_macros.c - 1.60 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_macros.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h xfs_macros.h - 1.23 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_macros.h.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h Update license/copyright notices to match the prefered SGI boilerplate. Date: Fri Sep 23 10:52:04 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:23903a xfs_trans_space.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_space.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsidbg.c - 1.284 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.284&r2=text&tr2=1.283&f=h xfs_log.h - 1.75 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.h.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h xfs_log.c - 1.311 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.311&r2=text&tr2=1.310&f=h xfs_inum.h - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inum.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h xfs_ialloc.h - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h xfs_ialloc.c - 1.182 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.182&r2=text&tr2=1.181&f=h xfs_ag.h - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ag.h.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h xfs_rw.h - 1.77 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rw.h.diff?r1=text&tr1=1.77&r2=text&tr2=1.76&f=h xfs_rw.c - 1.392 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rw.c.diff?r1=text&tr1=1.392&r2=text&tr2=1.391&f=h xfs_extfree_item.h - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfs_extfree_item.c - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.c.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h xfs_buf_item.h - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.h.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h xfs_buf_item.c - 1.154 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.c.diff?r1=text&tr1=1.154&r2=text&tr2=1.153&f=h xfs_trans_inode.c - 1.51 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_inode.c.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h xfs_trans_priv.h - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_priv.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfs_attr_sf.h - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_sf.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h xfs_log_priv.h - 1.109 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.109&r2=text&tr2=1.108&f=h xfs_da_btree.c - 1.157 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.157&r2=text&tr2=1.156&f=h xfs_da_btree.h - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.h.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h xfs.h - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h xfs_bit.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bit.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfs_bit.c - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bit.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h xfs_sb.h - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_sb.h.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h xfs_mac.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mac.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfs_trans_ail.c - 1.76 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_ail.c.diff?r1=text&tr1=1.76&r2=text&tr2=1.75&f=h xfs_vnodeops.c - 1.653 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.653&r2=text&tr2=1.652&f=h xfs_dir2_block.c - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_block.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h xfs_dir2_block.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_block.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfs_fs.h - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fs.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfs_dir.h - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir.h.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h xfs_dir.c - 1.164 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir.c.diff?r1=text&tr1=1.164&r2=text&tr2=1.163&f=h xfs_arch.h - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_arch.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h xfs_rtalloc.h - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfs_rtalloc.c - 1.96 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.96&r2=text&tr2=1.95&f=h xfs_itable.c - 1.131 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.131&r2=text&tr2=1.130&f=h xfs_itable.h - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h xfs_ialloc_btree.h - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h xfs_ialloc_btree.c - 1.80 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.c.diff?r1=text&tr1=1.80&r2=text&tr2=1.79&f=h xfs_cap.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_cap.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfs_dmapi.h - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dmapi.h.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h xfs_dmapi.c - 1.133 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dmapi.c.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h xfs_inode_item.c - 1.122 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.c.diff?r1=text&tr1=1.122&r2=text&tr2=1.121&f=h xfs_inode_item.h - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h xfs_iocore.c - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iocore.c.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h xfs_log_recover.h - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfs_log_recover.c - 1.301 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.301&r2=text&tr2=1.300&f=h xfs_trans_item.c - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_item.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h xfs_vfsops.c - 1.479 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.479&r2=text&tr2=1.478&f=h xfs_dfrag.c - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dfrag.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h xfs_dfrag.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dfrag.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfs_iget.c - 1.208 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.208&r2=text&tr2=1.207&f=h xfs_clnt.h - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_clnt.h.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h xfs_bmap_btree.h - 1.70 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.h.diff?r1=text&tr1=1.70&r2=text&tr2=1.69&f=h xfs_bmap_btree.c - 1.149 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.149&r2=text&tr2=1.148&f=h xfs_dir2_sf.h - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h xfs_dir2_sf.c - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h xfs_dir_leaf.c - 1.127 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.c.diff?r1=text&tr1=1.127&r2=text&tr2=1.126&f=h xfs_dir_leaf.h - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h xfs_mount.h - 1.207 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.207&r2=text&tr2=1.206&f=h xfs_mount.c - 1.364 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.364&r2=text&tr2=1.363&f=h xfs_btree.c - 1.112 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.c.diff?r1=text&tr1=1.112&r2=text&tr2=1.111&f=h xfs_btree.h - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.h.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h xfs_dir2_data.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_data.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfs_dir2_data.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_data.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfs_acl.h - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.h.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h xfs_acl.c - 1.56 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.c.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h xfs_trans_extfree.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_extfree.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h xfs_inode.c - 1.420 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.420&r2=text&tr2=1.419&f=h xfs_inode.h - 1.204 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.204&r2=text&tr2=1.203&f=h xfs_dir2_trace.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_trace.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h xfs_dir2_trace.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_trace.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfs_qmops.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_qmops.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfs_dir2_leaf.c - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h xfs_dir2_leaf.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfs_attr_leaf.h - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.h.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h xfs_attr_leaf.c - 1.86 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.86&r2=text&tr2=1.85&f=h xfs_types.h - 1.79 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_types.h.diff?r1=text&tr1=1.79&r2=text&tr2=1.78&f=h xfs_trans.c - 1.166 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.166&r2=text&tr2=1.165&f=h xfs_trans.h - 1.135 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.h.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h xfs_error.c - 1.52 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h xfs_error.h - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.h.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h xfs_utils.c - 1.68 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.c.diff?r1=text&tr1=1.68&r2=text&tr2=1.67&f=h xfs_utils.h - 1.33 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.h.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h xfs_dir_sf.h - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_sf.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h xfs_alloc.c - 1.176 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.176&r2=text&tr2=1.175&f=h xfs_alloc.h - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.h.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h xfs_fsops.h - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfs_fsops.c - 1.107 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h xfs_dmops.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dmops.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfs_imap.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_imap.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfs_bmap.h - 1.91 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.h.diff?r1=text&tr1=1.91&r2=text&tr2=1.90&f=h xfs_bmap.c - 1.331 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.331&r2=text&tr2=1.330&f=h xfs_alloc_btree.h - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfs_alloc_btree.c - 1.84 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h xfs_quota.h - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_quota.h.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h xfs_trans_buf.c - 1.123 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_buf.c.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h xfs_dir2_node.c - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_node.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h xfs_dir2_node.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_node.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfs_rename.c - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rename.c.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h xfs_attr.c - 1.126 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h xfs_attr.h - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.h.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h xfs_dir2.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfs_dir2.c - 1.52 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h xfs_dinode.h - 1.76 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dinode.h.diff?r1=text&tr1=1.76&r2=text&tr2=1.75&f=h support/debug.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h support/debug.c - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h support/qsort.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/qsort.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h support/qsort.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/qsort.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h support/uuid.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/uuid.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h support/uuid.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/uuid.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h support/move.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/move.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h support/move.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/move.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h support/ktrace.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/ktrace.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h support/ktrace.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/ktrace.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfs_iomap.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfs_refcache.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_refcache.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfs_refcache.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_refcache.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Makefile-linux-2.6 - 1.199 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.6.diff?r1=text&tr1=1.199&r2=text&tr2=1.198&f=h Makefile-linux-2.4 - 1.212 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.4.diff?r1=text&tr1=1.212&r2=text&tr2=1.211&f=h xfs_behavior.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_behavior.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h xfs_behavior.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_behavior.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfs_iomap.c - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h linux-2.6/xfs_lrw.h - 1.51 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.h.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h linux-2.6/xfs_lrw.c - 1.229 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.229&r2=text&tr2=1.228&f=h linux-2.6/xfs_version.h - 1.81 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_version.h.diff?r1=text&tr1=1.81&r2=text&tr2=1.80&f=h linux-2.6/xfs_ioctl.c - 1.125 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h linux-2.6/xfs_vfs.h - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h linux-2.6/xfs_vfs.c - 1.66 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.c.diff?r1=text&tr1=1.66&r2=text&tr2=1.65&f=h linux-2.6/xfs_globals.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_globals.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h linux-2.6/xfs_globals.c - 1.66 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_globals.c.diff?r1=text&tr1=1.66&r2=text&tr2=1.65&f=h linux-2.6/xfs_linux.h - 1.134 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h linux-2.6/xfs_file.c - 1.127 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.127&r2=text&tr2=1.126&f=h linux-2.6/xfs_cred.h - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_cred.h.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h linux-2.6/xfs_vnode.c - 1.134 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h linux-2.6/xfs_vnode.h - 1.112 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.112&r2=text&tr2=1.111&f=h linux-2.6/xfs_stats.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_stats.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h linux-2.6/xfs_stats.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_stats.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h linux-2.6/xfs_fs_subr.c - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_fs_subr.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h linux-2.6/xfs_fs_subr.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_fs_subr.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h linux-2.6/xfs_super.h - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.h.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h linux-2.6/xfs_super.c - 1.347 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.347&r2=text&tr2=1.346&f=h linux-2.6/xfs_iops.c - 1.229 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.229&r2=text&tr2=1.228&f=h linux-2.6/xfs_iops.h - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h linux-2.6/xfs_aops.c - 1.97 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.97&r2=text&tr2=1.96&f=h linux-2.6/xfs_sysctl.c - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.c.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h linux-2.6/xfs_sysctl.h - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h linux-2.4/xfs_lrw.h - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h linux-2.4/xfs_lrw.c - 1.224 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.c.diff?r1=text&tr1=1.224&r2=text&tr2=1.223&f=h linux-2.4/xfs_version.h - 1.172 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_version.h.diff?r1=text&tr1=1.172&r2=text&tr2=1.171&f=h linux-2.4/xfs_ioctl.c - 1.121 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.121&r2=text&tr2=1.120&f=h linux-2.4/xfs_vfs.h - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.h.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h linux-2.4/xfs_vfs.c - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h linux-2.4/xfs_globals.h - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_globals.h.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h linux-2.4/xfs_globals.c - 1.74 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_globals.c.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h linux-2.4/xfs_linux.h - 1.145 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.145&r2=text&tr2=1.144&f=h linux-2.4/xfs_file.c - 1.118 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_file.c.diff?r1=text&tr1=1.118&r2=text&tr2=1.117&f=h linux-2.4/xfs_cred.h - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_cred.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h linux-2.4/xfs_vnode.c - 1.134 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.c.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h linux-2.4/xfs_vnode.h - 1.105 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h linux-2.4/xfs_stats.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_stats.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h linux-2.4/xfs_stats.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_stats.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h linux-2.4/xfs_fs_subr.c - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_fs_subr.c.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h linux-2.4/xfs_fs_subr.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_fs_subr.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h linux-2.4/xfs_super.h - 1.70 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.h.diff?r1=text&tr1=1.70&r2=text&tr2=1.69&f=h linux-2.4/xfs_super.c - 1.316 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.316&r2=text&tr2=1.315&f=h linux-2.4/xfs_iops.c - 1.213 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.213&r2=text&tr2=1.212&f=h linux-2.4/xfs_iops.h - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h linux-2.4/xfs_aops.c - 1.93 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.93&r2=text&tr2=1.92&f=h linux-2.4/xfs_sysctl.c - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_sysctl.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h linux-2.4/xfs_sysctl.h - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_sysctl.h.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h linux-2.6/xfs_buf.h - 1.110 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.110&r2=text&tr2=1.109&f=h linux-2.6/xfs_buf.c - 1.209 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.209&r2=text&tr2=1.208&f=h linux-2.6/kmem.h - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.h.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h linux-2.4/xfs_buf.h - 1.113 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.h.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h linux-2.4/xfs_buf.c - 1.209 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.c.diff?r1=text&tr1=1.209&r2=text&tr2=1.208&f=h linux-2.4/kmem.h - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/kmem.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h linux-2.4/kmem.c - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/kmem.c.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h linux-2.6/xfs_ksyms.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h linux-2.4/xfs_ksyms.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h linux-2.6/sema.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/sema.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h linux-2.6/mrlock.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/mrlock.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h linux-2.6/time.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/time.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h linux-2.6/sv.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/sv.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h linux-2.6/spin.h - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/spin.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h linux-2.6/mutex.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/mutex.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h linux-2.4/sema.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/sema.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h linux-2.4/mrlock.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/mrlock.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h linux-2.4/mrlock.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/mrlock.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h linux-2.4/time.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/time.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h linux-2.4/sv.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/sv.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h linux-2.4/spin.h - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/spin.h.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h linux-2.4/mutex.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/mutex.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h quota/Makefile-linux-2.4 - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/Makefile-linux-2.4.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h quota/Makefile-linux-2.6 - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/Makefile-linux-2.6.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h linux-2.4/mrlock_rwsem.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/mrlock_rwsem.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h linux-2.6/kmem.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h linux-2.6/xfs_ioctl32.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl32.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h linux-2.6/xfs_ioctl32.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl32.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h linux-2.6/xfs_export.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h linux-2.4/xfs_export.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_export.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h linux-2.6/xfs_export.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h linux-2.4/xfs_ioctl32.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl32.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h linux-2.4/xfs_ioctl32.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl32.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h linux-2.6/xfs_aops.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h From owner-linux-xfs@oss.sgi.com Thu Sep 22 23:34:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Sep 2005 23:34:10 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8N6Y1iL019876 for ; Thu, 22 Sep 2005 23:34:02 -0700 Received: from gateway-att.yingternet.com (c-24-126-232-43.hsd1.ca.comcast.net [24.126.232.43]) by ying.yingternet.com (Postfix) with ESMTP id 6C0E33000AD; Thu, 22 Sep 2005 23:32:09 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id 77736204C18; Thu, 22 Sep 2005 23:31:14 -0700 (PDT) Message-ID: <4333A130.7040709@yingternet.com> Date: Fri, 23 Sep 2005 14:31:12 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> <4332CE65.2000500@animezone.org> <4332CF04.2060604@yingternet.com> <4332D17E.6060608@sgi.com> In-Reply-To: <4332D17E.6060608@sgi.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6226 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 963 Lines: 33 > > run xfs_bmap on a few files, and see how bad it really is. That number > can be misleading, sometimes. > > but preallocation is an easy way to mitigate any fragmentation problems. > > something like this: > when I run the sample code, and created "testfile" [yhchen@fc3 ~]$ ./xfs_fcntl testfile [yhchen@fc3 ~]$ ls -l testfile -rwx------ 1 yhchen yhchen 0 Sep 23 14:17 testfile [yhchen@fc3 ~]$ du testfile 20480 testfile [yhchen@fc3 ~]$ du -h testfile 20M testfile I see the filesize is 0, but du does show 20MB However, when I try to determine the file size via fseek, it returns 0. so, what does this kind of allocation mean? does it really mean that it DID allocate 20MB for this file so, if I write anything within this 20MB range, it will be writing to the allocated space and hence no fragmentation? what happens if I go over? my guess is if i go over, xfs allocation algorithm will be and there will be fragamentation? Thanks, -Ying From owner-linux-xfs@oss.sgi.com Fri Sep 23 00:14:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Sep 2005 00:14:52 -0700 (PDT) Received: from flyingAngel.upjs.sk (gprs185-222.eurotel.cz [160.218.185.222]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8N7EdiL024747 for ; Fri, 23 Sep 2005 00:14:41 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 09F18100127; Fri, 23 Sep 2005 09:11:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 06953180122; Fri, 23 Sep 2005 09:11:25 +0200 (CEST) Date: Fri, 23 Sep 2005 09:11:25 +0200 (CEST) From: Jan Derfinak To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair: dinode.c:2436: process_dinode_int: Assertion `err == 0' failed. In-Reply-To: <1127434758.12309.36.camel@naboo.americas.sgi.com> Message-ID: References: <1127434758.12309.36.camel@naboo.americas.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6227 X-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 Content-Length: 8143 Lines: 215 On Thu, 22 Sep 2005, Russell Cattelan wrote: > On Fri, 2005-09-23 at 00:23 +0200, Jan Derfinak wrote: > > Hello. > > > > I controled my FS's with "xfs_repair -n" to be sure that they are error > > free. Everything is OK but FS on disk hda9. I can do clean mount and umount > > of hda9. xfs_check do not notice any errors. But output of xfs_repair: > > # xfs_repair -n /dev/hda9 > > Phase 1 - find and verify superblock... > > Phase 2 - using internal log > > - scan filesystem freespace and inode maps... > > block (0,223632) multiply claimed by bno space tree, state - 1 > > block (1,223632) multiply claimed by bno space tree, state - 1 > > block (2,223632) multiply claimed by bno space tree, state - 1 > > block (4,223632) multiply claimed by bno space tree, state - 1 > > block (8,223632) multiply claimed by bno space tree, state - 1 > > block (9,223632) multiply claimed by bno space tree, state - 1 > > block (10,223632) multiply claimed by bno space tree, state - 1 > > block (11,223632) multiply claimed by bno space tree, state - 1 > > block (13,223632) multiply claimed by bno space tree, state - 1 > > block (14,223632) multiply claimed by bno space tree, state - 1 > > block (15,223632) multiply claimed by bno space tree, state - 1 > > - found root inode chunk > > Phase 3 - for each AG... > > - scan (but don't clear) agi unlinked lists... > > - process known inodes and perform inode discovery... > > - agno = 0 > > - agno = 1 > > - agno = 2 > > - agno = 3 > > data fork in ino 16152860 claims free block 1010064 > > - agno = 4 > > data fork in ino 16791313 claims free block 1534352 > > - agno = 5 > > - agno = 6 > > data fork in ino 25176869 claims free block 1796496 > > data fork in ino 25176898 claims free block 2058640 > > - agno = 7 > > - agno = 8 > > - agno = 9 > > - agno = 10 > > - agno = 11 > > - agno = 12 > > data fork in ino 53909610 claims free block 3369360 > > - agno = 13 > > - agno = 14 > > - agno = 15 > > - process newly discovered inodes... > > Phase 4 - check for duplicate blocks... > > - setting up duplicate extent list... > > - check for inodes claiming duplicate blocks... > > - agno = 0 > > - agno = 1 > > - agno = 2 > > - agno = 3 > > data fork in regular inode 16152860 claims used block 1010064 > > would have cleared inode 16152860 > > - agno = 4 > > data fork in regular inode 16791313 claims used block 1534352 > > would have cleared inode 16791313 > > entry "140_4023.JPG" at block 0 offset 2376 in directory inode 17462732 > > referenc > > es free inode 16791313 > > would clear inode number in entry at offset 2376... > > - agno = 5 > > - agno = 6 > > data fork in regular inode 25176869 claims used block 1796496 > > would have cleared inode 25176869 > > data fork in regular inode 25176898 claims used block 2058640 > > would have cleared inode 25176898 > > entry "del8s.jpg" at block 0 offset 1392 in directory inode 26502965 > > references > > free inode 25176869 > > would clear inode number in entry at offset 1392... > > entry "Rea4s.JPG" at block 0 offset 2088 in directory inode 26502965 > > references > > free inode 25176898 > > would clear inode number in entry at offset 2088... > > - agno = 7 > > - agno = 8 > > - agno = 9 > > - agno = 10 > > - agno = 11 > > - agno = 12 > > data fork in regular inode 53909610 claims used block 3369360 > > would have cleared inode 53909610 > > - agno = 13 > > - agno = 14 > > - agno = 15 > > No modify flag set, skipping phase 5 > > Phase 6 - check inode connectivity... > > Segmentation fault > > > > # xfs_repair /dev/hda9 > > Phase 1 - find and verify superblock... > > Phase 2 - using internal log > > - zero log... > > - scan filesystem freespace and inode maps... > > block (0,223632) multiply claimed by bno space tree, state - 1 > > block (1,223632) multiply claimed by bno space tree, state - 1 > > block (2,223632) multiply claimed by bno space tree, state - 1 > > block (4,223632) multiply claimed by bno space tree, state - 1 > > block (8,223632) multiply claimed by bno space tree, state - 1 > > block (9,223632) multiply claimed by bno space tree, state - 1 > > block (10,223632) multiply claimed by bno space tree, state - 1 > > block (11,223632) multiply claimed by bno space tree, state - 1 > > block (13,223632) multiply claimed by bno space tree, state - 1 > > block (14,223632) multiply claimed by bno space tree, state - 1 > > block (15,223632) multiply claimed by bno space tree, state - 1 > > - 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 > > data fork in ino 16152860 claims free block 1010064 > > - agno = 4 > > data fork in ino 16791313 claims free block 1534352 > > - agno = 5 > > - agno = 6 > > data fork in ino 25176869 claims free block 1796496 > > data fork in ino 25176898 claims free block 2058640 > > - agno = 7 > > - agno = 8 > > - agno = 9 > > - agno = 10 > > - agno = 11 > > - agno = 12 > > data fork in ino 53909610 claims free block 3369360 > > - agno = 13 > > - agno = 14 > > - agno = 15 > > - process newly discovered inodes... > > Phase 4 - check for duplicate blocks... > > - setting up duplicate extent list... > > - clear lost+found (if it exists) ... > > - check for inodes claiming duplicate blocks... > > - agno = 0 > > - agno = 1 > > - agno = 2 > > - agno = 3 > > data fork in regular inode 16152860 claims used block 1010064 > > xfs_repair: dinode.c:2436: process_dinode_int: Assertion `err == 0' failed. > > > > # xfs_info /mnt/mnt > > meta-data=/dev/hda9 isize=256 agcount=16, agsize=223633 blks > > = sectsz=512 > > data = bsize=4096 blocks=3578128, imaxpct=25 > > = sunit=0 swidth=0 blks, unwritten=1 > > naming =version 2 bsize=4096 > > log =internal bsize=4096 blocks=2560, version=1 > > = sectsz=512 sunit=0 blks > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > # xfs_db /dev/hda9 > > xfs_db> inode 16152860 > > xfs_db> print > > core.magic = 0x494e > > core.mode = 0100644 > > core.version = 1 > > core.format = 2 (extents) > > core.nlinkv1 = 1 > > core.uid = 500 > > core.gid = 500 > > core.flushiter = 5 > > core.atime.sec = Thu Aug 11 23:12:14 2005 > > core.atime.nsec = 855897961 > > core.mtime.sec = Thu Aug 11 23:12:14 2005 > > core.mtime.nsec = 856897741 > > core.ctime.sec = Thu Aug 11 23:12:14 2005 > > core.ctime.nsec = 856897741 > > core.size = 5898 > > core.nblocks = 2 > > core.extsize = 0 > > core.nextents = 1 > > 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 = 1 > > next_unlinked = null > > u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,1010063,2,0] > > > > Xfs_repair is from xfsprogs-2.7.1. Computer is amd64 with 512M memory and > > kernel SGI-XFS CVS-2005-09-21_05:00_UTC with ACLs, large block/inode > > numbers, no debug enabled. > > > > Is it bug in xfs_repair? > probably no > > > How can I repair this FS? > run xfs_repair without -n Please look closely on my mail. The second run is without "-n" and xfs_repair ended with message in subject. jan -- From owner-linux-xfs@oss.sgi.com Fri Sep 23 01:06:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Sep 2005 01:06:59 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8N86uiL001092 for ; Fri, 23 Sep 2005 01:06:56 -0700 Received: by xproxy.gmail.com with SMTP id t6so590581wxc for ; Fri, 23 Sep 2005 01:04:09 -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=rXspW9yjgXUOiYstBtRMHc1BYYWu5f59e68qmQcMraPhHVCZAK2UVoGC/TPORuqHfqe7RsC/FsTNgs6ibVz9AjF47P+OZ4qTWZZ6mQOOku+BlTnOxmYYcokEefZE1EhfG0zmx0y9KM/0RTwZk0sYXsdOcsnvh8TpC8LIMGN1A8o= Received: by 10.70.22.8 with SMTP id 8mr941522wxv; Fri, 23 Sep 2005 01:04:09 -0700 (PDT) Received: by 10.70.7.10 with HTTP; Fri, 23 Sep 2005 01:04:09 -0700 (PDT) Message-ID: Date: Fri, 23 Sep 2005 03:04:09 -0500 From: Andrew Lyons Reply-To: Andrew Lyons To: linux-xfs@oss.sgi.com Subject: problems with full filesystem? 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 j8N86viL001095 X-archive-position: 6228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lyonsam@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 771 Lines: 33 I have a very serious problem. I was making a tarball and I accidentally completely filled up my filesystem. Now whenever I try to access it, I get: /bin/ls: reading directory .: Input/output error sometimes it tells me it "cannot allocate memory." here is some relevant information: "ogd:/ # mount ... /dev/hda3 on /home type xfs (rw) ..." "ogd:/ # xfs_check /dev/hda3 xfs_check: /dev/hda3 contains a mounted and writable filesystem fatal error -- couldn't initialize XFS library" "ogd:/ # xfs_info /dev/hda3 xfs_info: /dev/hda3 is not a mounted XFS filesystem" any help would be greatly appreciated. this is some sort of disaster. -Andrew -- ------------------------------------------ Lyons, Andrew Myers Cell - 412.951.0816 andrew.m.lyons@vanderbilt.edu From owner-linux-xfs@oss.sgi.com Fri Sep 23 06:00:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Sep 2005 06:01:05 -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 j8ND0viL031569 for ; Fri, 23 Sep 2005 06:00:57 -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 j8NE0hnG011661 for ; Fri, 23 Sep 2005 07:00:43 -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 j8NCw9sS91090704; Fri, 23 Sep 2005 05:58:09 -0700 (PDT) Message-ID: <4333FBE1.2080400@sgi.com> Date: Fri, 23 Sep 2005 07:58:09 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ying-Hung Chen CC: linux-xfs@oss.sgi.com Subject: Re: howto preallocate to minimize fragmentation References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> <4332CE65.2000500@animezone.org> <4332CF04.2060604@yingternet.com> <4332D17E.6060608@sgi.com> <4333A130.7040709@yingternet.com> In-Reply-To: <4333A130.7040709@yingternet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6229 X-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: 1048 Lines: 35 Ying-Hung Chen wrote: > when I run the sample code, and created "testfile" > > [yhchen@fc3 ~]$ ./xfs_fcntl testfile > [yhchen@fc3 ~]$ ls -l testfile > -rwx------ 1 yhchen yhchen 0 Sep 23 14:17 testfile > [yhchen@fc3 ~]$ du testfile > 20480 testfile > [yhchen@fc3 ~]$ du -h testfile > 20M testfile > > I see the filesize is 0, but du does show 20MB > > However, when I try to determine the file size via fseek, it returns 0. > > so, what does this kind of allocation mean? does it really mean that it run xfs_bmap on the resulting file and you'll see... > so, if I write anything within this 20MB > range, it will be writing to the allocated space and hence no > fragmentation? right. > what happens if I go over? my guess is if i go over, xfs > allocation algorithm will be and there will be fragamentation? well it depends on what else is going on; if there is plenty of free space after that 20M, then no. but if you have parallel streams writing, then fragmentation past the amount of space you allocated is likely. -Eric From owner-linux-xfs@oss.sgi.com Fri Sep 23 14:06:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Sep 2005 14:06:12 -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 j8NL67iL022357 for ; Fri, 23 Sep 2005 14:06:07 -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 j8NM5t6q031183 for ; Fri, 23 Sep 2005 15:05:55 -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 j8NL2JDN16258410; Fri, 23 Sep 2005 16:02:19 -0500 (CDT) Message-ID: <43346D5B.60005@sgi.com> Date: Fri, 23 Sep 2005 16:02:19 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Lyons CC: linux-xfs@oss.sgi.com Subject: Re: problems with full filesystem? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6230 X-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: 901 Lines: 34 Andrew Lyons wrote: > I have a very serious problem. I was making a tarball and I > accidentally completely filled up my filesystem. Now whenever I try > to access it, I get: > > /bin/ls: reading directory .: Input/output error > > sometimes it tells me it "cannot allocate memory." > > here is some relevant information: > > "ogd:/ # mount > ... > /dev/hda3 on /home type xfs (rw) > ..." > > "ogd:/ # xfs_check /dev/hda3 > xfs_check: /dev/hda3 contains a mounted and writable filesystem > > fatal error -- couldn't initialize XFS library" normal for a mounted filesystem > "ogd:/ # xfs_info /dev/hda3 > xfs_info: /dev/hda3 is not a mounted XFS filesystem" xfs_info points at a mount point, not a device. (non-obvious, I know...) > any help would be greatly appreciated. this is some sort of disaster. check your log messages, odds are the filesystem got shut down on an error. -Eric From owner-linux-xfs@oss.sgi.com Sun Sep 25 00:50:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Sep 2005 00:50:51 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8P7ojiL028615 for ; Sun, 25 Sep 2005 00:50:45 -0700 Received: by xproxy.gmail.com with SMTP id t6so271205wxc for ; Sun, 25 Sep 2005 00:47:57 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S/fpRRnwb31vIshvhNhkvz2j3gHVESzBkSJYSGJGvkblNh/3P77IUmR5c59W6N0B4kX5ryqsbk3ufX4SPbXfRwhQ3VuZsLv3FELs4+xngnFH2SGE3QUa0IJWKgvJrLx1VuifL4j4eX+I92Md9LLda/iG3mHBIzKZPIIp+ZCXFeo= Received: by 10.70.34.10 with SMTP id h10mr1720959wxh; Sun, 25 Sep 2005 00:47:56 -0700 (PDT) Received: by 10.70.7.10 with HTTP; Sun, 25 Sep 2005 00:47:56 -0700 (PDT) Message-ID: Date: Sun, 25 Sep 2005 02:47:56 -0500 From: Andrew Lyons Reply-To: Andrew Lyons To: Eric Sandeen Subject: Re: problems with full filesystem? Cc: linux-xfs@oss.sgi.com In-Reply-To: <43346D5B.60005@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <43346D5B.60005@sgi.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8P7okiL028618 X-archive-position: 6233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lyonsam@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1530 Lines: 57 Thanks for your reply. I can't check the logfiles, I can't look at anything that's on the filesystem :-/ I did an xfs_info on /home and i got the following: "xfs_info: /home is not a mounted XFS filesystem" I am running suse 10.0 RC1 and it gave me a "disk is full" popup thing for the full partition. I have no idea what to do. Any help would be appreciated, this is a very serious issue. -Andrew On 9/23/05, Eric Sandeen wrote: > Andrew Lyons wrote: > > I have a very serious problem. I was making a tarball and I > > accidentally completely filled up my filesystem. Now whenever I try > > to access it, I get: > > > > /bin/ls: reading directory .: Input/output error > > > > sometimes it tells me it "cannot allocate memory." > > > > here is some relevant information: > > > > "ogd:/ # mount > > ... > > /dev/hda3 on /home type xfs (rw) > > ..." > > > > "ogd:/ # xfs_check /dev/hda3 > > xfs_check: /dev/hda3 contains a mounted and writable filesystem > > > > fatal error -- couldn't initialize XFS library" > > normal for a mounted filesystem > > > "ogd:/ # xfs_info /dev/hda3 > > xfs_info: /dev/hda3 is not a mounted XFS filesystem" > > xfs_info points at a mount point, not a device. (non-obvious, I know...) > > > any help would be greatly appreciated. this is some sort of disaster. > > check your log messages, odds are the filesystem got shut down on an error. > > -Eric > -- ------------------------------------------ Lyons, Andrew Myers Cell - 412.951.0816 andrew.m.lyons@vanderbilt.edu From owner-linux-xfs@oss.sgi.com Sun Sep 25 06:01:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Sep 2005 06:01: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 j8PD1YiL029953 for ; Sun, 25 Sep 2005 06:01:34 -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 j8PE1a8r020375 for ; Sun, 25 Sep 2005 07:01:36 -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 j8PCvisS90771080; Sun, 25 Sep 2005 05:57:45 -0700 (PDT) Message-ID: <43369ECA.3040108@sgi.com> Date: Sun, 25 Sep 2005 07:57:46 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Lyons CC: linux-xfs@oss.sgi.com Subject: Re: problems with full filesystem? References: <43346D5B.60005@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6234 X-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: 746 Lines: 28 Andrew Lyons wrote: > Thanks for your reply. > > I can't check the logfiles, I can't look at anything that's on the > filesystem :-/ Your logs are on /home not something like /var/log? er, ok... how about dmesg? > I did an xfs_info on /home and i got the following: > "xfs_info: /home is not a mounted XFS filesystem" does /proc/mounts think that /home is a mounted xfs filesystem? I still think your fs probably shut down due to an error encountered when the filesystem filled... but we haven't been able to show that yet. -Eric > I am running suse 10.0 RC1 and it gave me a "disk is full" popup thing > for the full partition. I have no idea what to do. > Any help would be appreciated, this is a very serious issue. > > -Andrew From owner-linux-xfs@oss.sgi.com Sun Sep 25 07:12:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Sep 2005 07:12:29 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8PECKiL005013 for ; Sun, 25 Sep 2005 07:12:21 -0700 Received: by xproxy.gmail.com with SMTP id t6so292334wxc for ; Sun, 25 Sep 2005 07:09:32 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ERNnMa+xXpGSZtUVALVaYW4kTFU8rhoFZiORzu3+1SZKXeDtpfI2u0f5ScAHoWzKd1jpg4T3sNl+oEAJoaNyvfG6RdJV2LB35cE6lSmp6oz9bJ2WTKZPi2gfV/MnwOv4Q+H/Jdmun9Kw5UPAysiMzK0HUqxddaDzORhfEn0ypCU= Received: by 10.70.14.8 with SMTP id 8mr1850603wxn; Sun, 25 Sep 2005 07:09:32 -0700 (PDT) Received: by 10.70.7.10 with HTTP; Sun, 25 Sep 2005 07:09:32 -0700 (PDT) Message-ID: Date: Sun, 25 Sep 2005 09:09:32 -0500 From: Andrew Lyons Reply-To: Andrew Lyons To: Eric Sandeen Subject: Re: problems with full filesystem? Cc: linux-xfs@oss.sgi.com In-Reply-To: <43369ECA.3040108@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <43346D5B.60005@sgi.com> <43369ECA.3040108@sgi.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8PECLiL005017 X-archive-position: 6235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lyonsam@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1236 Lines: 47 Ok, I miraculously was granted access to my filesystem for a few minutes, and during that time I deleted some big things to make room, but I continued to have problems with it. I was able to run xfs_repair on it, and it seems like it worked. Thanks for your help. -Andrew On 9/25/05, Eric Sandeen wrote: > Andrew Lyons wrote: > > Thanks for your reply. > > > > I can't check the logfiles, I can't look at anything that's on the > > filesystem :-/ > > Your logs are on /home not something like /var/log? er, ok... > > how about dmesg? > > > I did an xfs_info on /home and i got the following: > > "xfs_info: /home is not a mounted XFS filesystem" > > does /proc/mounts think that /home is a mounted xfs > filesystem? > > I still think your fs probably shut down due to an error encountered > when the filesystem filled... but we haven't been able to show that yet. > > -Eric > > > I am running suse 10.0 RC1 and it gave me a "disk is full" popup thing > > for the full partition. I have no idea what to do. > > > Any help would be appreciated, this is a very serious issue. > > > > -Andrew > -- ------------------------------------------ Lyons, Andrew Myers Cell - 412.951.0816 andrew.m.lyons@vanderbilt.edu From owner-linux-xfs@oss.sgi.com Sun Sep 25 13:49:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Sep 2005 13:49:25 -0700 (PDT) Received: from prnet.org (pppoe240-static-luxdsl-128.pt.lu [213.135.240.128]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8PKnCiL016946 for ; Sun, 25 Sep 2005 13:49:15 -0700 Received: from [127.0.0.1] (win.intern.prnet.org [192.168.1.2]) (authenticated bits=0) by prnet.org (8.13.1/8.13.1) with ESMTP id j8PKkFiH001621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Sep 2005 22:46:16 +0200 Message-ID: <43370C96.6000306@prnet.org> Date: Sun, 25 Sep 2005 22:46:14 +0200 From: David Arendt User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: segfault using xfs_db -c frag -r /dev/hda4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6236 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: admin@prnet.org Precedence: bulk X-list: linux-xfs Content-Length: 678 Lines: 23 Hi, Well I am experiencing a segmentation fault when using the above command. freesp works perfectly. If I specify frag - frag seems to work correctly. The files on this filesystem are rather big (avg 30GBytes/file), but a low number of files (10 files). dmesg doesn't show any unusual error messages. Also xfs_repair -n /dev/hda4 doesn't show any anomaly. The used versions are: Kernel (compiled from source): 2.6.13.2 Xfs-Progs (compiled from source): xfsprogs-2.6.36.src.tar.gz Any ideas what could be wrong ? Feel free to contact me if you need more information. Thanks in advance. Bye, David Arendt From owner-linux-xfs@oss.sgi.com Sun Sep 25 14:57:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Sep 2005 14:57:46 -0700 (PDT) Received: from flyingAngel.upjs.sk (gate.rudna.net [195.122.192.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8PLvfiL022691 for ; Sun, 25 Sep 2005 14:57:42 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 79D2210015C; Sun, 25 Sep 2005 23:54:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 724F7180123; Sun, 25 Sep 2005 23:54:31 +0200 (CEST) Date: Sun, 25 Sep 2005 23:54:31 +0200 (CEST) From: Jan Derfinak To: David Arendt Cc: linux-xfs@oss.sgi.com Subject: Re: segfault using xfs_db -c frag -r /dev/hda4 In-Reply-To: <43370C96.6000306@prnet.org> Message-ID: References: <43370C96.6000306@prnet.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6237 X-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 Content-Length: 753 Lines: 23 On Sun, 25 Sep 2005, David Arendt wrote: > Hi, > > Well I am experiencing a segmentation fault when using the above command. > freesp works perfectly. If I specify frag - files, directories or symlinks> frag seems to work correctly. The files on > this filesystem are rather big (avg 30GBytes/file), but a low number of files > (10 files). dmesg doesn't show any unusual error messages. Also xfs_repair -n > /dev/hda4 doesn't show any anomaly. > > The used versions are: > > Kernel (compiled from source): 2.6.13.2 > Xfs-Progs (compiled from source): xfsprogs-2.6.36.src.tar.gz I have the same problem with xfsprogs-2.6.37 and xfsprogs-2.7.1, kernel 2.6.1[123]. (2 different computers and 12 filesystems). jan -- From owner-linux-xfs@oss.sgi.com Mon Sep 26 00:04:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Sep 2005 00:04:31 -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 j8Q74NiL012142 for ; Mon, 26 Sep 2005 00:04:24 -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 RAA09051; Mon, 26 Sep 2005 17:01:28 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4241249BFB21; Mon, 26 Sep 2005 17:01:27 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 941645 - attr2 enable fix Message-Id: <20050926070127.4241249BFB21@chook.melbourne.sgi.com> Date: Mon, 26 Sep 2005 17:01:27 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6238 X-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: 601 Lines: 16 Fix up a 32/64 local flags variable issue when enabling attr2 mode. Date: Mon Sep 26 17:01:00 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:23925a xfs_attr_leaf.c - 1.87 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.87&r2=text&tr2=1.86&f=h xfs_bmap.c - 1.332 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.332&r2=text&tr2=1.331&f=h From owner-linux-xfs@oss.sgi.com Mon Sep 26 00:17:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Sep 2005 00:17:50 -0700 (PDT) Received: from smtp.pzkagis.cz (gis6.netbox.cz [83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8Q7HhiL013822 for ; Mon, 26 Sep 2005 00:17:46 -0700 Received: (from luf@localhost) by smtp.pzkagis.cz (8.11.6/8.11.6) id j8Q7Epr04041 for linux-xfs@oss.sgi.com; Mon, 26 Sep 2005 09:14:51 +0200 Date: Mon, 26 Sep 2005 09:14:51 +0200 From: Ludek Finstrle To: linux-xfs@oss.sgi.com Subject: ls -l versus du -sk after xfs_fsr Message-ID: <20050926071451.GA3751@soptik.pzkagis.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 6239 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luf@pzkagis.cz Precedence: bulk X-list: linux-xfs Content-Length: 374 Lines: 22 Hello, I have problem with diferrence in filesize between ls -l and du -sk after xfs_fsr (it was ok before running xfs_fsr): # ls -l Drafts -rw-rw---- 1 user group 74646 Apr 15 17:37 Drafts # du -b Drafts 3221303296 Drafts Is there a way to correct it? My versions: kernel 2.4.31 vanilla + ACL patches xfsprogs-2.6.36-1 acl-2.2.31-1 attr-2.4.23-0 Thanks Luf From owner-linux-xfs@oss.sgi.com Mon Sep 26 01:16:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Sep 2005 01:17:02 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8Q8GoiL024484 for ; Mon, 26 Sep 2005 01:16:51 -0700 Received: from gateway-att.yingternet.com (c-24-126-232-43.hsd1.ca.comcast.net [24.126.232.43]) by ying.yingternet.com (Postfix) with ESMTP id E913D30009E for ; Mon, 26 Sep 2005 01:14:51 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id 7A3A4204C18; Mon, 26 Sep 2005 01:13:51 -0700 (PDT) Message-ID: <4337ADB7.3060700@yingternet.com> Date: Mon, 26 Sep 2005 16:13:43 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: Ying-Hung Chen Subject: kernel dump (may be related to previous fragmentation problem) X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 6396 Lines: 118 Hi there, We are seeing two (very similar?) kernel dumps (order:5, mode 0xd0 / order:4 mode 0x50) on our systems, I have search the mailing list and it seem to somehow related to the fragmentation problem? (ours is at > 99%) though someone maintained this is not Fatal, but our system usually becomes unresponsive when the dump starts to appear (sometimes its ok after a while, but most of time it just dumps forever and system becomes unusable and we have to reboot) are there fixes / workaround we can try? Are these two message dump the same thing? Thanks, Sep 26 00:09:39 localhost kernel: EngineMain: page allocation failure. order:5, mode:0xd0 Sep 26 00:09:39 localhost kernel: [<02146dbe>] __alloc_pages+0x28b/0x298 Sep 26 00:09:39 localhost kernel: [<02146de3>] __get_free_pages+0x18/0x24 Sep 26 00:09:39 localhost kernel: [<0214a4f1>] kmem_getpages+0x15/0x94 Sep 26 00:09:39 localhost kernel: [<0214b27d>] cache_grow+0x155/0x29a Sep 26 00:09:39 localhost kernel: [<0214b5cf>] cache_alloc_refill+0x20d/0x23d Sep 26 00:09:39 localhost kernel: [<0214bb80>] __kmalloc+0x6b/0x7d Sep 26 00:09:39 localhost kernel: [<2291e964>] kmem_alloc+0x50/0x96 [xfs] Sep 26 00:09:39 localhost kernel: [<228fe7df>] xfs_iread_extents+0x73/0xc4 [xfs] Sep 26 00:09:39 localhost kernel: [<228de41a>] xfs_bmapi+0x2b8/0x129f [xfs] Sep 26 00:09:39 localhost kernel: [<0224f390>] cfq_add_crq_rb+0x3b/0x4d Sep 26 00:09:39 localhost kernel: [<0224fb19>] cfq_enqueue+0x33/0x64 Sep 26 00:09:39 localhost kernel: [<0224fbb7>] cfq_insert_request+0x6d/0xdf Sep 26 00:09:39 localhost kernel: [<0226c42b>] __ide_dma_begin+0x21/0x2f Sep 26 00:09:39 localhost kernel: [<0226c36d>] __ide_dma_read+0x8a/0x95 Sep 26 00:09:39 localhost kernel: [<0226c0ef>] dma_timer_expiry+0x0/0x6e Sep 26 00:09:39 localhost kernel: [<0226e823>] __ide_do_rw_disk+0x2d8/0x4aa Sep 26 00:09:39 localhost kernel: [<02302380>] schedule+0x478/0x5a4 Sep 26 00:09:39 localhost kernel: [<0211ba79>] __wake_up_locked+0x11/0x13 Sep 26 00:09:39 localhost kernel: [<229020c3>] xfs_iomap+0x23a/0x3ec [xfs] Sep 26 00:09:39 localhost kernel: [<02142938>] find_lock_page+0x84/0x228 Sep 26 00:09:39 localhost kernel: [<229263a2>] xfs_bmap+0x1a/0x1e [xfs] Sep 26 00:09:39 localhost kernel: [<2291fac9>] linvfs_get_block_core+0x6b/0x22b [xfs] Sep 26 00:09:39 localhost kernel: [<02302db4>] __cond_resched+0x14/0x3b Sep 26 00:09:39 localhost kernel: [<02168b48>] set_bh_page+0x2c/0x34 Sep 26 00:09:40 localhost kernel: [<2291fc9c>] linvfs_get_block+0x13/0x17 [xfs] Sep 26 00:09:40 localhost kernel: [<02169224>] __block_prepare_write+0x15b/0x3dd Sep 26 00:09:40 localhost kernel: [<02151de2>] follow_page_pfn+0xec/0xfd Sep 26 00:09:40 localhost kernel: [<02169b04>] block_prepare_write+0x16/0x22 Sep 26 00:09:40 localhost kernel: [<2291fc89>] linvfs_get_block+0x0/0x17 [xfs] Sep 26 00:09:40 localhost kernel: [<2291ffb5>] linvfs_prepare_write+0x12/0x15 [xfs] Sep 26 00:09:40 localhost kernel: [<2291fc89>] linvfs_get_block+0x0/0x17 [xfs] Sep 26 00:09:40 localhost kernel: [<02144290>] generic_file_buffered_write+0x1b4/0x48e Sep 26 00:09:40 localhost kernel: [<228fc7a6>] xfs_iget+0x62/0x103 [xfs] Sep 26 00:09:40 localhost kernel: [<02302db4>] __cond_resched+0x14/0x3b Sep 26 00:09:40 localhost kernel: [<228fcd93>] xfs_ilock+0xce/0xdc [xfs] ///////////////////////////////////////////////////////////////////////// localhost kernel: possible deadlock in kmem_alloc (mode:0x50) localhost last message repeated 39 times localhost kernel: printk: 4168 messages suppressed. localhost kernel: EngineMain: page allocation failure. order:4, mode:0x50 localhost kernel: [<02146dbe>] __alloc_pages+0x28b/0x298 localhost kernel: [<02146de3>] __get_free_pages+0x18/0x24 localhost kernel: [<0214a4f1>] kmem_getpages+0x15/0x94 localhost kernel: [<0214b27d>] cache_grow+0x155/0x29a localhost kernel: [<0214b5cf>] cache_alloc_refill+0x20d/0x23d localhost kernel: [<0214bb80>] __kmalloc+0x6b/0x7d localhost kernel: [<421ee964>] kmem_alloc+0x50/0x96 [xfs] localhost kernel: [<421eea2c>] kmem_realloc+0x17/0x52 [xfs] localhost kernel: [<421cff07>] xfs_iext_realloc+0xc9/0xdc [xfs] localhost kernel: [<421aca5b>] xfs_bmap_insert_exlist+0x22/0x77 [xfs] localhost kernel: [<421a9e77>] xfs_bmap_add_extent_hole_delay+0x438/0x48e [xfs] localhost kernel: [<421a78e9>] xfs_bmap_add_extent+0x133/0x386 [xfs] localhost kernel: [<421aec42>] xfs_bmapi+0xae0/0x129f [xfs] localhost kernel: [<02108a01>] do_IRQ+0x187/0x309 localhost kernel: [<421ae462>] xfs_bmapi+0x300/0x129f [xfs] localhost kernel: [<421d2cdc>] xfs_iomap_write_delay+0x62b/0x705 [xfs] localhost kernel: [<421d1c26>] xfs_imap_to_bmap+0x2a/0x28d [xfs] localhost kernel: [<02108af0>] do_IRQ+0x276/0x309 localhost kernel: [<421d20c3>] xfs_iomap+0x23a/0x3ec [xfs] localhost kernel: [<421d216d>] xfs_iomap+0x2e4/0x3ec [xfs] localhost kernel: [<0210cc88>] do_gettimeofday+0x14/0x90 localhost kernel: [<421f63a2>] xfs_bmap+0x1a/0x1e [xfs] localhost kernel: [<421efac9>] linvfs_get_block_core+0x6b/0x22b [xfs] localhost kernel: [<02302db4>] __cond_resched+0x14/0x3b localhost kernel: [<02168b48>] set_bh_page+0x2c/0x34 localhost kernel: [<421efc9c>] linvfs_get_block+0x13/0x17 [xfs] localhost kernel: [<02169224>] __block_prepare_write+0x15b/0x3dd localhost kernel: [<02151de2>] follow_page_pfn+0xec/0xfd localhost kernel: [<02169b04>] block_prepare_write+0x16/0x22 localhost kernel: [<421efc89>] linvfs_get_block+0x0/0x17 [xfs] localhost kernel: [<421effb5>] linvfs_prepare_write+0x12/0x15 [xfs] localhost kernel: [<421efc89>] linvfs_get_block+0x0/0x17 [xfs] localhost kernel: [<02144290>] generic_file_buffered_write+0x1b4/0x48e localhost kernel: [<0215e45f>] rw_vm+0x3f7/0x482 localhost kernel: [<022a780c>] skb_copy_datagram_iovec+0x4f/0x1e1 localhost kernel: [<022cace1>] cleanup_rbuf+0xbf/0xdb localhost kernel: [<421f600b>] xfs_write+0x598/0x8dd [xfs] localhost kernel: [<421f2521>] linvfs_write+0x6f/0x77 [xfs] localhost kernel: [<02165612>] do_sync_write+0x97/0xc9 localhost kernel: [<0211953a>] do_page_fault+0x1bc/0x511 localhost kernel: [<02302380>] schedule+0x478/0x5a4 localhost kernel: [<0211cf5b>] autoremove_wake_function+0x0/0x2d localhost kernel: [<0215e45f>] rw_vm+0x3f7/0x482 localhost kernel: [<021656fa>] vfs_write+0xb6/0xe2 localhost kernel: [<021657c4>] sys_write+0x3c/0x62 From owner-linux-xfs@oss.sgi.com Mon Sep 26 05:55:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Sep 2005 05:55:31 -0700 (PDT) Received: from smtp05av.ntr.oleane.net (smtp-out2.net.av.oleane.com [195.25.12.12]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8QCtGiL025036 for ; Mon, 26 Sep 2005 05:55:17 -0700 Received: from Antivirus (localhost [127.0.0.1]) by smtp05av.ntr.oleane.net with ESMTP id j8QCoelq032155 for ; Mon, 26 Sep 2005 14:52:27 +0200 Received: from hermesadm.chb.fr ([194.3.110.58]) by smtp05av.ntr.oleane.net (8.12.11/8.12.11/8.12-FT) with ESMTP id j8QCmmAm030727 for ; Mon, 26 Sep 2005 14:48:49 +0200 To: linux-xfs@oss.sgi.com Subject: xfsdump and tar on same tape Message-ID: <1127738813.4337edbd27a25@hermesadm.chb.fr> Date: Mon, 26 Sep 2005 14:46:53 +0200 (CEST) From: Xavier Poirier MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-WebMail-Company: Centre Hospitalier de Bourg en Bresse X-FAX-Notify: requeued X-MIME-Autoconverted: from 8bit to quoted-printable by hermesadm.chb.fr id j8QCkrP05432 X-AntiVirus: scanned for viruses by AMaViS (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8QCtHiL025038 X-archive-position: 6242 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xpoirier@ch-bourg01.fr Precedence: bulk X-list: linux-xfs Content-Length: 676 Lines: 23 hi, I want to make a backup of my two filesystems witch are: / (EXT2) /home (XFS) I want to do an XFSDUMP of /home with no-rewind capabilities of the tape and add next a TAR of / to the end. The problem is that I cannot read TAR archive of the tape (xfsdump read without problem), I don't know the number session to go on the tape. Any idea? Xavier -------------------------------------------------------------------- Ce courriel est envoyé au travers de l' interface IMP: ch-bourg01.fr Ce message a été passé automatiquement à l' antivirus This email have been sent through Imap Mail Program: ch-bourg01.fr This message have been scanned with an antivirus scanner From owner-linux-xfs@oss.sgi.com Mon Sep 26 06:47:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Sep 2005 06:47:48 -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 j8QDlViL001354 for ; Mon, 26 Sep 2005 06:47:31 -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 j8QElgbg023010 for ; Mon, 26 Sep 2005 07:47:42 -0700 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j8QDhgDN16428439; Mon, 26 Sep 2005 08:43:42 -0500 (CDT) Message-ID: <4337FB0E.8090302@sgi.com> Date: Mon, 26 Sep 2005 08:43:42 -0500 From: Bill Kendall User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xavier Poirier CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump and tar on same tape References: <1127738813.4337edbd27a25@hermesadm.chb.fr> In-Reply-To: <1127738813.4337edbd27a25@hermesadm.chb.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 6243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 872 Lines: 30 After xfsrestore completes, issue "mt -f /dev/nstX fsf 1" to seek to the next file and then run tar. Bill On 09/26/05 07:46, Xavier Poirier wrote: > hi, > > I want to make a backup of my two filesystems witch are: > > / (EXT2) > /home (XFS) > > I want to do an XFSDUMP of /home with no-rewind capabilities of the > tape and add next a TAR of / to the end. > The problem is that I cannot read TAR archive of the tape (xfsdump > read without problem), I don't know the number session to go on the tape. > Any idea? > > Xavier > > > -------------------------------------------------------------------- > Ce courriel est envoyé au travers de l' interface IMP: ch-bourg01.fr > Ce message a été passé automatiquement à l' antivirus > This email have been sent through Imap Mail Program: ch-bourg01.fr > This message have been scanned with an antivirus scanner > > From owner-linux-xfs@oss.sgi.com Mon Sep 26 08:04:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Sep 2005 08:04: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 j8QF4WiL011949 for ; Mon, 26 Sep 2005 08:04:32 -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 j8QG4hub007484 for ; Mon, 26 Sep 2005 09:04:43 -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 j8QF1hDN16430467 for ; Mon, 26 Sep 2005 10:01:43 -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 j8QF1dLL8598272; Mon, 26 Sep 2005 10:01:42 -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 j8QF1dvM028173; Mon, 26 Sep 2005 10:01:39 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j8QF1cfY028171; Mon, 26 Sep 2005 10:01:38 -0500 Date: Mon, 26 Sep 2005 10:01:38 -0500 From: Eric Sandeen Message-Id: <200509261501.j8QF1cfY028171@penguin.americas.sgi.com> To: sgi.bugs.xfs@fido.engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 943266 - save some stack in xfs_iomap_write_direct X-archive-position: 6244 X-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: 814 Lines: 24 xfs_iomap_write_direct puts XFS_WRITE_IMAPS (4) xfs_bmbt_irec_t's on the stack, but only ever uses one. It also does some calculations that it throws away. Clean this up a bit... and save 80 bytes of stack in this function in the process :) Remove dead code in xfs_iomap_write_direct; save some stack Date: Mon Sep 26 08:00: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:199750a xfs_iomap.c - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h - Don't put more imaps on the stack than we're going to use, take out some unused vars & calculations done on them From owner-linux-xfs@oss.sgi.com Mon Sep 26 08:26:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Sep 2005 08:27:10 -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 j8QFQoiL019135 for ; Mon, 26 Sep 2005 08:26: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 j8QGR1M5012975 for ; Mon, 26 Sep 2005 09:27:01 -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 j8QFO0sL22363309; Mon, 26 Sep 2005 10:24:00 -0500 (CDT) Message-ID: <4338128F.8000707@sgi.com> Date: Mon, 26 Sep 2005 10:23:59 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludek Finstrle CC: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr References: <20050926071451.GA3751@soptik.pzkagis.cz> In-Reply-To: <20050926071451.GA3751@soptik.pzkagis.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6245 X-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: 894 Lines: 38 Ludek Finstrle wrote: > Hello, > > I have problem with diferrence in filesize between ls -l and du -sk > after xfs_fsr (it was ok before running xfs_fsr): > > # ls -l Drafts > -rw-rw---- 1 user group 74646 Apr 15 17:37 Drafts > # du -b Drafts > 3221303296 Drafts > > Is there a way to correct it? can you run xfs_bmap -v Drafts I'm curious to see how this is laid out on disk.... whether it is really using 3G of blocks... If the file is otherwise readable (i.e. the first 74646 bytes are right) simply copying the file to a new name & back -might- solve the problem. I haven't seen this particular problem before... If you can keep the original problematic file around, though, it'd be interesting to figure out what's happened here. -Eric > My versions: > kernel 2.4.31 vanilla + ACL patches > xfsprogs-2.6.36-1 > acl-2.2.31-1 > attr-2.4.23-0 > > Thanks > > Luf > From owner-linux-xfs@oss.sgi.com Mon Sep 26 08:29:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Sep 2005 08:29:25 -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 j8QFT5iL019729 for ; Mon, 26 Sep 2005 08:29:05 -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 j8QGTGmP013892 for ; Mon, 26 Sep 2005 09:29:16 -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 j8QFQGsL22364869; Mon, 26 Sep 2005 10:26:16 -0500 (CDT) Message-ID: <43381317.8040007@sgi.com> Date: Mon, 26 Sep 2005 10:26:15 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ying-Hung Chen CC: linux-xfs@oss.sgi.com Subject: Re: kernel dump (may be related to previous fragmentation problem) References: <4337ADB7.3060700@yingternet.com> In-Reply-To: <4337ADB7.3060700@yingternet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6246 X-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: 1021 Lines: 32 Ying-Hung Chen wrote: > Hi there, > > We are seeing two (very similar?) kernel dumps (order:5, mode 0xd0 / > order:4 mode 0x50) on our systems, the kernel didn't dump, this is just a backtrace. It is unable to allocate enough contiguous memory to accommodate your extent list, so yes, it is probably related to your fragmentation problem. If you use the method I suggested previously for preallocating space, this problem should go away. > I have search the mailing list and it seem to somehow related to the > fragmentation problem? (ours is at > 99%) though someone maintained this > is not Fatal, but our system usually becomes unresponsive when the dump > starts to appear (sometimes its ok after a while, but most of time it > just dumps forever and system becomes unusable and we have to reboot) it's in a loop trying to allocate memory, and it can't. > are there fixes / workaround we can try? Use preallocation, as I suggested. > Are these two message dump the same thing? > basically, yes. -Eric From owner-linux-xfs@oss.sgi.com Mon Sep 26 19:57:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Sep 2005 19:57:41 -0700 (PDT) Received: from smtp07av.ntr.oleane.net (smtp-out2.net.av.oleane.com [195.25.12.12]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8R2vSiL030213 for ; Mon, 26 Sep 2005 19:57:29 -0700 Received: from Antivirus (localhost [127.0.0.1]) by smtp07av.ntr.oleane.net with ESMTP id j8R2sbBP017171 for ; Tue, 27 Sep 2005 04:54:38 +0200 Received: from hermesadm.chb.fr ([194.3.110.58]) by smtp07av.ntr.oleane.net (8.12.11/8.12.11/8.12-FT) with ESMTP id j8R2sbIT017164 for ; Tue, 27 Sep 2005 04:54:37 +0200 To: Bill Kendall Subject: Re: xfsdump and tar on same tape Message-ID: <1127745384.4338076895826@hermesadm.chb.fr> Date: Mon, 26 Sep 2005 16:36:24 +0200 (CEST) From: Xavier Poirier Cc: linux-xfs@oss.sgi.com References: <1127738813.4337edbd27a25@hermesadm.chb.fr> <4337FB0E.8090302@sgi.com> In-Reply-To: <4337FB0E.8090302@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-WebMail-Company: Centre Hospitalier de Bourg en Bresse X-FAX-Notify: requeued X-MIME-Autoconverted: from 8bit to quoted-printable by hermesadm.chb.fr id j8QEaOt25795 X-AntiVirus: scanned for viruses by AMaViS (http://amavis.org/) X-AntiVirus: scanned for viruses by AMaViS (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8R2vTiL030220 X-archive-position: 6247 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xpoirier@ch-bourg01.fr Precedence: bulk X-list: linux-xfs Content-Length: 1965 Lines: 70 En réponse à Bill Kendall : not working , see also : (next to xfsdump -f /dev/nst0 /home) mt -f /dev/nst0 fsf 1 /dev/nst0: Input/output error [root@intranet /]# mt -f /dev/nst0 status SCSI 2 tape drive: File number=44, block number=0, partition=0. Tape block size 1048576 bytes. Density code 0x26 (DDS-4 or QIC-4GB). Soft error count since last status=0 General status bits on (89010000): EOF EOD ONLINE IM_REP_EN > After xfsrestore completes, issue "mt -f /dev/nstX fsf 1" > to seek to the next file and then run tar. > > Bill > > On 09/26/05 07:46, Xavier Poirier wrote: > > hi, > > > > I want to make a backup of my two filesystems witch are: > > > > / (EXT2) > > /home (XFS) > > > > I want to do an XFSDUMP of /home with no-rewind capabilities > of the > > tape and add next a TAR of / to the end. > > The problem is that I cannot read TAR archive of the tape > (xfsdump > > read without problem), I don't know the number session to go > on the tape. > > Any idea? > > > > Xavier > > > > > > > -------------------------------------------------------------------- > > Ce courriel est envoyé au travers de l' interface IMP: > ch-bourg01.fr > > Ce message a été passé automatiquement à l' antivirus > > This email have been sent through Imap Mail Program: > ch-bourg01.fr > > This message have been scanned with an antivirus scanner > > > > > ***** Xavier Poirier ***** *** Technicien Informatique *** * Centre Hospitalier de Bourg en Bresse * * Tel : 04 74 45 41 17 * *** eFax : 04 74 23 04 53 *** ***** mailto:xpoirier@ch-bourg01.fr ***** -------------------------------------------------------------------- Ce courriel est envoyé au travers de l' interface IMP: ch-bourg01.fr Ce message a été passé automatiquement à l' antivirus This email have been sent through Imap Mail Program: ch-bourg01.fr This message have been scanned with an antivirus scanner From owner-linux-xfs@oss.sgi.com Mon Sep 26 23:14:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Sep 2005 23:14:44 -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 j8R6EZiL008386 for ; Mon, 26 Sep 2005 23:14:36 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j8R6BkxT021475 for ; Tue, 27 Sep 2005 01:11:46 -0500 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j8R6EXAQ58142789 for ; Mon, 26 Sep 2005 23:14:33 -0700 (PDT) X-ASG-Debug-ID: 1127752576-11543-20-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id AF3B36DDB52 for ; Mon, 26 Sep 2005 09:36:16 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j8QGaDfS003015; Mon, 26 Sep 2005 11:36:15 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j8QGaAEI002940; Mon, 26 Sep 2005 11:36:10 -0500 Date: Mon, 26 Sep 2005 11:36:10 -0500 From: Christoph Hellwig Message-Id: <200509261636.j8QGaAEI002940@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com X-ASG-Orig-Subj: TAKE 943272 - endianess annotations and cleanup for the quota code Subject: TAKE 943272 - endianess annotations and cleanup for the quota code X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.4129 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6248 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1820 Lines: 33 first step towards making our byte swapping code sparse clean Date: Mon Sep 26 09:35:34 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.4.x Inspected by: nathans, tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:199767a fs/xfs/xfsidbg.c - 1.286 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.286&r2=text&tr2=1.285&f=h fs/xfs/xfs_arch.h - 1.49 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_arch.h.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h fs/xfs/xfs_log_recover.c - 1.302 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.302&r2=text&tr2=1.301&f=h fs/xfs/xfs_quota.h - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_quota.h.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h fs/xfs/quota/xfs_trans_dquot.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_trans_dquot.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h fs/xfs/quota/xfs_qm_syscalls.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h fs/xfs/quota/xfs_dquot_item.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot_item.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h fs/xfs/quota/xfs_dquot.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h fs/xfs/quota/xfs_qm.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h fs/xfs/linux-2.4/xfs_linux.h - 1.146 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.146&r2=text&tr2=1.145&f=h From owner-linux-xfs@oss.sgi.com Tue Sep 27 08:51:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Sep 2005 08:51:24 -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 j8RFp3iL020197 for ; Tue, 27 Sep 2005 08:51:03 -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 j8RFmDxT031820 for ; Tue, 27 Sep 2005 10:48:13 -0500 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j8RFmCDN16509551; Tue, 27 Sep 2005 10:48:12 -0500 (CDT) Message-ID: <433969BB.9050207@sgi.com> Date: Tue, 27 Sep 2005 10:48:11 -0500 From: Bill Kendall User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xavier Poirier CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump and tar on same tape References: <1127738813.4337edbd27a25@hermesadm.chb.fr> <4337FB0E.8090302@sgi.com> <1127745384.4338076895826@hermesadm.chb.fr> In-Reply-To: <1127745384.4338076895826@hermesadm.chb.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 6250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2640 Lines: 111 It appears you did the "mt fsf" after the dump. I meant for that to be done only when you were doing a restore, and to do so after the xfsrestore completed. The following sequence works for me: You might want to try using variable block mode on your tape device, if it supports it: # mt -f /dev/nst0 setblk 0 Then do your backups: # mt -f /dev/nst0 rewind # xfsdump -f /dev/nst0 /home # tar cvf /dev/nst0 /boot And to restore: # mt -f /dev/nst0 rewind # xfsrestore -f /dev/nst0 /somepath # mt -f /dev/nst0 fsf 1 # tar xvf /dev/nst0 Bill On 09/26/05 09:36, Xavier Poirier wrote: > En réponse à Bill Kendall : > > not working , see also : > > (next to xfsdump -f /dev/nst0 /home) > > mt -f /dev/nst0 fsf 1 > /dev/nst0: Input/output error > > [root@intranet /]# mt -f /dev/nst0 status > SCSI 2 tape drive: > File number=44, block number=0, partition=0. > Tape block size 1048576 bytes. Density code 0x26 (DDS-4 or QIC-4GB). > Soft error count since last status=0 > General status bits on (89010000): > EOF EOD ONLINE IM_REP_EN > > >>After xfsrestore completes, issue "mt -f /dev/nstX fsf 1" >>to seek to the next file and then run tar. >> >>Bill >> >>On 09/26/05 07:46, Xavier Poirier wrote: >> >>>hi, >>> >>>I want to make a backup of my two filesystems witch are: >>> >>>/ (EXT2) >>>/home (XFS) >>> >>>I want to do an XFSDUMP of /home with no-rewind capabilities >> >>of the >> >>>tape and add next a TAR of / to the end. >>>The problem is that I cannot read TAR archive of the tape >> >>(xfsdump >> >>>read without problem), I don't know the number session to go >> >>on the tape. >> >>>Any idea? >>> >>>Xavier >>> >>> >>> >> >>-------------------------------------------------------------------- >> >>>Ce courriel est envoyé au travers de l' interface IMP: >> >>ch-bourg01.fr >> >>>Ce message a été passé automatiquement à l' antivirus >>>This email have been sent through Imap Mail Program: >> >>ch-bourg01.fr >> >>>This message have been scanned with an antivirus scanner >>> >>> >> > > > > ***** Xavier Poirier ***** > *** Technicien Informatique *** > * Centre Hospitalier de Bourg en Bresse * > * Tel : 04 74 45 41 17 * > *** eFax : 04 74 23 04 53 *** > ***** mailto:xpoirier@ch-bourg01.fr ***** > > -------------------------------------------------------------------- > Ce courriel est envoyé au travers de l' interface IMP: ch-bourg01.fr > Ce message a été passé automatiquement à l' antivirus > This email have been sent through Imap Mail Program: ch-bourg01.fr > This message have been scanned with an antivirus scanner > > From owner-linux-xfs@oss.sgi.com Tue Sep 27 09:38:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Sep 2005 09:38:49 -0700 (PDT) Received: from smtp.pzkagis.cz (gis6.netbox.cz [83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8RGcWiL025323 for ; Tue, 27 Sep 2005 09:38:33 -0700 Received: (from luf@localhost) by smtp.pzkagis.cz (8.11.6/8.11.6) id j8RGZVb22680; Tue, 27 Sep 2005 18:35:31 +0200 Date: Tue, 27 Sep 2005 18:35:31 +0200 From: Ludek Finstrle To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr Message-ID: <20050927163531.GA19652@soptik.pzkagis.cz> References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4338128F.8000707@sgi.com> User-Agent: Mutt/1.4i X-archive-position: 6251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luf@pzkagis.cz Precedence: bulk X-list: linux-xfs Content-Length: 1483 Lines: 44 > > I have problem with diferrence in filesize between ls -l and du -sk > >after xfs_fsr (it was ok before running xfs_fsr): > > > ># ls -l Drafts > >-rw-rw---- 1 user group 74646 Apr 15 17:37 Drafts > ># du -b Drafts > >3221303296 Drafts > > can you run xfs_bmap -v Drafts # xfs_bmap -v Drafts Drafts: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..151]: 14693632..14693783 7 (13568..13719) 152 00101 > If the file is otherwise readable (i.e. the first 74646 bytes are right) > simply copying the file to a new name & back -might- solve the problem. Yes, this helps but there are a lot of problematic files. BTW all files are readable and it seems the data isn't corrupted. > If you can keep the original problematic file around, though, it'd be > interesting to figure out what's happened here. I'm sorry. I'm stupid. I run xfs_repair which correct it. So I lost the original file this way :-( But I run xfs_bmap before xfs_repair. I don't know why I didn't run xfs_repair before I wrote to xfs mail list. > >My versions: > >kernel 2.4.31 vanilla + ACL patches > >xfsprogs-2.6.36-1 > >acl-2.2.31-1 > >attr-2.4.23-0 FS was created with kernel 2.4.9 (xfs 1.0.3). I don't remember exactly the version number. Maybe it was quite older. FS has several error (in dmesg) since (approximately) January. So I upgraded kernel to 2.4.31 with recent utils and didn't run neither xfs_repair nor xfs_verify. Best regards Luf From owner-linux-xfs@oss.sgi.com Tue Sep 27 09:46:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Sep 2005 09:46: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 j8RGkdiL026217 for ; Tue, 27 Sep 2005 09:46:39 -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 j8RGhoxT008729 for ; Tue, 27 Sep 2005 11:43:50 -0500 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 j8RGhnDN16507701; Tue, 27 Sep 2005 11:43:49 -0500 (CDT) Message-ID: <433976C5.1000104@sgi.com> Date: Tue, 27 Sep 2005 11:43:49 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludek Finstrle CC: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> In-Reply-To: <20050927163531.GA19652@soptik.pzkagis.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6252 X-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: 746 Lines: 28 Ludek Finstrle wrote: >>> I have problem with diferrence in filesize between ls -l and du -sk >>>after xfs_fsr (it was ok before running xfs_fsr): >>> >>># ls -l Drafts >>>-rw-rw---- 1 user group 74646 Apr 15 17:37 Drafts >>># du -b Drafts >>>3221303296 Drafts >> >>can you run xfs_bmap -v Drafts > > > # xfs_bmap -v Drafts > Drafts: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS > 0: [0..151]: 14693632..14693783 7 (13568..13719) 152 00101 151 * 512 = 77824, so that's fine... bmap reports only 78k used. Not sure du is reporting more... Well, if you run into this again we'll dig some more :) Do you happen to still have the xfs_repair output in scrollback somewhere? Thanks, -Eric From owner-linux-xfs@oss.sgi.com Tue Sep 27 12:21:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Sep 2005 12:21:24 -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 j8RJLBiL009325 for ; Tue, 27 Sep 2005 12:21:12 -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 j8RJIMxT004557 for ; Tue, 27 Sep 2005 14:18:22 -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 j8RJILsL22431163; Tue, 27 Sep 2005 14:18:21 -0500 (CDT) Message-ID: <43399AFD.9030909@sgi.com> Date: Tue, 27 Sep 2005 14:18:21 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Ludek Finstrle , linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> In-Reply-To: <433976C5.1000104@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6253 X-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: 539 Lines: 21 Eric Sandeen wrote: > Ludek Finstrle wrote: > >>>> I have problem with diferrence in filesize between ls -l and du -sk >>>> after xfs_fsr (it was ok before running xfs_fsr): >>>> >>>> # ls -l Drafts >>>> -rw-rw---- 1 user group 74646 Apr 15 17:37 Drafts >>>> # du -b Drafts >>>> 3221303296 Drafts >>> >>> >>> can you run xfs_bmap -v Drafts I suppose we should have checked the attribute fork.... any idea if you're using extended attributes? if you still have a problematic file around, try xfs_bmap with the -a option. -Eric From owner-linux-xfs@oss.sgi.com Tue Sep 27 15:16:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Sep 2005 15:16:38 -0700 (PDT) Received: from asteria.debian.or.at (asteria.debian.or.at [86.59.5.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8RMGViL022969 for ; Tue, 27 Sep 2005 15:16:32 -0700 Received: by asteria.debian.or.at (Postfix, from userid 1002) id 598C370CD0C; Wed, 28 Sep 2005 00:13:41 +0200 (CEST) Date: Wed, 28 Sep 2005 00:13:41 +0200 From: Peter Palfrader To: linux-xfs@oss.sgi.com Subject: LEAFN node level is 1 inode 97055 bno = 8388608 Message-ID: <20050927221341.GB14305@asteria.noreply.org> Mail-Followup-To: Peter Palfrader , linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline X-PGP: 1024D/94C09C7F 5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F X-Request-PGP: http://www.palfrader.org/keys/94C09C7F.asc X-Accept-Language: de, en User-Agent: Mutt/1.5.9i X-archive-position: 6254 X-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@palfrader.org Precedence: bulk X-list: linux-xfs Content-Length: 2006 Lines: 73 Hi, I have an xfs filesystem (on lvm on a 3ware raid1) that might be slightly corrupted. xfs_check doesn't find any problems and exits with a nice exitcode of 0. xfs_repair complains a few times about | LEAFN node level is 1 inode bno = 8388608 during phases 3 and 4. It lists 5 inodes, and all of them are directories. This looks to be the very same thing as described in June already: http://oss.sgi.com/archives/linux-xfs/2005-06/msg00049.html Russell Howe on the #xfs channel on OFTC suggested I also attach the xfs_db output of one such inode: xfs_db> inode 97055 xfs_db> print core.magic = 0x494e core.mode = 040750 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 2 core.uid = 100 core.gid = 105 core.flushiter = 680 core.atime.sec = Tue Sep 27 16:27:58 2005 core.atime.nsec = 490530254 core.mtime.sec = Thu Sep 22 09:53:25 2005 core.mtime.nsec = 483402945 core.ctime.sec = Thu Sep 22 09:53:25 2005 core.ctime.nsec = 483402945 core.size = 24576 core.nblocks = 8 core.extsize = 0 core.nextents = 8 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.gen = 0 next_unlinked = null u.bmx[0-7] = [startoff,startblock,blockcount,extentflag] 0:[0,6350,1,0] 1:[1,13826,1,0] 2:[2,43526,1,0] 3:[3,19019,1,0] 4:[4,15787,1,0] 5:[5,13426,1,0] 6:[8388608,13639,1,0] 7:[16777216,1243,1,0] xfs_db> If there isn't anything you would like me to try with the filesystem I will go ahead and do what the poster in the mail from June suggested, moving the contents of the corrupted directories to newly created directories and rmdir the offending ones. Cheers, Peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred. | : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `- http://www.debian.org/ From owner-linux-xfs@oss.sgi.com Wed Sep 28 01:47:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 01:47:55 -0700 (PDT) Received: from smtp01av.ntr.oleane.net (smtp-out2.net.av.oleane.com [195.25.12.12]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8S8lmiL022539 for ; Wed, 28 Sep 2005 01:47:49 -0700 Received: from Antivirus (localhost [127.0.0.1]) by smtp01av.ntr.oleane.net with ESMTP id j8S8ivT7017112 for ; Wed, 28 Sep 2005 10:44:57 +0200 Received: from hermesadm.chb.fr ([194.3.110.58]) by smtp01av.ntr.oleane.net (8.12.11/8.12.11/8.12-FT) with ESMTP id j8S8iuq3017104 for ; Wed, 28 Sep 2005 10:44:56 +0200 To: Bill Kendall Subject: Re: xfsdump and tar on same tape Message-ID: <1127896987.433a579b3165d@hermesadm.chb.fr> Date: Wed, 28 Sep 2005 10:43:07 +0200 (CEST) From: Xavier Poirier Cc: linux-xfs@oss.sgi.com References: <1127738813.4337edbd27a25@hermesadm.chb.fr> <4337FB0E.8090302@sgi.com> <1127745384.4338076895826@hermesadm.chb.fr> <433969BB.9050207@sgi.com> In-Reply-To: <433969BB.9050207@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-WebMail-Company: Centre Hospitalier de Bourg en Bresse X-FAX-Notify: requeued X-MIME-Autoconverted: from 8bit to quoted-printable by hermesadm.chb.fr id j8S8h7W17551 X-AntiVirus: scanned for viruses by AMaViS (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8S8loiL022541 X-archive-position: 6255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xpoirier@ch-bourg01.fr Precedence: bulk X-list: linux-xfs Content-Length: 707 Lines: 23 Hi Bill, I tryed what you say, ok I had not well anderstood before. I still have a problem next to the xfsrestore command: look: (xfsrestore)... [root@intranet /]# mt -f /dev/nst0 fsf 1 [root@intranet /]# tar tvf /dev/nst0 tar: /dev/nst0: ne peut read: Cannot allocate memory tar: Au début du ruban, fin prématurée. tar: Erreur non récupérable: fin de l'exécution immédiate Xavier -------------------------------------------------------------------- Ce courriel est envoyé au travers de l' interface IMP: ch-bourg01.fr Ce message a été passé automatiquement à l' antivirus This email have been sent through Imap Mail Program: ch-bourg01.fr This message have been scanned with an antivirus scanner From owner-linux-xfs@oss.sgi.com Wed Sep 28 04:48:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 04:48:37 -0700 (PDT) Received: from smtp08av.ntr.oleane.net (smtp-out2.net.av.oleane.com [195.25.12.12]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8SBmXiL007554 for ; Wed, 28 Sep 2005 04:48:34 -0700 Received: from Antivirus (localhost [127.0.0.1]) by smtp08av.ntr.oleane.net with ESMTP id j8SBjgck022542 for ; Wed, 28 Sep 2005 13:45:42 +0200 Received: from hermesadm.chb.fr ([194.3.110.58]) by smtp08av.ntr.oleane.net (8.12.11/8.12.11/8.12-FT) with ESMTP id j8SBjgiv022501 for ; Wed, 28 Sep 2005 13:45:42 +0200 To: Bill Kendall Subject: Re: xfsdump and tar on same tape Message-ID: <1127907833.433a81f964af4@hermesadm.chb.fr> Date: Wed, 28 Sep 2005 13:43:53 +0200 (CEST) From: Xavier Poirier Cc: linux-xfs@oss.sgi.com References: <1127738813.4337edbd27a25@hermesadm.chb.fr> <4337FB0E.8090302@sgi.com> <1127745384.4338076895826@hermesadm.chb.fr> <433969BB.9050207@sgi.com> In-Reply-To: <433969BB.9050207@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-WebMail-Company: Centre Hospitalier de Bourg en Bresse X-FAX-Notify: requeued X-MIME-Autoconverted: from 8bit to quoted-printable by hermesadm.chb.fr id j8SBhr815186 X-AntiVirus: scanned for viruses by AMaViS (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8SBmYiL007557 X-archive-position: 6256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xpoirier@ch-bourg01.fr Precedence: bulk X-list: linux-xfs Content-Length: 765 Lines: 27 This seems to work for me, look: # mt -f /dev/nst0 setblk 0 # mt -f /dev/nst0 rewind # xfsdump -f /dev/nst0 /home # mt -f /dev/nst0 status|grep "File number"|cut -d "," -f 1|cut -d "=" -f 2 (to get next session number) # tar cvf /dev/nst0 /boot And to restore: # mt -f /dev/nst0 rewind # mt -f /dev/nst0 fsf X (where X is session number I've get before) # tar tvf /dev/nst0 I read my tar session and xfsdump session ! Good Xavier -------------------------------------------------------------------- Ce courriel est envoyé au travers de l' interface IMP: ch-bourg01.fr Ce message a été passé automatiquement à l' antivirus This email have been sent through Imap Mail Program: ch-bourg01.fr This message have been scanned with an antivirus scanner From owner-linux-xfs@oss.sgi.com Wed Sep 28 12:03:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 12:03:37 -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 j8SJ3RO0013140 for ; Wed, 28 Sep 2005 12:03:27 -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 j8SK3t9x009715 for ; Wed, 28 Sep 2005 13:03:55 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j8SIxYDN16586116; Wed, 28 Sep 2005 13:59:35 -0500 (CDT) Received: from [128.162.232.14] (lnx-yingping.americas.sgi.com [128.162.232.14]) by tulip-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id j8SIxYRA6582934; Wed, 28 Sep 2005 13:59:34 -0500 (CDT) Message-ID: <433AE816.8010700@sgi.com> Date: Wed, 28 Sep 2005 13:59:34 -0500 From: Yingping Lu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 943405 - xfs_repair memory allocation problem caused segmentation fault Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yingping@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 887 Lines: 24 Fix segmentation fault due to allocation size Date: Wed Sep 28 11:53:35 PDT 2005 Workarea: attica.americas.sgi.com:/home/tulip60/yingping/projects/xfs-cmds Inspected by: Sandeen Author: yingping The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:199925a xfsprogs/VERSION - 1.134 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h - Change version xfsprogs/doc/CHANGES - 1.178 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.178&r2=text&tr2=1.177&f=h - Update CHANGE log xfsprogs/repair/incore.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/incore.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h - Fix roundup error of size in setup_bmap function From owner-linux-xfs@oss.sgi.com Wed Sep 28 12:40:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 12:40:31 -0700 (PDT) Received: from mail.levigo.de (hg-msq-srv.levigo.de [62.206.214.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8SJePO0020110 for ; Wed, 28 Sep 2005 12:40:26 -0700 Received: from ASSP-nospam (mail.levigo.de [127.0.0.1]) by mail.levigo.de (Postfix) with ESMTP id D9BBA7E6F for ; Wed, 28 Sep 2005 21:37:33 +0200 (CEST) Received: from 10.208.1.44 ([10.208.1.44] helo=[10.208.1.44]) by ASSP-nospam ; 28 Sep 05 19:37:33 -0000 Message-ID: <433AF0FC.1040205@levigo.de> Date: Wed, 28 Sep 2005 21:37:32 +0200 From: Klaus Rein Organization: levigo systems gmbh User-Agent: Debian Thunderbird 1.0.2 (X11/20050817) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs on PowerPC X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090400060800040501010203" X-archive-position: 6258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: k.rein@levigo.de Precedence: bulk X-list: linux-xfs Content-Length: 5539 Lines: 107 This is a cryptographically signed message in MIME format. --------------ms090400060800040501010203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, are there any known issues regarding xfs on power architecture? We want to build a samba file server and need a file system with acl support. The target hardware *could* be an IBM OpenPower system with SLES9 (xfs or ext3) if there are no serious reasons against this combination. We use xfs on a lot of machines, but so far only with Intel and AMD hardware. Klaus. --------------ms090400060800040501010203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIKCzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsT H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0x MzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/ Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVt YWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggNgMIICyaADAgEC AgMO1FswDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDYwMTEyNTcz OVoXDTA2MDYwMTEyNTczOVowgdQxCzAJBgNVBAYTAkRFMRswGQYDVQQIExJC YWRlbi1XdWVydHRlbWJlcmcxFjAUBgNVBAcTDUhvbHpnZXJsaW5nZW4xHDAa BgNVBAoTE2xldmlnbyBzeXN0ZW1zIGdtYmgxHTAbBgNVBAwTFFN5c3RlbSBB ZG1pbmlzdHJhdG9yMQ0wCwYDVQQEEwRSZWluMQ4wDAYDVQQqEwVLbGF1czET MBEGA1UEAxMKS2xhdXMgUmVpbjEfMB0GCSqGSIb3DQEJARYQay5yZWluQGxl dmlnby5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKs2+e0O ELR8kZdmQ3Yj7tZB4YrCcJjIxrJkTBwS0XB2IkawUY4OIT/ATOX23/WYLb0Z YyXDGBemjPsNL+SXQa2Unu9IQfNTuHLyApvubqpEWxMI76rpPLgVgfC/8ms7 bpF/MxfT38oAzpN48vj5q2Lt0N8C8F7ogZOdoLyLOz//QG3il75ax1PK7JRQ ZbCBSZIQHjOrUMNDYs6fUbGqc4DRWBRpiKXyq3Xj1BRjoxb75MMvd0lOZdJM oHNuaBxDjvxkuxlfOVsdRPsBuprKrznVD7D8/eS6nSuSSC4WZmip//FG8jRb fHIqv3PFUa6Bab8fzr4UVtxshObcTzb2tKUCAwEAAaMtMCswGwYDVR0RBBQw EoEQay5yZWluQGxldmlnby5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BAUAA4GBABVinjKJxMcnD16heQBBYyA3W/UF/GGNfU4EwId9yDbfmcUYxJ4U RfJNIgq85BCHk1/QSYG39E5FSiizRZ1YOd/2aLsr2L17VkHICD59vwNKinsO 9XRhAor8VC+QeO1NRp3s/i9y3kRzJ1X8F7X0fUPXqFT1oCrDjkcABqlrTy7W MIIDYDCCAsmgAwIBAgIDDtRbMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAe Fw0wNTA2MDExMjU3MzlaFw0wNjA2MDExMjU3MzlaMIHUMQswCQYDVQQGEwJE RTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRYwFAYDVQQHEw1Ib2x6 Z2VybGluZ2VuMRwwGgYDVQQKExNsZXZpZ28gc3lzdGVtcyBnbWJoMR0wGwYD VQQMExRTeXN0ZW0gQWRtaW5pc3RyYXRvcjENMAsGA1UEBBMEUmVpbjEOMAwG A1UEKhMFS2xhdXMxEzARBgNVBAMTCktsYXVzIFJlaW4xHzAdBgkqhkiG9w0B CQEWEGsucmVpbkBsZXZpZ28uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCrNvntDhC0fJGXZkN2I+7WQeGKwnCYyMayZEwcEtFwdiJGsFGO DiE/wEzl9t/1mC29GWMlwxgXpoz7DS/kl0GtlJ7vSEHzU7hy8gKb7m6qRFsT CO+q6Ty4FYHwv/JrO26RfzMX09/KAM6TePL4+ati7dDfAvBe6IGTnaC8izs/ /0Bt4pe+WsdTyuyUUGWwgUmSEB4zq1DDQ2LOn1GxqnOA0VgUaYil8qt149QU Y6MW++TDL3dJTmXSTKBzbmgcQ478ZLsZXzlbHUT7Abqayq851Q+w/P3kup0r kkguFmZoqf/xRvI0W3xyKr9zxVGugWm/H86+FFbcbITm3E829rSlAgMBAAGj LTArMBsGA1UdEQQUMBKBEGsucmVpbkBsZXZpZ28uZGUwDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQQFAAOBgQAVYp4yicTHJw9eoXkAQWMgN1v1BfxhjX1O BMCHfcg235nFGMSeFEXyTSIKvOQQh5Nf0EmBt/RORUoos0WdWDnf9mi7K9i9 e1ZByAg+fb8DSop7DvV0YQKK/FQvkHjtTUad7P4vct5EcydV/Be19H1D16hU 9aAqw45HAAapa08u1jGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMO1FswCQYF Kw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwOTI4MTkzNzMyWjAjBgkqhkiG9w0BCQQxFgQUsPwpwv4L 7zAwocSgq4FUmV8VggswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7UWzB6Bgsq hkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMO1FswDQYJKoZIhvcNAQEBBQAE ggEATXlV3OgDoAT5AmyGFWMqt03LEb1RooWSfAxiEJWC77u56GgAzVJFzSqO ByyBWgimK7GWUwIoiW4jEn3wp3O/NlXAZHz+W3gIuFj17a1hgQec2bCP3aO1 JwqKE77wbjblUgr1F8UHCQLelDtFA/zwHGrL5U7B/NxxPORGnxdJQIHHz0iz XekHiFdPaAhwMAvCMAXXVt5Suoz3LvlEuEnhSvpwhK1Q90/DcYiM+0xhVYJ/ AgEC8/C5vAuNYhX0OwNXQWPjCTSLoAZaX7DZPNfYdqnnjL+hpNL1qYtxat09 IkPT8ltt79ODuoO/tpHvvX1uIRpZklCjAqzNjbRoJow8CAAAAAAAAA== --------------ms090400060800040501010203-- From owner-linux-xfs@oss.sgi.com Wed Sep 28 17:05:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 17:05:38 -0700 (PDT) Received: from cfoemail.com ([60.176.202.171]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j8T05OO0011286; Wed, 28 Sep 2005 17:05:26 -0700 Message-ID: <91ff01c5c48d$b509ac30$a645f0c9@berit> Reply-To: "duncan lasswell" From: "duncan lasswell" To: "Irwin Perron" Cc: , , , Subject: sinister Broad medicinal collections gratify your wants. southeast Date: Thu, 29 Sep 2005 00:35:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-archive-position: 6259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: berit@cfoemail.com Precedence: bulk X-list: linux-xfs Content-Length: 629 Lines: 24 Saves for real therapeutics. Immediate results capsulle to heal your cramps. It's our motto that accomplishes brisk carriage. Ours non-expensive because of minor fixed cost. Let our professional review your health profiles at zero cents. Thanks for providing free Internet check up. Ben J --NJ. http://uk.geocities.com/timecravatshine/?dlnfxpfmt "Rheumatism, sir?" said Richard. debuginit dptspd filipiniana HZ03 dpu eqfn "Are you busy this morning, Hilda?" he asked as he sat down, his hat and gloves in his hand. "Very. I've been up and about three hours, working at my part. We open in February, you know." From owner-linux-xfs@oss.sgi.com Wed Sep 28 17:12:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 17:12:18 -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 j8T0C6O0012565 for ; Wed, 28 Sep 2005 17:12:08 -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 KAA01027; Thu, 29 Sep 2005 10:09:09 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 2443249BFB26; Thu, 29 Sep 2005 10:09:08 +1000 (EST) To: linux-xfs@oss.sgi.com Cc: agruen@suse.de Subject: TAKE 907752 - French translation for acl package Message-Id: <20050929000908.2443249BFB26@chook.melbourne.sgi.com> Date: Thu, 29 Sep 2005 10:09:08 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6260 X-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: 1009 Lines: 23 Add French translation from the debian-l10n-french folks (thanks to Sylvain Archenault). Date: Thu Sep 29 10:07:33 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: sylvain.archenault@laposte.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:23974a acl/po/fr.po - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/po/fr.po acl/VERSION - 1.72 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/VERSION.diff?r1=text&tr1=1.72&r2=text&tr2=1.71&f=h acl/doc/CHANGES - 1.79 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.79&r2=text&tr2=1.78&f=h acl/debian/changelog - 1.66 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/debian/changelog.diff?r1=text&tr1=1.66&r2=text&tr2=1.65&f=h acl/po/Makefile - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/po/Makefile.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h From owner-linux-xfs@oss.sgi.com Wed Sep 28 18:11:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 18:11:24 -0700 (PDT) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8T1BGO0017687 for ; Wed, 28 Sep 2005 18:11:17 -0700 Received: from saturn (c211-28-165-30.eburwd2.vic.optusnet.com.au [211.28.165.30]) by mail04.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j8T18Feo008806; Thu, 29 Sep 2005 11:08:20 +1000 Received: from [192.168.1.65] (helo=localhost.localdomain) by saturn with esmtp (Exim 3.36 #1 (Debian)) id 1EKmuF-0005TG-00; Thu, 29 Sep 2005 11:08:15 +1000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id B8BF3140EA6A; Thu, 29 Sep 2005 11:08:25 +1000 (EST) Subject: Re: xfs on PowerPC From: Stewart Smith To: Klaus Rein Cc: linux-xfs@oss.sgi.com In-Reply-To: <433AF0FC.1040205@levigo.de> References: <433AF0FC.1040205@levigo.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XUSne6y50RWx3kxESVNJ" Date: Thu, 29 Sep 2005 11:08:24 +1000 Message-Id: <1127956105.28583.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 X-archive-position: 6261 X-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: 927 Lines: 31 --=-XUSne6y50RWx3kxESVNJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-09-28 at 21:37 +0200, Klaus Rein wrote: > are there any known issues regarding xfs on power architecture? I can tell you from years of first hand experience that it works fine. Great in fact. I have run it on PPC32 for many years - on laptops and desktops. --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-XUSne6y50RWx3kxESVNJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQCVAwUAQzs+iIwDm44RooHBAQJ9NwQApGMiA2VYikQwP0/9TPOwFwbIlkFGxTKb 6fvc12RE+l9jzI32k5h3KgoUmAOniBDBr+fSPKHGqFewmHTHnrzD648IGviD7ikV sZv9XpWl/u0jNgiUs2LTST6ADWn/hPFePb05IUhk1RVRWep4tvz6/GVEgtrX6/+r h7kxd/0Ehuk= =vfg5 -----END PGP SIGNATURE----- --=-XUSne6y50RWx3kxESVNJ-- From owner-linux-xfs@oss.sgi.com Wed Sep 28 19:46:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 19:46:43 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8T2kaO0024954 for ; Wed, 28 Sep 2005 19:46:36 -0700 Received: by zproxy.gmail.com with SMTP id 4so689492nzn for ; Wed, 28 Sep 2005 19:43:45 -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; b=n9lGcva5irRGO22nGw3gKxoNENqqZmf4abprcWWqIHvuDACIfwEG4wYANVWuKequSjACFw3L90raggSH/Lwmu+pjWB0SkHIIp0NpfWZDcq+z6PygUPk64V8uBOlJkRZ94LvufyZ60Z12kzlJqvsna8hFyIO201I3kId0d0NJFHg= Received: by 10.36.75.12 with SMTP id x12mr4024711nza; Wed, 28 Sep 2005 18:02:51 -0700 (PDT) Received: by 10.36.61.19 with HTTP; Wed, 28 Sep 2005 18:02:51 -0700 (PDT) Message-ID: <61f78fbe05092818029050dfb@mail.gmail.com> Date: Wed, 28 Sep 2005 21:02:51 -0400 From: Larry K Reply-To: Larry K To: linux-xfs@oss.sgi.com Subject: Need xfs Assistance With Weird Problem MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lunchtimelarry@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 2589 Lines: 64 I have a FC3 box running mythtv. Up until recently, I had been running LVM (and xfs) with only a single physical volume of 300GB. I probably have 100GB of data files in the volume, waiting to be watched. So, Myth was running fine and all was well, except I had another 150GB partition just laying around, not in use. So, I decided to extend my volume group and add this 150GB to make it a total of 450GB, like so: 1. Using fdisk, deleted /dev/hda4 partition 2. Using fdisk, created /dev/hda4 as LVM 3. Created physical volume: pvcreate /dev/hda4 4. Extended volume group: vgextend vg /dev/hda4 5. Ran vgdisplay to see amount of free space that needs to be extended (18214) 6. unmount the volume group: umount /dev/vg/video 7. extend: lvextend -l +18214 /dev/vg/video 8. mount /dev/vg/video 9. grow the xfs file system: xfs_grow /dev/vg/video 10. Remove /video from /etc/fstab Now, df -k shows the new space: [root@mythtv ~]# df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 10080520 2938120 6630332 31% / /dev/hda1 101086 16752 79115 18% /boot none 257908 0 257908 0% /dev/shm /dev/mapper/vg-video 442105856 113816336 328289520 26% /video2 Everything appeared to be OK. I now had a 450GB partition instead of 300GB. However, I soon discovered that new files are written with a length of zero (empty files). Doh! The mythfrontend was able to play back the existing files that were in the VG, but if I tried to delete a file, the app would hang. That's when I knew I had a problem for sure. Also odd is that when, as root, I cat /dev/video0 > /video2/xxx.mpg, this file is also empty. However, if I copy an existing file, as in cp /video2/blah blah.nuv /video2/xxx, it shows up with the proper length. So old files copy correctly, but new files are not written correctly. There are no error messages in either the mythtv application logs, nor the log file at /var/log/messages. I did notice that one of the HDs is running DMA 100, while the other is DMA 133. Does this matter to xfs or even to LVM? Anyone have any thoughts as to what might be causing this? Diagnostics? Hidden error messages? Backing up 100GB of data is gonna be difficult. About the only way I have is to ftp the data to another box, which will take at least 24 hours, according to my estimates. Since everything was working before I expanded the file system from 300GB up to 450GB, I suppose going back might be an option. Since there is no way to shrink an xfs file system, I'm not sure if I can go back now? Thanks! [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Sep 28 21:00:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 21:00: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 j8T40bO0002902 for ; Wed, 28 Sep 2005 21:00: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 NAA05074; Thu, 29 Sep 2005 13:57:41 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id E3FF949BFB2B; Thu, 29 Sep 2005 13:57:39 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 941645 - attr2 userspace fixups Message-Id: <20050929035739.E3FF949BFB2B@chook.melbourne.sgi.com> Date: Thu, 29 Sep 2005 13:57:39 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6263 X-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: 4796 Lines: 105 Merge back a kernel attr2 fix into libxfs. Date: Wed Sep 28 20:23:31 PDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/us-xfs-cmds Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:199955a xfsprogs/libxfs/xfs_bmap.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_bmap.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h Merge back further kernel changes into libxfs, esp. attr2 related, and extend xfs_db attrset code to allow noattr2 debugging also. Date: Wed Sep 28 20:27:13 PDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/us-xfs-cmds Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:199956a xfsprogs/libxlog/xfs_log_recover.c - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxlog/xfs_log_recover.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h xfsprogs/include/xfs_da_btree.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_da_btree.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/include/libxfs.h - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h xfsprogs/libxfs/xfs.h - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h xfsprogs/libxfs/init.c - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/init.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h xfsprogs/libxfs/xfs_dir2_block.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir2_block.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/libxfs/xfs_dir.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/libxfs/xfs_dir2_sf.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir2_sf.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/libxfs/xfs_attr_leaf.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_attr_leaf.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/libxfs/xfs_bmap.c - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_bmap.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h xfsprogs/db/attrset.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/attrset.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfsprogs/libxfs/xfs_attr.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_attr.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Add repair code for propogating attr2 bit to secondary superblocks (ala attr1). Date: Wed Sep 28 20:32:20 PDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/us-xfs-cmds Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:199958a xfsprogs/repair/versions.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/versions.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/repair/versions.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/versions.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsprogs/repair/xfs_repair.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/xfs_repair.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h Fix morebits bit check in xfs_repair, previously it would clear features2. Date: Wed Sep 28 20:44:42 PDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/us-xfs-cmds Inspected by: overby The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:199959a xfsprogs/repair/agheader.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/agheader.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h Bump xfsprogs version number for recent changes. Date: Wed Sep 28 20:56:47 PDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/us-xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:199960a xfsprogs/VERSION - 1.135 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h xfsprogs/doc/CHANGES - 1.179 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.179&r2=text&tr2=1.178&f=h xfsprogs/debian/changelog - 1.121 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.121&r2=text&tr2=1.120&f=h From owner-linux-xfs@oss.sgi.com Wed Sep 28 22:47:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 22:47:13 -0700 (PDT) Received: from smtp.pzkagis.cz (gis6.netbox.cz [83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8T5l6O0010322 for ; Wed, 28 Sep 2005 22:47:07 -0700 Received: (from luf@localhost) by smtp.pzkagis.cz (8.11.6/8.11.6) id j8T5iAH31061; Thu, 29 Sep 2005 07:44:10 +0200 Date: Thu, 29 Sep 2005 07:44:10 +0200 From: Ludek Finstrle To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr Message-ID: <20050929054410.GA30789@soptik.pzkagis.cz> References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433976C5.1000104@sgi.com> User-Agent: Mutt/1.4i X-archive-position: 6264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luf@pzkagis.cz Precedence: bulk X-list: linux-xfs Content-Length: 1518 Lines: 48 > Well, if you run into this again we'll dig some more :) I try xfs_fsr again and the problem is back. > ># xfs_bmap -v Drafts > >Drafts: > > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS > > 0: [0..151]: 14693632..14693783 7 (13568..13719) 152 00101 > > 151 * 512 = 77824, so that's fine... bmap reports only 78k used. Not sure > du is reporting more... # ls -l Inbox -rwxrwx--- 1 user group 5038423 Sep 28 15:43 Inbox # du -b Inbox 1347219456 Inbox # xfs_bmap -v Inbox Inbox: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..9847]: 58182528..58192375 27 (1559424..1569271) 9848 00111 > if you still have a problematic file around, try xfs_bmap with the -a option. # xfs_bmap -a Inbox Inbox: 0: [0..7]: 23962832..23962839 1: [8..8388607]: hole > Do you happen to still have the xfs_repair output in scrollback somewhere? Unfortunetelly I haven't. But there were a lot of lines with bad block count (9 to 12 digits maybe more - corrected e.g. to 2 blocks). And / for FS was moved to lost+found. If you are interested in xfs_repair output I can run it again in the evening (I'm in timezone GMT+2). The problem is on production machine so I have to wait. > I suppose we should have checked the attribute fork.... any idea if you're > using extended attributes? I use ACL (extended attributes). # chacl -l Inbox Inbox [u::rwx,u:user:rwx,g::---,g:group1:rwx,g:group2:rwx,m::rwx,o::---] Thanks, Luf From owner-linux-xfs@oss.sgi.com Wed Sep 28 23:39:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Sep 2005 23:40:01 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8T6dwO0013854 for ; Wed, 28 Sep 2005 23:39:58 -0700 Received: from gateway-att.yingternet.com (c-24-126-232-43.hsd1.ca.comcast.net [24.126.232.43]) by ying.yingternet.com (Postfix) with ESMTP id 48CC230009E for ; Wed, 28 Sep 2005 23:38:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id 31879204C18; Wed, 28 Sep 2005 23:37:05 -0700 (PDT) Message-ID: <433B8B8F.9010300@yingternet.com> Date: Thu, 29 Sep 2005 14:37:03 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: Ying-Hung Chen Subject: preallocation References: <4337ADB7.3060700@yingternet.com> <43381317.8040007@sgi.com> In-Reply-To: <43381317.8040007@sgi.com> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/mixed; boundary="------------080501030004060500030503" X-archive-position: 6265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 6712 Lines: 254 This is a multi-part message in MIME format. --------------080501030004060500030503 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I just tried the preallocation method Eric provided: after run the xfs_allocate code to allocate 52MB each (see xfs_preallocate.cpp) [root@localhost hdb4]# xfs_bmap 00001.ivf 00001.ivf: 0: [0..106495]: 96..106591 [root@localhost hdb4]# du -sh 00001.ivf 52M 00001.ivf and when I writing data in it (see recorder_simulator.cpp) bascially i am simulating 16 cocurrent streams (up to 50MB, so there are still space left) I got heavy fragmentations (shown below) did I do anything wrong? Thanks -Ying [root@localhost hdb4]# xfs_bmap 00001.ivf 00001.ivf: 0: [0..639]: 96..735 1: [640..1151]: 10336..10847 2: [1152..2687]: 30048..31583 3: [2688..3967]: 50528..51807 4: [3968..17151]: 220768..233951 5: [17152..19711]: 298080..300639 6: [19712..20223]: 320608..321119 7: [20224..20479]: 324704..324959 8: [20480..20991]: 328312..328823 9: [20992..21247]: 336304..336559 10: [21248..21759]: 340704..341215 11: [21760..22015]: 348640..348895 12: [22016..22271]: 352480..352735 13: [22272..22783]: 357088..357599 14: [22784..23039]: 368096..368351 15: [23040..23295]: 372192..372447 16: [23296..23551]: 376288..376543 17: [23552..24063]: 383712..384223 18: [24064..24319]: 388576..388831 19: [24320..24575]: 391904..392159 20: [24576..24831]: 396000..396255 21: [24832..25087]: 400352..400607 22: [25088..25343]: 404448..404703 23: [25344..25855]: 411360..411871 24: [25856..26111]: 416480..416735 25: [26112..26367]: 419296..419551 26: [26368..26623]: 423904..424159 27: [26624..26879]: 428000..428255 28: [26880..27135]: 430304..430559 29: [27136..27391]: 434400..434655 30: [27392..27647]: 438496..438751 31: [27648..27903]: 442592..442847 32: [27904..28671]: 446688..447455 33: [28672..28927]: 460256..460511 34: [28928..29439]: 463072..463583 35: [29440..29695]: 471264..471519 36: [29696..29951]: 475360..475615 37: [29952..30207]: 479456..479711 38: [30208..30463]: 483552..483807 39: [30464..30975]: 487648..488159 40: [30976..31231]: 495840..496095 41: [31232..31487]: 502752..503007 42: [31488..31743]: 506848..507103 43: [31744..31999]: 511200..511455 44: [32000..32255]: 515296..515551 45: [32256..32511]: 519392..519647 46: [32512..32767]: 522464..522719 47: [32768..33023]: 526560..526815 48: [33024..33791]: 533088..533855 49: [33792..34047]: 540512..540767 50: [34048..34303]: 544480..544735 51: [34304..34559]: 548320..548575 52: [34560..34815]: 551648..551903 53: [34816..35071]: 555488..555743 54: [35072..35327]: 559328..559583 55: [35328..36351]: 563168..564191 56: [36352..39679]: 605664..608991 57: [39680..42495]: 648416..651231 58: [42496..44799]: 684000..686303 59: [44800..47615]: 726240..729055 60: [47616..50175]: 764384..766943 61: [50176..52223]: 800736..802783 62: [52224..54399]: 830560..832735 63: [54400..55935]: 858592..860127 64: [55936..57471]: 883040..884575 65: [57472..58751]: 12200360..12201639 66: [58752..62335]: 18281744..18285327 67: [62336..70271]: 30493152..30501087 68: [70272..76287]: 42713776..42719791 69: [76288..84223]: 54900560..54908495 70: [84224..91647]: 61045096..61052519 71: [91648..100479]: 85444488..85453319 72: [100480..102399]: 91550192..91552111 --------------080501030004060500030503 Content-Type: text/plain; name="xfs_preallocate.cpp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_preallocate.cpp" #include #include void preallocate() { int fd, err; xfs_flock64_t fl; fl.l_whence = 0; fl.l_start = 1; fl.l_len = (off64_t)(52 * 1024 * 1024); /* 52M */ char str[10]; memset(str, 0, 10); int count = 1; while(count < 900) { snprintf(str, 10, "%05d.ivf", count); fd = open(str, O_RDWR|O_CREAT, S_IRWXU); if (fd < 0) { perror("open: "); printf("open of file %s failed\n", str); exit(1); } err = xfsctl(str, fd, XFS_IOC_RESVSP64, &fl); if (err < 0) { perror("allocsp: "); printf("XFS_IOC_RESVSP64 failed\n"); close(fd); exit(1); } close(fd); count++; } } int main(int argc, char **argv) { //if(argc != 2) // return fprintf(stderr, "Filename expected.\n"), 1; preallocate(); return 0; } --------------080501030004060500030503 Content-Type: text/plain; name="recorder_simulator.cpp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="recorder_simulator.cpp" #include #include #include #include #include #include #include using namespace std; const int WRITE_BLOCK=1024; class RecorderSimulator : public ACE_Task_Base { public: RecorderSimulator()//:cuException(NULL) { //sprintf(test_file,"05%d.ivf", getcount()); } int svc() { char data[WRITE_BLOCK]; while(1) { sprintf(test_file,"%05d.ivf", getcount()); cout << "Writing to file "<< test_file< 900) count = 1; else count ++; return count; } //CppUnit::Exception* cuException; char test_file[20]; /*void CatchException(CppUnit::Exception& e) { cuException = new CppUnit::Exception(e); }*/ }; int RecorderSimulator::count = 0; int main(void) { RecorderSimulator thread[16]; for(int i=0; i<16; ++i) thread[i].activate(); for(int i=0; i<16; ++i) thread[i].wait(); return 0; } --------------080501030004060500030503-- From owner-linux-xfs@oss.sgi.com Thu Sep 29 00:02:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Sep 2005 00:02:57 -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 j8T72qO0017438 for ; Thu, 29 Sep 2005 00:02:53 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA08080; Thu, 29 Sep 2005 16:59:52 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j8T6xo8q8883119; Thu, 29 Sep 2005 16:59:51 +1000 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j8T6xnJP8861479; Thu, 29 Sep 2005 16:59:49 +1000 (EST) Date: Thu, 29 Sep 2005 16:59:49 +1000 From: David Chinner To: Ying-Hung Chen Cc: linux-xfs@oss.sgi.com Subject: Re: preallocation Message-ID: <20050929065949.GC8727140@melbourne.sgi.com> References: <4337ADB7.3060700@yingternet.com> <43381317.8040007@sgi.com> <433B8B8F.9010300@yingternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433B8B8F.9010300@yingternet.com> User-Agent: Mutt/1.4.1i X-archive-position: 6266 X-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: 1618 Lines: 63 On Thu, Sep 29, 2005 at 02:37:03PM +0800, Ying-Hung Chen wrote: > Hi, I just tried the preallocation method Eric provided: > > after run the xfs_allocate code to allocate 52MB each (see > xfs_preallocate.cpp) > > [root@localhost hdb4]# xfs_bmap 00001.ivf > 00001.ivf: > 0: [0..106495]: 96..106591 > > [root@localhost hdb4]# du -sh 00001.ivf > 52M 00001.ivf > > and when I writing data in it (see recorder_simulator.cpp) bascially i > am simulating 16 cocurrent streams (up to 50MB, so there are still space > left) > > I got heavy fragmentations (shown below) > did I do anything wrong? Yes: > class RecorderSimulator : public ACE_Task_Base > { > public: > RecorderSimulator()//:cuException(NULL) > { > //sprintf(test_file,"05%d.ivf", getcount()); > } > > int svc() > { > char data[WRITE_BLOCK]; > while(1) > { > sprintf(test_file,"%05d.ivf", getcount()); > > cout << "Writing to file "<< test_file< FILE * f = fopen(test_file, "w+b"); What does "w" do when opening the file? w Truncate file to zero length or create text file for writing. The stream is positioned at the beginning of the file. w+ Open for reading and writing. The file is created if it does not exist, otherwise it is truncated. The stream is positioned at the beginning of the file. ` It truncates it. IOWS, it throws away the prealloc you did externally to this program. You need to do the preallocation after the truncation but before you start writing. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Thu Sep 29 02:25:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Sep 2005 02:25:45 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8T9PcO0029916 for ; Thu, 29 Sep 2005 02:25:38 -0700 Received: from gateway-att.yingternet.com (c-24-126-232-43.hsd1.ca.comcast.net [24.126.232.43]) by ying.yingternet.com (Postfix) with ESMTP id 453EC30009E; Thu, 29 Sep 2005 02:23:46 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id E67BE204C18; Thu, 29 Sep 2005 02:22:44 -0700 (PDT) Message-ID: <433BB263.4060108@yingternet.com> Date: Thu, 29 Sep 2005 17:22:43 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner Cc: linux-xfs@oss.sgi.com, Ying-Hung Chen Subject: Re: preallocation References: <4337ADB7.3060700@yingternet.com> <43381317.8040007@sgi.com> <433B8B8F.9010300@yingternet.com> <20050929065949.GC8727140@melbourne.sgi.com> In-Reply-To: <20050929065949.GC8727140@melbourne.sgi.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 645 Lines: 30 > It truncates it. IOWS, it throws away the prealloc you did externally > to this program. You need to do the preallocation after the truncation > but before you start writing. > > Cheers, > > Dave. Thanks Dave, now it seems to work!! just out of curiosity, when i run xfs_bmap on each file, it shows 00001.ivf: 0: [0..106495]: 96..106591 which is cool, but when i do xfs_db -r /dev/hdb4 and check the fragementation status, it shows [root@localhost tmp]# xfs_db -r /dev/hdb4 xfs_db> frag actual 1763, ideal 902, fragmentation factor 48.84% where are all the fragments coming from? do I need to worry about it? thanks, -Ying From owner-linux-xfs@oss.sgi.com Thu Sep 29 03:48:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Sep 2005 03:48:46 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8TAmgO0003052 for ; Thu, 29 Sep 2005 03:48:42 -0700 Received: from gateway-att.yingternet.com (c-24-126-232-43.hsd1.ca.comcast.net [24.126.232.43]) by ying.yingternet.com (Postfix) with ESMTP id 44B4B30009E for ; Thu, 29 Sep 2005 03:46:50 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gateway-att.yingternet.com (Postfix) with ESMTP id 45819204C18; Thu, 29 Sep 2005 03:45:50 -0700 (PDT) Message-ID: <433BC5DC.8000109@yingternet.com> Date: Thu, 29 Sep 2005 18:45:48 +0800 From: Ying-Hung Chen User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: Ying-Hung Chen Subject: get allocated filesize after preallocate X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 206 Lines: 10 Hello all, one more question, after I preallocate with XFS_IOC_RESVSP, the filesize is 0. How do I get the 'allocated' filesize? fseek/lseek/stat all returns 0 instead of allocated size, Thanks, -Ying From owner-linux-xfs@oss.sgi.com Thu Sep 29 06:50:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Sep 2005 06:50:36 -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 j8TDoWO0023265 for ; Thu, 29 Sep 2005 06:50:32 -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 j8TDlfxT015242 for ; Thu, 29 Sep 2005 08:47:41 -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 j8TDlcsS92393595; Thu, 29 Sep 2005 06:47:39 -0700 (PDT) Message-ID: <433BF07E.3030200@sgi.com> Date: Thu, 29 Sep 2005 08:47:42 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ying-Hung Chen CC: David Chinner , linux-xfs@oss.sgi.com Subject: Re: preallocation References: <4337ADB7.3060700@yingternet.com> <43381317.8040007@sgi.com> <433B8B8F.9010300@yingternet.com> <20050929065949.GC8727140@melbourne.sgi.com> <433BB263.4060108@yingternet.com> In-Reply-To: <433BB263.4060108@yingternet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6270 X-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: 686 Lines: 28 Ying-Hung Chen wrote: > Thanks Dave, now it seems to work!! just out of curiosity, when i run > xfs_bmap on each file, it shows > > 00001.ivf: > 0: [0..106495]: 96..106591 > > which is cool, > > but when i do xfs_db -r /dev/hdb4 > and check the fragementation status, it shows > > [root@localhost tmp]# xfs_db -r /dev/hdb4 > xfs_db> frag > actual 1763, ideal 902, fragmentation factor 48.84% this means on average, you have 2 roughly extents per file. Not so bad. > where are all the fragments coming from? do I need to worry about it? other files, presumeably. > do I need to worry about it? probably not... 2 extents per file is not very fragmented at all. -Eric From owner-linux-xfs@oss.sgi.com Thu Sep 29 14:34:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Sep 2005 14:34:18 -0700 (PDT) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8TLYBO0004726 for ; Thu, 29 Sep 2005 14:34:12 -0700 Received: by qproxy.gmail.com with SMTP id q10so114133qbq for ; Thu, 29 Sep 2005 14:31:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=KhOugrrMKQYCT9DpmWwY7dR5B70Z1Em7vU4wNpkDWpEHpQe4a/TZ4o/alGAvHRm6G2clKUfMNHAHH5ymLHPi0AWvgclcaoF5MsNCvil7U1baAHqWrziDMXV+5eIhBaHKMl7WwXtvj1Wk/vjEcx4qbvgOY2HJT3/RfYEpqC3fWt8= Received: by 10.65.11.14 with SMTP id o14mr545044qbi; Thu, 29 Sep 2005 14:31:20 -0700 (PDT) Received: from ?128.227.248.250? ( [128.227.248.250]) by mx.gmail.com with ESMTP id m3sm823799qbe.2005.09.29.14.31.19; Thu, 29 Sep 2005 14:31:20 -0700 (PDT) Message-ID: <433C5DEE.6020306@gmail.com> Date: Thu, 29 Sep 2005 17:34:38 -0400 From: Chandan Talukdar User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Contribution to XFS on Linux Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: chandan.talukdar@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 211 Lines: 10 Hello, I want to contribute towards the above mentioned proposed enhancement to XFS. Could anyone tell me how to go about the process. Thanks, --Chandan ps: I have prior file system development experience. From owner-linux-xfs@oss.sgi.com Thu Sep 29 14:54:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Sep 2005 14:54: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 j8TLs9O0006459 for ; Thu, 29 Sep 2005 14:54: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 HAA25613; Fri, 30 Sep 2005 07:51:11 +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 j8TLpLkt5311473; Fri, 30 Sep 2005 07:51:21 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j8TLpJfE5302441; Fri, 30 Sep 2005 07:51:19 +1000 (EST) Date: Fri, 30 Sep 2005 07:51:18 +1000 From: Nathan Scott To: Ying-Hung Chen Cc: linux-xfs@oss.sgi.com Subject: Re: get allocated filesize after preallocate Message-ID: <20050930075118.A5266163@wobbly.melbourne.sgi.com> References: <433BC5DC.8000109@yingternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <433BC5DC.8000109@yingternet.com>; from ying@yingternet.com on Thu, Sep 29, 2005 at 06:45:48PM +0800 X-archive-position: 6272 X-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: 389 Lines: 15 On Thu, Sep 29, 2005 at 06:45:48PM +0800, Ying-Hung Chen wrote: > Hello all, > > one more question, after I preallocate with XFS_IOC_RESVSP, the > filesize is 0. How do I get the 'allocated' filesize? fseek/lseek/stat > all returns 0 instead of allocated size, The XFS_IOC_GETBMAPX ioctl is the only way to figure this out (this is what xfs_bmap uses), I believe. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Sep 29 16:12:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Sep 2005 16:13:02 -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 j8TNCsO0011829 for ; Thu, 29 Sep 2005 16:12: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 JAA27282; Fri, 30 Sep 2005 09:10:00 +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 j8TNABkt5312216; Fri, 30 Sep 2005 09:10:11 +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 j8TN10nm001039; Fri, 30 Sep 2005 09:01:00 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j8TN0wIV001037; Fri, 30 Sep 2005 09:00:58 +1000 Date: Fri, 30 Sep 2005 09:00:58 +1000 From: Nathan Scott To: Chandan Talukdar Cc: linux-xfs@oss.sgi.com Subject: Re: Contribution to XFS on Linux Message-ID: <20050929230058.GD823@frodo> References: <433C5DEE.6020306@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433C5DEE.6020306@gmail.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j8TNCuO0011831 X-archive-position: 6273 X-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: 1548 Lines: 46 Hi Chandan, On Thu, Sep 29, 2005 at 05:34:38PM -0400, Chandan Talukdar wrote: > Hello, > > I want to contribute towards the above mentioned proposed enhancement to > XFS. Could anyone tell me how to go about the process. > > Thanks, > > ps: I have prior file system development experience. > From a very high level, there are two possible angles of attack for this problem. The first way would be to allow the PAGE_CACHE_SIZE to be increased, which then reduces the problem to ensuring the increased page size covers all interesting blocksizes (the core XFS code, & XFS on IRIX, allows blocksizes in powers of 2 between 512 bytes to 64 kilobytes currently). The second would be to deal with multiple page cache pages spanning a single block, and to audit all uses of (struct inode)->i_blkbits through the VFS and XFS, and also change the VM to ensure we can't get into deadlocks in the filesystem (we'd need to hold multiple contiguous-within-an-address_space pages locked simultaneously in this model, I think). There was some discussion a long time back on the linux-fsdevel list about this, so check those archives. The NTFS folks have had to do something to try address this problem, I'm not sure where they ended up with that though. Last time I discussed this with Christoph (a long time back now), I think he favoured the first approach above. I suspect the NTFS guys went for something more like the second approach to resolve their issues, but I don't know for sure what they did in the end. Good luck! cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Sep 30 02:02:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Sep 2005 02:02:18 -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 j8U92FO0032490 for ; Fri, 30 Sep 2005 02:02:15 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j8UA2uqg021080 for ; Fri, 30 Sep 2005 03:02:56 -0700 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j8U92DAQ58988896 for ; Fri, 30 Sep 2005 02:02:13 -0700 (PDT) X-ASG-Debug-ID: 1128070762-11966-75-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1D108D2E1588 for ; Fri, 30 Sep 2005 01:59:23 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j8U8xKDD028283; Fri, 30 Sep 2005 03:59:21 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j8U8xIGY028279; Fri, 30 Sep 2005 03:59:18 -0500 Date: Fri, 30 Sep 2005 03:59:18 -0500 From: Christoph Hellwig Message-Id: <200509300859.j8U8xIGY028279@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com X-ASG-Orig-Subj: TAKE 943511 - silence gcc4 warnings Subject: TAKE 943511 - silence gcc4 warnings X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.4206 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1140 Lines: 24 the directory ones are wrong because of information gcc could not find out (that a directory always has a .. entry), the others are outright gcc bugs. Date: Fri Sep 30 01:58:51 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: felixb, mandy, sandeen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:200055a fs/xfs/xfs_ialloc_btree.c - 1.81 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.c.diff?r1=text&tr1=1.81&r2=text&tr2=1.80&f=h fs/xfs/xfs_dir2_sf.c - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h fs/xfs/xfs_dir_leaf.c - 1.128 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.c.diff?r1=text&tr1=1.128&r2=text&tr2=1.127&f=h fs/xfs/xfs_acl.c - 1.57 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h fs/xfs/xfs_alloc_btree.c - 1.85 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.c.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h From owner-linux-xfs@oss.sgi.com Fri Sep 30 03:26:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Sep 2005 03:26:54 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8UAQgO0007382 for ; Fri, 30 Sep 2005 03:26:44 -0700 Received: from minion.mpc.local ([172.16.11.112] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.43) id 1ELI3S-0000oM-BJ; Fri, 30 Sep 2005 11:23:50 +0100 Message-ID: <433D1236.4070602@moving-picture.com> Date: Fri, 30 Sep 2005 11:23:50 +0100 From: James Pearson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: netllama@linux-sxs.org Subject: Re: grub disaster with FC4 & XFS Content-Type: multipart/mixed; boundary="------------020205090208080207040008" X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 6277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs Content-Length: 7055 Lines: 193 This is a multi-part message in MIME format. --------------020205090208080207040008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > On 07/04/2005 01:22 PM, Ethan Benson wrote: >> On Mon, Jul 04, 2005 at 01:54:40PM +0100, James Pearson wrote: >>> >Not sure if anyone is aware of this mess of a bug: >>> >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160444 >>> > >>> >Basically grub pukes all over itself when trying to interact with XFS >>> >filesystems, resulting in an unbootable, or barely bootable FC4 >>> >installation. >>> > >>> >Any gurus here know of a solution? >>> > >>> >Yes, i know, this is really a FC/grub issue, but since its specific to >>> >XFS, i thought someone might have run into it and found a workaround >>> >and/or fix. >>> >>> Not sure if this is connected, but the FC installer (anaconda) uses the >>> code in 'booty' to install the bootloader - this has a work around for >>> grub on XFS which uses xfs_freeze - see the thread that starts with: >>> >>> http://marc.theaimsgroup.com/?l=linux-xfs&m=108009684613605&w=2 >> >> which is a kludge, and an unecessary one at that. >> >> if you install grub as followes it does not modify XFS filesystems via >> raw devices, but instead through the standard unix interfaces: >> >> embed /boot/grub/xfs_stage1_5 (hd0) >> >> xx sectors embedded. >> >> install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0) (hd0)1+xx p (hd0,1)/boot/grub/stage2 /etc/grub.conf >> >> note the xx in the first message is the value you need to use in the >> (hd0)1+xx part above. the last argument is the path to the config >> file you can have that where you like. >> >> what should be done is rewrite the setup command in grub to perform >> the above, instead of the broken method it currently uses. >> > > Actually, the command you noted above is what the FC4 installer was > trying to do when grub went south. > > I did finally manage to fix this mess by booting with knoppix, purging > everything in /boot/grub, repopulating with the templates that ship with > grub, and running 'setup (hd0)' again. I have no clue why all of that > was neccesary. To follow up on this - I think I might have a work round for this XFS/grub/RedHat installer problem - Based on a comment in another thread: http://marc.theaimsgroup.com/?l=linux-xfs&m=112096901910385&w=2 remounting the file system that contains /boot read-only and then read-write before running the grub install command appears to work fine. I've attached a patch below to RedHat's 'booty' package if anyone is interested James Pearson --------------020205090208080207040008 Content-Type: text/x-patch; name="booty-xfs_remount.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="booty-xfs_remount.patch" Patch to make grub install on an XFS filesystem when using the RedHat anaconda installer Patch works by remounting the XFS file system containing /boot read-only and then read-write based on an idea from: http://marc.theaimsgroup.com/?l=linux-xfs&m=112096901910385&w=2 The patch should work with most recent versions of booty i.e. Fedora Core 2, 3 and 4, RHEL4, CentOS4 etc. This patch can either be used to patch the booty SRPM, rebuild the RPM and then rebuild the installer, or just used to create an 'update' for the installer - to do this: Install the booty RPM cd /usr/lib/booty patch -p1 < this_file This will patch 'bootloaderInfo.py' If you install over NFS, then create a directory at the top level of the install tree called 'RHupdates' and copy in bootloaderInfo.py to this directory. The anaconda installer will look here by default when doing NFS installs. If installing via other methods, then you need to create an updates floppy, CD or USB drive - for a floppy disk, do something like: mkfs -t ext2 /dev/fd0 mount /media/floppy (or /mnt/floppy or whatever) cp /usr/lib/booty/bootloaderInfo.py /media/floppy umount /media/floppy Then, at the installer 'boot:' prompt, type: boot: linux updates This will prompt you to insert the update floppy and the installer will use the new bootloaderInfo.py The CD and USB disk update disks (probably) work in a similar way (not tested) James Pearson *** ./bootloaderInfo.py.dist 2005-05-11 16:41:51.000000000 +0100 --- ./bootloaderInfo.py 2005-09-29 12:16:11.117385013 +0100 *************** *** 49,71 **** # there's no guarantee that data is written to the disk and grub # reads both the filesystem and the disk. suck. def syncDataToDisk(dev, mntpt, instRoot = "/"): ! import isys, fsset isys.sync() isys.sync() isys.sync() ! # and xfs is even more "special" (#117968) if fsset.isValidXFS(dev): ! rhpl.executil.execWithRedirect( "/usr/sbin/xfs_freeze", ! ["/usr/sbin/xfs_freeze", "-f", mntpt], ! stdout = "/dev/tty5", ! stderr = "/dev/tty5", ! root = instRoot) ! rhpl.executil.execWithRedirect( "/usr/sbin/xfs_freeze", ! ["/usr/sbin/xfs_freeze", "-u", mntpt], ! stdout = "/dev/tty5", ! stderr = "/dev/tty5", ! root = instRoot) class BootyNoKernelWarning: def __init__ (self, value=""): --- 49,84 ---- # there's no guarantee that data is written to the disk and grub # reads both the filesystem and the disk. suck. def syncDataToDisk(dev, mntpt, instRoot = "/"): ! import isys, fsset, _isys isys.sync() isys.sync() isys.sync() ! # for XFS make sure the data is _really_ sync'd to disk by remounting ! # /boot first read-only and then read-write - idea from: ! # http://marc.theaimsgroup.com/?l=linux-xfs&m=112096901910385&w=2 ! # James Pearson MPC 29-sep-2005 if fsset.isValidXFS(dev): ! fstype = "xfs" ! device = "/tmp/%s" % dev ! location = "%s%s" % (instRoot, mntpt) ! readOnly = 1 ! bindMount = 0 ! remount = 1 ! log("remounting %s on %s read-only" % (device, location)) ! # remount the boot partition as read-only ! rc = _isys.mount(fstype, device, location, readOnly, bindMount, remount) ! ! # if the remount fails, then we should really do something else e.g. ! # sleep for a few minutes? - for the time being we'll just log the ! # return ! log("remount return: %s (None == OK)" % rc) ! ! # now remount as read-write ! readOnly = 0 ! log("remounting %s on %s read-write" % (device, location)) ! rc = _isys.mount(fstype, device, location, readOnly, bindMount, remount) ! log("remount return: %s (None == OK)" % rc) class BootyNoKernelWarning: def __init__ (self, value=""): --------------020205090208080207040008-- From owner-linux-xfs@oss.sgi.com Fri Sep 30 05:23:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Sep 2005 05:23:33 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8UCNSO0019491 for ; Fri, 30 Sep 2005 05:23:29 -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 mx2.suse.de (Postfix) with ESMTP id 28B111CC39; Fri, 30 Sep 2005 14:20:36 +0200 (CEST) To: Nathan Scott Cc: linux-xfs@oss.sgi.com, chandan.talukdar@gmail.com Subject: Re: Contribution to XFS on Linux References: <433C5DEE.6020306@gmail.com> <20050929230058.GD823@frodo> From: Andi Kleen Date: 30 Sep 2005 14:20:34 +0200 In-Reply-To: <20050929230058.GD823@frodo> 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: 6278 X-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: 1389 Lines: 33 Nathan Scott writes: The main problem here is that this is more a Linux VM limitation than a XFS limitation. > The first way would be to allow the PAGE_CACHE_SIZE to be increased, > which then reduces the problem to ensuring the increased page size > covers all interesting blocksizes (the core XFS code, & XFS on IRIX, > allows blocksizes in powers of 2 between 512 bytes to 64 kilobytes > currently). I don't think it would be a good idea. Allocating so many pages with order > 0 would very likely bring the VM into a nervous breakdown. At least you would need to fix the fragmentation in there first (there have been some approaches for this, but nothing in mainline) Increasing PAGE_SIZE too would avoid that, but that would require fixing the low level code in each architectures that maps pages from page cache into user processes. That would be probably a good thing (there has been long talk to have larger softpagesizes on i386/x86-64 because it's not really efficient to manage multiple GB of memory in 4K pieces), but is definitely major work. There have been patches for that in the past, but they never were remotely usable and quite complex. > > Last time I discussed this with Christoph (a long time back now), > I think he favoured the first approach above. I suspect the NTFS I don't see how you can make it work without major effort. -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 30 08:04:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Sep 2005 08:04:39 -0700 (PDT) Received: from priv-edmwes48.telusplanet.net (defout.telus.net [204.209.205.55]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8UF4XO0032443 for ; Fri, 30 Sep 2005 08:04:33 -0700 Received: from [127.0.0.1] (really [198.53.208.240]) by priv-edmwes48.telusplanet.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050930150138.YAC14855.priv-edmwes48.telusplanet.net@[127.0.0.1]> for ; Fri, 30 Sep 2005 09:01:38 -0600 Message-ID: <433D533D.7060404@telus.net> Date: Fri, 30 Sep 2005 09:01:17 -0600 From: Aly Dharshi User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: grub disaster with FC4 & XFS References: <433D1236.4070602@moving-picture.com> In-Reply-To: <433D1236.4070602@moving-picture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aly.dharshi@telus.net Precedence: bulk X-list: linux-xfs Content-Length: 7405 Lines: 200 Woudl you be able to send this as a patch to the RedHat Anaconda folks, this would greatly assist in future FC installs. Unless they know about it already. James Pearson wrote: >> On 07/04/2005 01:22 PM, Ethan Benson wrote: >> >>> On Mon, Jul 04, 2005 at 01:54:40PM +0100, James Pearson wrote: >>> >>>> >Not sure if anyone is aware of this mess of a bug: >>>> >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160444 >>>> > >>>> >Basically grub pukes all over itself when trying to interact with >>>> XFS >filesystems, resulting in an unbootable, or barely bootable FC4 >>>> >installation. >>>> > >>>> >Any gurus here know of a solution? >>>> > >>>> >Yes, i know, this is really a FC/grub issue, but since its specific >>>> to >XFS, i thought someone might have run into it and found a >>>> workaround >and/or fix. >>>> >>>> Not sure if this is connected, but the FC installer (anaconda) uses >>>> the code in 'booty' to install the bootloader - this has a work >>>> around for grub on XFS which uses xfs_freeze - see the thread that >>>> starts with: >>>> >>>> http://marc.theaimsgroup.com/?l=linux-xfs&m=108009684613605&w=2 >>> >>> >>> which is a kludge, and an unecessary one at that. >>> >>> if you install grub as followes it does not modify XFS filesystems via >>> raw devices, but instead through the standard unix interfaces: >>> >>> embed /boot/grub/xfs_stage1_5 (hd0) >>> >>> xx sectors embedded. >>> >>> install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0) (hd0)1+xx >>> p (hd0,1)/boot/grub/stage2 /etc/grub.conf >>> >>> note the xx in the first message is the value you need to use in the >>> (hd0)1+xx part above. the last argument is the path to the config >>> file you can have that where you like. >>> >>> what should be done is rewrite the setup command in grub to perform >>> the above, instead of the broken method it currently uses. >>> >> >> Actually, the command you noted above is what the FC4 installer was >> trying to do when grub went south. >> >> I did finally manage to fix this mess by booting with knoppix, purging >> everything in /boot/grub, repopulating with the templates that ship >> with grub, and running 'setup (hd0)' again. I have no clue why all of >> that was neccesary. > > > To follow up on this - I think I might have a work round for this > XFS/grub/RedHat installer problem - > > Based on a comment in another thread: > > http://marc.theaimsgroup.com/?l=linux-xfs&m=112096901910385&w=2 > > remounting the file system that contains /boot read-only and then > read-write before running the grub install command appears to work fine. > > I've attached a patch below to RedHat's 'booty' package if anyone is > interested > > James Pearson > > > > > > ------------------------------------------------------------------------ > > Patch to make grub install on an XFS filesystem when using the RedHat > anaconda installer > > Patch works by remounting the XFS file system containing /boot read-only > and then read-write based on an idea from: > > http://marc.theaimsgroup.com/?l=linux-xfs&m=112096901910385&w=2 > > The patch should work with most recent versions of booty i.e. Fedora Core > 2, 3 and 4, RHEL4, CentOS4 etc. > > This patch can either be used to patch the booty SRPM, rebuild the RPM and > then rebuild the installer, or just used to create an 'update' for the > installer - to do this: > > Install the booty RPM > > cd /usr/lib/booty > patch -p1 < this_file > > This will patch 'bootloaderInfo.py' > > If you install over NFS, then create a directory at the top level of > the install tree called 'RHupdates' and copy in bootloaderInfo.py to > this directory. The anaconda installer will look here by default when > doing NFS installs. > > If installing via other methods, then you need to create an updates floppy, > CD or USB drive - for a floppy disk, do something like: > > mkfs -t ext2 /dev/fd0 > mount /media/floppy (or /mnt/floppy or whatever) > cp /usr/lib/booty/bootloaderInfo.py /media/floppy > umount /media/floppy > > Then, at the installer 'boot:' prompt, type: > > boot: linux updates > > This will prompt you to insert the update floppy and the installer will use > the new bootloaderInfo.py > > The CD and USB disk update disks (probably) work in a similar way (not tested) > > James Pearson > > > *** ./bootloaderInfo.py.dist 2005-05-11 16:41:51.000000000 +0100 > --- ./bootloaderInfo.py 2005-09-29 12:16:11.117385013 +0100 > *************** > *** 49,71 **** > # there's no guarantee that data is written to the disk and grub > # reads both the filesystem and the disk. suck. > def syncDataToDisk(dev, mntpt, instRoot = "/"): > ! import isys, fsset > isys.sync() > isys.sync() > isys.sync() > > ! # and xfs is even more "special" (#117968) > if fsset.isValidXFS(dev): > ! rhpl.executil.execWithRedirect( "/usr/sbin/xfs_freeze", > ! ["/usr/sbin/xfs_freeze", "-f", mntpt], > ! stdout = "/dev/tty5", > ! stderr = "/dev/tty5", > ! root = instRoot) > ! rhpl.executil.execWithRedirect( "/usr/sbin/xfs_freeze", > ! ["/usr/sbin/xfs_freeze", "-u", mntpt], > ! stdout = "/dev/tty5", > ! stderr = "/dev/tty5", > ! root = instRoot) > > class BootyNoKernelWarning: > def __init__ (self, value=""): > --- 49,84 ---- > # there's no guarantee that data is written to the disk and grub > # reads both the filesystem and the disk. suck. > def syncDataToDisk(dev, mntpt, instRoot = "/"): > ! import isys, fsset, _isys > isys.sync() > isys.sync() > isys.sync() > > ! # for XFS make sure the data is _really_ sync'd to disk by remounting > ! # /boot first read-only and then read-write - idea from: > ! # http://marc.theaimsgroup.com/?l=linux-xfs&m=112096901910385&w=2 > ! # James Pearson MPC 29-sep-2005 > if fsset.isValidXFS(dev): > ! fstype = "xfs" > ! device = "/tmp/%s" % dev > ! location = "%s%s" % (instRoot, mntpt) > ! readOnly = 1 > ! bindMount = 0 > ! remount = 1 > ! log("remounting %s on %s read-only" % (device, location)) > ! # remount the boot partition as read-only > ! rc = _isys.mount(fstype, device, location, readOnly, bindMount, remount) > ! > ! # if the remount fails, then we should really do something else e.g. > ! # sleep for a few minutes? - for the time being we'll just log the > ! # return > ! log("remount return: %s (None == OK)" % rc) > ! > ! # now remount as read-write > ! readOnly = 0 > ! log("remounting %s on %s read-write" % (device, location)) > ! rc = _isys.mount(fstype, device, location, readOnly, bindMount, remount) > ! log("remount return: %s (None == OK)" % rc) > > class BootyNoKernelWarning: > def __init__ (self, value=""): -- Aly Dharshi aly.dharshi@telus.net "A good speech is like a good dress that's short enough to be interesting and long enough to cover the subject" From owner-linux-xfs@oss.sgi.com Fri Sep 30 08:31:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Sep 2005 08:31:54 -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 j8UFVkO0005933 for ; Fri, 30 Sep 2005 08:31:47 -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 j8UFSd0Q006846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Sep 2005 10:28:40 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.4/8.13.4/Submit) with ESMTP id j8UFScIp006843; Fri, 30 Sep 2005 10:28:39 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Fri, 30 Sep 2005 10:28:38 -0500 (EST) From: Net Llama! To: Aly Dharshi cc: linux-xfs@oss.sgi.com Subject: Re: grub disaster with FC4 & XFS In-Reply-To: <433D533D.7060404@telus.net> Message-ID: References: <433D1236.4070602@moving-picture.com> <433D533D.7060404@telus.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Fri, 30 Sep 2005 10:28:40 -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: 6281 X-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: 8023 Lines: 206 RH's anaconda folks have already stated that XFS is 100% unsupported, and they have refused to do anything to fix any problems with it, including ignoring my question as to why they're shipping XFS support in FC if they have no intention of fixing its bugs. On Fri, 30 Sep 2005, Aly Dharshi wrote: > Woudl you be able to send this as a patch to the RedHat Anaconda folks, > this would greatly assist in future FC installs. Unless they know about > it already. > > James Pearson wrote: > >> On 07/04/2005 01:22 PM, Ethan Benson wrote: > >> > >>> On Mon, Jul 04, 2005 at 01:54:40PM +0100, James Pearson wrote: > >>> > >>>> >Not sure if anyone is aware of this mess of a bug: > >>>> >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160444 > >>>> > > >>>> >Basically grub pukes all over itself when trying to interact with > >>>> XFS >filesystems, resulting in an unbootable, or barely bootable FC4 > >>>> >installation. > >>>> > > >>>> >Any gurus here know of a solution? > >>>> > > >>>> >Yes, i know, this is really a FC/grub issue, but since its specific > >>>> to >XFS, i thought someone might have run into it and found a > >>>> workaround >and/or fix. > >>>> > >>>> Not sure if this is connected, but the FC installer (anaconda) uses > >>>> the code in 'booty' to install the bootloader - this has a work > >>>> around for grub on XFS which uses xfs_freeze - see the thread that > >>>> starts with: > >>>> > >>>> http://marc.theaimsgroup.com/?l=linux-xfs&m=108009684613605&w=2 > >>> > >>> > >>> which is a kludge, and an unecessary one at that. > >>> > >>> if you install grub as followes it does not modify XFS filesystems via > >>> raw devices, but instead through the standard unix interfaces: > >>> > >>> embed /boot/grub/xfs_stage1_5 (hd0) > >>> > >>> xx sectors embedded. > >>> > >>> install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0) (hd0)1+xx > >>> p (hd0,1)/boot/grub/stage2 /etc/grub.conf > >>> > >>> note the xx in the first message is the value you need to use in the > >>> (hd0)1+xx part above. the last argument is the path to the config > >>> file you can have that where you like. > >>> > >>> what should be done is rewrite the setup command in grub to perform > >>> the above, instead of the broken method it currently uses. > >>> > >> > >> Actually, the command you noted above is what the FC4 installer was > >> trying to do when grub went south. > >> > >> I did finally manage to fix this mess by booting with knoppix, purging > >> everything in /boot/grub, repopulating with the templates that ship > >> with grub, and running 'setup (hd0)' again. I have no clue why all of > >> that was neccesary. > > > > > > To follow up on this - I think I might have a work round for this > > XFS/grub/RedHat installer problem - > > > > Based on a comment in another thread: > > > > http://marc.theaimsgroup.com/?l=linux-xfs&m=112096901910385&w=2 > > > > remounting the file system that contains /boot read-only and then > > read-write before running the grub install command appears to work fine. > > > > I've attached a patch below to RedHat's 'booty' package if anyone is > > interested > > > > James Pearson > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Patch to make grub install on an XFS filesystem when using the RedHat > > anaconda installer > > > > Patch works by remounting the XFS file system containing /boot read-only > > and then read-write based on an idea from: > > > > http://marc.theaimsgroup.com/?l=linux-xfs&m=112096901910385&w=2 > > > > The patch should work with most recent versions of booty i.e. Fedora Core > > 2, 3 and 4, RHEL4, CentOS4 etc. > > > > This patch can either be used to patch the booty SRPM, rebuild the RPM and > > then rebuild the installer, or just used to create an 'update' for the > > installer - to do this: > > > > Install the booty RPM > > > > cd /usr/lib/booty > > patch -p1 < this_file > > > > This will patch 'bootloaderInfo.py' > > > > If you install over NFS, then create a directory at the top level of > > the install tree called 'RHupdates' and copy in bootloaderInfo.py to > > this directory. The anaconda installer will look here by default when > > doing NFS installs. > > > > If installing via other methods, then you need to create an updates floppy, > > CD or USB drive - for a floppy disk, do something like: > > > > mkfs -t ext2 /dev/fd0 > > mount /media/floppy (or /mnt/floppy or whatever) > > cp /usr/lib/booty/bootloaderInfo.py /media/floppy > > umount /media/floppy > > > > Then, at the installer 'boot:' prompt, type: > > > > boot: linux updates > > > > This will prompt you to insert the update floppy and the installer will use > > the new bootloaderInfo.py > > > > The CD and USB disk update disks (probably) work in a similar way (not tested) > > > > James Pearson > > > > > > *** ./bootloaderInfo.py.dist 2005-05-11 16:41:51.000000000 +0100 > > --- ./bootloaderInfo.py 2005-09-29 12:16:11.117385013 +0100 > > *************** > > *** 49,71 **** > > # there's no guarantee that data is written to the disk and grub > > # reads both the filesystem and the disk. suck. > > def syncDataToDisk(dev, mntpt, instRoot = "/"): > > ! import isys, fsset > > isys.sync() > > isys.sync() > > isys.sync() > > > > ! # and xfs is even more "special" (#117968) > > if fsset.isValidXFS(dev): > > ! rhpl.executil.execWithRedirect( "/usr/sbin/xfs_freeze", > > ! ["/usr/sbin/xfs_freeze", "-f", mntpt], > > ! stdout = "/dev/tty5", > > ! stderr = "/dev/tty5", > > ! root = instRoot) > > ! rhpl.executil.execWithRedirect( "/usr/sbin/xfs_freeze", > > ! ["/usr/sbin/xfs_freeze", "-u", mntpt], > > ! stdout = "/dev/tty5", > > ! stderr = "/dev/tty5", > > ! root = instRoot) > > > > class BootyNoKernelWarning: > > def __init__ (self, value=""): > > --- 49,84 ---- > > # there's no guarantee that data is written to the disk and grub > > # reads both the filesystem and the disk. suck. > > def syncDataToDisk(dev, mntpt, instRoot = "/"): > > ! import isys, fsset, _isys > > isys.sync() > > isys.sync() > > isys.sync() > > > > ! # for XFS make sure the data is _really_ sync'd to disk by remounting > > ! # /boot first read-only and then read-write - idea from: > > ! # http://marc.theaimsgroup.com/?l=linux-xfs&m=112096901910385&w=2 > > ! # James Pearson MPC 29-sep-2005 > > if fsset.isValidXFS(dev): > > ! fstype = "xfs" > > ! device = "/tmp/%s" % dev > > ! location = "%s%s" % (instRoot, mntpt) > > ! readOnly = 1 > > ! bindMount = 0 > > ! remount = 1 > > ! log("remounting %s on %s read-only" % (device, location)) > > ! # remount the boot partition as read-only > > ! rc = _isys.mount(fstype, device, location, readOnly, bindMount, remount) > > ! > > ! # if the remount fails, then we should really do something else e.g. > > ! # sleep for a few minutes? - for the time being we'll just log the > > ! # return > > ! log("remount return: %s (None == OK)" % rc) > > ! > > ! # now remount as read-write > > ! readOnly = 0 > > ! log("remounting %s on %s read-write" % (device, location)) > > ! rc = _isys.mount(fstype, device, location, readOnly, bindMount, remount) > > ! log("remount return: %s (None == OK)" % rc) > > > > class BootyNoKernelWarning: > > def __init__ (self, value=""): > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Fri Sep 30 09:35:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Sep 2005 09:35:46 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8UGZgO0010677 for ; Fri, 30 Sep 2005 09:35:43 -0700 Received: from minion.mpc.local ([172.16.11.112] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.43) id 1ELNoY-0000km-IP for linux-xfs@oss.sgi.com; Fri, 30 Sep 2005 17:32:50 +0100 Message-ID: <433D68B2.4040309@moving-picture.com> Date: Fri, 30 Sep 2005 17:32:50 +0100 From: James Pearson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: grub disaster with FC4 & XFS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 6282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs Content-Length: 815 Lines: 19 > RH's anaconda folks have already stated that XFS is 100% unsupported, and > they have refused to do anything to fix any problems with it, including > ignoring my question as to why they're shipping XFS support in FC if they > have no intention of fixing its bugs. It might be worth trying - they did add the xfs_freeze patch (which doesn't work most of the time), even though RedHat say anything to do with XFS will be automatically marked 'WONTFIX' - see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117968#c9 You never know, they might be willing to accept a patch that fixes the problem - as it may keep people that have this problem off their back ... If I can get some confirmation from others that this work around does 'fix' the problem, then I'll see what can be done ... James Pearson From owner-linux-xfs@oss.sgi.com Fri Sep 30 10:15:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Sep 2005 10:15:47 -0700 (PDT) Received: from priv-edtnes40.telusplanet.net (outbound05.telus.net [199.185.220.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j8UHFfO0013278 for ; Fri, 30 Sep 2005 10:15:41 -0700 Received: from [127.0.0.1] (really [198.53.208.240]) by priv-edtnes40.telusplanet.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050930171249.JSFD13208.priv-edtnes40.telusplanet.net@[127.0.0.1]>; Fri, 30 Sep 2005 11:12:49 -0600 Message-ID: <433D7200.9070702@telus.net> Date: Fri, 30 Sep 2005 11:12:32 -0600 From: Aly Dharshi User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Pearson CC: linux-xfs@oss.sgi.com Subject: Re: grub disaster with FC4 & XFS References: <433D68B2.4040309@moving-picture.com> In-Reply-To: <433D68B2.4040309@moving-picture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aly.dharshi@telus.net Precedence: bulk X-list: linux-xfs Content-Length: 1440 Lines: 43 That would be excellent, I have asked the FC mailing list for ideas on how to get this in the main stream anaconda without having to type linux xfs all the time at the install boot prompt to get XFS support. I don't understand why they are so resistant to adding XFS and ReiserFS support to FC and Anaconda. I would be very interested in knowing the reason. Cheers, Aly. James Pearson wrote: >> RH's anaconda folks have already stated that XFS is 100% unsupported, and >> they have refused to do anything to fix any problems with it, including >> ignoring my question as to why they're shipping XFS support in FC if they >> have no intention of fixing its bugs. > > > It might be worth trying - they did add the xfs_freeze patch (which > doesn't work most of the time), even though RedHat say anything to do > with XFS will be automatically marked 'WONTFIX' - see: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117968#c9 > > You never know, they might be willing to accept a patch that fixes the > problem - as it may keep people that have this problem off their back ... > > If I can get some confirmation from others that this work around does > 'fix' the problem, then I'll see what can be done ... > > James Pearson > > -- Aly Dharshi aly.dharshi@telus.net "A good speech is like a good dress that's short enough to be interesting and long enough to cover the subject"