From owner-linux-xfs Tue Feb 1 01:49:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 01:49:17 -0800 (PST) Received: from mail.artcom-gmbh.de (ns1.artcom-gmbh.de [62.145.22.162]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j119nBDw014373 for ; Tue, 1 Feb 2005 01:49:11 -0800 Received: from [196.0.0.41] (helo=artcom10.artcom-gmbh.de) by mail.artcom-gmbh.de with smtp (Exim 4.34) id 1Cvuee-0006DC-Ae for linux-xfs@oss.sgi.com; Tue, 01 Feb 2005 10:49:04 +0100 Received: from blau.artcom-gmbh.de by artcom10.artcom-gmbh.de with esmtp (Smail3.2 #1) id m1Cvued-018DesC; Tue, 1 Feb 2005 10:49:03 +0100 (CET) Received: by blau.artcom-gmbh.de (Postfix, from userid 530) id 3B6F014075962; Tue, 1 Feb 2005 10:49:04 +0100 (CET) Date: Tue, 1 Feb 2005 10:49:04 +0100 From: Martin =?iso-8859-1?Q?Schr=F6der?= To: linux-xfs@oss.sgi.com Subject: Re: xfs caching and data loss Message-ID: <20050201094904.GK5322@blau.artcom-gmbh.de> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: ArtCom GmbH, Lise-Meitner-Strasse 5, 28359 Bremen, Germany X-Disclaimer: The views expressed are my own and not necessarily that of my employers. X-Loop: Really sent by mail.artcom-gmbh.de X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j119nCDw014376 X-archive-position: 4834 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ms@artcom-gmbh.de Precedence: bulk X-list: linux-xfs On 2005-02-01 05:02:44 +1100, David J N Begley wrote: > In that sense, from what I can tell XFS risks data loss (data intended to be > sent to the disk but it never made it before the power disappeared) - though > so does any other file system (only the amount varies). IBTD: Take a look at ffs with soft updates and disabled hdd write cache. http://www.usenix.org/publications/library/proceedings/usenix2000/general/full_papers/seltzer/seltzer_html/index.html or http://tinyurl.com/20c2 Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de From owner-linux-xfs Tue Feb 1 04:53:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 04:53:06 -0800 (PST) Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11Cr4lo028106 for ; Tue, 1 Feb 2005 04:53:05 -0800 Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.47) id 1CvxWh-0007sY-NO for linux-xfs@oss.sgi.com; Tue, 01 Feb 2005 13:53:03 +0100 Received: from pd9ec26ee.dip.t-dialin.net ([217.236.38.238] helo=pcdiano) by mx3.freenet.de with esmtpa (ID baggadogio@freenet.de) (Exim 4.43 #13) id 1CvxWh-00014a-EX for linux-xfs@oss.sgi.com; Tue, 01 Feb 2005 13:53:03 +0100 From: "Daniel E." To: Subject: Suggestions for xfs Date: Tue, 1 Feb 2005 13:53:03 +0100 Message-ID: <000401c5085c$facba270$0a01a8c0@pcdiano> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Warning: freenet.de is listed at abuse.rfc-ignorant.org X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4835 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: baggadogio@freenet.de Precedence: bulk X-list: linux-xfs Here are some suggestions for xfsprogs. Some people want xfs to be the standard file system for GNU/Linux. These changes will bring compatibility with other tools and file systems. You could take a look to the other fs utilities to find common switches. I know that you are not responsible for all of these things. Mkfs.xfs: -L should be appended as xfs_admin has it. -(c/C?) for the bad block command. Mount.xfs: Acl, user_xattr: put these options in mount or in the xfs kernel module. Both should ignore them. (only for compatibility) I migrated from ext3 to xfs and I only changed the file system type in /etc/fstab. After reboot the root partition was not mounted rw, because of this not appended feature. I had to edit /etc/fstab and delete these options. You can log a notice message that acl, user_xattr are ignored and on by default. XFS has acls on by default I know. Resize: this should also be appended. JFS has this option and file system size will grow. This option can executed xfs_growfs. Fsck.xfs: This tells only success. -f: should execute xfs_check on a ro file system. (ext2/3 has a option for optimization I don't know the switch now) execute xfs_fsr on a ro file system. Add the usal options for fsck too. Fsck.xfs should also report the used blocks and the whole blocks and should report about fragmentation. If you want you can add a percentage when fsck.xfs will start xfs_fsr automatically. Xfs_check: Mv -v to -vv. -v should say checking journal, replaying journal, checking directories and files, checking ownerships and permissions and acls If it finds errors it should execute xfs_repair or xfs_ncheck to correct these errors. Xfs_fsr: You usally use it on a rw mounted fs. But if you add ro and non mounted you are able to optimize faster and no application can disturb. After optimization the system should be rebooted. I think error level 1 or 2 should be reported, that the boot scripts know that an error accrued and the system will be rebooted. This ensures that the application find its libraries and other stuff. Xfs_fsr is going to put them away from their place, and put them later back. Xfs_admin: Should get a link to xfstune or should be renamed. There are reiserfstune and tune2fs. I think that sounds logically. Xfs_grow: It should not only be able to grow the fs size. It should also be able to shrink. Reiserfs knows howto grow and to shrink. Best regards Daniel From owner-linux-xfs Tue Feb 1 06:45:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 06:45:17 -0800 (PST) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11EjCRM002762 for ; Tue, 1 Feb 2005 06:45:13 -0800 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.2/8.13.2/Debian-1) with ESMTP id j11DSDMx022736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2005 08:28:14 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.2/8.13.2/Submit) with ESMTP id j11DSCSw022733; Tue, 1 Feb 2005 08:28:13 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Tue, 1 Feb 2005 08:28:12 -0500 (EST) From: Net Llama! To: "Daniel E." cc: linux-xfs@oss.sgi.com Subject: Re: Suggestions for xfs In-Reply-To: <000401c5085c$facba270$0a01a8c0@pcdiano> Message-ID: References: <000401c5085c$facba270$0a01a8c0@pcdiano> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Tue, 01 Feb 2005 08:28:15 -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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4836 X-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 On Tue, 1 Feb 2005, Daniel E. wrote: > Here are some suggestions for xfsprogs. > > Some people want xfs to be the standard file system for GNU/Linux. These Who wants this? Linux has no standard filesystem, so I don' see how this could ever be possible. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Tue Feb 1 09:02:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 09:02:21 -0800 (PST) Received: from kevlar.burdell.org (dsl027-162-124.atl1.dsl.speakeasy.net [216.27.162.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11H2Cdo015943 for ; Tue, 1 Feb 2005 09:02:13 -0800 Received: by kevlar.burdell.org (Postfix, from userid 1189) id A670766CE1; Tue, 1 Feb 2005 11:49:48 -0500 (EST) Date: Tue, 1 Feb 2005 11:49:48 -0500 From: Sonny Rao To: Bryan Henderson Cc: Anton Altaparmakov , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-fsdevel-owner@vger.kernel.org, linux-xfs@oss.sgi.com, viro@parcelfarce.linux.theplanet.co.uk Subject: Re: Advice sought on how to lock multiple pages in ->prepare_write and ->writepage Message-ID: <20050201164948.GA3084@kevlar.burdell.org> References: <20050201001053.GB11044@kevlar.burdell.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4837 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sonny@burdell.org Precedence: bulk X-list: linux-xfs On Mon, Jan 31, 2005 at 05:32:31PM -0800, Bryan Henderson wrote: > Thanks for the numbers, though there are enough variables here that it's > hard to make any hard conclusions. I agree, I just throught the data was interesting. > When I've seen these comparisons in the past, it turned out to be one of > two things: > > 1) The system with the smaller I/Os (I/O = unit seen by the device) had > more CPU time per megabyte in the code path to start I/O, so that it > started less I/O. The small I/Os are a consequence of the lower > throughput, not a cause. You can often rule this out just by looking at > CPU utilization. Actually in this case, I was running a single threaded test on an 8-way machine. So, the flushing should have been able to happen on a different (mostly dedicated) CPU from the application that was writing. In this case, the differences in filesystems was probably the cause. What might be a better test is to take JFS, and "hobble" it so that it won't submit multi-page BIOs (i.e. kill it's writepages aop) > 2) The system with the smaller I/Os had a window tuning problem in which > it was waiting for previous I/O to complete before starting more, with > queues not full, and thus starting less I/O. Some devices, with good > intentions, suck the Linux queue dry, one tiny I/O at a time, and then > perform miserably processing those tiny I/Os. Properly tuned, the device > would buffer fewer I/Os and thus let the queues build inside Linux and > thus cause Linux to send larger I/Os. > > People have done ugly queue plugging algorithms to try to defeat this > queue sucking by withholding I/O from a device willing to take it. Others > defeat it by withholding I/O from a willing Linux block layer, instead > saving up I/O and submitting it in large bios. Sure, it seems to work well in practice. We've played a little bit with adjusting the plugging/unplugging thresholds, and in general, playing with them either made things worse or simply had no effect. Sonny -- IBM LTC Kernel Perf. From owner-linux-xfs Tue Feb 1 11:04:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 11:04:42 -0800 (PST) Received: from mail-gw.seakr.com (gw2.seakr.com [209.144.181.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11J4d58019670 for ; Tue, 1 Feb 2005 11:04:40 -0800 Received: from e250.seakr.com (seakr5.seakr.com [192.168.100.10]) by mail-gw.seakr.com (8.12.10/8.12.10) with ESMTP id j11Ijefs017015 for ; Tue, 1 Feb 2005 11:45:40 -0700 Received: from seakr5.seakr.com(192.168.100.10) by e250.seakr.com via csmap id f6ceaeea_7483_11d9_9c17_0002b3ecf11d_14714; Tue, 01 Feb 2005 19:03:31 +0000 (UTC) Received: from osiris.seakr.com (osiris [192.168.10.60]) by seakr5.seakr.com (8.10.2/8.10.2) with ESMTP id j11J4X724794 for ; Tue, 1 Feb 2005 12:04:33 -0700 (MST) Subject: influencing reported free inodes? From: Tim Flower To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: SEAKR Engineering Date: Tue, 01 Feb 2005 12:04:16 -0700 Message-Id: <1107284656.6468.67.camel@osiris.seakr.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4838 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tim@seakr.com Precedence: bulk X-list: linux-xfs Greetings, I have an odd question I'm trying to answer and was wondering if some kind soul help point me in the right direction. I have a SUSE 8 Server with an attached ~1.4 TB RAID device that I've formatted as a single XFS partition. I didn't use any odd options or anything, just a straight 'mkfs.xfs /dev/sdb1' fileserver$ xfs_info /dev/sdb1 meta-data=/myshare isize=256 agcount=351, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=367276014, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 fileserver$ dmesg|grep XFS SGI XFS 1.3.1 with ACLs, no debug enabled SGI XFS Quota Management subsystem fileserver$ rpm -qa |grep xfs xfsprogs-2.5.11-0 xfsprogs-devel-2.5.11-0 The partition is served out via NFS to a Solaris 9 box. The Solaris box mounts/accesses the the partition just fine. No problems from an OS-standpoint. The problem is with one of the apps that runs on the Solaris box. I've traced the problem to a statvfs() system call that gets an overflow error (EOVERFLOW) that the app decides to bail on. I dug further and found that the statvfs() call wants 32-bit addressing and overflows on some large numbers that are being returned. For example, if I do a df on the partition on the Solaris box (which uses the 64-bit friendly stat stavfs64() call) I see the following: $ df /myshare /myshare (fileserver:/myshare):1700188000 blocks 18446744073706766974 files Small XFS paritions (sorry, don't have good example...~1-2 GB total size, probably a little larger too) seem to solve the problem but defeat the purpose of having the large direct-attached RAID since they're only a few percent (?) the total size I want to work with. My question is this. Is there anything that can be done on the server-side to influence the free inodes/files that XFS reports? (Specifically, other than rebuilding the XFS partition smaller) Also a related question, has anyone ever run into this sort problem in the past and (if so) what did you do to work around it? The app's vendor has been notified and has logged this as a bug but they consider this to be a "corner-case" and don't seem to care much about updating their code, at least very quickly. I've pointed out to them the many other apps that run on there without problems but was unable to successfully goad them into patching the problem. Sorry about the length. Many thanks in advance to anyone helping me out! tim From owner-linux-xfs Tue Feb 1 12:30:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 12:30:48 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:zTvgxn1ARbaTTE/tqXaaaRNgxRG3pGKi@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11KUhcW028234 for ; Tue, 1 Feb 2005 12:30:43 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 5081F1800CC8; Tue, 1 Feb 2005 15:30:40 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06890-03; Tue, 1 Feb 2005 15:30:39 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 9873E18000A5; Tue, 1 Feb 2005 15:30:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 953021C0A522; Tue, 1 Feb 2005 15:30:39 -0500 (EST) Date: Tue, 1 Feb 2005 15:30:39 -0500 (EST) From: Mike Burger To: Net Llama! Cc: "Daniel E." , linux-xfs@oss.sgi.com Subject: Re: Suggestions for xfs In-Reply-To: Message-ID: References: <000401c5085c$facba270$0a01a8c0@pcdiano> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-Virus-Status: Clean X-archive-position: 4839 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs On Tue, 1 Feb 2005, Net Llama! wrote: > On Tue, 1 Feb 2005, Daniel E. wrote: > > Here are some suggestions for xfsprogs. > > > > Some people want xfs to be the standard file system for GNU/Linux. These > > Who wants this? Linux has no standard filesystem, so I don' see how this > could ever be possible. Actually, wouldn't it be safe to say that ext2 is/was the standard FS under linux. After all, unless you specify that you want to use an alternate filesystem, under any distribution, ext2 (maybe ext3, now) is used. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs Tue Feb 1 12:35:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 12:35:22 -0800 (PST) Received: from rockridge.uits.indiana.edu (rockridge.uits.indiana.edu [129.79.1.74]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11KZI1M028707 for ; Tue, 1 Feb 2005 12:35:19 -0800 Received: from iu-mssg-smtp04.ads.iu.edu (iu-mssg-smtp04.exchange.iu.edu [129.79.1.223]) by rockridge.uits.indiana.edu (8.12.10/8.12.10/IUPO) with ESMTP id j11KYbHh023130 for ; Tue, 1 Feb 2005 15:35:09 -0500 (EST) Received: from iu-mssg-mbx05.ads.iu.edu ([129.79.1.214]) by iu-mssg-smtp04.ads.iu.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Feb 2005 15:34:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Suggestions for xfs Date: Tue, 1 Feb 2005 15:34:03 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Suggestions for xfs Thread-Index: AcUInO8WeK4jOaonRN+CZHr5jgGKUQAAD1WO From: "Wilkins, Vern" To: X-OriginalArrivalTime: 01 Feb 2005 20:34:03.0997 (UTC) FILETIME=[5E9A10D0:01C5089D] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j11KZJ1M028709 X-archive-position: 4840 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vwilkins@indiana.edu Precedence: bulk X-list: linux-xfs I believe that's not the case. There are several distributions now that use XFS and/or reiser as the default filesystem. I think Suse uses Reiser as the default, for example. -----Original Message----- From: linux-xfs-bounce@oss.sgi.com on behalf of Mike Burger Sent: Tue 2/1/2005 3:30 PM To: Net Llama! Cc: Daniel E.; linux-xfs@oss.sgi.com Subject: Re: Suggestions for xfs On Tue, 1 Feb 2005, Net Llama! wrote: > On Tue, 1 Feb 2005, Daniel E. wrote: > > Here are some suggestions for xfsprogs. > > > > Some people want xfs to be the standard file system for GNU/Linux. These > > Who wants this? Linux has no standard filesystem, so I don' see how this > could ever be possible. Actually, wouldn't it be safe to say that ext2 is/was the standard FS under linux. After all, unless you specify that you want to use an alternate filesystem, under any distribution, ext2 (maybe ext3, now) is used. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs Tue Feb 1 12:35:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 12:35:58 -0800 (PST) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11KZrZs028929 for ; Tue, 1 Feb 2005 12:35:54 -0800 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.2/8.13.2/Debian-1) with ESMTP id j11JJ14a027050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2005 14:19:02 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.2/8.13.2/Submit) with ESMTP id j11JJ1ck027047; Tue, 1 Feb 2005 14:19:01 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Tue, 1 Feb 2005 14:19:01 -0500 (EST) From: Net Llama! To: Mike Burger cc: "Daniel E." , linux-xfs@oss.sgi.com Subject: Re: Suggestions for xfs In-Reply-To: Message-ID: References: <000401c5085c$facba270$0a01a8c0@pcdiano> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Tue, 01 Feb 2005 14:19:03 -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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4841 X-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 On Tue, 1 Feb 2005, Mike Burger wrote: > On Tue, 1 Feb 2005, Net Llama! wrote: > > > On Tue, 1 Feb 2005, Daniel E. wrote: > > > Here are some suggestions for xfsprogs. > > > > > > Some people want xfs to be the standard file system for GNU/Linux. These > > > > Who wants this? Linux has no standard filesystem, so I don' see how this > > could ever be possible. > > Actually, wouldn't it be safe to say that ext2 is/was the standard FS > under linux. Perhaps 5+ years ago, when there were no other choices. > After all, unless you specify that you want to use an alternate > filesystem, under any distribution, ext2 (maybe ext3, now) is used. I'm pretty sure that Mandrake, or some other quasi-mainstream distro uses ReiserFS by default. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Tue Feb 1 12:47:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 12:47:23 -0800 (PST) Received: from nirmala.opentrend.net (nirmala.opentrend.net [65.39.131.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11KlJqO029694 for ; Tue, 1 Feb 2005 12:47:19 -0800 Received: from localhost (localhost [127.0.0.1]) by nirmala.opentrend.net (Postfix) with ESMTP id 93F16FDB8 for ; Tue, 1 Feb 2005 15:43:57 -0500 (EST) Received: from nirmala.opentrend.net ([127.0.0.1]) by localhost (nirmala.opentrend.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 77691-02 for ; Tue, 1 Feb 2005 15:43:54 -0500 (EST) Received: by nirmala.opentrend.net (Postfix, from userid 1003) id ADF17FDB5; Tue, 1 Feb 2005 15:43:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nirmala.opentrend.net (Postfix) with ESMTP id A87C7FDB1 for ; Tue, 1 Feb 2005 20:43:54 +0000 (GMT) Date: Tue, 1 Feb 2005 20:43:54 +0000 (GMT) From: Robert Brockway To: linux-xfs@oss.sgi.com Subject: Re: Suggestions for xfs In-Reply-To: Message-ID: <20050201203908.X70122@nirmala.opentrend.net> References: <000401c5085c$facba270$0a01a8c0@pcdiano> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: amavisd-new at opentrend.net X-Virus-Status: Clean X-archive-position: 4842 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rbrockway@opentrend.net Precedence: bulk X-list: linux-xfs On Tue, 1 Feb 2005, Mike Burger wrote: > Actually, wouldn't it be safe to say that ext2 is/was the standard FS > under linux. > > After all, unless you specify that you want to use an alternate > filesystem, under any distribution, ext2 (maybe ext3, now) is used. It has been called the "defacto standard" filesystem but this is only for historical reasons. There is no way to enforce a standard filesystem for Linux since I can wake up tomorrow and make a distro based on xiafs if I want (ok, so I'd need to patch it back into the kernel :) I've read that ext2/3 is predicted to suffer significant performance penalties vs xfs, reiserfs or jfs for filesystems in the multi-TB range so we can expect to see ext2/3 fade in years to come. Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (http://www.spi-inc.org) From owner-linux-xfs Tue Feb 1 12:56:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 12:56:33 -0800 (PST) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11KuSN2030743 for ; Tue, 1 Feb 2005 12:56:29 -0800 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.2/8.13.2/Debian-1) with ESMTP id j11JdfZg027266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2005 14:39:42 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.2/8.13.2/Submit) with ESMTP id j11JdfoN027263; Tue, 1 Feb 2005 14:39:41 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Tue, 1 Feb 2005 14:39:41 -0500 (EST) From: Net Llama! To: Robert Brockway cc: linux-xfs@oss.sgi.com Subject: Re: Suggestions for xfs In-Reply-To: <20050201203908.X70122@nirmala.opentrend.net> Message-ID: References: <000401c5085c$facba270$0a01a8c0@pcdiano> <20050201203908.X70122@nirmala.opentrend.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]); Tue, 01 Feb 2005 14:39:45 -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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4843 X-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 On Tue, 1 Feb 2005, Robert Brockway wrote: > On Tue, 1 Feb 2005, Mike Burger wrote: > > > Actually, wouldn't it be safe to say that ext2 is/was the standard FS > > under linux. > > > > After all, unless you specify that you want to use an alternate > > filesystem, under any distribution, ext2 (maybe ext3, now) is used. > > It has been called the "defacto standard" filesystem but this is only for > historical reasons. There is no way to enforce a standard filesystem for > Linux since I can wake up tomorrow and make a distro based on xiafs if I > want (ok, so I'd need to patch it back into the kernel :) > > I've read that ext2/3 is predicted to suffer significant performance > penalties vs xfs, reiserfs or jfs for filesystems in the multi-TB range so > we can expect to see ext2/3 fade in years to come. I'm not a big fan of ext2/3 by any means, but i think its a bit near-sighted to assume that ext2/3 won't evolve in the3 future to better handle larger filesystems. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Tue Feb 1 13:40:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 13:40:49 -0800 (PST) Received: from nirmala.opentrend.net (nirmala.opentrend.net [65.39.131.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11LekmX032006 for ; Tue, 1 Feb 2005 13:40:46 -0800 Received: from localhost (localhost [127.0.0.1]) by nirmala.opentrend.net (Postfix) with ESMTP id 43BBDFDEE; Tue, 1 Feb 2005 16:37:24 -0500 (EST) Received: from nirmala.opentrend.net ([127.0.0.1]) by localhost (nirmala.opentrend.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 78056-01-7; Tue, 1 Feb 2005 16:37:21 -0500 (EST) Received: by nirmala.opentrend.net (Postfix, from userid 1003) id 5FD1AFDBA; Tue, 1 Feb 2005 16:37:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nirmala.opentrend.net (Postfix) with ESMTP id 5DBFFFDB2; Tue, 1 Feb 2005 21:37:21 +0000 (GMT) Date: Tue, 1 Feb 2005 21:37:21 +0000 (GMT) From: Robert Brockway To: Net Llama! Cc: linux-xfs@oss.sgi.com Subject: Re: Suggestions for xfs In-Reply-To: Message-ID: <20050201212952.I70122@nirmala.opentrend.net> References: <000401c5085c$facba270$0a01a8c0@pcdiano> <20050201203908.X70122@nirmala.opentrend.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: amavisd-new at opentrend.net X-Virus-Status: Clean X-archive-position: 4844 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rbrockway@opentrend.net Precedence: bulk X-list: linux-xfs On Tue, 1 Feb 2005, Net Llama! wrote: > I'm not a big fan of ext2/3 by any means, but i think its a bit > near-sighted to assume that ext2/3 won't evolve in the3 future to better > handle larger filesystems. I don't claim to be a filesystem expert by any means but my understanding was the predicted problems went right to the core of ext2/3. Maybe it would be possible to work around the problems but maybe it'd be easier to accept it will have run its course by then, especially when other filesystems like xfs are showing better performance in many ways already. Linux has dropped many core filesystems over its life (Minix and Ext were both considered the defacto standard in their time and xiafs was considered a viable alternative to ext2 once). In any case I only use ext2/3 when I need to so if someone wants to fix the problems I say good luck to them :) Cheers, Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (http://www.spi-inc.org) From owner-linux-xfs Tue Feb 1 15:52:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 15:52:31 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11NqSFL006645 for ; Tue, 1 Feb 2005 15:52:29 -0800 Received: from [10.0.0.2] (sandeen.net [209.173.210.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 02C9328BAF7; Tue, 1 Feb 2005 17:52:21 -0600 (CST) Message-ID: <42001633.3040808@sgi.com> Date: Tue, 01 Feb 2005 17:52:19 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Flower Cc: linux-xfs@oss.sgi.com Subject: Re: influencing reported free inodes? References: <1107284656.6468.67.camel@osiris.seakr.com> In-Reply-To: <1107284656.6468.67.camel@osiris.seakr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4845 X-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 xfs dynamically allocates inodes, up to some maximum percentage of disk space - that's the imaxpct you see in the mkfs output below. df -i reports as total inodes the number which -could- be allocated. You can reduce this with xfs_growfs: [root@lite ~]# df -i /mnt/sda1 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 2008064 5 2008059 1% /mnt/sda1 [root@lite ~]# xfs_growfs -m 1 /mnt/sda1 xfs_growfs: ignoring entry /eric1s0 in /etc/mtab: Stale NFS file handle meta-data=/mnt/sda1 isize=256 agcount=8, agsize=62752 blks = sectsz=512 data = bsize=4096 blocks=502016, 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 inode max percent changed from 25 to 1 [root@lite ~]# df -i /mnt/sda1 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 80320 5 80315 1% /mnt/sda1 -Eric Tim Flower wrote: > My question is this. Is there anything that can be done on the > server-side to influence the free inodes/files that XFS reports? > (Specifically, other than rebuilding the XFS partition smaller) > > Also a related question, has anyone ever run into this sort problem in > the past and (if so) what did you do to work around it? From owner-linux-xfs Tue Feb 1 16:13:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Feb 2005 16:15:17 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j120Dq1w007773 for ; Tue, 1 Feb 2005 16:13:52 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j120DqsU007772 for linux-xfs@oss.sgi.com; Tue, 1 Feb 2005 16:13:52 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j120Dpgd007755 for ; Tue, 1 Feb 2005 16:13:51 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j11NacNT006355; Tue, 1 Feb 2005 15:36:38 -0800 Date: Tue, 1 Feb 2005 15:36:38 -0800 Message-Id: <200502012336.j11NacNT006355@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 383] Write to an XFS file system generates errno 990 X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4846 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=383 ------- Additional Comments From byang@dsg.stanford.edu 2005-01-02 15:36 PDT ------- I got a similar error on a different system. We use XFS over a software raid device: -- linux 2.4.25; -- software raid5; -- 4-disk raid5 array; 250 GB per drive; SATA drives; -- Marvell SATA controller card; The user program gets an error: "ioctl XFS_IOC_RESVSP64 failed. errno: Unknown error 990:" while writing data to XFS. Kernel log contains the following messages: Jan 20 17:50:27 mstor02 kernel: 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jan 20 17:50:27 mstor02 kernel: Filesystem "md(9,11)": XFS internal error xfs_alloc_read_agf at line 2201 of file xfs_alloc.c. Caller 0x8019e0af Jan 20 17:50:27 mstor02 kernel: b1fb9900 b1fb9938 801ca3df 00000008 00000001 af183400 803033e0 802f9e33 Jan 20 17:50:27 mstor02 kernel: 00000899 802f9df5 8019e0af 00000001 af183400 00000000 b1fb995c 801ca50a Jan 20 17:50:27 mstor02 kernel: 802f9e33 00000001 af183400 802f9df5 00000899 8019e0af 00000000 b1fb9994 Jan 20 17:50:27 mstor02 kernel: Call Trace: [<801ca3df>] [<8019e0af>] [<801ca50a>] [<8019e0af>] [<8019e2fa>] Jan 20 17:50:27 mstor02 kernel: [<8019e0af>] [<8019e0af>] [<801ac5fa>] [] [<801b5d4b>] [<801ae2e8>] Jan 20 17:50:27 mstor02 kernel: [<801afd0e>] [<8012fccf>] [<80201e47>] [<801bbe86>] [<801be2d8>] [<801bbcc7>] Jan 20 17:50:27 mstor02 kernel: [<801c136b>] [<801fc81a>] [<801aeffe>] [<801be618>] [<801bdcaa>] [<801eae0e>] Jan 20 17:50:27 mstor02 kernel: [<801f2271>] [<801fa815>] [<801eb5a1>] [<801d16b3>] [<801d1529>] [<801f0a45>] Jan 20 17:50:27 mstor02 kernel: [<80127d57>] [<80127d57>] [<801fa903>] [<8014db88>] [<8014dc7d>] [<8010902f>] Jan 20 17:50:27 mstor02 kernel: xfs_force_shutdown(md(9,11),0x8) called from line 1070 of file xfs_trans.c. Return address = 0x801fdc31 Jan 20 17:50:27 mstor02 kernel: Filesystem "md(9,11)": Corruption of in-memory data detected. Shutting down filesystem: md(9,11) Jan 20 17:50:27 mstor02 kernel: Please umount the filesystem, and rectify the problem(s) /var/log/messages.1:Jan 20 00:25:08 mstor02 kernel: 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 /var/log/messages.1:Jan 20 00:25:08 mstor02 kernel: Filesystem "md(9,11)": XFS internal error xfs_alloc_read_agf at line 2201 of file xfs_alloc.c. Caller 0x8019e0af /var/log/messages.1:Jan 20 00:25:08 mstor02 kernel: b22ad9a4 b22ad9dc 801ca3df 00000008 00000001 ed11a000 803033e0 802f9e33 /var/log/messages.1:Jan 20 00:25:08 mstor02 kernel: 00000899 802f9df5 8019e0af 00000001 ed11a000 00000000 b22ada00 801ca50a /var/log/messages.1:Jan 20 00:25:08 mstor02 kernel: 802f9e33 00000001 ed11a000 802f9df5 00000899 8019e0af 00000000 b22ada38 /var/log/messages.1:Jan 20 00:25:08 mstor02 kernel: Call Trace: [<801ca3df>] [<8019e0af>] [<801ca50a>] [<8019e0af>] [<8019e2fa>] /var/log/messages.1:Jan 20 00:25:08 mstor02 kernel: [<8019e0af>] [<8019e0af>] [<801ac5fa>] [<80130009>] [<801feb58>] [<801365a8>] /var/log/messages.1:Jan 20 00:25:08 mstor02 kernel: [<801b8532>] [<801ae2e8>] [<801afd0e>] [<801ea7bd>] [<801fc7c9>] [<801b8532>] /var/log/messages.1:Jan 20 00:25:08 mstor02 kernel: [<801da971>] [<801eae01>] [<801f4242>] [<801f50a2>] [<801fa1f1>] [<801fa89d>] /var/log/messages.1:Jan 20 00:25:08 mstor02 kernel: [<80110bfb>] [<801f9c20>] [<801f966b>] [<80125163>] [<8012555a>] [<80125d45>] /var/log/messages.1:Jan 20 00:25:08 mstor02 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Feb 2 01:59:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Feb 2005 01:59:33 -0800 (PST) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j129xSWU007661 for ; Wed, 2 Feb 2005 01:59:29 -0800 Received: from minion.mpc.local ([172.16.11.112] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.43) id 1CwHIE-0007u8-U1; Wed, 02 Feb 2005 09:59:26 +0000 Message-ID: <4200A47E.8030608@moving-picture.com> Date: Wed, 02 Feb 2005 09:59:26 +0000 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: Tim Flower CC: linux-xfs@oss.sgi.com Subject: Re: influencing reported free inodes? 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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4847 X-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 Tim Flower wrote: > My question is this. Is there anything that can be done on the > server-side to influence the free inodes/files that XFS reports? > (Specifically, other than rebuilding the XFS partition smaller) > > Also a related question, has anyone ever run into this sort problem in > the past and (if so) what did you do to work around it? > > The app's vendor has been notified and has logged this as a bug but they > consider this to be a "corner-case" and don't seem to care much about > updating their code, at least very quickly. I've pointed out to them > the many other apps that run on there without problems but was unable to > successfully goad them into patching the problem. You might want to look at: http://marc.theaimsgroup.com/?l=linux-nfs&m=108910578914714&w=2 and the threads it refers to. James Pearson From owner-linux-xfs Wed Feb 2 14:38:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Feb 2005 14:38:18 -0800 (PST) Received: from mail.cambrianventures.com (206.173.21.243.ptr.us.xo.net [206.173.21.243]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j12McFKc001517 for ; Wed, 2 Feb 2005 14:38:16 -0800 Received: (qmail 23623 invoked from network); 2 Feb 2005 22:36:25 -0000 Received: from unknown (HELO wds19.cosmixcorp.com) (206.173.21.85) by ns0.cambrianventures.com with SMTP; 2 Feb 2005 22:36:25 -0000 Subject: Re: ls: reading directory .: Input/output error From: Douglass Judd To: linux-xfs@oss.sgi.com In-Reply-To: <1106941376.13349.322.camel@sedna.cambrianventures.com> References: <1106941376.13349.322.camel@sedna.cambrianventures.com> Content-Type: text/plain Message-Id: <1107383515.26459.64.camel@sedna.cambrianventures.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Wed, 02 Feb 2005 14:31:55 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4848 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doug@cosmixcorp.com Precedence: bulk X-list: linux-xfs Ok, I had some luck with xfs_repair -L. However, after running for a while, the problem happened again. Another thing I forgot to mention is that the log was corrupt. xfs_logprint produces: xfs_logprint: data device: 0x801 log device: 0x801 daddr: 1708906272 length: 262144 Header 0x4 wanted 0xfeedbabe ********************************************************************** * ERROR: header cycle=4 block=88181 * ********************************************************************** Bad log record header Another thing to note. After running "xfs_repair -L", xfs_check still reports errors such as the following: bad format 2 for inode 805325336 type 0 bad format 2 for inode 805325337 type 0 [... later followed by ...] allocated inode 805325336 has 0 link count allocated inode 805325337 has 0 link count [...] Is this OK? Is it known that xfs_repair will not fix some of the errors reported by xfs_check? - Doug On Fri, 2005-01-28 at 11:42, Douglass Judd wrote: > Hello, > > I'm using XFS on a large 8 disk RAID-5 partition. I was running a MySQL > process that was doing some random access (reads and writes) on a couple > of files. I then kicked off an scp job that was copying a few gigabytes > worth of data in about 5000 files to this machine when I lost the > filesystem. Any attempt to read resulted in input/output errors: > > [doug@wds12 webcache]$ ls > ls: reading directory .: Input/output error > > Something similar happened before, so I upgraded to the 2.6.10 kernel > after reading the thread "RE: Unknown Issue" > (http://oss.sgi.com/archives/linux-xfs/2004-12/msg00048.html) hoping > that it would solve my problems. > > The 3dm daemon reported no errors with the disk array and > /var/log/messages had the following lines in it: > > Jan 28 10:47:40 wds12 kernel: xfs_force_shutdown(sda1,0x8) called from > line 1091 of file fs/xfs/xfs_trans.c. Return address = > 0xffffffff8021cb48 > Jan 28 10:47:40 wds12 kernel: Filesystem "sda1": Corruption of in-memory > data detected. Shutting down filesystem: sda1 > Jan 28 10:47:40 wds12 kernel: Please umount the filesystem, and rectify > the problem(s) > > Here's my system configuration: > > Hardware: > Tyan S2882G3NR Thunder K8S Pro Motherboard > 2 - AMD Opteron processors > 3ware 9500S-8 RAID Controller > 8 - Western Digital 2500SD 250GB disk drives > > OS: 2.6.10 Kernel, built with these options ... > - Processor Family: AMD Opteron/Athalon64 > - Symmetric multi-processing support > - Preemptible kernel > > I ran xfs_check and here's what it reported: > > [root@wds12 log]# xfs_check /dev/sda1 > bad format 2 for inode 1208 type 0 > bad format 2 for inode 1209 type 0 > bad format 2 for inode 1210 type 0 > bad format 2 for inode 1211 type 0 > bad format 2 for inode 1212 type 0 > bad format 2 for inode 1213 type 0 > bad format 2 for inode 1214 type 0 > bad format 2 for inode 1215 type 0 > ir_freecount/free mismatch, inode chunk 0/1152, freecount 64 nfree 56 > bad format 2 for inode 268436760 type 0 > bad format 2 for inode 268436761 type 0 > bad format 2 for inode 268436762 type 0 > bad format 2 for inode 268436763 type 0 > bad format 2 for inode 268436767 type 0 > ir_freecount/free mismatch, inode chunk 1/1248, freecount 52 nfree 47 > bad format 2 for inode 268454488 type 0 > bad format 2 for inode 268454489 type 0 > bad format 2 for inode 268454490 type 0 > bad format 2 for inode 268454491 type 0 > bad format 2 for inode 268454492 type 0 > bad format 2 for inode 268454494 type 0 > bad format 2 for inode 268454495 type 0 > ir_freecount/free mismatch, inode chunk 1/18976, freecount 64 nfree 57 > bad format 2 for inode 536872216 type 0 > bad format 2 for inode 536872217 type 0 > bad format 2 for inode 536872218 type 0 > bad format 2 for inode 536872219 type 0 > bad format 2 for inode 536872220 type 0 > bad format 2 for inode 536872221 type 0 > bad format 2 for inode 536872222 type 0 > bad format 2 for inode 536872223 type 0 > ir_freecount/free mismatch, inode chunk 2/1248, freecount 8 nfree 0 > bad format 2 for inode 536889880 type 0 > bad format 2 for inode 536889881 type 0 > bad format 2 for inode 536889883 type 0 > bad format 2 for inode 536889886 type 0 > bad format 2 for inode 536889887 type 0 > ir_freecount/free mismatch, inode chunk 2/18912, freecount 64 nfree 59 > bad format 2 for inode 805325336 type 0 > bad format 2 for inode 805325337 type 0 > bad format 2 for inode 805325338 type 0 > bad format 2 for inode 805325339 type 0 > bad format 2 for inode 805325340 type 0 > bad format 2 for inode 805325341 type 0 > bad format 2 for inode 805325342 type 0 > bad format 2 for inode 805325343 type 0 > ir_freecount/free mismatch, inode chunk 3/18912, freecount 64 nfree 56 > bad format 2 for inode 1073743128 type 0 > bad format 2 for inode 1073743129 type 0 > bad format 2 for inode 1073743130 type 0 > bad format 2 for inode 1073743131 type 0 > bad format 2 for inode 1073743132 type 0 > bad format 2 for inode 1073743133 type 0 > bad format 2 for inode 1073743134 type 0 > bad format 2 for inode 1073743135 type 0 > ir_freecount/free mismatch, inode chunk 4/1248, freecount 64 nfree 56 > bad format 2 for inode 1073760824 type 0 > bad format 2 for inode 1073760825 type 0 > bad format 2 for inode 1073760826 type 0 > bad format 2 for inode 1073760827 type 0 > ir_freecount/free mismatch, inode chunk 4/18944, freecount 64 nfree 60 > bad format 2 for inode 1342178584 type 0 > bad format 2 for inode 1342178585 type 0 > bad format 2 for inode 1342178586 type 0 > bad format 2 for inode 1342178587 type 0 > bad format 2 for inode 1342178588 type 0 > bad format 2 for inode 1342178589 type 0 > bad format 2 for inode 1342178590 type 0 > bad format 2 for inode 1342178591 type 0 > ir_freecount/free mismatch, inode chunk 5/1248, freecount 59 nfree 51 > bad format 2 for inode 1342196280 type 0 > bad format 2 for inode 1342196281 type 0 > bad format 2 for inode 1342196282 type 0 > bad format 2 for inode 1342196283 type 0 > bad format 2 for inode 1342196284 type 0 > bad format 2 for inode 1342196285 type 0 > bad format 2 for inode 1342196286 type 0 > bad format 2 for inode 1342196287 type 0 > ir_freecount/free mismatch, inode chunk 5/18944, freecount 64 nfree 56 > bad format 2 for inode 1610614011 type 0 > bad format 2 for inode 1610614012 type 0 > bad format 2 for inode 1610614013 type 0 > bad format 2 for inode 1610614014 type 0 > ir_freecount/free mismatch, inode chunk 6/1216, freecount 64 nfree 60 > bad format 2 for inode 1610631704 type 0 > bad format 2 for inode 1610631705 type 0 > bad format 2 for inode 1610631706 type 0 > bad format 2 for inode 1610631707 type 0 > bad format 2 for inode 1610631708 type 0 > bad format 2 for inode 1610631709 type 0 > bad format 2 for inode 1610631710 type 0 > bad format 2 for inode 1610631711 type 0 > ir_freecount/free mismatch, inode chunk 6/18nk count > allocated inode 1213 has 0 link count > allocated inode 1214 has 0 link count > allocated inode 1215 has 0 link count > allocated inode 268436760 has 0 link count > allocated inode 268436761 has 0 link count > allocated inode 268436762 has 0 link count > allocated inode 268436763 has 0 link count > [... 150 lines like this ...] > > I haven't run xfs_repair yet. Is there anything more I can do to > diagnose this problem? > > - Doug > > P.S. I'm here in Mountain View, CA so if someone want's to swing by and > have a look, feel free! :) > > From owner-linux-xfs Wed Feb 2 17:03:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Feb 2005 17:03:38 -0800 (PST) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1313ZUk016836 for ; Wed, 2 Feb 2005 17:03:36 -0800 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 j1313RVV2034247; Thu, 3 Feb 2005 12:03:28 +1100 (AEDT) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j1313PQP2033848; Thu, 3 Feb 2005 12:03:25 +1100 (AEDT) Date: Thu, 3 Feb 2005 12:03:25 +1100 From: Tim Shimmin To: Douglass Judd Cc: linux-xfs@oss.sgi.com Subject: Re: ls: reading directory .: Input/output error Message-ID: <20050203120325.A730632@boing.melbourne.sgi.com> References: <1106941376.13349.322.camel@sedna.cambrianventures.com> <1107383515.26459.64.camel@sedna.cambrianventures.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: <1107383515.26459.64.camel@sedna.cambrianventures.com>; from doug@cosmixcorp.com on Wed, Feb 02, 2005 at 02:31:55PM -0800 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4849 X-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 Wed, Feb 02, 2005 at 02:31:55PM -0800, Douglass Judd wrote: > Another thing I forgot to mention is > that the log was corrupt. xfs_logprint produces: > > xfs_logprint: > data device: 0x801 > log device: 0x801 daddr: 1708906272 length: 262144 > > Header 0x4 wanted 0xfeedbabe > ********************************************************************** > * ERROR: header cycle=4 block=88181 * > ********************************************************************** > Bad log record header > FYI It's best to use the -t option to xfs_logprint. The -t option will ensure it starts printing from the tail of the log to the head of the log i.e. the items which get processed on recovery. Also, it prints the higher level transactions. If you don't use -t then you print out the lower level log-ops and it starts printing at the start of the log, which may in fact be midway thru a log record created when the log was last wrapped - and thus one is likely not to start with a header (one could use -s to start from somehere else). --Tim From owner-linux-xfs Wed Feb 2 22:05:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Feb 2005 22:05:20 -0800 (PST) Received: from ns1.networkiowa.com (ns1.networkiowa.com [209.234.64.192]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1365HW7030619 for ; Wed, 2 Feb 2005 22:05:18 -0800 Received: from dsl.78.136.networkiowa.com (dsl.78.136.networkiowa.com [209.234.78.136]) by ns1.networkiowa.com (8.13.1/8.13.1) with ESMTP id j13654TH025790 for ; Thu, 3 Feb 2005 00:05:05 -0600 Subject: Write event -> dm_read_invis? From: Ben Myers To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Thu, 03 Feb 2005 00:05:04 -0600 Message-Id: <1107410704.5512.27.camel@debian> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Freese-Notis-MailScanner-Information: Please contact the ISP for more information X-Freese-Notis-MailScanner: Found to be clean X-Freese-Notis-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.776, required 8, autolearn=not spam, ALL_TRUSTED -3.30, AWL 0.12, BAYES_00 -2.60) X-MailScanner-From: dative@raccoon.com X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4850 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dative@raccoon.com Precedence: bulk X-list: linux-xfs Hi, I'm working on a small data migration app. I'm getting DM_EVENT_WRITE events, responding with DM_RESP_CONTINUE, and wanting to immediately turn a round and dm_read_invis() on that handle from de_offset to de_length and spit it out (with some other info) towards my tape drive. Can I assume that a dm_read_invis will get me only the change affected by the write event i responded to? What behavior should I expect for overlapping writes, and how can I tell when a write is finished and it's ok to copy the data out to tape? Thanks for any help, -Ben -- Ben Myers From owner-linux-xfs Thu Feb 3 01:05:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 01:05:10 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13954Ig006814 for ; Thu, 3 Feb 2005 01:05:05 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 107EDFB460 for ; Thu, 3 Feb 2005 10:05:04 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 10:05:03 +0100 From: Anders Saaby Organization: Cohaesio A/S To: linux-xfs@oss.sgi.com Subject: Question: Does XFS journal data or only metadata? Date: Thu, 3 Feb 2005 10:05:57 +0100 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031005.57621.as@cohaesio.com> X-OriginalArrivalTime: 03 Feb 2005 09:05:03.0991 (UTC) FILETIME=[72DD4070:01C509CF] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4851 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Hi List, We are considering using NVRAM for external journal on some of our XFS filesystems, but questions emerge which I can not find answers for: Does XFS journal everything (data and metadata) or only metadata? Are we able to move an internal log to external log on an existing filesystem? (xfs_growfs has an option for it "-x", but the man page says it is "not implemented") - If this is not implemented, do we have alternative measures for creating an external log on an existing filesystem? Thanks in advance, -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Thu Feb 3 01:47:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 01:47:26 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j139lNYw008382 for ; Thu, 3 Feb 2005 01:47:24 -0800 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 UAA01667; Thu, 3 Feb 2005 20:47:13 +1100 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 j139lBXE1927761; Thu, 3 Feb 2005 20:47:12 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j139lAtj1926951; Thu, 3 Feb 2005 20:47:10 +1100 (EST) Date: Thu, 3 Feb 2005 20:47:10 +1100 From: Nathan Scott To: Anders Saaby Cc: linux-xfs@oss.sgi.com Subject: Re: Question: Does XFS journal data or only metadata? Message-ID: <20050203204709.A1929258@wobbly.melbourne.sgi.com> References: <200502031005.57621.as@cohaesio.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200502031005.57621.as@cohaesio.com>; from as@cohaesio.com on Thu, Feb 03, 2005 at 10:05:57AM +0100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4852 X-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 On Thu, Feb 03, 2005 at 10:05:57AM +0100, Anders Saaby wrote: > Hi List, > > We are considering using NVRAM for external journal on some of our XFS > filesystems, but questions emerge which I can not find answers for: > > Does XFS journal everything (data and metadata) or only metadata? Only metadata. > Are we able to move an internal log to external log on an existing filesystem? > (xfs_growfs has an option for it "-x", but the man page says it is "not > implemented") - If this is not implemented, do we have alternative measures > for creating an external log on an existing filesystem? Its not implemented. It would be quite straightforward to do offline (I remember Steve sent mail about an unsupported way to do this a few years ago) - could be done through xfs_db. It's really not a difficult extension to xfs_db if you want to try coding it. Online would be more involved, though could be done (probably via xfs_freeze, then xfs_growfs-x+, then thaw). cheers. -- Nathan From owner-linux-xfs Thu Feb 3 02:32:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 02:32:40 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13AWYu7009726 for ; Thu, 3 Feb 2005 02:32:38 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 76FB5FB45E; Thu, 3 Feb 2005 11:32:33 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 11:32:33 +0100 From: Anders Saaby Organization: Cohaesio A/S To: Nathan Scott Subject: Re: Question: Does XFS journal data or only metadata? Date: Thu, 3 Feb 2005 11:33:26 +0100 User-Agent: KMail/1.7.2 Cc: linux-xfs@oss.sgi.com, Steve Lord References: <200502031005.57621.as@cohaesio.com> <20050203204709.A1929258@wobbly.melbourne.sgi.com> In-Reply-To: <20050203204709.A1929258@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031133.27056.as@cohaesio.com> X-OriginalArrivalTime: 03 Feb 2005 10:32:33.0389 (UTC) FILETIME=[ABBFD1D0:01C509DB] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4853 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Thank you for your fast reply! On Thursday 03 February 2005 10:47, Nathan Scott wrote: > > > > Does XFS journal everything (data and metadata) or only metadata? > > Only metadata. OK > > Are we able to move an internal log to external log on an existing > > filesystem? (xfs_growfs has an option for it "-x", but the man page says > > it is "not implemented") - If this is not implemented, do we have > > alternative measures for creating an external log on an existing > > filesystem? > > Its not implemented. It would be quite straightforward to do > offline (I remember Steve sent mail about an unsupported way to > do this a few years ago) - could be done through xfs_db. It's > really not a difficult extension to xfs_db if you want to try > coding it. > > Online would be more involved, though could be done (probably > via xfs_freeze, then xfs_growfs-x+, then thaw). OK - An offline solution is fine with me, but I cannot find Steve's mail (Haven't been subscribed to this list that long). - Steve, Is this still an option with present XFS implementation? - And can you maybe elaborate a bit on how to do it? :) -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Thu Feb 3 05:38:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 05:38:18 -0800 (PST) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13DcDk1021576 for ; Thu, 3 Feb 2005 05:38:14 -0800 Received: from minion.mpc.local ([172.16.11.112] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.43) id 1CwhBU-0001XR-9t; Thu, 03 Feb 2005 13:38:12 +0000 Message-ID: <42022944.9050307@moving-picture.com> Date: Thu, 03 Feb 2005 13:38:12 +0000 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: Anders Saaby CC: linux-xfs@oss.sgi.com Subject: Re: Question: Does XFS journal data or only metadata? 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-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4854 X-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 Anders Saaby wrote: > OK - An offline solution is fine with me, but I cannot find Steve's mail > (Haven't been subscribed to this list that long). A quick search at http://marc.theaimsgroup.com/?l=linux-xfs gives: http://marc.theaimsgroup.com/?l=linux-xfs&m=106929781232520&w=2 James Pearson From owner-linux-xfs Thu Feb 3 05:47:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 05:47:26 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13DlOuZ022163 for ; Thu, 3 Feb 2005 05:47:24 -0800 Received: from filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.131.176]) by relay03.roc.ny.frontiernet.net (Postfix) with ESMTP id 6F46A191C88; Thu, 3 Feb 2005 13:47:23 +0000 (UTC) Received: from relay03.roc.ny.frontiernet.net ([66.133.131.36]) by filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.131.176]) (amavisd-new, port 10024) with LMTP id 00744-35-40; Thu, 3 Feb 2005 13:47:23 +0000 (UTC) Received: from [192.168.1.100] (67-137-96-87.dsl2.brv.mn.frontiernet.net [67.137.96.87]) by relay03.roc.ny.frontiernet.net (Postfix) with ESMTP id AD983191C97; Thu, 3 Feb 2005 13:47:19 +0000 (UTC) Message-ID: <42022B64.2060604@xfs.org> Date: Thu, 03 Feb 2005 07:47:16 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Saaby Cc: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: Question: Does XFS journal data or only metadata? References: <200502031005.57621.as@cohaesio.com> <20050203204709.A1929258@wobbly.melbourne.sgi.com> <200502031133.27056.as@cohaesio.com> In-Reply-To: <200502031133.27056.as@cohaesio.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter01.roc.ny.frontiernet.net X-Virus-Status: Clean X-archive-position: 4855 X-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 Anders Saaby wrote: >>>Are we able to move an internal log to external log on an existing >>>filesystem? (xfs_growfs has an option for it "-x", but the man page says >>>it is "not implemented") - If this is not implemented, do we have >>>alternative measures for creating an external log on an existing >>>filesystem? >> >>Its not implemented. It would be quite straightforward to do >>offline (I remember Steve sent mail about an unsupported way to >>do this a few years ago) - could be done through xfs_db. It's >>really not a difficult extension to xfs_db if you want to try >>coding it. >> >>Online would be more involved, though could be done (probably >>via xfs_freeze, then xfs_growfs-x+, then thaw). > > > OK - An offline solution is fine with me, but I cannot find Steve's mail > (Haven't been subscribed to this list that long). > > - Steve, Is this still an option with present XFS implementation? - And can > you maybe elaborate a bit on how to do it? :) > > Found it: http://oss.sgi.com/archives/linux-xfs/2001-07/msg00564.html Steve From owner-linux-xfs Thu Feb 3 06:41:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 06:41:15 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13EfC4k024101 for ; Thu, 3 Feb 2005 06:41:13 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 1F224FB44F; Thu, 3 Feb 2005 15:41:12 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 15:41:12 +0100 From: Anders Saaby Organization: Cohaesio A/S To: Steve Lord Subject: Re: Question: Does XFS journal data or only metadata? Date: Thu, 3 Feb 2005 15:42:05 +0100 User-Agent: KMail/1.7.2 Cc: Nathan Scott , linux-xfs@oss.sgi.com References: <200502031005.57621.as@cohaesio.com> <200502031133.27056.as@cohaesio.com> <42022B64.2060604@xfs.org> In-Reply-To: <42022B64.2060604@xfs.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031542.05619.as@cohaesio.com> X-OriginalArrivalTime: 03 Feb 2005 14:41:12.0018 (UTC) FILETIME=[67F1F320:01C509FE] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4856 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs On Thursday 03 February 2005 14:47, Steve Lord wrote: > Anders Saaby wrote: > > - Steve, Is this still an option with present XFS implementation? - And > > can you maybe elaborate a bit on how to do it? :) > > Found it: > > http://oss.sgi.com/archives/linux-xfs/2001-07/msg00564.html > > Steve Thanks a lot! - Looks pretty funky :) - Will try it right away. -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Thu Feb 3 06:50:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 06:50:13 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Eo90W024660 for ; Thu, 3 Feb 2005 06:50:09 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id D7EAFFB44F; Thu, 3 Feb 2005 15:50:08 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 15:50:08 +0100 From: Anders Saaby Organization: Cohaesio A/S To: James Pearson Subject: Re: Question: Does XFS journal data or only metadata? Date: Thu, 3 Feb 2005 15:51:02 +0100 User-Agent: KMail/1.7.2 Cc: linux-xfs@oss.sgi.com References: <42022944.9050307@moving-picture.com> In-Reply-To: <42022944.9050307@moving-picture.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031551.02588.as@cohaesio.com> X-OriginalArrivalTime: 03 Feb 2005 14:50:08.0799 (UTC) FILETIME=[A7E43AF0:01C509FF] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4857 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs On Thursday 03 February 2005 14:38, James Pearson wrote: > Anders Saaby wrote: > > OK - An offline solution is fine with me, but I cannot find Steve's mail > > (Haven't been subscribed to this list that long). > > A quick search at http://marc.theaimsgroup.com/?l=linux-xfs gives: > > http://marc.theaimsgroup.com/?l=linux-xfs&m=106929781232520&w=2 > > James Pearson Hehe thanks - I think I will have a chat with my google skills later today. ;) -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Thu Feb 3 07:16:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 07:16:29 -0800 (PST) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13FGPdB025623 for ; Thu, 3 Feb 2005 07:16:25 -0800 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Feb 2005 07:16:15 -0800 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Feb 2005 07:16:15 -0800 Message-ID: <42024015.5000004@xfs.org> Date: Thu, 03 Feb 2005 09:15:33 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Saaby CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: Question: Does XFS journal data or only metadata? References: <200502031005.57621.as@cohaesio.com> <200502031133.27056.as@cohaesio.com> <42022B64.2060604@xfs.org> <200502031542.05619.as@cohaesio.com> In-Reply-To: <200502031542.05619.as@cohaesio.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2005 15:16:15.0398 (UTC) FILETIME=[4DA84460:01C50A03] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4858 X-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 Anders Saaby wrote: > On Thursday 03 February 2005 14:47, Steve Lord wrote: > >>Anders Saaby wrote: >> >>>- Steve, Is this still an option with present XFS implementation? - And >>>can you maybe elaborate a bit on how to do it? :) >> >>Found it: >> >>http://oss.sgi.com/archives/linux-xfs/2001-07/msg00564.html >> >>Steve > > > Thanks a lot! - Looks pretty funky :) > > - Will try it right away. > The bit about setting the values twice should not be necessary, I think that endian bug should be ancient history. You may need to run xfs_repair before mount will work nowadays too, try it and see. Steve From owner-linux-xfs Thu Feb 3 07:46:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 07:46:58 -0800 (PST) Received: from poptart.bithose.com (poptart.bithose.com [204.97.176.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13FkuIO027060 for ; Thu, 3 Feb 2005 07:46:57 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.10/8.12.10) with ESMTP id j13Fkclp243187 for ; Thu, 3 Feb 2005 10:46:38 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.10/8.12.10/Submit) with ESMTP id j13FkcKK242961 for ; Thu, 3 Feb 2005 10:46:38 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Thu, 3 Feb 2005 10:46:37 -0500 (EST) From: Jameel Akari To: linux-xfs@oss.sgi.com Subject: du vs. df inconsistency Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4859 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: linux-xfs I have an issue with an XFS filesystem on one server where df reports it as one value (say, 95%, or even 100% full) but the actual total of file sizes is much less. df -h: /dev/sda5 9.8G 8.0G 1.8G 82% /foo # du -hs /foo 1.6G /foo The environment on /foo is a little odd and probably has something to do with the problem. This filesystem receives a number of largish (100-800MB) datafiles each day, which are seperated into subdirectories which are rotated daily at midnight: Feb 3 00:00 20050201 Feb 2 23:54 20050202 Feb 3 05:50 20050203 Feb 3 00:00 current -> 20050203 Feb 3 00:00 yesterday -> 20050202 The process puts files in "current" and there are lockfiles checked between the process code and the rotate scripts. That works well enough. Additionally, a script runs to compress the files after two days (i.e. they used to be in "yesterday" and now they're a day older). After a directory is 2 weeks old (+14 days) it is removed entirely. There are about a dozen subdirectories which are in /foo that are rotated and compressed like this. The point is, the rotate/compress scripts are supposed to keep /foo clean, which it does - except df (and other system calls) think more is used than actually is by the files. So if df says "100%", and a file tries to copy into here, it will fail, saying it's out of space. Interim solution has been to remove subdirectories and compress yesterday's datafiles manually to give it more apparent space, but that's becoming less effective over time. When you've deleted everything you can down to < 1GB and it still says 9GB is used, it's obvious there's a problem. I have already tried a xfs_fsr on /foo which has improved the extents used by some files, but the apparent utilization didn't change. Anything else I can try before I dump the fs and make a new one? -- #!/jameel/akari sleep 4800; make clean && make breakfast From owner-linux-xfs Thu Feb 3 08:16:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 08:16:09 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13GG6RT028362 for ; Thu, 3 Feb 2005 08:16:07 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 244E8FB44F; Thu, 3 Feb 2005 17:16:06 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 17:16:06 +0100 From: Anders Saaby Organization: Cohaesio A/S To: Steve Lord Subject: Re: Question: Does XFS journal data or only metadata? Date: Thu, 3 Feb 2005 17:16:59 +0100 User-Agent: KMail/1.7.2 Cc: Nathan Scott , linux-xfs@oss.sgi.com References: <200502031005.57621.as@cohaesio.com> <200502031542.05619.as@cohaesio.com> <42024015.5000004@xfs.org> In-Reply-To: <42024015.5000004@xfs.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031716.59894.as@cohaesio.com> X-OriginalArrivalTime: 03 Feb 2005 16:16:06.0053 (UTC) FILETIME=[A9DABD50:01C50A0B] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4860 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs On Thursday 03 February 2005 16:15, Steve Lord wrote: > > The bit about setting the values twice should not be necessary, I > think that endian bug should be ancient history. > > You may need to run xfs_repair before mount will work nowadays too, > try it and see. > > Steve Yup - This is fixed: xfs_db> write logblocks 8750 logblocks = 8750 Actually the move works, I am able to move the log from internal to external and back again. - And able to mount the filesystem in both cituations, but xfs_repair doesen't agree. When running xfs_repair on the filesystem after I have moved the log to an external device the following error occurs: st3:~# xfs_repair -L -l /dev/sda4 /dev/sdc1 Phase 1 - find and verify superblock... fatal error -- could not read superblock - This only happens when I have created the filesystem with an internal log and then manually moved it to external, and the filesystem mounts fine with the following command: mount -t xfs -o logbufs=4,logdev=/dev/sda4 /dev/sdc1 /mnt/xfs_test/ - Do you have any ideas? Here is some extra info: xfsprogs version is: 2.6.20-1 (debian/sarge package). magicnum = 0x58465342 blocksize = 4096 dblocks = 17921520 rblocks = 0 rextents = 0 uuid = 8f98e5b4-e433-4caa-85eb-992791971236 logstart = 0 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 1120095 agcount = 16 rbmblocks = 0 logblocks = 8750 versionnum = 0x3084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 21 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 64 ifree = 60 fdblocks = 17921452 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 magicnum = 0x58465342 blocksize = 4096 dblocks = 17921520 rblocks = 0 rextents = 0 uuid = 912b1329-63c7-4892-8c47-1d7447112a3d logstart = 0 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 1120095 agcount = 16 rbmblocks = 0 logblocks = 8750 versionnum = 0x3084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 21 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 64 ifree = 61 fdblocks = 17912702 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 st3:~# diff -u extfromstart.sb moved.sb --- extfromstart.sb 2005-02-03 16:29:42.000000000 +0100 +++ moved.sb 2005-02-03 16:31:31.000000000 +0100 @@ -3,7 +3,7 @@ dblocks = 17921520 rblocks = 0 rextents = 0 -uuid = 8f98e5b4-e433-4caa-85eb-992791971236 +uuid = 912b1329-63c7-4892-8c47-1d7447112a3d logstart = 0 rootino = 128 rbmino = 129 @@ -27,8 +27,8 @@ inprogress = 0 imax_pct = 25 icount = 64 -ifree = 60 -fdblocks = 17921452 +ifree = 61 +fdblocks = 17912702 frextents = 0 uquotino = 0 gquotino = 0 -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Thu Feb 3 08:24:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 08:24:05 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13GO3MI032258 for ; Thu, 3 Feb 2005 08:24:03 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id D18E9FB44F; Thu, 3 Feb 2005 17:24:02 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 17:24:02 +0100 From: Anders Saaby Organization: Cohaesio A/S To: Steve Lord Subject: Re: Question: Does XFS journal data or only metadata? Date: Thu, 3 Feb 2005 17:24:56 +0100 User-Agent: KMail/1.7.2 Cc: Nathan Scott , linux-xfs@oss.sgi.com References: <200502031005.57621.as@cohaesio.com> <42024015.5000004@xfs.org> <200502031716.59894.as@cohaesio.com> In-Reply-To: <200502031716.59894.as@cohaesio.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031724.56665.as@cohaesio.com> X-OriginalArrivalTime: 03 Feb 2005 16:24:02.0768 (UTC) FILETIME=[C5FFAD00:01C50A0C] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4861 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs On Thursday 03 February 2005 17:16, Anders Saaby wrote: > On Thursday 03 February 2005 16:15, Steve Lord wrote: > > The bit about setting the values twice should not be necessary, I > > think that endian bug should be ancient history. > > > > You may need to run xfs_repair before mount will work nowadays too, > > try it and see. > > > > Steve > > Yup - This is fixed: > > xfs_db> write logblocks 8750 > logblocks = 8750 > > Actually the move works, I am able to move the log from internal to > external and back again. - And able to mount the filesystem in both > cituations, but xfs_repair doesen't agree. When running xfs_repair on the > filesystem after I have moved the log to an external device the following > error occurs: > > > st3:~# xfs_repair -L -l /dev/sda4 /dev/sdc1 > Phase 1 - find and verify superblock... > > fatal error -- could not read superblock > Don't know if this is relevant, but this strace looks interesting: st3:~# strace xfs_repair -L -l /dev/sda4 /dev/sdc1 execve("/sbin/xfs_repair", ["xfs_repair", "-L", "-l", "/dev/sda4", "/dev/sdc1"], [/* 16 vars */]) = 0 uname({sys="Linux", node="st3", ...}) = 0 brk(0) = 0x80d5000 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5556c000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=12946, ...}) = 0 old_mmap(NULL, 12946, PROT_READ, MAP_PRIVATE, 3, 0) = 0x5556d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libuuid.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0l\f\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=9128, ...}) = 0 old_mmap(NULL, 12140, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x55571000 old_mmap(0x55573000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x55573000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360Y\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=1253924, ...}) = 0 old_mmap(NULL, 1260140, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x55574000 old_mmap(0x5569d000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x129000) = 0x5569d000 old_mmap(0x556a5000, 10860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| MAP_ANONYMOUS, -1, 0) = 0x556a5000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x556a8000 set_thread_area({entry_number:-1 -> 11, base_addr:0x556a8460, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0x5556d000, 12946) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=290448, ...}) = 0 mmap2(NULL, 290448, PROT_READ, MAP_PRIVATE, 3, 0) = 0x556a9000 close(3) = 0 brk(0) = 0x80d5000 brk(0x80f6000) = 0x80f6000 brk(0) = 0x80f6000 getcwd("/root", 4096) = 6 stat64("/dev/sdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33), ...}) = 0 stat64("/dev/sdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33), ...}) = 0 ustat(0x821, 0xffffc914) = -1 EINVAL (Invalid argument) open("/dev/sdc1", O_RDONLY|O_LARGEFILE) = 3 stat64("/dev/sdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33), ...}) = 0 stat64("/dev/sdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33), ...}) = 0 ustat(0x821, 0xffffc914) = -1 EINVAL (Invalid argument) open("/dev/sdc1", O_RDWR|O_LARGEFILE) = 4 fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33), ...}) = 0 ioctl(4, BLKBSZSET, 0xffffc948) = 0 fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33), ...}) = 0 ioctl(4, BLKGETSIZE64, 0xffffc960) = 0 ioctl(4, BLKSSZGET, 0x80d4b50) = 0 stat64("/dev/sda4", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 4), ...}) = 0 stat64("/dev/sda4", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 4), ...}) = 0 ustat(0x804, 0xffffc914) = -1 EINVAL (Invalid argument) open("/dev/sda4", O_RDWR|O_LARGEFILE) = 5 fstat64(5, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 4), ...}) = 0 ioctl(5, BLKBSZSET, 0xffffc948) = 0 fstat64(5, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 4), ...}) = 0 ioctl(5, BLKGETSIZE64, 0xffffc960) = 0 ioctl(5, BLKSSZGET, 0x80d4b54) = 0 chdir("/root") = 0 close(3) = 0 open("/dev/sdc1", O_RDWR|O_LARGEFILE) = 3 write(2, "Phase 1 - find and verify superb"..., 40Phase 1 - find and verify superblock... ) = 40 mmap2(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x556f0000 mmap2(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x55771000 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 524288) = 524288 munmap(0x55771000, 528384) = 0 _llseek(3, 4587909120, [4587909120], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 9175818240, [9175818240], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 13763727360, [13763727360], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 18351636480, [18351636480], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 22939545600, [22939545600], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 27527454720, [27527454720], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 32115363840, [32115363840], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 36703272960, [36703272960], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 41291182080, [41291182080], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 45879091200, [45879091200], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 50467000320, [50467000320], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 55054909440, [55054909440], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 59642818560, [59642818560], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 64230727680, [64230727680], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 68818636800, [68818636800], SEEK_SET) = 0 read(3, "XFSB\0\0\20\0\0\0\0\0\1\21u\360\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(3, 292941824, [292941824], SEEK_SET) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 write(2, "\nfatal error -- ", 16 fatal error -- ) = 16 write(2, "could not read superblock\n", 26could not read superblock ) = 26 exit_group(1) = ? -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Thu Feb 3 08:39:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 08:39:12 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Gd78A000459 for ; Thu, 3 Feb 2005 08:39:10 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 47630FB45E; Thu, 3 Feb 2005 17:39:07 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 17:39:07 +0100 From: Anders Saaby Organization: Cohaesio A/S To: Steve Lord Subject: Re: Question: Does XFS journal data or only metadata? Date: Thu, 3 Feb 2005 17:40:00 +0100 User-Agent: KMail/1.7.2 Cc: Nathan Scott , linux-xfs@oss.sgi.com References: <200502031005.57621.as@cohaesio.com> <200502031716.59894.as@cohaesio.com> <200502031724.56665.as@cohaesio.com> In-Reply-To: <200502031724.56665.as@cohaesio.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031740.01081.as@cohaesio.com> X-OriginalArrivalTime: 03 Feb 2005 16:39:07.0189 (UTC) FILETIME=[E1135E50:01C50A0E] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4862 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs On Thursday 03 February 2005 17:24, Anders Saaby wrote: > On Thursday 03 February 2005 17:16, Anders Saaby wrote: > > On Thursday 03 February 2005 16:15, Steve Lord wrote: > > > The bit about setting the values twice should not be necessary, I > > > think that endian bug should be ancient history. > > > > > > You may need to run xfs_repair before mount will work nowadays too, > > > try it and see. > > > > > > Steve > > > > Yup - This is fixed: > > > > xfs_db> write logblocks 8750 > > logblocks = 8750 > > > > Actually the move works, I am able to move the log from internal to > > external and back again. - And able to mount the filesystem in both > > cituations, but xfs_repair doesen't agree. When running xfs_repair on the > > filesystem after I have moved the log to an external device the following > > error occurs: > > > > > > st3:~# xfs_repair -L -l /dev/sda4 /dev/sdc1 > > Phase 1 - find and verify superblock... > > > > fatal error -- could not read superblock > > > > Don't know if this is relevant, but this strace looks interesting: > OK - After looking at the strace I checked the _other_ superblocks. As I only altered SB0, the other superblocks SB1+ still contains the old logstart value. Wrote "logfile 0" to SB 0 - SB 15, and it all works! :) It this the way to do it, or am I missing something obvious? -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Thu Feb 3 09:03:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 09:03:59 -0800 (PST) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13H3vSB001959 for ; Thu, 3 Feb 2005 09:03:58 -0800 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Feb 2005 09:03:52 -0800 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Feb 2005 09:03:52 -0800 Message-ID: <4202594B.3030204@xfs.org> Date: Thu, 03 Feb 2005 11:03:07 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Saaby CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: Question: Does XFS journal data or only metadata? References: <200502031005.57621.as@cohaesio.com> <200502031716.59894.as@cohaesio.com> <200502031724.56665.as@cohaesio.com> <200502031740.01081.as@cohaesio.com> In-Reply-To: <200502031740.01081.as@cohaesio.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2005 17:03:52.0200 (UTC) FILETIME=[56361080:01C50A12] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4863 X-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 Anders Saaby wrote: > On Thursday 03 February 2005 17:24, Anders Saaby wrote: > >>On Thursday 03 February 2005 17:16, Anders Saaby wrote: >> >>>On Thursday 03 February 2005 16:15, Steve Lord wrote: >>> >>>>The bit about setting the values twice should not be necessary, I >>>>think that endian bug should be ancient history. >>>> >>>>You may need to run xfs_repair before mount will work nowadays too, >>>>try it and see. >>>> >>>>Steve >>> >>>Yup - This is fixed: >>> >>>xfs_db> write logblocks 8750 >>>logblocks = 8750 >>> >>>Actually the move works, I am able to move the log from internal to >>>external and back again. - And able to mount the filesystem in both >>>cituations, but xfs_repair doesen't agree. When running xfs_repair on the >>>filesystem after I have moved the log to an external device the following >>>error occurs: >>> >>> >>>st3:~# xfs_repair -L -l /dev/sda4 /dev/sdc1 >>>Phase 1 - find and verify superblock... >>> >>>fatal error -- could not read superblock >>> >> >>Don't know if this is relevant, but this strace looks interesting: >> > > > OK - After looking at the strace I checked the _other_ superblocks. As I only > altered SB0, the other superblocks SB1+ still contains the old logstart > value. > > Wrote "logfile 0" to SB 0 - SB 15, and it all works! :) > > It this the way to do it, or am I missing something obvious? > That is the way to do it, the tools are more picky than they used to be about this. Which is why getting the facility built into the tools would help a lot - since it would do the fixup of all superblocks itself. Steve From owner-linux-xfs Thu Feb 3 09:54:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 09:54:47 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Hsieb003937 for ; Thu, 3 Feb 2005 09:54:44 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 97C2EFB446; Thu, 3 Feb 2005 18:54:43 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 18:54:43 +0100 From: Anders Saaby Organization: Cohaesio A/S To: Steve Lord Subject: Re: Question: Does XFS journal data or only metadata? Date: Thu, 3 Feb 2005 18:55:37 +0100 User-Agent: KMail/1.7.2 Cc: Nathan Scott , linux-xfs@oss.sgi.com References: <200502031005.57621.as@cohaesio.com> <200502031740.01081.as@cohaesio.com> <4202594B.3030204@xfs.org> In-Reply-To: <4202594B.3030204@xfs.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031855.37399.as@cohaesio.com> X-OriginalArrivalTime: 03 Feb 2005 17:54:43.0484 (UTC) FILETIME=[70EB0DC0:01C50A19] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4864 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs On Thursday 03 February 2005 18:03, Steve Lord wrote: > > > > OK - After looking at the strace I checked the _other_ superblocks. As I > > only altered SB0, the other superblocks SB1+ still contains the old > > logstart value. > > > > Wrote "logfile 0" to SB 0 - SB 15, and it all works! :) > > > > It this the way to do it, or am I missing something obvious? > > That is the way to do it, the tools are more picky than they used > to be about this. Which is why getting the facility built into > the tools would help a lot - since it would do the fixup of all > superblocks itself. > > Steve OK, that explains it. A tool would definetly be nice, but xfs_db works for me for now. :) - Thanks for you help everyone, you just made the coming weeks a _lot_ easier for me! -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Thu Feb 3 12:25:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 12:25:45 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13KPfx5016337 for ; Thu, 3 Feb 2005 12:25:42 -0800 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 j13LstUp016134 for ; Thu, 3 Feb 2005 13:54:55 -0800 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j13KPeR01329765; Thu, 3 Feb 2005 14:25:40 -0600 (CST) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id A38B94FDCA; Thu, 3 Feb 2005 14:25:40 -0600 (CST) To: Ben Myers Cc: linux-xfs@oss.sgi.com Subject: Re: Write event -> dm_read_invis? Date: Thu, 03 Feb 2005 14:25:40 -0600 From: Dean Roehrich Message-Id: <20050203202540.A38B94FDCA@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4865 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs >From: Ben Myers >Hi, > >I'm working on a small data migration app. I'm getting DM_EVENT_WRITE >events, responding with DM_RESP_CONTINUE, and wanting to immediately >turn a round and dm_read_invis() on that handle from de_offset to >de_length and spit it out (with some other info) towards my tape >drive. > >Can I assume that a dm_read_invis will get me only the change affected >by the write event i responded to? What behavior should I expect for >overlapping writes, and how can I tell when a write is finished and it's >ok to copy the data out to tape? The dm_read_invis will see what was written by the write(2), provided the write has occured. The write(2) won't actually happen until sometime after your call to dm_respond_event. Your data migration app cannot know when the write(2) (that goes with the DM_EVENT_WRITE) is finished. There's nothing in the DMAPI spec, anyway, that would provide for this--there's no such thing as DM_EVENT_POSTWRITE. If mirroring or snapshotting is what you want, then maybe a volume manager would be a better solution? Dean From owner-linux-xfs Thu Feb 3 15:50:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 15:50:49 -0800 (PST) Received: from ns1.networkiowa.com (ns1.networkiowa.com [209.234.64.192]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Noh5x027965 for ; Thu, 3 Feb 2005 15:50:46 -0800 Received: from dsl.78.136.networkiowa.com (dsl.78.136.networkiowa.com [209.234.78.136]) by ns1.networkiowa.com (8.13.1/8.13.1) with ESMTP id j13NoVcL024814; Thu, 3 Feb 2005 17:50:32 -0600 Subject: Re: Write event -> dm_read_invis? From: Ben Myers To: Dean Roehrich Cc: linux-xfs@oss.sgi.com In-Reply-To: <20050203202540.A38B94FDCA@chewtoy.americas.sgi.com> References: <20050203202540.A38B94FDCA@chewtoy.americas.sgi.com> Content-Type: text/plain Date: Thu, 03 Feb 2005 17:50:29 -0600 Message-Id: <1107474629.5512.49.camel@debian> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Freese-Notis-MailScanner-Information: Please contact the ISP for more information X-Freese-Notis-MailScanner: Found to be clean X-Freese-Notis-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.739, required 8, autolearn=not spam, ALL_TRUSTED -3.30, AWL 0.16, BAYES_00 -2.60) X-MailScanner-From: dative@raccoon.com X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4866 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dative@raccoon.com Precedence: bulk X-list: linux-xfs On Thu, 2005-02-03 at 14:25 -0600, Dean Roehrich wrote: > The dm_read_invis will see what was written by the write(2), provided the > write has occured. The write(2) won't actually happen until sometime after > your call to dm_respond_event. > > Your data migration app cannot know when the write(2) (that goes with the > DM_EVENT_WRITE) is finished. There's nothing in the DMAPI spec, anyway, that > would provide for this--there's no such thing as DM_EVENT_POSTWRITE. Pity. DM_EVENT_POSTWRITE is exactly what I'm looking for. How about dm_sync_by_handle()? If I respond with DM_RESP_CONTINUE and then immediately sync that file, won't I block until the write is finished? > If mirroring or snapshotting is what you want, then maybe a volume manager > would be a better solution? I'm hoping for something more along the lines of logging. Anyway. Thanks, Ben -- Ben Myers From owner-linux-xfs Thu Feb 3 16:01:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 16:01:33 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1401ViD029532 for ; Thu, 3 Feb 2005 16:01:32 -0800 Received: by wproxy.gmail.com with SMTP id 67so381488wri for ; Thu, 03 Feb 2005 16:01:26 -0800 (PST) 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:references; b=sbqysvQgeAP2Fdi4bmCd4ymlXZciOEMwA7Gx5cIheKXIT8x83dPxtXhIkpCg3XTG7ZUszW23xEpyQd4JdXvq/DmRZF2ml2Ypai6iWbM5sDku2FnpAXDR0wtiF5yMFZG3foRN2ch0Uu7rcuFEMXkLf7JNXbB0T7R+3plYiRORspE= Received: by 10.54.44.62 with SMTP id r62mr97420wrr; Thu, 03 Feb 2005 16:01:19 -0800 (PST) Received: by 10.54.2.40 with HTTP; Thu, 3 Feb 2005 16:00:28 -0800 (PST) Message-ID: <87f94c37050203160047d4f89d@mail.gmail.com> Date: Thu, 3 Feb 2005 19:00:28 -0500 From: Greg Freemyer Reply-To: Greg Freemyer To: Ben Myers Subject: Re: Write event -> dm_read_invis? Cc: Dean Roehrich , linux-xfs@oss.sgi.com In-Reply-To: <1107474629.5512.49.camel@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050203202540.A38B94FDCA@chewtoy.americas.sgi.com> <1107474629.5512.49.camel@debian> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4867 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg.freemyer@gmail.com Precedence: bulk X-list: linux-xfs On Thu, 03 Feb 2005 17:50:29 -0600, Ben Myers wrote: > On Thu, 2005-02-03 at 14:25 -0600, Dean Roehrich wrote: > > The dm_read_invis will see what was written by the write(2), provided the > > write has occured. The write(2) won't actually happen until sometime after > > your call to dm_respond_event. > > > > Your data migration app cannot know when the write(2) (that goes with the > > DM_EVENT_WRITE) is finished. There's nothing in the DMAPI spec, anyway, that > > would provide for this--there's no such thing as DM_EVENT_POSTWRITE. > > Pity. DM_EVENT_POSTWRITE is exactly what I'm looking for. How about > dm_sync_by_handle()? If I respond with DM_RESP_CONTINUE and then > immediately sync that file, won't I block until the write is finished? > > > If mirroring or snapshotting is what you want, then maybe a volume manager > > would be a better solution? > > I'm hoping for something more along the lines of logging. > If you can live with getting your log at the block level, then maybe you could look at how drbd does dirty block logging. IIRC, protocol-c ensures the log is built in the order that the blocks are written. This is particularily important if a database is using the disk. ie. a replay is transactionally valid at any point including a partial log reply. FYI: If you don't know, drbd ships the activity log to another computer which replays it. That way if the first computer/disk dies, the second computer can take over. Greg -- Greg Freemyer From owner-linux-xfs Thu Feb 3 16:50:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 16:50:44 -0800 (PST) Received: from smtp1.ActiveState.com (gw.activestate.com [209.17.183.249]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j140ohb1006073 for ; Thu, 3 Feb 2005 16:50:43 -0800 Received: from rock.activestate.com (rock.ActiveState.com [192.168.3.223]) by smtp1.ActiveState.com (8.12.10/8.12.10) with ESMTP id j140oZKX028738 for ; Thu, 3 Feb 2005 16:50:35 -0800 (envelope-from daves@activestate.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by rock.activestate.com (8.12.11/8.12.11) with ESMTP id j140oZuW018119 for ; Thu, 3 Feb 2005 16:50:35 -0800 (envelope-from daves@activestate.com) Message-ID: <4202C6DA.1060809@activestate.com> Date: Thu, 03 Feb 2005 16:50:34 -0800 From: David Sparks Reply-To: daves@activestate.com User-Agent: Mozilla Thunderbird 0.8 (X11/20040920) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: external log vs internal log and mkfs.xfs options X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4868 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daves@activestate.com Precedence: bulk X-list: linux-xfs I'm setting up a SAN with a 1TB partition and am seeking some advice. Previously when setting up servers, I would specify options to mkfs.xfs to lower the agcount and create a 32m log, ie for a 33GB partition: mkfs.xfs -d agcount=32 -l size=32m /dev/sda3 This was based on an article I read at: http://www-106.ibm.com/developerworks/linux/library/l-fs10.html More recently I've not bothered with those options because I read somewhere that the defaults are sane. (I've never noticed any difference either way) Are the mkfs.xfs defaults good for a 1TB partition? Regarding external logs, I've never formatted a XFS with an external log. From what I can gather (google, man pages), doing so is supposed to reduce disk head seeking hence performance is improved. Is anyone aware of any benchmarks that explore internal/external logs and sizes? My preference is for an internal log as that just simplifies things. Thanks! ds From owner-linux-xfs Thu Feb 3 16:56:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 16:57:01 -0800 (PST) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j140uwY4007691 for ; Thu, 3 Feb 2005 16:56:59 -0800 Received: from localhost (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 6A1488DE182 for ; Fri, 4 Feb 2005 08:56:56 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gusi.leathercollection.ph (Postfix) with ESMTP id 3886C88A66D for ; Fri, 4 Feb 2005 08:56:50 +0800 (PHT) Received: from musang.free.net.ph (musang.free.net.ph [192.168.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lawin.alabang.leathercollection.ph (Postfix) with ESMTP id 9078DA54F1B5 for ; Fri, 4 Feb 2005 08:56:49 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 679D16000AB; Fri, 4 Feb 2005 08:56:49 +0800 (PHT) Date: Fri, 4 Feb 2005 08:56:49 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: du vs. df inconsistency Message-ID: <20050204005649.GD4949@free.net.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at leathercollection.ph X-Virus-Status: Clean X-archive-position: 4869 X-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 On Thu, Feb 03, 2005 at 10:46:37AM -0500, Jameel Akari wrote: > I have already tried a xfs_fsr on /foo which has improved the extents > used by some files, but the apparent utilization didn't change. > > Anything else I can try before I dump the fs and make a new one? Have you tried running xfs_repair on the properly unmounted filesystem? A small disparity between du and df is expected and acceptable for filesystem overhead, but the disparity you're reporting is abnormally high, IMHO. My hunch is something's wrong with the filesystem, which xfs_repair will hopefully find. There's also xfs_check, just to make sure things are fine. If you could replicate the problem in a finite number of operations from a clean filesystem, I'm sure the XFS team would love to be able to replicate it in their laboratories for testing (they'll need your kernel version and some scripts, I presume) and, if possible, fixing. --> 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 Thu Feb 3 17:00:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 17:00:04 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j14101LL008475 for ; Thu, 3 Feb 2005 17:00:03 -0800 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 LAA20365; Fri, 4 Feb 2005 11:59:49 +1100 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 j140xkXE1945638; Fri, 4 Feb 2005 11:59:47 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j140xhp41946708; Fri, 4 Feb 2005 11:59:43 +1100 (EST) Date: Fri, 4 Feb 2005 11:59:43 +1100 From: Nathan Scott To: David Sparks Cc: linux-xfs@oss.sgi.com Subject: Re: external log vs internal log and mkfs.xfs options Message-ID: <20050204115943.E1943129@wobbly.melbourne.sgi.com> References: <4202C6DA.1060809@activestate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4202C6DA.1060809@activestate.com>; from daves@activestate.com on Thu, Feb 03, 2005 at 04:50:34PM -0800 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4870 X-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 On Thu, Feb 03, 2005 at 04:50:34PM -0800, David Sparks wrote: > I'm setting up a SAN with a 1TB partition and am seeking some advice. > > Previously when setting up servers, I would specify options to mkfs.xfs > to lower the agcount and create a 32m log, ie for a 33GB partition: > > mkfs.xfs -d agcount=32 -l size=32m /dev/sda3 > > This was based on an article I read at: > > http://www-106.ibm.com/developerworks/linux/library/l-fs10.html Aha, thats whos been telling people that! The article is a bit out of date now. > More recently I've not bothered with those options because I read > somewhere that the defaults are sane. (I've never noticed any > difference either way) Are the mkfs.xfs defaults good for a 1TB partition? Yes, should be just fine. In fact, from a quick check, current mkfs will create a 32 AG filesystem on a 1Terabyte device... # mkfs.xfs -N -dfile,size=1t,name=/dev/null meta-data=/dev/null isize=256 agcount=32, agsize=8388608 blks = sectsz=512 data = bsize=4096 blocks=268435456, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 cheers. -- Nathan From owner-linux-xfs Thu Feb 3 17:47:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 17:47:36 -0800 (PST) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j141lXrx011970 for ; Thu, 3 Feb 2005 17:47:33 -0800 Received: from localhost (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 0A93E8E1286 for ; Fri, 4 Feb 2005 09:47:32 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gusi.leathercollection.ph (Postfix) with ESMTP id A0C938DE182 for ; Fri, 4 Feb 2005 09:47:27 +0800 (PHT) Received: from musang.free.net.ph (musang.free.net.ph [192.168.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lawin.alabang.leathercollection.ph (Postfix) with ESMTP id 4DAF8A54F1B5 for ; Fri, 4 Feb 2005 09:47:27 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 0ED51600108; Fri, 4 Feb 2005 09:47:27 +0800 (PHT) Date: Fri, 4 Feb 2005 09:47:26 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: mkfs and mount Performance Tweaks (was: external log vs internal log and mkfs.xfs options) Message-ID: <20050204014726.GA4809@free.net.ph> Mail-Followup-To: Linux-XFS Mailing List References: <4202C6DA.1060809@activestate.com> <20050204115943.E1943129@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204115943.E1943129@wobbly.melbourne.sgi.com> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at leathercollection.ph X-Virus-Status: Clean X-archive-position: 4871 X-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 On Fri, Feb 04, 2005 at 11:59:43AM +1100, Nathan Scott wrote: > On Thu, Feb 03, 2005 at 04:50:34PM -0800, David Sparks wrote: > > I'm setting up a SAN with a 1TB partition and am seeking some > > advice. > > > > Previously when setting up servers, I would specify options to > > mkfs.xfs to lower the agcount and create a 32m log, ie for a 33GB > > partition: > > > > mkfs.xfs -d agcount=32 -l size=32m /dev/sda3 > > > > This was based on an article I read at: > > > > http://www-106.ibm.com/developerworks/linux/library/l-fs10.html > > Aha, thats whos been telling people that! The article is a bit out of > date now. I remember getting standard optimization tips -- not from the above article, I think it was from Steve Lord on this list or from the FAQ, but it's not there anymore -- that basically said create a filesystem using "-l size=32768b", and mount it using "logbufs=8,logbsize=32768". The metadata log size tweaks are the same as in the DeveloperWorks article, but I had not (until now) read about tweaking the agcount. If the article's out of date, does the XFS team have any optimization suggestions that are valid for the most recent version of XFS (in the kernel) and xfsprogs? Or should we just trust the defaults for that perfect balance between performance and reliability? Thanks in advance. --> 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 Thu Feb 3 18:04:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 18:04:52 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1424osv013126 for ; Thu, 3 Feb 2005 18:04:50 -0800 Received: from [10.0.0.2] (sandeen.net [209.173.210.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id AC30628BAFB; Thu, 3 Feb 2005 20:04:43 -0600 (CST) Message-ID: <4202D839.2090003@sgi.com> Date: Thu, 03 Feb 2005 20:04:41 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jameel Akari Cc: linux-xfs@oss.sgi.com Subject: Re: du vs. df inconsistency References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4872 X-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 Jameel Akari wrote: > Anything else I can try before I dump the fs and make a new one? Does the problem persist immediately after remounting the fs? -eric From owner-linux-xfs Thu Feb 3 19:14:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 19:14:06 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j143E2qF015991 for ; Thu, 3 Feb 2005 19:14:02 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j143E248015990 for linux-xfs@oss.sgi.com; Thu, 3 Feb 2005 19:14:02 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j143E0cl015975 for ; Thu, 3 Feb 2005 19:14:01 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j142qamZ014482; Thu, 3 Feb 2005 18:52:36 -0800 Date: Thu, 3 Feb 2005 18:52:36 -0800 Message-Id: <200502040252.j142qamZ014482@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 395] New: BUG: using smp_processor_id() in preemptible X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=395 Summary: BUG: using smp_processor_id() in preemptible Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: mike@udel.edu XFS in linux-2.6.11-rc2 Compiled kernel with various debug options (SMP kernel) Am receiving: BUG: using smp_processor_id() in preemptible [00000001] code: xfssyncd/2768 caller is xfs_log_force+0x2f/0xb0 [xfs] [] smp_processor_id+0xa3/0xc0 [] xfs_log_force+0x2f/0xb0 [xfs] [] xfs_log_force+0x2f/0xb0 [xfs] [] xfs_syncsub+0x58/0x380 [xfs] [] xfs_sync+0x25/0x30 [xfs] [] vfs_sync_worker+0x4a/0x50 [xfs] [] xfssyncd+0x13d/0x1c0 [xfs] [] xfssyncd+0x0/0x1c0 [xfs] [] kernel_thread_helper+0x5/0x10 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Feb 3 20:14:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Feb 2005 20:14:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j144E2WF018017 for ; Thu, 3 Feb 2005 20:14:02 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j144E2iN018016 for linux-xfs@oss.sgi.com; Thu, 3 Feb 2005 20:14:02 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j144E0Hf018001 for ; Thu, 3 Feb 2005 20:14:01 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j143HEeJ016445; Thu, 3 Feb 2005 19:17:14 -0800 Date: Thu, 3 Feb 2005 19:17:14 -0800 Message-Id: <200502040317.j143HEeJ016445@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 395] BUG: using smp_processor_id() in preemptible X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4874 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=395 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From nathans@sgi.com 2005-03-02 19:17 PDT ------- Fixed in 2.6.11-rc3. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Feb 4 00:08:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Feb 2005 00:08:43 -0800 (PST) Received: from redix.it (host49-169.pool8172.interbusiness.it [81.72.169.49]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1488cJS026391 for ; Fri, 4 Feb 2005 00:08:39 -0800 Received: (qmail 28960 invoked by uid 72); 4 Feb 2005 08:08:36 -0000 Received: by mail.redix.it (tmda-sendmail, from uid 72); Fri, 04 Feb 2005 09:08:36 +0100 (CET) Received: from 192.168.0.77 (SquirrelMail authenticated user roberto) by mail.redix.it:443 with HTTP; Fri, 4 Feb 2005 09:08:35 +0100 (CET) Message-ID: <65517.192.168.0.77.1107504515.squirrel@mail.redix.it:443> In-Reply-To: <4202D839.2090003@sgi.com> References: <4202D839.2090003@sgi.com> Date: Fri, 4 Feb 2005 09:08:35 +0100 (CET) Subject: Re: du vs. df inconsistency To: "Jameel Akari" Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Roberto X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4875 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roberto.trovo@redix.it Precedence: bulk X-list: linux-xfs > Jameel Akari wrote: > >> Anything else I can try before I dump the fs and make a new one? > > Does the problem persist immediately after remounting the fs? > > -eric > > > Yes, this could be an interesting test: I remember (some times ago) on this list a similar problem where a deleted files where still keep open by a daemon process: this led to df - du to disagree... But I've not enough info to say it's the same problem ... Kind regards, Roberto e-mail roberto.trovo [at] redix.it From owner-linux-xfs Fri Feb 4 05:14:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Feb 2005 05:14:07 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14DE347012014 for ; Fri, 4 Feb 2005 05:14:03 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j14DE3dK012013 for linux-xfs@oss.sgi.com; Fri, 4 Feb 2005 05:14:03 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14DE229011997 for ; Fri, 4 Feb 2005 05:14:02 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j14CMX0E010347; Fri, 4 Feb 2005 04:22:33 -0800 Date: Fri, 4 Feb 2005 04:22:33 -0800 Message-Id: <200502041222.j14CMX0E010347@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 395] BUG: using smp_processor_id() in preemptible X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4876 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=395 matthias.christian@tiscali.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Feb 4 07:46:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Feb 2005 07:46:47 -0800 (PST) Received: from poptart.bithose.com (poptart.bithose.com [204.97.176.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14FkiEW017643 for ; Fri, 4 Feb 2005 07:46:45 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.10/8.12.10) with ESMTP id j14FkUlp247844; Fri, 4 Feb 2005 10:46:30 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.10/8.12.10/Submit) with ESMTP id j14FkUgp247805; Fri, 4 Feb 2005 10:46:30 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Fri, 4 Feb 2005 10:46:29 -0500 (EST) From: Jameel Akari To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: du vs. df inconsistency In-Reply-To: <4202D839.2090003@sgi.com> Message-ID: References: <4202D839.2090003@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4877 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: linux-xfs On Thu, 3 Feb 2005, Eric Sandeen wrote: > Jameel Akari wrote: > >> Anything else I can try before I dump the fs and make a new one? > > Does the problem persist immediately after remounting the fs? Well, not really, but now we're worse off... mount: wrong fs type, bad option, bad superblock on /dev/sda5, or too many mounted file systems xfs_check spews this: $ sudo /usr/sbin/xfs_check /dev/sda5 agi unlinked bucket 1 is 143681 in ag 0 (inode=143681) agi unlinked bucket 4 is 174660 in ag 0 (inode=174660) agi unlinked bucket 49 is 181553 in ag 0 (inode=181553) agi unlinked bucket 57 is 174713 in ag 0 (inode=174713) agi unlinked bucket 3 is 23747 in ag 1 (inode=4218051) agi unlinked bucket 5 is 23749 in ag 1 (inode=4218053) agi unlinked bucket 25 is 28505 in ag 1 (inode=4222809) agi unlinked bucket 42 is 26218 in ag 1 (inode=4220522) agi unlinked bucket 18 is 1118290 in ag 3 (inode=13701202) agi unlinked bucket 51 is 1106931 in ag 3 (inode=13689843) agi unlinked bucket 9 is 137 in ag 4 (inode=16777353) agi unlinked bucket 14 is 142 in ag 4 (inode=16777358) agi unlinked bucket 22 is 119638 in ag 6 (inode=25285462) agi unlinked bucket 45 is 29741 in ag 6 (inode=25195565) agi unlinked bucket 17 is 81 in ag 7 (inode=29360209) agi unlinked bucket 34 is 250658 in ag 7 (inode=29610786) agi unlinked bucket 40 is 15720 in ag 7 (inode=29375848) agi unlinked bucket 54 is 11766 in ag 7 (inode=29371894) agi unlinked bucket 59 is 315 in ag 7 (inode=29360443) agi unlinked bucket 8 is 80712 in ag 8 (inode=33635144) agi unlinked bucket 53 is 81973 in ag 8 (inode=33636405) allocated inode 181553 has 0 link count link count mismatch for inode 143681 (name ?), nlink 0, counted 1 link count mismatch for inode 174660 (name ?), nlink 0, counted 1 allocated inode 174713 has 0 link count link count mismatch for inode 4218051 (name ?), nlink 0, counted 1 allocated inode 4218053 has 0 link count link count mismatch for inode 4220522 (name ?), nlink 0, counted 1 allocated inode 4222809 has 0 link count link count mismatch for inode 13689843 (name ?), nlink 0, counted 1 allocated inode 13701202 has 0 link count link count mismatch for inode 16777353 (name ?), nlink 0, counted 1 allocated inode 16777358 has 0 link count allocated inode 25285462 has 0 link count link count mismatch for inode 25195565 (name ?), nlink 0, counted 1 link count mismatch for inode 29360209 (name ?), nlink 0, counted 1 allocated inode 29371894 has 0 link count link count mismatch for inode 29375848 (name ?), nlink 0, counted 1 allocated inode 29360443 has 0 link count allocated inode 29610786 has 0 link count allocated inode 33636405 has 0 link count link count mismatch for inode 33635144 (name ?), nlink 0, counted 1 link count mismatch for inode 37748864 (name ?), nlink 8, counted 18 Anything I can do to fix it? Going to go warm up the tape drive in the meanwhile. -- #!/jameel/akari sleep 4800; make clean && make breakfast From owner-linux-xfs Fri Feb 4 07:51:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Feb 2005 07:51:16 -0800 (PST) Received: from poptart.bithose.com (poptart.bithose.com [204.97.176.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14FpERI018099 for ; Fri, 4 Feb 2005 07:51:15 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.10/8.12.10) with ESMTP id j14Fp2lp247868; Fri, 4 Feb 2005 10:51:02 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.10/8.12.10/Submit) with ESMTP id j14Fp1Jo247879; Fri, 4 Feb 2005 10:51:01 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Fri, 4 Feb 2005 10:51:01 -0500 (EST) From: Jameel Akari To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: du vs. df inconsistency In-Reply-To: Message-ID: References: <4202D839.2090003@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4878 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: linux-xfs > mount: wrong fs type, bad option, bad superblock on /dev/sda5, > or too many mounted file systems Oh, and these wonderful kernel messages: Feb 4 10:54:01 alb-ndm kernel: xfs_unmount: xfs_ibusy says error/16 Feb 4 10:54:01 alb-ndm kernel: XFS unmount got error 16 Feb 4 10:54:01 alb-ndm kernel: linvfs_put_super: vfsp/0xd7861fa0 left dangling! Feb 4 10:54:01 alb-ndm kernel: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... Feb 4 10:56:32 alb-ndm kernel: XFS: Filesystem sd(8,5) has duplicate UUID - can't mount Feb 4 10:57:05 alb-ndm kernel: XFS: Filesystem sd(8,5) has duplicate UUID - can't mount Feb 4 11:04:37 alb-ndm kernel: XFS: Filesystem sd(8,5) has duplicate UUID - can't mount This is kernel 2.4.18 w/ XFS1.1. Kernel upgrade not an (immediate) option. > > xfs_check spews this: > $ sudo /usr/sbin/xfs_check /dev/sda5 > agi unlinked bucket 1 is 143681 in ag 0 (inode=143681) > agi unlinked bucket 4 is 174660 in ag 0 (inode=174660) > agi unlinked bucket 49 is 181553 in ag 0 (inode=181553) > agi unlinked bucket 57 is 174713 in ag 0 (inode=174713) > agi unlinked bucket 3 is 23747 in ag 1 (inode=4218051) > agi unlinked bucket 5 is 23749 in ag 1 (inode=4218053) > agi unlinked bucket 25 is 28505 in ag 1 (inode=4222809) > agi unlinked bucket 42 is 26218 in ag 1 (inode=4220522) > agi unlinked bucket 18 is 1118290 in ag 3 (inode=13701202) > agi unlinked bucket 51 is 1106931 in ag 3 (inode=13689843) > agi unlinked bucket 9 is 137 in ag 4 (inode=16777353) > agi unlinked bucket 14 is 142 in ag 4 (inode=16777358) > agi unlinked bucket 22 is 119638 in ag 6 (inode=25285462) > agi unlinked bucket 45 is 29741 in ag 6 (inode=25195565) > agi unlinked bucket 17 is 81 in ag 7 (inode=29360209) > agi unlinked bucket 34 is 250658 in ag 7 (inode=29610786) > agi unlinked bucket 40 is 15720 in ag 7 (inode=29375848) > agi unlinked bucket 54 is 11766 in ag 7 (inode=29371894) > agi unlinked bucket 59 is 315 in ag 7 (inode=29360443) > agi unlinked bucket 8 is 80712 in ag 8 (inode=33635144) > agi unlinked bucket 53 is 81973 in ag 8 (inode=33636405) > allocated inode 181553 has 0 link count > link count mismatch for inode 143681 (name ?), nlink 0, counted 1 > link count mismatch for inode 174660 (name ?), nlink 0, counted 1 > allocated inode 174713 has 0 link count > link count mismatch for inode 4218051 (name ?), nlink 0, counted 1 > allocated inode 4218053 has 0 link count > link count mismatch for inode 4220522 (name ?), nlink 0, counted 1 > allocated inode 4222809 has 0 link count > link count mismatch for inode 13689843 (name ?), nlink 0, counted 1 > allocated inode 13701202 has 0 link count > link count mismatch for inode 16777353 (name ?), nlink 0, counted 1 > allocated inode 16777358 has 0 link count > allocated inode 25285462 has 0 link count > link count mismatch for inode 25195565 (name ?), nlink 0, counted 1 > link count mismatch for inode 29360209 (name ?), nlink 0, counted 1 > allocated inode 29371894 has 0 link count > link count mismatch for inode 29375848 (name ?), nlink 0, counted 1 > allocated inode 29360443 has 0 link count > allocated inode 29610786 has 0 link count > allocated inode 33636405 has 0 link count > link count mismatch for inode 33635144 (name ?), nlink 0, counted 1 > link count mismatch for inode 37748864 (name ?), nlink 8, counted 18 > > > Anything I can do to fix it? Going to go warm up the tape drive in the > meanwhile. > > -- > #!/jameel/akari > sleep 4800; > make clean && make breakfast > > > -- #!/jameel/akari sleep 4800; make clean && make breakfast From owner-linux-xfs Fri Feb 4 08:11:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Feb 2005 08:11:56 -0800 (PST) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14GBpI5018993 for ; Fri, 4 Feb 2005 08:11:52 -0800 Received: from filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) by relay02.roc.ny.frontiernet.net (Postfix) with ESMTP id F0541FFDE; Fri, 4 Feb 2005 16:11:50 +0000 (UTC) Received: from relay02.roc.ny.frontiernet.net ([66.133.131.35]) by filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) (amavisd-new, port 10024) with LMTP id 31154-06-90; Fri, 4 Feb 2005 16:11:50 +0000 (UTC) Received: from [192.168.1.65] (67-137-96-87.dsl2.brv.mn.frontiernet.net [67.137.96.87]) by relay02.roc.ny.frontiernet.net (Postfix) with ESMTP id 45682FFEE; Fri, 4 Feb 2005 16:11:39 +0000 (UTC) Message-ID: <42039EBD.3010001@xfs.org> Date: Fri, 04 Feb 2005 10:11:41 -0600 From: Stephen Lord User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jameel Akari Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: du vs. df inconsistency References: <4202D839.2090003@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter02.roc.ny.frontiernet.net X-Virus-Status: Clean X-archive-position: 4879 X-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 Jameel Akari wrote: > >> mount: wrong fs type, bad option, bad superblock on /dev/sda5, >> or too many mounted file systems > > > Oh, and these wonderful kernel messages: > Feb 4 10:54:01 alb-ndm kernel: xfs_unmount: xfs_ibusy says error/16 > Feb 4 10:54:01 alb-ndm kernel: XFS unmount got error 16 > Feb 4 10:54:01 alb-ndm kernel: linvfs_put_super: vfsp/0xd7861fa0 left > dangling! > Feb 4 10:54:01 alb-ndm kernel: VFS: Busy inodes after unmount. > Self-destruct in 5 seconds. Have a nice day... > Feb 4 10:56:32 alb-ndm kernel: XFS: Filesystem sd(8,5) has duplicate > UUID - can't mount > Feb 4 10:57:05 alb-ndm kernel: XFS: Filesystem sd(8,5) has duplicate > UUID - can't mount > Feb 4 11:04:37 alb-ndm kernel: XFS: Filesystem sd(8,5) has duplicate > UUID - can't mount > > This is kernel 2.4.18 w/ XFS1.1. Kernel upgrade not an (immediate) option. > The unmount failed beause xfs thought something was still busy, but the kernel did not. Looks like a reference count leak somewhere in the old kernel. If you reboot and run repair you should be ok. Those unlinked bucket messages refer to unlinked inodes which should have been freed at some point. They probably still have a reference count inside xfs which means they did not get freed. This is where your space has gone. Steve From owner-linux-xfs Fri Feb 4 08:26:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Feb 2005 08:26:25 -0800 (PST) Received: from poptart.bithose.com (poptart.bithose.com [204.97.176.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14GQNvD023049 for ; Fri, 4 Feb 2005 08:26:24 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.10/8.12.10) with ESMTP id j14GQ9lp248024; Fri, 4 Feb 2005 11:26:10 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.10/8.12.10/Submit) with ESMTP id j14GQ90A247886; Fri, 4 Feb 2005 11:26:09 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Fri, 4 Feb 2005 11:26:08 -0500 (EST) From: Jameel Akari To: Stephen Lord cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: du vs. df inconsistency In-Reply-To: <42039EBD.3010001@xfs.org> Message-ID: References: <4202D839.2090003@sgi.com> <42039EBD.3010001@xfs.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4880 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: linux-xfs >> Feb 4 10:54:01 alb-ndm kernel: VFS: Busy inodes after unmount. >> Self-destruct in 5 seconds. Have a nice day... >> Feb 4 10:56:32 alb-ndm kernel: XFS: Filesystem sd(8,5) has duplicate UUID >> - can't mount > > The unmount failed beause xfs thought something was still busy, but the > kernel did not. Looks like a reference count leak somewhere in the old > kernel. That's what I figured. I'll definitely move this to the top of "reasons to upgrade already!" pile. (I'd do it tomorrow if there were some XFS-patched RHEL kernels ready to go... ;) > If you reboot and run repair you should be ok. I found some mention of this on the mailing list where it was suggested to `mount -o nouuid`. This worked for me - the filesystem recovered itself, and I see the freed space now. > Those unlinked bucket messages refer to unlinked inodes which should > have been freed at some point. They probably still have a reference > count inside xfs which means they did not get freed. This is where > your space has gone. Well, now I know more about XFS internals than I did before. Always has to learned the hard way... Thanks for your replies. -- #!/jameel/akari sleep 4800; make clean && make breakfast From owner-linux-xfs Fri Feb 4 08:55:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Feb 2005 08:55:31 -0800 (PST) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14GtTfL024170 for ; Fri, 4 Feb 2005 08:55:29 -0800 Received: from filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) by relay02.roc.ny.frontiernet.net (Postfix) with ESMTP id D821410299; Fri, 4 Feb 2005 16:55:28 +0000 (UTC) Received: from relay02.roc.ny.frontiernet.net ([66.133.131.35]) by filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) (amavisd-new, port 10024) with LMTP id 28518-34-37; Fri, 4 Feb 2005 16:55:28 +0000 (UTC) Received: from [192.168.1.65] (67-137-96-87.dsl2.brv.mn.frontiernet.net [67.137.96.87]) by relay02.roc.ny.frontiernet.net (Postfix) with ESMTP id 8A4AC1020C; Fri, 4 Feb 2005 16:55:23 +0000 (UTC) Message-ID: <4203A8FD.2040002@xfs.org> Date: Fri, 04 Feb 2005 10:55:25 -0600 From: Stephen Lord User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jameel Akari Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: du vs. df inconsistency References: <4202D839.2090003@sgi.com> <42039EBD.3010001@xfs.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter02.roc.ny.frontiernet.net X-Virus-Status: Clean X-archive-position: 4881 X-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 Jameel Akari wrote: > >>> Feb 4 10:54:01 alb-ndm kernel: VFS: Busy inodes after unmount. >>> Self-destruct in 5 seconds. Have a nice day... >>> Feb 4 10:56:32 alb-ndm kernel: XFS: Filesystem sd(8,5) has duplicate >>> UUID - can't mount >> >> >> The unmount failed beause xfs thought something was still busy, but the >> kernel did not. Looks like a reference count leak somewhere in the old >> kernel. > > > That's what I figured. I'll definitely move this to the top of "reasons > to upgrade already!" pile. (I'd do it tomorrow if there were some > XFS-patched RHEL kernels ready to go... ;) > >> If you reboot and run repair you should be ok. > > > I found some mention of this on the mailing list where it was suggested > to `mount -o nouuid`. This worked for me - the filesystem recovered > itself, and I see the freed space now. > You still have a dangling dead mount inside the kernel, a reboot at an opportune moment will clean that up. Steve From owner-linux-xfs Fri Feb 4 08:59:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Feb 2005 08:59:35 -0800 (PST) Received: from mail.cambrianventures.com (206.173.21.243.ptr.us.xo.net [206.173.21.243]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j14GxXcW025388 for ; Fri, 4 Feb 2005 08:59:33 -0800 Received: (qmail 6013 invoked from network); 4 Feb 2005 16:57:31 -0000 Received: from unknown (HELO wds19.cosmixcorp.com) (206.173.21.85) by ns0.cambrianventures.com with SMTP; 4 Feb 2005 16:57:31 -0000 Subject: Re: ls: reading directory .: Input/output error From: Douglass Judd To: Douglass Judd Cc: linux-xfs@oss.sgi.com In-Reply-To: <1106941376.13349.322.camel@sedna.cambrianventures.com> References: <1106941376.13349.322.camel@sedna.cambrianventures.com> Content-Type: text/plain Message-Id: <1107535982.26459.86.camel@sedna.cambrianventures.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Fri, 04 Feb 2005 08:53:02 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4882 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doug@cosmixcorp.com Precedence: bulk X-list: linux-xfs Unfortunately, this problem keeps happening. I think I'm going to throw in the towel and roll back to ext3. If it happens again with ext3, I'll post. - Doug On Fri, 2005-01-28 at 11:42, Douglass Judd wrote: > Hello, > > I'm using XFS on a large 8 disk RAID-5 partition. I was running a MySQL > process that was doing some random access (reads and writes) on a couple > of files. I then kicked off an scp job that was copying a few gigabytes > worth of data in about 5000 files to this machine when I lost the > filesystem. Any attempt to read resulted in input/output errors: > > [doug@wds12 webcache]$ ls > ls: reading directory .: Input/output error > > Something similar happened before, so I upgraded to the 2.6.10 kernel > after reading the thread "RE: Unknown Issue" > (http://oss.sgi.com/archives/linux-xfs/2004-12/msg00048.html) hoping > that it would solve my problems. > > The 3dm daemon reported no errors with the disk array and > /var/log/messages had the following lines in it: > > Jan 28 10:47:40 wds12 kernel: xfs_force_shutdown(sda1,0x8) called from > line 1091 of file fs/xfs/xfs_trans.c. Return address = > 0xffffffff8021cb48 > Jan 28 10:47:40 wds12 kernel: Filesystem "sda1": Corruption of in-memory > data detected. Shutting down filesystem: sda1 > Jan 28 10:47:40 wds12 kernel: Please umount the filesystem, and rectify > the problem(s) > > Here's my system configuration: > > Hardware: > Tyan S2882G3NR Thunder K8S Pro Motherboard > 2 - AMD Opteron processors > 3ware 9500S-8 RAID Controller > 8 - Western Digital 2500SD 250GB disk drives > > OS: 2.6.10 Kernel, built with these options ... > - Processor Family: AMD Opteron/Athalon64 > - Symmetric multi-processing support > - Preemptible kernel > > I ran xfs_check and here's what it reported: > > [root@wds12 log]# xfs_check /dev/sda1 > bad format 2 for inode 1208 type 0 > bad format 2 for inode 1209 type 0 > bad format 2 for inode 1210 type 0 > bad format 2 for inode 1211 type 0 > bad format 2 for inode 1212 type 0 > bad format 2 for inode 1213 type 0 > bad format 2 for inode 1214 type 0 > bad format 2 for inode 1215 type 0 > ir_freecount/free mismatch, inode chunk 0/1152, freecount 64 nfree 56 > bad format 2 for inode 268436760 type 0 > bad format 2 for inode 268436761 type 0 > bad format 2 for inode 268436762 type 0 > bad format 2 for inode 268436763 type 0 > bad format 2 for inode 268436767 type 0 > ir_freecount/free mismatch, inode chunk 1/1248, freecount 52 nfree 47 > bad format 2 for inode 268454488 type 0 > bad format 2 for inode 268454489 type 0 > bad format 2 for inode 268454490 type 0 > bad format 2 for inode 268454491 type 0 > bad format 2 for inode 268454492 type 0 > bad format 2 for inode 268454494 type 0 > bad format 2 for inode 268454495 type 0 > ir_freecount/free mismatch, inode chunk 1/18976, freecount 64 nfree 57 > bad format 2 for inode 536872216 type 0 > bad format 2 for inode 536872217 type 0 > bad format 2 for inode 536872218 type 0 > bad format 2 for inode 536872219 type 0 > bad format 2 for inode 536872220 type 0 > bad format 2 for inode 536872221 type 0 > bad format 2 for inode 536872222 type 0 > bad format 2 for inode 536872223 type 0 > ir_freecount/free mismatch, inode chunk 2/1248, freecount 8 nfree 0 > bad format 2 for inode 536889880 type 0 > bad format 2 for inode 536889881 type 0 > bad format 2 for inode 536889883 type 0 > bad format 2 for inode 536889886 type 0 > bad format 2 for inode 536889887 type 0 > ir_freecount/free mismatch, inode chunk 2/18912, freecount 64 nfree 59 > bad format 2 for inode 805325336 type 0 > bad format 2 for inode 805325337 type 0 > bad format 2 for inode 805325338 type 0 > bad format 2 for inode 805325339 type 0 > bad format 2 for inode 805325340 type 0 > bad format 2 for inode 805325341 type 0 > bad format 2 for inode 805325342 type 0 > bad format 2 for inode 805325343 type 0 > ir_freecount/free mismatch, inode chunk 3/18912, freecount 64 nfree 56 > bad format 2 for inode 1073743128 type 0 > bad format 2 for inode 1073743129 type 0 > bad format 2 for inode 1073743130 type 0 > bad format 2 for inode 1073743131 type 0 > bad format 2 for inode 1073743132 type 0 > bad format 2 for inode 1073743133 type 0 > bad format 2 for inode 1073743134 type 0 > bad format 2 for inode 1073743135 type 0 > ir_freecount/free mismatch, inode chunk 4/1248, freecount 64 nfree 56 > bad format 2 for inode 1073760824 type 0 > bad format 2 for inode 1073760825 type 0 > bad format 2 for inode 1073760826 type 0 > bad format 2 for inode 1073760827 type 0 > ir_freecount/free mismatch, inode chunk 4/18944, freecount 64 nfree 60 > bad format 2 for inode 1342178584 type 0 > bad format 2 for inode 1342178585 type 0 > bad format 2 for inode 1342178586 type 0 > bad format 2 for inode 1342178587 type 0 > bad format 2 for inode 1342178588 type 0 > bad format 2 for inode 1342178589 type 0 > bad format 2 for inode 1342178590 type 0 > bad format 2 for inode 1342178591 type 0 > ir_freecount/free mismatch, inode chunk 5/1248, freecount 59 nfree 51 > bad format 2 for inode 1342196280 type 0 > bad format 2 for inode 1342196281 type 0 > bad format 2 for inode 1342196282 type 0 > bad format 2 for inode 1342196283 type 0 > bad format 2 for inode 1342196284 type 0 > bad format 2 for inode 1342196285 type 0 > bad format 2 for inode 1342196286 type 0 > bad format 2 for inode 1342196287 type 0 > ir_freecount/free mismatch, inode chunk 5/18944, freecount 64 nfree 56 > bad format 2 for inode 1610614011 type 0 > bad format 2 for inode 1610614012 type 0 > bad format 2 for inode 1610614013 type 0 > bad format 2 for inode 1610614014 type 0 > ir_freecount/free mismatch, inode chunk 6/1216, freecount 64 nfree 60 > bad format 2 for inode 1610631704 type 0 > bad format 2 for inode 1610631705 type 0 > bad format 2 for inode 1610631706 type 0 > bad format 2 for inode 1610631707 type 0 > bad format 2 for inode 1610631708 type 0 > bad format 2 for inode 1610631709 type 0 > bad format 2 for inode 1610631710 type 0 > bad format 2 for inode 1610631711 type 0 > ir_freecount/free mismatch, inode chunk 6/18nk count > allocated inode 1213 has 0 link count > allocated inode 1214 has 0 link count > allocated inode 1215 has 0 link count > allocated inode 268436760 has 0 link count > allocated inode 268436761 has 0 link count > allocated inode 268436762 has 0 link count > allocated inode 268436763 has 0 link count > [... 150 lines like this ...] > > I haven't run xfs_repair yet. Is there anything more I can do to > diagnose this problem? > > - Doug > > P.S. I'm here in Mountain View, CA so if someone want's to swing by and > have a look, feel free! :) > > From owner-linux-xfs Fri Feb 4 09:05:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Feb 2005 09:05:33 -0800 (PST) Received: from nirmala.opentrend.net (nirmala.opentrend.net [65.39.131.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14H5SmE026172 for ; Fri, 4 Feb 2005 09:05:28 -0800 Received: from localhost (localhost [127.0.0.1]) by nirmala.opentrend.net (Postfix) with ESMTP id 713D7FE3F for ; Fri, 4 Feb 2005 12:02:34 -0500 (EST) Received: from nirmala.opentrend.net ([127.0.0.1]) by localhost (nirmala.opentrend.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07273-01-13 for ; Fri, 4 Feb 2005 12:02:31 -0500 (EST) Received: by nirmala.opentrend.net (Postfix, from userid 1003) id 5B38BFE3A; Fri, 4 Feb 2005 12:02:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nirmala.opentrend.net (Postfix) with ESMTP id 58C1EFE30 for ; Fri, 4 Feb 2005 17:02:31 +0000 (GMT) Date: Fri, 4 Feb 2005 17:02:31 +0000 (GMT) From: Robert Brockway To: linux-xfs@oss.sgi.com Subject: Re: du vs. df inconsistency In-Reply-To: <65517.192.168.0.77.1107504515.squirrel@mail.redix.it:443> Message-ID: <20050204165531.V319@nirmala.opentrend.net> References: <4202D839.2090003@sgi.com> <65517.192.168.0.77.1107504515.squirrel@mail.redix.it:443> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: amavisd-new at opentrend.net X-Virus-Status: Clean X-archive-position: 4883 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rbrockway@opentrend.net Precedence: bulk X-list: linux-xfs On Fri, 4 Feb 2005, Roberto wrote: > Yes, this could be an interesting test: I remember (some times ago) on > this list a similar problem where a deleted files where still keep open by > a daemon process: this led to df - du to disagree... > > But I've not enough info to say it's the same problem ... The correct behaviour for a filesystem on Unix is for the kernel to hold on to the pointer to the file while it is still being kept open by a process even if the file has had its link count reduced to zero (ie, deleted). The other day I accidentally deleted a tar file I was compressing (with bzip2). This was on an xfs filesystem too. I didn't worry (no need to pull it from backups) as bzip2 happily completed the compression. After it had finished it told me its attempt to remove the tar file failed. I would only have had a problem if I had killed the bzip2 process. Getting back to the original poster, it is well known that differences betweeen du and df output can be a result of holes in a file. I have seen this with empty swap files and I'm not necessarily surprised if a database file is exhibiting this behaviour. Cheers, Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (http://www.spi-inc.org) From owner-linux-xfs Fri Feb 4 09:19:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Feb 2005 09:19:58 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j14HJthr026857 for ; Fri, 4 Feb 2005 09:19:55 -0800 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 j14InGGU012442 for ; Fri, 4 Feb 2005 10:49:17 -0800 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j14HJsR01390087; Fri, 4 Feb 2005 11:19:54 -0600 (CST) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id E625C4FDCA; Fri, 4 Feb 2005 11:19:53 -0600 (CST) To: Ben Myers Cc: linux-xfs@oss.sgi.com Subject: Re: Write event -> dm_read_invis? Date: Fri, 04 Feb 2005 11:19:53 -0600 From: Dean Roehrich Message-Id: <20050204171953.E625C4FDCA@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4884 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs >From: Ben Myers >On Thu, 2005-02-03 at 14:25 -0600, Dean Roehrich wrote: >> The dm_read_invis will see what was written by the write(2), provided the >> write has occured. The write(2) won't actually happen until sometime after >> your call to dm_respond_event. >> >> Your data migration app cannot know when the write(2) (that goes with the >> DM_EVENT_WRITE) is finished. There's nothing in the DMAPI spec, anyway, tha >t >> would provide for this--there's no such thing as DM_EVENT_POSTWRITE. > >Pity. DM_EVENT_POSTWRITE is exactly what I'm looking for. How about >dm_sync_by_handle()? If I respond with DM_RESP_CONTINUE and then >immediately sync that file, won't I block until the write is finished? There's a user thread in the kernel, attempting to execute a write(2). That thread was temporarily caught in the dmapi queues, and you've now released it with dm_respond_event. Now that thread is going to continue on to the filesystem where some I/O will occur. This isn't about getting the data sync'd--it's about waiting long enough for that thread to back itself out of the dmapi queues and reacquire locks and get back into the filesystem to do some I/O. >> If mirroring or snapshotting is what you want, then maybe a volume manager >> would be a better solution? > >I'm hoping for something more along the lines of logging. Logging of the contents of every write? Dean From owner-linux-xfs Sun Feb 6 14:34:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Feb 2005 14:34:04 -0800 (PST) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16MY06E029045 for ; Sun, 6 Feb 2005 14:34:01 -0800 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j16MXpBd012827; Mon, 7 Feb 2005 09:33:51 +1100 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j16MXo1O012825; Mon, 7 Feb 2005 09:33:50 +1100 Date: Mon, 7 Feb 2005 09:33:50 +1100 From: Nathan Scott Message-Id: <200502062233.j16MXo1O012825@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: TAKE 929309 - releasepage fix X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4885 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Prevent releasepage from releasing pages early, while they still have delayed allocate buffers. Affects filesystem blocksizes smaller than the pagesize only. Date: Mon Feb 7 09:31:59 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch@engr.sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:21409a linux-2.6/xfs_aops.c - 1.83 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.83&r2=text&tr2=1.82&f=h linux-2.4/xfs_aops.c - 1.87 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.87&r2=text&tr2=1.86&f=h From owner-linux-xfs Sun Feb 6 15:02:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Feb 2005 15:02:59 -0800 (PST) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j16N2uCj030361 for ; Sun, 6 Feb 2005 15:02:57 -0800 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j16N2m5Q013278; Mon, 7 Feb 2005 10:02:48 +1100 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j16MM4DD012588; Mon, 7 Feb 2005 09:22:04 +1100 Date: Mon, 7 Feb 2005 09:22:04 +1100 From: Nathan Scott Message-Id: <200502062222.j16MM4DD012588@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: TAKE 925910 - fix xfs_freeze X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4886 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Reinstate missing frozen check on write, fixes snapshots and xfs_freeze. Date: Mon Feb 7 09:20:13 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch@engr.sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:21407a linux-2.6/xfs_lrw.c - 1.220 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.220&r2=text&tr2=1.219&f=h From owner-linux-xfs Mon Feb 7 07:38:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 07:38:36 -0800 (PST) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17FcYWY026523 for ; Mon, 7 Feb 2005 07:38:35 -0800 Received: from [134.29.32.1] (j3gum-3.ITS.MNSU.EDU [134.29.32.1]) by mail.mnsu.edu (8.12.11/8.12.11) with ESMTP id j17FcTFX004644 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Feb 2005 09:38:29 -0600 Message-ID: <42078B74.2080306@mnsu.edu> Date: Mon, 07 Feb 2005 09:38:28 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: linux-2.6.11-rc3: XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4887 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs I'm sorry for this truncated report... but it's all I've got. If you need .config or system configuration, etc. let me know and I'll send'em ASAP. I don't believe this is hardware related; ide-smart shows all fine. From dmesg: xfs_da_do_buf: bno 8388608 dir: inode 117526252 Filesystem "hda4": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/x fs/xfs_da_btree.c. Caller 0xc01bda27 [] xfs_da_do_buf+0x65c/0x7b0 [] xfs_da_read_buf+0x47/0x60 [] __alloc_pages+0x2ad/0x3d0 [] cache_grow+0xe2/0x150 [] xfs_da_read_buf+0x47/0x60 [] xfs_da_node_lookup_int+0x7e/0x320 [] xfs_da_node_lookup_int+0x7e/0x320 [] xfs_dir2_node_lookup+0x36/0xa0 [] xfs_dir2_lookup+0xf7/0x110 [] xfs_ichgtime+0xf8/0xfa [] xfs_readlink+0x96/0x2c0 [] xfs_dir_lookup_int+0x38/0x100 [] xfs_iaccess+0xc2/0x1c0 [] xfs_lookup+0x4d/0x90 [] linvfs_lookup+0x4e/0x80 [] real_lookup+0xae/0xd0 [] do_lookup+0x7e/0x90 [] link_path_walk+0x722/0xd50 [] path_lookup+0x7b/0x130 [] __user_walk+0x2f/0x60 [] vfs_stat+0x1d/0x50 [] sys_stat64+0x12/0x30 [] syscall_call+0x7/0xb xfs_da_do_buf: bno 8388608 dir: inode 117526252 Filesystem "hda4": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/x fs/xfs_da_btree.c. Caller 0xc01bda27 [] xfs_da_do_buf+0x65c/0x7b0 [] xfs_da_read_buf+0x47/0x60 [] __alloc_pages+0x2ad/0x3d0 [] cache_grow+0xe2/0x150 [] xfs_da_read_buf+0x47/0x60 [] xfs_da_node_lookup_int+0x7e/0x320 [] xfs_da_node_lookup_int+0x7e/0x320 [] xfs_dir2_node_lookup+0x36/0xa0 [] xfs_dir2_lookup+0xf7/0x110 [] xfs_ichgtime+0xf8/0xfa [] xfs_readlink+0x96/0x2c0 [] xfs_dir_lookup_int+0x38/0x100 [] xfs_iaccess+0xc2/0x1c0 [] xfs_lookup+0x4d/0x90 [] linvfs_lookup+0x4e/0x80 [] real_lookup+0xae/0xd0 [] do_lookup+0x7e/0x90 [] link_path_walk+0x722/0xd50 [] path_lookup+0x7b/0x130 [] __user_walk+0x2f/0x60 [] vfs_stat+0x1d/0x50 [] sys_stat64+0x12/0x30 [] syscall_call+0x7/0xb From syslog: [xfs_da_do_buf+1628/1968] xfs_da_do_buf+0x65c/0x7b0 [xfs_da_read_buf+71/96] xfs_da_read_buf+0x47/0x60 [__alloc_pages+685/976] __alloc_pages+0x2ad/0x3d0 [cache_grow+226/336] cache_grow+0xe2/0x150 [xfs_da_read_buf+71/96] xfs_da_read_buf+0x47/0x60 [xfs_da_node_lookup_int+126/800] xfs_da_node_lookup_int+0x7e/0x320 [xfs_da_node_lookup_int+126/800] xfs_da_node_lookup_int+0x7e/0x320 [xfs_dir2_node_lookup+54/160] xfs_dir2_node_lookup+0x36/0xa0 [xfs_dir2_lookup+247/272] xfs_dir2_lookup+0xf7/0x110 [xfs_ichgtime+248/250] xfs_ichgtime+0xf8/0xfa [xfs_readlink+150/704] xfs_readlink+0x96/0x2c0 [xfs_dir_lookup_int+56/256] xfs_dir_lookup_int+0x38/0x100 [xfs_iaccess+194/448] xfs_iaccess+0xc2/0x1c0 [xfs_lookup+77/144] xfs_lookup+0x4d/0x90 [linvfs_lookup+78/128] linvfs_lookup+0x4e/0x80 [real_lookup+174/208] real_lookup+0xae/0xd0 [do_lookup+126/144] do_lookup+0x7e/0x90 [link_path_walk+1826/3408] link_path_walk+0x722/0xd50 [path_lookup+123/304] path_lookup+0x7b/0x130 [__user_walk+47/96] __user_walk+0x2f/0x60 [vfs_stat+29/80] vfs_stat+0x1d/0x50 [sys_stat64+18/48] sys_stat64+0x12/0x30 [syscall_call+7/11] syscall_call+0x7/0xb [xfs_da_do_buf+1628/1968] xfs_da_do_buf+0x65c/0x7b0 [xfs_da_read_buf+71/96] xfs_da_read_buf+0x47/0x60 [__alloc_pages+685/976] __alloc_pages+0x2ad/0x3d0 [cache_grow+226/336] cache_grow+0xe2/0x150 [xfs_da_read_buf+71/96] xfs_da_read_buf+0x47/0x60 [xfs_da_node_lookup_int+126/800] xfs_da_node_lookup_int+0x7e/0x320 [xfs_da_node_lookup_int+126/800] xfs_da_node_lookup_int+0x7e/0x320 [xfs_dir2_node_lookup+54/160] xfs_dir2_node_lookup+0x36/0xa0 [xfs_dir2_lookup+247/272] xfs_dir2_lookup+0xf7/0x110 [xfs_ichgtime+248/250] xfs_ichgtime+0xf8/0xfa [xfs_readlink+150/704] xfs_readlink+0x96/0x2c0 [xfs_dir_lookup_int+56/256] xfs_dir_lookup_int+0x38/0x100 [xfs_iaccess+194/448] xfs_iaccess+0xc2/0x1c0 [xfs_lookup+77/144] xfs_lookup+0x4d/0x90 [linvfs_lookup+78/128] linvfs_lookup+0x4e/0x80 [real_lookup+174/208] real_lookup+0xae/0xd0 [do_lookup+126/144] do_lookup+0x7e/0x90 [link_path_walk+1826/3408] link_path_walk+0x722/0xd50 [path_lookup+123/304] path_lookup+0x7b/0x130 [__user_walk+47/96] __user_walk+0x2f/0x60 [vfs_stat+29/80] vfs_stat+0x1d/0x50 [sys_stat64+18/48] sys_stat64+0x12/0x30 [syscall_call+7/11] syscall_call+0x7/0xb -- jeffrey hundstad From owner-linux-xfs Mon Feb 7 08:12:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 08:12:10 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17GC7FR028325 for ; Mon, 7 Feb 2005 08:12:08 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 142D6FB455; Mon, 7 Feb 2005 17:12:06 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Feb 2005 17:12:05 +0100 From: Anders Saaby Organization: Cohaesio A/S To: "Jeffrey E. Hundstad" Subject: Re: linux-2.6.11-rc3: XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Date: Mon, 7 Feb 2005 17:13:02 +0100 User-Agent: KMail/1.7.2 Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <42078B74.2080306@mnsu.edu> In-Reply-To: <42078B74.2080306@mnsu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502071713.03158.as@cohaesio.com> X-OriginalArrivalTime: 07 Feb 2005 16:12:05.0991 (UTC) FILETIME=[C46B2F70:01C50D2F] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4888 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Is this system running SMP og UP? On Monday 07 February 2005 16:38, Jeffrey E. Hundstad wrote: > I'm sorry for this truncated report... but it's all I've got. If you > need .config or system configuration, etc. let me know and I'll send'em > ASAP. I don't believe this is hardware related; ide-smart shows all fine. > > From dmesg: > > xfs_da_do_buf: bno 8388608 > dir: inode 117526252 > Filesystem "hda4": XFS internal error xfs_da_do_buf(1) at line 2176 of > file fs/x -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Mon Feb 7 08:56:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 08:56:56 -0800 (PST) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17Gussb001764 for ; Mon, 7 Feb 2005 08:56:55 -0800 Received: from [134.29.32.1] (j3gum-3.ITS.MNSU.EDU [134.29.32.1]) by mail.mnsu.edu (8.12.11/8.12.11) with ESMTP id j17GulD5026556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Feb 2005 10:56:47 -0600 Message-ID: <42079DCF.4070907@mnsu.edu> Date: Mon, 07 Feb 2005 10:56:47 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Saaby CC: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: linux-2.6.11-rc3: XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. References: <42078B74.2080306@mnsu.edu> <200502071713.03158.as@cohaesio.com> In-Reply-To: <200502071713.03158.as@cohaesio.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4889 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs Anders Saaby wrote: >Is this system running SMP og UP? > >On Monday 07 February 2005 16:38, Jeffrey E. Hundstad wrote: > > >>I'm sorry for this truncated report... but it's all I've got. If you >>need .config or system configuration, etc. let me know and I'll send'em >>ASAP. I don't believe this is hardware related; ide-smart shows all fine. >> >> From dmesg: >> >>xfs_da_do_buf: bno 8388608 >>dir: inode 117526252 >>Filesystem "hda4": XFS internal error xfs_da_do_buf(1) at line 2176 of >>file fs/x >> >> > > > UP From owner-linux-xfs Mon Feb 7 09:44:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 09:44:17 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17HiEkL003514 for ; Mon, 7 Feb 2005 09:44:14 -0800 Received: by rproxy.gmail.com with SMTP id a36so721413rnf for ; Mon, 07 Feb 2005 09:44:14 -0800 (PST) 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; b=JPUXIYtUmZpYZvWfPlcVmXjhEw4llzDFAK+Dkte4bvRxBT5SeTHb4ncg3TR8f0y/W9BpBA5dHF0GAWpFa41s143j06Kofuis+0g9hklOXzGP2/6rvDcM1dpnbJpfffO9R4n3MQiLoMBVfVGUf91j9pq/ZDGimBGFmeiukuJHWdU= Received: by 10.38.14.32 with SMTP id 32mr154804rnn; Mon, 07 Feb 2005 09:44:13 -0800 (PST) Received: by 10.38.83.28 with HTTP; Mon, 7 Feb 2005 09:44:13 -0800 (PST) Message-ID: Date: Mon, 7 Feb 2005 12:44:13 -0500 From: Rick Spillane Reply-To: Rick Spillane To: linux-xfs@oss.sgi.com Subject: ACID Question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4890 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: necro351@gmail.com Precedence: bulk X-list: linux-xfs Does XFS entirely follow the ACID requirements: Atomic, Consistancy, Isolated, and Durability? -- Rick necro351@gmail.com From owner-linux-xfs Mon Feb 7 09:50:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 09:50:59 -0800 (PST) Received: from kevlar.burdell.org (dsl027-162-124.atl1.dsl.speakeasy.net [216.27.162.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17HorFJ004560 for ; Mon, 7 Feb 2005 09:50:58 -0800 Received: by kevlar.burdell.org (Postfix, from userid 1189) id 6527A66C83; Mon, 7 Feb 2005 12:37:55 -0500 (EST) Date: Mon, 7 Feb 2005 12:37:55 -0500 From: Sonny Rao To: linux-xfs@oss.sgi.com Subject: Delayed Allocation Question Message-ID: <20050207173755.GA24277@kevlar.burdell.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4891 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sonny@burdell.org Precedence: bulk X-list: linux-xfs Random question: If a file is being written (to memory) and hasn't been allocated, then will calling the FIBMAP-ioctl on that file force allocation ? Sonny From owner-linux-xfs Mon Feb 7 11:04:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 11:04:58 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17J4uBr008753 for ; Mon, 7 Feb 2005 11:04:57 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 7B4CCD033E; Mon, 7 Feb 2005 20:04:50 +0100 (CET) To: Rick Spillane Cc: linux-xfs@oss.sgi.com Subject: Re: ACID Question References: From: Andi Kleen Date: Mon, 07 Feb 2005 20:04:50 +0100 In-Reply-To: (Rick Spillane's message of "Mon, 7 Feb 2005 12:44:13 -0500") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4892 X-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@muc.de Precedence: bulk X-list: linux-xfs Rick Spillane writes: > Does XFS entirely follow the ACID requirements: Atomic, Consistancy, > Isolated, and Durability? For user data (read/write) etc. no. It follows POSIX semantics for that, which are much weaker. You can implemented full ACID on top of it though using fsync/fdatasync/O_SYNC. It probably does for internal transactions on its disk data structures (like updating directories or inodes), but user visible actions (rename, create file etc.) are also not necessary atomic or isolated because the Linux VFS often splits them up into multiple actions. They should be all consitent in itself though and durable if you flush the data at some point (fsync). -Andi From owner-linux-xfs Mon Feb 7 11:56:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 11:56:02 -0800 (PST) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17Ju0bm012619 for ; Mon, 7 Feb 2005 11:56:01 -0800 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 11:55:55 -0800 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 11:55:51 -0800 Message-ID: <4207C7C9.8060005@xfs.org> Date: Mon, 07 Feb 2005 13:55:53 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sonny Rao CC: linux-xfs@oss.sgi.com Subject: Re: Delayed Allocation Question References: <20050207173755.GA24277@kevlar.burdell.org> In-Reply-To: <20050207173755.GA24277@kevlar.burdell.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2005 19:55:51.0607 (UTC) FILETIME=[06B59C70:01C50D4F] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4893 X-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 Sonny Rao wrote: > Random question: If a file is being written (to memory) and hasn't > been allocated, then will calling the FIBMAP-ioctl on that file force > allocation ? > > Sonny > Yes, at least it did last time I looked. Otherwise things like lilo fall over in a heap. Steve From owner-linux-xfs Mon Feb 7 12:31:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 12:31:26 -0800 (PST) Received: from kevlar.burdell.org (dsl027-162-124.atl1.dsl.speakeasy.net [216.27.162.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17KVNhR017115 for ; Mon, 7 Feb 2005 12:31:24 -0800 Received: by kevlar.burdell.org (Postfix, from userid 1189) id B6C6066C83; Mon, 7 Feb 2005 15:18:24 -0500 (EST) Date: Mon, 7 Feb 2005 15:18:24 -0500 From: Sonny Rao To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Delayed Allocation Question Message-ID: <20050207201824.GA26160@kevlar.burdell.org> References: <20050207173755.GA24277@kevlar.burdell.org> <4207C7C9.8060005@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4207C7C9.8060005@xfs.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4894 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sonny@burdell.org Precedence: bulk X-list: linux-xfs On Mon, Feb 07, 2005 at 01:55:53PM -0600, Steve Lord wrote: > Sonny Rao wrote: > >Random question: If a file is being written (to memory) and hasn't > >been allocated, then will calling the FIBMAP-ioctl on that file force > >allocation ? > > > >Sonny > > > > Yes, at least it did last time I looked. Otherwise things like lilo > fall over in a heap. > > Steve Ok that makes sense, I was seeing huge file fragmentation and thought maybe running filefrag was causing it, but it was actually because of holes in the file. I didn't realize that cp kept holes in files :-P Sonny From owner-linux-xfs Mon Feb 7 13:43:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 13:43:51 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j17Lhmuu020014 for ; Mon, 7 Feb 2005 13:43:49 -0800 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 IAA19988; Tue, 8 Feb 2005 08:41:50 +1100 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 j17LfmXE2061531; Tue, 8 Feb 2005 08:41:48 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j17LfhKx2047436; Tue, 8 Feb 2005 08:41:43 +1100 (EST) Date: Tue, 8 Feb 2005 08:41:42 +1100 From: Nathan Scott To: Sonny Rao , Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Delayed Allocation Question Message-ID: <20050208084142.B2044436@wobbly.melbourne.sgi.com> References: <20050207173755.GA24277@kevlar.burdell.org> <4207C7C9.8060005@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4207C7C9.8060005@xfs.org>; from lord@xfs.org on Mon, Feb 07, 2005 at 01:55:53PM -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4895 X-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 On Mon, Feb 07, 2005 at 01:55:53PM -0600, Steve Lord wrote: > Sonny Rao wrote: > > Random question: If a file is being written (to memory) and hasn't > > been allocated, then will calling the FIBMAP-ioctl on that file force > > allocation ? > > > > Yes, at least it did last time I looked. Otherwise things like lilo > fall over in a heap. Yep, still does - see linvfs_bmap, which calls fs_flush_pages before doing the generic_block_bmap. cheers. -- Nathan From owner-linux-xfs Mon Feb 7 14:44:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 14:44:47 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j17MiiHb021726 for ; Mon, 7 Feb 2005 14:44:44 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id BAF6EFB455 for ; Mon, 7 Feb 2005 23:44:43 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Feb 2005 23:44:43 +0100 From: Anders Saaby Organization: Cohaesio A/S To: linux-xfs@oss.sgi.com Subject: 2.6.11-rc3: 80-95% systime when serving files via NFS Date: Mon, 7 Feb 2005 23:45:30 +0100 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502072345.38636.as@cohaesio.com> X-OriginalArrivalTime: 07 Feb 2005 22:44:43.0682 (UTC) FILETIME=[9DE59020:01C50D66] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4896 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Hi List, At the moment we are testing an NFS server based on a Xeon Nocona (em64t) and 2.6.11-rc3 compiled for X86_64/em64t as the machine has 8GB memory. Filesystem is based on XFS with external journal. This is a top snip when the server is under heavy read load: top - 23:02:25 up 5:14, 6 users, load average: 8.54, 9.51, 8.99 Tasks: 122 total, 6 running, 116 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3% us, 92.4% sy, 0.0% ni, 0.0% id, 5.0% wa, 0.0% hi, 2.3% si Mem: 8226600k total, 6946504k used, 1280096k free, 4212k buffers Swap: 0k total, 0k used, 0k free, 6203480k cached As you can see, the systime is ~90%. I saw an earlier mail from Nathan regarding xfs_iget_core optimizations in december, but as the following kernel profile shows, this procedure is responsible for most of the load: This is a kernel profile at the same time: 99621 total 0,0387 56322 xfs_iget_core 45,1298 33711 mwait_idle 234,1042 4500 xfs_iextract 10,8173 1077 __do_softirq 5,6094 284 tg3_start_xmit 0,1830 272 tg3_rx 0,2464 201 *unknown* 199 tg3_interrupt 0,5923 - Is this expected behavior? - or is something wrong (I would like to think so :-)) - If you need any additional info I will be happy to provide it! NOTE: This behavior does not show unless most of the memory is used for cache (Right after reboot, systime is ~5%). NOTE2: When only serving files which is already in cache systime also drops to ~5-10% -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Mon Feb 7 15:14:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 15:14:21 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j17NEImK024286 for ; Mon, 7 Feb 2005 15:14:19 -0800 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22113; Tue, 8 Feb 2005 10:14:07 +1100 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j17NE6RS131216; Tue, 8 Feb 2005 10:14:06 +1100 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j17NE5FI146010; Tue, 8 Feb 2005 10:14:05 +1100 (EST) Date: Tue, 8 Feb 2005 10:14:05 +1100 From: Dave Chinner To: Anders Saaby Cc: linux-xfs@oss.sgi.com Subject: Re: 2.6.11-rc3: 80-95% systime when serving files via NFS Message-ID: <20050208101405.D147127@melbourne.sgi.com> References: <200502072345.38636.as@cohaesio.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: <200502072345.38636.as@cohaesio.com>; from as@cohaesio.com on Mon, Feb 07, 2005 at 11:45:30PM +0100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4897 X-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 On Mon, Feb 07, 2005 at 11:45:30PM +0100, Anders Saaby wrote: > Hi List, > > At the moment we are testing an NFS server based on a Xeon Nocona (em64t) and > 2.6.11-rc3 compiled for X86_64/em64t as the machine has 8GB memory. > > Filesystem is based on XFS with external journal. ..... > As you can see, the systime is ~90%. > > I saw an earlier mail from Nathan regarding xfs_iget_core optimizations in > december, but as the following kernel profile shows, this procedure is > responsible for most of the load: > > This is a kernel profile at the same time: > > > 99621 total 0,0387 > 56322 xfs_iget_core 45,1298 ..... How many inodes are cached? Can you dump out the xfs slabs from /proc/slabinfo when this is occurring? i.e. # egrep "^(xfs|linvfs|dentry)" /proc/slabinfo xfs_acl 212 212 304 4 4 1 : 3844 961 xfs_chashlist 9944 9944 32 22 22 1 : 7812 1953 xfs_ili 5976 5976 192 72 72 1 : 7812 1953 xfs_ifork 0 0 64 0 0 1 : 7812 1953 xfs_efi_item 5760 5760 352 128 128 1 : 3844 961 xfs_efd_item 5764 5764 360 131 131 1 : 3844 961 xfs_buf_item 7998 7998 184 93 93 1 : 7812 1953 xfs_dabuf 2324 2324 24 4 4 1 : 7812 1953 xfs_da_state 132 132 488 4 4 1 : 3844 961 xfs_trans 7600 9522 872 460 529 1 : 3844 961 xfs_inode 160341 201579 544 6858 6951 1 : 3844 961 xfs_btree_cur 332 332 192 4 4 1 : 7812 1953 xfs_bmap_free_item 2324 2324 24 4 4 1 : 7812 1953 xfs_buf_t 8988 8988 384 214 214 1 : 3844 961 linvfs_icache 166115 199500 640 7919 7980 1 : 3844 961 dentry_cache 80693 155682 256 2397 2511 1 : 7812 1953 # If you have a significant number of cached inodes, and you are repeatedly missing the cache, then we will spend a significant amount of time searching the cache... Judging by the amount of memory used and not in the page cache (~700MiB from your top output), I'd say there are quite a few cached inodes. > NOTE: This behavior does not show unless most of the memory is used for cache > (Right after reboot, systime is ~5%). Probably because there aren't many cached inodes. Can you dump the slabinfo at this time as well? Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs Mon Feb 7 16:37:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 16:37:19 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j180bHcF029955 for ; Mon, 7 Feb 2005 16:37:17 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 721FFFB455; Tue, 8 Feb 2005 01:37:16 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: 2.6.11-rc3: 80-95% systime when serving files via NFS Date: Tue, 8 Feb 2005 01:37:16 +0100 Message-ID: <222BE5975A4813449559163F8F8CF5030C22D2@cohsrv1.cohaesio.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2.6.11-rc3: 80-95% systime when serving files via NFS Thread-Index: AcUNasNGSUxeCtsbSFm7gCZyREZQOQAB/GN+ From: "Anders Saaby" To: "Dave Chinner" Cc: X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j180bIcF029957 X-archive-position: 4898 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Hi, On Tue, Feb 08, 2005 at 12:14:26AM +0100, Dave Chinner wrote: >How many inodes are cached? Can you dump out the xfs slabs from >/proc/slabinfo when this is occurring? i.e. > ># egrep "^(xfs|linvfs|dentry)" /proc/slabinfo Here is my slabinfo after heavy load: grep "^(xfs|linvfs|dentry)" /proc/slabinfo xfs_chashlist 178433 199325 32 119 1 : tunables 120 60 0 : slabdata 1675 1675 0 xfs_ili 269 280 192 20 1 : tunables 120 60 0 : slabdata 14 14 0 xfs_ifork 0 0 64 61 1 : tunables 120 60 0 : slabdata 0 0 0 xfs_efi_item 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0 xfs_efd_item 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0 xfs_buf_item 8 21 184 21 1 : tunables 120 60 0 : slabdata 1 1 0 xfs_dabuf 64 156 24 156 1 : tunables 120 60 0 : slabdata 1 1 0 xfs_da_state 8 8 488 8 1 : tunables 54 27 0 : slabdata 1 1 0 xfs_trans 14 18 864 9 2 : tunables 54 27 0 : slabdata 2 2 0 xfs_inode 417324 423464 512 8 1 : tunables 54 27 0 : slabdata 52933 52933 0 xfs_btree_cur 5 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0 xfs_bmap_free_item 0 0 24 156 1 : tunables 120 60 0 : slabdata 0 0 0 xfs_buf_t 52 120 384 10 1 : tunables 54 27 0 : slabdata 12 12 0 linvfs_icache 417324 421421 544 7 1 : tunables 54 27 0 : slabdata 60203 60203 0 dentry_cache 345650 401004 216 18 1 : tunables 120 60 0 : slabdata 22278 22278 0 - xfs_inode, linvfs_cache and dentry_cache gets even higher after a longer test run. > >If you have a significant number of cached inodes, and you are >repeatedly missing the cache, then we will spend a significant >amount of time searching the cache... I have quite a lot: df -i: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb1 716043376 19405588 696637788 3% /mnt/xfs_test And part of my test is to relatively often miss the cache. > >Judging by the amount of memory used and not in the page cache >(~700MiB from your top output), I'd say there are quite a few >cached inodes. Yes. > >> NOTE: This behavior does not show unless most of the memory is used for cache >> (Right after reboot, systime is ~5%). > >Probably because there aren't many cached inodes. Can you dump the >slabinfo at this time as well? That is correct. inode cache was very low at that point. - Does this mean that this is expected behavior? - If that is the case, do you have any ideas to how I can get my system to perform better? (Performance gets very poor efter approx. two hours of heavy load.) Thanks in advance! //Anders Saaby From owner-linux-xfs Mon Feb 7 17:30:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 17:30:19 -0800 (PST) Received: from smtp1.ActiveState.com (gw.activestate.com [209.17.183.249]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j181UF3A032108 for ; Mon, 7 Feb 2005 17:30:18 -0800 Received: from rock.activestate.com (rock.ActiveState.com [192.168.3.223]) by smtp1.ActiveState.com (8.12.10/8.12.10) with ESMTP id j181UAiC021176 for ; Mon, 7 Feb 2005 17:30:10 -0800 (envelope-from daves@activestate.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by rock.activestate.com (8.12.11/8.12.11) with ESMTP id j181UFru007089 for ; Mon, 7 Feb 2005 17:30:15 -0800 (envelope-from daves@activestate.com) Message-ID: <42081627.4090307@activestate.com> Date: Mon, 07 Feb 2005 17:30:15 -0800 From: David Sparks Reply-To: daves@activestate.com User-Agent: Mozilla Thunderbird 0.8 (X11/20040920) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: external log vs internal log and mkfs.xfs options References: <4202C6DA.1060809@activestate.com> <20050204115943.E1943129@wobbly.melbourne.sgi.com> In-Reply-To: <20050204115943.E1943129@wobbly.melbourne.sgi.com> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4899 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daves@activestate.com Precedence: bulk X-list: linux-xfs Nathan Scott wrote: > On Thu, Feb 03, 2005 at 04:50:34PM -0800, David Sparks wrote: > >>I'm setting up a SAN with a 1TB partition and am seeking some advice. >> >>Previously when setting up servers, I would specify options to mkfs.xfs >>to lower the agcount and create a 32m log, ie for a 33GB partition: >> >> mkfs.xfs -d agcount=32 -l size=32m /dev/sda3 >> >>This was based on an article I read at: >> >> http://www-106.ibm.com/developerworks/linux/library/l-fs10.html > > > Aha, thats whos been telling people that! The article is a bit > out of date now. > > >>More recently I've not bothered with those options because I read >>somewhere that the defaults are sane. (I've never noticed any >>difference either way) Are the mkfs.xfs defaults good for a 1TB partition? > > > Yes, should be just fine. In fact, from a quick check, current > mkfs will create a 32 AG filesystem on a 1Terabyte device... > > # mkfs.xfs -N -dfile,size=1t,name=/dev/null > meta-data=/dev/null isize=256 agcount=32, agsize=8388608 blks ... This didn't make any sense to me until I noticed this change in the manpage: man mkfs.xfs used to say: > The minimum allocation group size > is 16 MB; the maximum size is just under 4 GB. now it says: > The minimum allocation group size > is 16 MiB; the maximum size is just under 1 TiB. (max ag size went from 4 GB to 1 TiB) So I would agree that the original article is now out of date in regards to mkfs.xfs suggestions. Nobody commented on this question though, I'll put it up again. Most of the information I've gathered on external logs dates back to the IRIX days -- I hope there isn't anything out of date there. > Regarding external logs, I've never formatted a XFS with an external > log. From what I can gather (google, man pages), doing so is supposed > to reduce disk head seeking hence performance is improved. Is anyone > aware of any benchmarks that explore internal/external logs and sizes? > My preference is for an internal log as that just simplifies things. Is there any advantage to an external log on a separate partition on the same device, as opposed to an external log on a separate device? Basically is an external log only for performance benefits or are there robustness benefits also? Cheers! ds From owner-linux-xfs Mon Feb 7 19:53:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 19:53:39 -0800 (PST) Received: from www.sfo.jp (h219-110-181-023.catv02.itscom.jp [219.110.181.23]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j183rUaI004481 for ; Mon, 7 Feb 2005 19:53:33 -0800 Received: (qmail 3397 invoked from network); 8 Feb 2005 03:53:29 -0000 Received: from unknown (HELO localhost.sugar.lan.sfo.jp) (127.0.0.1) by localhost with SMTP; 8 Feb 2005 03:53:29 -0000 Date: Tue, 08 Feb 2005 12:53:29 +0900 Message-ID: <87zmyf907a.wl%fumiya@samba.gr.jp> From: SATOH Fumiyasu to: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: Re: linux-2.6.11-rc3: XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. In-Reply-To: <42078B74.2080306@mnsu.edu> References: <42078B74.2080306@mnsu.edu> User-Agent: Wanderlust/2.11.30 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) Organization: Samba-JP / Namazu Developer / THRUST Co., Ltd. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4900 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fumiya@samba.gr.jp Precedence: bulk X-list: linux-xfs At Mon, 07 Feb 2005 09:38:28 -0600, Jeffrey E. Hundstad wrote: > I'm sorry for this truncated report... but it's all I've got. If you > need .config or system configuration, etc. let me know and I'll send'em > ASAP. I don't believe this is hardware related; ide-smart shows all fine. > > From dmesg: > > xfs_da_do_buf: bno 8388608 > dir: inode 117526252 > Filesystem "hda4": XFS internal error xfs_da_do_buf(1) at line 2176 of > file fs/xfs/xfs_da_btree.c. Caller 0xc01bda27 I've seen similar problems on Debian GNU/Linux testing ver. (sarge) and kernel-image-2.6.8-1-686-smp and kernel-image-2.6.10-1-686-smp (kernel-image-* are Debian-oriented Linux kernel binary packages). I think this is NOT hardware related. These problems are occured on three different hardwares. Host1 ----- OS: Debian GNU/Linux testing (sarge) Kernel: kernel-image-2.6.8-1-686-smp (compiled by gcc version 3.3.5 (Debian 1:3.3.5-2) Filesystem: / (/dev/md0 (RAID1, /dev/hda1, /dev/hdd1)) CPU: Intel(R) Xeon(TM) CPU 2.40GHz x 2 (SMP) # xfs_info / meta-data=/ isize=256 agcount=8, agsize=244232 blks = sectsz=512 data = bsize=4096 blocks=1953856, imaxpct=25 = sunit=8 swidth=16 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 Log: Not found in /var/log/* Host2 ----- OS: Debian GNU/Linux testing (sarge) Kernel: kernel-image-2.6.10-1-686-smp (compiled by gcc version 3.3.5 (Debian 1:3.3.5-6)) Filesystem: / (/dev/md0 (RAID1, /dev/hda1, /dev/hdd1)) CPU: Intel(R) Xeon(TM) CPU 2.40GHz x 2 (SMP) # xfs_info / meta-data=/ isize=256 agcount=8, agsize=244232 blks = sectsz=512 data = bsize=4096 blocks=1953856, imaxpct=25 = sunit=8 swidth=16 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 Log1 from /var/log/kern.log*: Jan 28 21:11:50 host2 kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller 0xf89d02a5 Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+782770/5290900] xfs_free_ag_extent+0x471/0x7a0 [xfs] Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+787494/5290900] xfs_free_extent+0xe5/0x110 [xfs] Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+787494/5290900] xfs_free_extent+0xe5/0x110 [xfs] Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+1189885/5290900] kmem_zone_alloc+0x4c/0xa0 [xfs] Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+997143/5290900] xfs_efd_init+0x86/0x90 [xfs] Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+1142537/5290900] xfs_trans_get_efd+0x38/0x50 [xfs] Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+867408/5290900] xfs_bmap_finish+0x13f/0x1e0 [xfs] Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+1039636/5290900] xfs_itruncate_finish+0x233/0x460 [xfs] Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+1167530/5290900] xfs_inactive+0x509/0x570 [xfs] Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+1237072/5290900] vn_rele+0xff/0x120 [xfs] Jan 28 21:11:50 host2 kernel: [__crc_pm_idle+1230441/5290900] linvfs_clear_inode+0x18/0x30 [xfs] Jan 28 21:11:50 host2 kernel: [clear_inode+230/288] clear_inode+0xe6/0x120 Jan 28 21:11:50 host2 kernel: [generic_delete_inode+362/416] generic_delete_inode+0x16a/0x1a0 Jan 28 21:11:50 host2 kernel: [iput+99/144] iput+0x63/0x90 Jan 28 21:11:50 host2 kernel: [sys_unlink+275/320] sys_unlink+0x113/0x140 Jan 28 21:11:50 host2 kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 Jan 28 21:11:50 host2 kernel: xfs_force_shutdown(md0,0x8) called from line 4049 of file fs/xfs/xfs_bmap.c. Return address = 0xf8a3d2db Jan 28 21:11:50 host2 kernel: Filesystem "md0": Corruption of in-memory data detected. Shutting down filesystem: md0 Jan 28 21:11:50 host2 kernel: Please umount the filesystem, and rectify the problem(s) Log2 from /var/log/kern.log*: Feb 3 14:35:18 host2 kernel: xfs_force_shutdown(md0,0x8) called from line 1091 of file fs/xfs/xfs_trans.c. Return address = 0xf8a8b23b Feb 3 14:35:18 host2 kernel: Filesystem "md0": Corruption of in-memory data detected. Shutting down filesystem: md0 Feb 3 14:35:18 host2 kernel: Please umount the filesystem, and rectify the problem(s) Host3: ------ OS: Debian GNU/Linux testing version (sarge) Kernel: kernel-image-2.6.10-1-686-smp (compiled by gcc version 3.3.5 (Debian 1:3.3.5-6)) Filesystem: / (/dev/md0 (RAID1, /dev/hda1, /dev/hdd1)) CPU: Intel(R) Xeon(TM) CPU 2.40GHz x 2 (SMP) # xfs_info / meta-data=/ isize=256 agcount=8, agsize=125000 blks = sectsz=512 data = bsize=4096 blocks=1000000, imaxpct=25 = sunit=8 swidth=16 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 Log from /var/log/kern.log* Jan 18 06:25:06 host3 kernel: 0x0: 0a 54 68 69 73 20 6d 6f 64 75 6c 65 20 69 73 20 Jan 18 06:25:06 host3 kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xf89ff0b8 Jan 18 06:25:06 host3 kernel: [__crc_pm_idle+977969/5541136] xfs_da_do_buf+0x3d0/0x920 [xfs] Jan 18 06:25:06 host3 kernel: [__crc_pm_idle+979513/5541136] xfs_da_read_buf+0x58/0x60 [xfs] Jan 18 06:25:06 host3 last message repeated 2 times Jan 18 06:25:06 host3 kernel: [__crc_pm_idle+1007691/5541136] xfs_dir2_leaf_getdents+0x3ea/0xc90 [xfs] Jan 18 06:25:06 host3 kernel: [__crc_pm_idle+1007691/5541136] xfs_dir2_leaf_getdents+0x3ea/0xc90 [xfs] Jan 18 06:25:06 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 18 06:25:06 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 18 06:25:06 host3 kernel: [__crc_pm_idle+988970/5541136] xfs_dir2_getdents+0x109/0x160 [xfs] Jan 18 06:25:06 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 18 06:25:06 host3 kernel: [__crc_pm_idle+1228481/5541136] xfs_readdir+0x60/0xc0 [xfs] Jan 18 06:25:06 host3 kernel: [__crc_pm_idle+1262471/5541136] linvfs_readdir+0x116/0x230 [xfs] Jan 18 06:25:06 host3 kernel: [vfs_readdir+167/192] vfs_readdir+0xa7/0xc0 Jan 18 06:25:06 host3 kernel: [filldir64+0/256] filldir64+0x0/0x100 Jan 18 06:25:06 host3 kernel: [sys_getdents64+110/170] sys_getdents64+0x6e/0xaa Jan 18 06:25:06 host3 kernel: [filldir64+0/256] filldir64+0x0/0x100 Jan 18 06:25:06 host3 kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 Jan 18 06:25:06 host3 kernel: Jan 19 06:25:06 host3 kernel: 0x0: 0a 54 68 69 73 20 6d 6f 64 75 6c 65 20 69 73 20 Jan 19 06:25:06 host3 kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xf89ff0b8 Jan 19 06:25:06 host3 kernel: [__crc_pm_idle+977969/5541136] xfs_da_do_buf+0x3d0/0x920 [xfs] Jan 19 06:25:06 host3 kernel: [__crc_pm_idle+979513/5541136] xfs_da_read_buf+0x58/0x60 [xfs] Jan 19 06:25:06 host3 last message repeated 2 times Jan 19 06:25:06 host3 kernel: [__crc_pm_idle+1007691/5541136] xfs_dir2_leaf_getdents+0x3ea/0xc90 [xfs] Jan 19 06:25:06 host3 kernel: [__crc_pm_idle+1007691/5541136] xfs_dir2_leaf_getdents+0x3ea/0xc90 [xfs] Jan 19 06:25:06 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 19 06:25:06 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 19 06:25:06 host3 kernel: [__crc_pm_idle+988970/5541136] xfs_dir2_getdents+0x109/0x160 [xfs] Jan 19 06:25:06 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 19 06:25:06 host3 kernel: [__crc_pm_idle+1228481/5541136] xfs_readdir+0x60/0xc0 [xfs] Jan 19 06:25:06 host3 kernel: [__crc_pm_idle+1262471/5541136] linvfs_readdir+0x116/0x230 [xfs] Jan 19 06:25:06 host3 kernel: [vfs_readdir+167/192] vfs_readdir+0xa7/0xc0 Jan 19 06:25:06 host3 kernel: [filldir64+0/256] filldir64+0x0/0x100 Jan 19 06:25:06 host3 kernel: [sys_getdents64+110/170] sys_getdents64+0x6e/0xaa Jan 19 06:25:06 host3 kernel: [filldir64+0/256] filldir64+0x0/0x100 Jan 19 06:25:06 host3 kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 Jan 19 06:25:06 host3 kernel: Jan 20 06:25:07 host3 kernel: 0x0: 0a 54 68 69 73 20 6d 6f 64 75 6c 65 20 69 73 20 Jan 20 06:25:07 host3 kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xf89ff0b8 Jan 20 06:25:07 host3 kernel: [__crc_pm_idle+977969/5541136] xfs_da_do_buf+0x3d0/0x920 [xfs] Jan 20 06:25:07 host3 kernel: [__crc_pm_idle+979513/5541136] xfs_da_read_buf+0x58/0x60 [xfs] Jan 20 06:25:07 host3 last message repeated 2 times Jan 20 06:25:07 host3 kernel: [__crc_pm_idle+1007691/5541136] xfs_dir2_leaf_getdents+0x3ea/0xc90 [xfs] Jan 20 06:25:07 host3 kernel: [__crc_pm_idle+1007691/5541136] xfs_dir2_leaf_getdents+0x3ea/0xc90 [xfs] Jan 20 06:25:07 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 20 06:25:07 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 20 06:25:07 host3 kernel: [__crc_pm_idle+988970/5541136] xfs_dir2_getdents+0x109/0x160 [xfs] Jan 20 06:25:07 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 20 06:25:07 host3 kernel: [__crc_pm_idle+1228481/5541136] xfs_readdir+0x60/0xc0 [xfs] Jan 20 06:25:07 host3 kernel: [__crc_pm_idle+1262471/5541136] linvfs_readdir+0x116/0x230 [xfs] Jan 20 06:25:07 host3 kernel: [vfs_readdir+167/192] vfs_readdir+0xa7/0xc0 Jan 20 06:25:07 host3 kernel: [filldir64+0/256] filldir64+0x0/0x100 Jan 20 06:25:07 host3 kernel: [sys_getdents64+110/170] sys_getdents64+0x6e/0xaa Jan 20 06:25:07 host3 kernel: [filldir64+0/256] filldir64+0x0/0x100 Jan 20 06:25:07 host3 kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 Jan 20 06:25:07 host3 kernel: Jan 21 06:25:07 host3 kernel: 0x0: 0a 54 68 69 73 20 6d 6f 64 75 6c 65 20 69 73 20 Jan 21 06:25:07 host3 kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xf89ff0b8 Jan 21 06:25:07 host3 kernel: [__crc_pm_idle+977969/5541136] xfs_da_do_buf+0x3d0/0x920 [xfs] Jan 21 06:25:07 host3 kernel: [__crc_pm_idle+979513/5541136] xfs_da_read_buf+0x58/0x60 [xfs] Jan 21 06:25:07 host3 last message repeated 2 times Jan 21 06:25:07 host3 kernel: [__crc_pm_idle+1007691/5541136] xfs_dir2_leaf_getdents+0x3ea/0xc90 [xfs] Jan 21 06:25:07 host3 kernel: [__crc_pm_idle+1007691/5541136] xfs_dir2_leaf_getdents+0x3ea/0xc90 [xfs] Jan 21 06:25:07 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 21 06:25:07 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 21 06:25:07 host3 kernel: [__crc_pm_idle+988970/5541136] xfs_dir2_getdents+0x109/0x160 [xfs] Jan 21 06:25:07 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 21 06:25:07 host3 kernel: [__crc_pm_idle+1228481/5541136] xfs_readdir+0x60/0xc0 [xfs] Jan 21 06:25:07 host3 kernel: [__crc_pm_idle+1262471/5541136] linvfs_readdir+0x116/0x230 [xfs] Jan 21 06:25:07 host3 kernel: [vfs_readdir+167/192] vfs_readdir+0xa7/0xc0 Jan 21 06:25:07 host3 kernel: [filldir64+0/256] filldir64+0x0/0x100 Jan 21 06:25:07 host3 kernel: [sys_getdents64+110/170] sys_getdents64+0x6e/0xaa Jan 21 06:25:07 host3 kernel: [filldir64+0/256] filldir64+0x0/0x100 Jan 21 06:25:07 host3 kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 Jan 21 06:25:07 host3 kernel: Jan 22 06:25:06 host3 kernel: 0x0: 0a 54 68 69 73 20 6d 6f 64 75 6c 65 20 69 73 20 Jan 22 06:25:06 host3 kernel: Filesystem "md0": XFS internal error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xf89ff0b8 Jan 22 06:25:06 host3 kernel: [__crc_pm_idle+977969/5541136] xfs_da_do_buf+0x3d0/0x920 [xfs] Jan 22 06:25:06 host3 kernel: [__crc_pm_idle+979513/5541136] xfs_da_read_buf+0x58/0x60 [xfs] Jan 22 06:25:06 host3 last message repeated 2 times Jan 22 06:25:06 host3 kernel: [__crc_pm_idle+1007691/5541136] xfs_dir2_leaf_getdents+0x3ea/0xc90 [xfs] Jan 22 06:25:06 host3 kernel: [__crc_pm_idle+1007691/5541136] xfs_dir2_leaf_getdents+0x3ea/0xc90 [xfs] Jan 22 06:25:06 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 22 06:25:06 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 22 06:25:06 host3 kernel: [__crc_pm_idle+988970/5541136] xfs_dir2_getdents+0x109/0x160 [xfs] Jan 22 06:25:06 host3 kernel: [__crc_pm_idle+991073/5541136] xfs_dir2_put_dirent64_direct+0x0/0xa0 [xfs] Jan 22 06:25:06 host3 kernel: [__crc_pm_idle+1228481/5541136] xfs_readdir+0x60/0xc0 [xfs] Jan 22 06:25:06 host3 kernel: [__crc_pm_idle+1262471/5541136] linvfs_readdir+0x116/0x230 [xfs] Jan 22 06:25:06 host3 kernel: [vfs_readdir+167/192] vfs_readdir+0xa7/0xc0 Jan 22 06:25:06 host3 kernel: [filldir64+0/256] filldir64+0x0/0x100 Jan 22 06:25:06 host3 kernel: [sys_getdents64+110/170] sys_getdents64+0x6e/0xaa Jan 22 06:25:06 host3 kernel: [filldir64+0/256] filldir64+0x0/0x100 Jan 22 06:25:06 host3 kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 Jan 22 06:25:06 host3 kernel: Jan 22 14:15:20 host3 kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller 0xf89dc2a5 Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+831922/5541136] xfs_free_ag_extent+0x471/0x7a0 [xfs] Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+836646/5541136] xfs_free_extent+0xe5/0x110 [xfs] Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+836646/5541136] xfs_free_extent+0xe5/0x110 [xfs] Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+1242045/5541136] kmem_zone_alloc+0x4c/0xa0 [xfs] Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+1048935/5541136] xfs_efd_init+0x86/0x90 [xfs] Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+1194697/5541136] xfs_trans_get_efd+0x38/0x50 [xfs] Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+917680/5541136] xfs_bmap_finish+0x13f/0x1e0 [xfs] Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+1091828/5541136] xfs_itruncate_finish+0x233/0x460 [xfs] Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+1219690/5541136] xfs_inactive+0x509/0x570 [xfs] Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+1289152/5541136] vn_rele+0xff/0x120 [xfs] Jan 22 14:15:20 host3 kernel: [__crc_pm_idle+1282601/5541136] linvfs_clear_inode+0x18/0x30 [xfs] Jan 22 14:15:20 host3 kernel: [clear_inode+182/208] clear_inode+0xb6/0xd0 Jan 22 14:15:20 host3 kernel: [generic_delete_inode+362/416] generic_delete_inode+0x16a/0x1a0 Jan 22 14:15:20 host3 kernel: [iput+99/144] iput+0x63/0x90 Jan 22 14:15:20 host3 kernel: [sys_unlink+275/320] sys_unlink+0x113/0x140 Jan 22 14:15:20 host3 kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 Jan 22 14:15:20 host3 kernel: Jan 22 14:15:20 host3 kernel: xfs_force_shutdown(md0,0x8) called from line 4049 of file fs/xfs/xfs_bmap.c. Return address = 0xf8a49e4b Jan 22 14:15:20 host3 kernel: Filesystem "md0": Corruption of in-memory data detected. Shutting down filesystem: md0 Jan 22 14:15:20 host3 kernel: Please umount the filesystem, and rectify the problem(s) -- -- Name: SATOH Fumiyasu -- Home: http://www.sfo.jp (in Japanese only) -- Mail: fumiya at net-thrust.com, samba.gr.jp, namazu.org or ... From owner-linux-xfs Mon Feb 7 19:57:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 19:57:57 -0800 (PST) Received: from www.sfo.jp (h219-110-181-023.catv02.itscom.jp [219.110.181.23]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j183vt3I004956 for ; Mon, 7 Feb 2005 19:57:56 -0800 Received: (qmail 3438 invoked from network); 8 Feb 2005 03:57:55 -0000 Received: from unknown (HELO localhost.sugar.lan.sfo.jp) (127.0.0.1) by localhost with SMTP; 8 Feb 2005 03:57:55 -0000 Date: Tue, 08 Feb 2005 12:57:55 +0900 Message-ID: <87y8dz8zzw.wl%fumiya@samba.gr.jp> From: SATOH Fumiyasu to: linux-xfs@oss.sgi.com cc: linux-kernel@vger.kernel.org Subject: Re: linux-2.6.11-rc3: XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. In-Reply-To: <87zmyf907a.wl%fumiya@samba.gr.jp> References: <42078B74.2080306@mnsu.edu> <87zmyf907a.wl%fumiya@samba.gr.jp> User-Agent: Wanderlust/2.11.30 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) Organization: Samba-JP / Namazu Developer / THRUST Co., Ltd. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4901 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fumiya@samba.gr.jp Precedence: bulk X-list: linux-xfs There are some corrections for my message... Sorry. At Tue, 08 Feb 2005 12:53:29 +0900, SATOH Fumiyasu wrote: > Host3: > ------ > OS: Debian GNU/Linux testing version (sarge) > Kernel: kernel-image-2.6.10-1-686-smp > (compiled by gcc version 3.3.5 (Debian 1:3.3.5-6)) > Filesystem: / (/dev/md0 (RAID1, /dev/hda1, /dev/hdd1)) > CPU: Intel(R) Xeon(TM) CPU 2.40GHz x 2 (SMP) Filesystem: / (/dev/md0 (RAID1, /dev/sda1, /dev/sdb1)) CPU: Intel(R) Pentium(R) III CPU family 1133MHz x 2 (SMP) SCSI-HBA: Adaptec AIC-7899P U160/m (rev 01) -- -- Name: SATOH Fumiyasu -- Home: http://www.sfo.jp (in Japanese only) -- Mail: fumiya at net-thrust.com, samba.gr.jp, namazu.org or ... From owner-linux-xfs Mon Feb 7 20:34:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 20:34:47 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j184Yg0k010443 for ; Mon, 7 Feb 2005 20:34:43 -0800 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28678; Tue, 8 Feb 2005 15:34:30 +1100 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j184YSRS148499; Tue, 8 Feb 2005 15:34:28 +1100 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j184YRI0148582; Tue, 8 Feb 2005 15:34:27 +1100 (EST) Date: Tue, 8 Feb 2005 15:34:27 +1100 From: Dave Chinner To: Anders Saaby Cc: linux-xfs@oss.sgi.com Subject: Re: 2.6.11-rc3: 80-95% systime when serving files via NFS Message-ID: <20050208153427.G147390@melbourne.sgi.com> References: <222BE5975A4813449559163F8F8CF5030C22D2@cohsrv1.cohaesio.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: <222BE5975A4813449559163F8F8CF5030C22D2@cohsrv1.cohaesio.com>; from as@cohaesio.com on Tue, Feb 08, 2005 at 01:37:16AM +0100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4902 X-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 On Tue, Feb 08, 2005 at 01:37:16AM +0100, Anders Saaby wrote: > Hi, > > On Tue, Feb 08, 2005 at 12:14:26AM +0100, Dave Chinner wrote: > >How many inodes are cached? Can you dump out the xfs slabs from > >/proc/slabinfo when this is occurring? i.e. > > > ># egrep "^(xfs|linvfs|dentry)" /proc/slabinfo > > Here is my slabinfo after heavy load: > > > grep "^(xfs|linvfs|dentry)" /proc/slabinfo > > xfs_inode 417324 423464 512 8 1 : tunables 54 27 0 : slabdata 52933 52933 0 > linvfs_icache 417324 421421 544 7 1 : tunables 54 27 0 : slabdata 60203 60203 0 > dentry_cache 345650 401004 216 18 1 : tunables 120 60 0 : slabdata 22278 22278 0 > > > - xfs_inode, linvfs_cache and dentry_cache gets even higher after a longer > test run. So at this point, you've already got >400,000 cached inodes on a single filesystem.... > >If you have a significant number of cached inodes, and you are > >repeatedly missing the cache, then we will spend a significant > >amount of time searching the cache... > > I have quite a lot: > df -i: > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/sdb1 716043376 19405588 696637788 3% /mnt/xfs_test > > And part of my test is to relatively often miss the cache. Uselessly chasing long chains in the hash is probably where the CPU usage is coming from, then. > - If that is the case, do you have any ideas to how I can get my system to > perform better? (Performance gets very poor efter approx. two hours of heavy > load.) Seeing as you are running 2.6.11-rc3, you're in luck. Nathan's inode hash tweaks were merged into -rc3, so you can increase the size of the inode hash with a mount option. The mount option is "ihashsize", and it specifies the width of the hash table. i.e. `mount -o ihashsize=xxxxx /dev/sdb1 /mntpt` I'm not sure what the default your filesystem will be using, but a maximum of 16*PAGE_SIZE (=64k chains on i386/x86-64) applies to the default setting. If you specify a size this maximum does not apply, but if you specify a value too large memory allocation for the hash will silently fail and the size will be halved repeatedly until the allocation succeeds. HTH. Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs Mon Feb 7 21:50:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Feb 2005 21:50:59 -0800 (PST) Received: from mail22.syd.optusnet.com.au (mail22.syd.optusnet.com.au [211.29.133.160]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j185osbZ012882 for ; Mon, 7 Feb 2005 21:50:55 -0800 Received: from saturn (c211-28-166-127.eburwd2.vic.optusnet.com.au [211.28.166.127]) by mail22.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j185oXf3007500; Tue, 8 Feb 2005 16:50:34 +1100 Received: from [192.168.1.54] (helo=kennedy ident=Debian-exim) by saturn with esmtp (Exim 3.35 #1 (Debian)) id 1CyOFv-000638-00; Tue, 08 Feb 2005 16:49:47 +1100 Received: from localhost ([127.0.0.1] helo=kennedy ident=stewart) by kennedy with esmtp (Exim 4.44) id 1CyOFT-0004Wp-Lb; Tue, 08 Feb 2005 16:49:19 +1100 Subject: Re: ACID Question From: Stewart Smith To: Andi Kleen Cc: Rick Spillane , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rRZKi3fVWntDtcU+MG6y" Date: Tue, 08 Feb 2005 16:49:18 +1100 Message-Id: <1107841758.19311.21.camel@kennedy> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4903 X-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 --=-rRZKi3fVWntDtcU+MG6y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-02-07 at 20:04 +0100, Andi Kleen wrote: > Rick Spillane writes: >=20 > > Does XFS entirely follow the ACID requirements: Atomic, Consistancy, > > Isolated, and Durability? >=20 > For user data (read/write) etc. no. It follows POSIX semantics for that,= =20 > which are much weaker. You can implemented full ACID on top of=20 > it though using fsync/fdatasync/O_SYNC.=20 that is, if your OS does actually flush data to disk with an fsync. POSIX explicitly allows fsync to be null. check your OS docs or look for the POSIX_SYNCHRONISED_IO #define. Linux does sync on fsync(), MacOS X does not (for internal drives at least). --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-rRZKi3fVWntDtcU+MG6y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iQCVAwUAQghS3YwDm44RooHBAQL8kAQAqrKppAPlIpWNThfzm33QseZ6WEfYniZW Y6KnvnQNIxMYjksj8qosLkWBo2tKYwb/5qGRi/GriMJU9E5bFltiDETiujZ6G9ge PUlPXOjACb0EP8AQg7W1oaXNp2zralX1q/Au+3ylIxxeCdqw0IljPhm34DVeRrgG QMsaSHj1w+I= =JKgK -----END PGP SIGNATURE----- --=-rRZKi3fVWntDtcU+MG6y-- From owner-linux-xfs Tue Feb 8 01:23:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 01:23:50 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j189Nk1w024080 for ; Tue, 8 Feb 2005 01:23:48 -0800 Received: (qmail 57630 invoked by uid 3709); 8 Feb 2005 09:23:45 -0000 Date: 8 Feb 2005 10:23:45 +0100 Date: Tue, 8 Feb 2005 10:23:45 +0100 From: Andi Kleen To: Stewart Smith Cc: Rick Spillane , linux-xfs@oss.sgi.com Subject: Re: ACID Question Message-ID: <20050208092345.GB55921@muc.de> References: <1107841758.19311.21.camel@kennedy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107841758.19311.21.camel@kennedy> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4904 X-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@muc.de Precedence: bulk X-list: linux-xfs > Linux does sync on fsync(), MacOS X does not (for internal drives at > least). This would sound extremly bad for MacOS X if true. I hope it is not. -Andi From owner-linux-xfs Tue Feb 8 01:33:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 01:33:14 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j189X8hb024682 for ; Tue, 8 Feb 2005 01:33:11 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 2E661FB47E; Tue, 8 Feb 2005 10:33:08 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 10:33:07 +0100 From: Anders Saaby Organization: Cohaesio A/S To: "Jeffrey E. Hundstad" Subject: Re: linux-2.6.11-rc3: XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Date: Tue, 8 Feb 2005 10:33:59 +0100 User-Agent: KMail/1.7.2 Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <42078B74.2080306@mnsu.edu> <200502071713.03158.as@cohaesio.com> <42079DCF.4070907@mnsu.edu> In-Reply-To: <42079DCF.4070907@mnsu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502081034.04849.as@cohaesio.com> X-OriginalArrivalTime: 08 Feb 2005 09:33:08.0051 (UTC) FILETIME=[32B52A30:01C50DC1] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4905 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs On Monday 07 February 2005 17:56, Jeffrey E. Hundstad wrote: > Anders Saaby wrote: > >Is this system running SMP og UP? > > UP Ouch OK. Then I at least haven't seen it before. -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Tue Feb 8 02:52:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 02:52:02 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18ApxSr030389 for ; Tue, 8 Feb 2005 02:52:00 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 0C8A1FB455; Tue, 8 Feb 2005 11:51:59 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 11:51:58 +0100 From: Anders Saaby Organization: Cohaesio A/S To: Dave Chinner Subject: Re: 2.6.11-rc3: 80-95% systime when serving files via NFS Date: Tue, 8 Feb 2005 11:52:54 +0100 User-Agent: KMail/1.7.2 Cc: linux-xfs@oss.sgi.com References: <222BE5975A4813449559163F8F8CF5030C22D2@cohsrv1.cohaesio.com> <20050208153427.G147390@melbourne.sgi.com> In-Reply-To: <20050208153427.G147390@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502081152.55315.as@cohaesio.com> X-OriginalArrivalTime: 08 Feb 2005 10:51:58.0934 (UTC) FILETIME=[36889F60:01C50DCC] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4906 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs On Tuesday 08 February 2005 05:34, Dave Chinner wrote: > On Tue, Feb 08, 2005 at 01:37:16AM +0100, Anders Saaby wrote: > > Uselessly chasing long chains in the hash is probably where the CPU > usage is coming from, then. Sounds right when hashsize is small - Looking at the code it seems default was around 512 (?). > > > - If that is the case, do you have any ideas to how I can get my system > > to perform better? (Performance gets very poor efter approx. two hours of > > heavy load.) > > Seeing as you are running 2.6.11-rc3, you're in luck. Nathan's > inode hash tweaks were merged into -rc3, so you can increase the > size of the inode hash with a mount option. The mount option > is "ihashsize", and it specifies the width of the hash table. > i.e. `mount -o ihashsize=xxxxx /dev/sdb1 /mntpt` I just tried: mount -o ihashsize=65536,logdev=/dev/sdc1 Systime went from ~90% to ~5% !! :-) This is so sweet. The server now performs amazing under any load I can throw at it. - Only thing yet to show in the long run is stability ;) > I'm not sure what the default your filesystem will be using, but > a maximum of 16*PAGE_SIZE (=64k chains on i386/x86-64) applies to the > default setting. I couldn't really find out what hashsize was default before, so 64K was just a (good?) guess. As I can not see any large increase in memory usage maybe default values should be changed? - Thank you for your help! - You guys have now provided me with invaluable help more than once! :) -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Tue Feb 8 04:09:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 04:09:41 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18C9W0H000656 for ; Tue, 8 Feb 2005 04:09:33 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 0E0FEFB455; Tue, 8 Feb 2005 13:09:32 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 13:09:31 +0100 From: Anders Saaby Organization: Cohaesio A/S To: Dave Chinner Subject: Re: 2.6.11-rc3: 80-95% systime when serving files via NFS Date: Tue, 8 Feb 2005 13:10:29 +0100 User-Agent: KMail/1.7.2 Cc: linux-xfs@oss.sgi.com References: <222BE5975A4813449559163F8F8CF5030C22D2@cohsrv1.cohaesio.com> <20050208153427.G147390@melbourne.sgi.com> <200502081152.55315.as@cohaesio.com> In-Reply-To: <200502081152.55315.as@cohaesio.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502081310.30303.as@cohaesio.com> X-OriginalArrivalTime: 08 Feb 2005 12:09:31.0968 (UTC) FILETIME=[0BF54400:01C50DD7] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4907 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs On Tuesday 08 February 2005 11:52, Anders Saaby wrote: > On Tuesday 08 February 2005 05:34, Dave Chinner wrote: > > On Tue, Feb 08, 2005 at 01:37:16AM +0100, Anders Saaby wrote: > > I just tried: > > mount -o ihashsize=65536,logdev=/dev/sdc1 > > Systime went from ~90% to ~5% !! :-) > ... > I couldn't really find out what hashsize was default before, so 64K was > just a (good?) guess. As I can not see any large increase in memory usage > maybe default values should be changed? > Extra note: As one of my colleagues pointed out, prime numbers are usually better for hashtable sizes, so I just tried ihashsize=64433 (prime number). This resulted in ~20% less systime and the following kernel profiles looks like prime numbers definetly _is_ a good idea: - Look at the xfs_iget_core tick change. # cat with_65k_ihash_tables_all_good.profile | sort -nr | head -20 94726 total 0,0368 69223 mwait_idle 480,7153 2636 tg3_rx 2,3877 1782 xfs_iget_core 1,4279 1555 *unknown* 1460 tg3_interrupt 4,3452 1429 tg3_start_xmit 0,9207 958 __do_softirq 4,9896 676 uhci_irq 1,2803 647 finish_task_switch 5,7768 470 handle_IRQ_event 4,1964 461 memcpy 2,6193 461 find_inode_fast 3,6016 447 local_bh_enable 2,7938 414 permission 3,2344 372 __wake_up 11,6250 369 sk_run_filter 0,3494 365 __kmalloc 2,5347 323 svc_recv 0,2347 269 s_show 0,5254 # cat with_65k_ihash_tables_all_good_prime.profile | sort -nr | head -20 95470 total 0,0371 69693 mwait_idle 483,9792 2847 tg3_rx 2,5788 1664 *unknown* 1576 tg3_start_xmit 1,0155 1479 tg3_interrupt 4,4018 929 __do_softirq 4,8385 768 finish_task_switch 6,8571 741 uhci_irq 1,4034 552 handle_IRQ_event 4,9286 526 find_inode_fast 4,1094 472 local_bh_enable 2,9500 468 memcpy 2,6591 419 __wake_up 13,0938 412 permission 3,2188 411 xfs_iget_core 0,3293 391 sk_run_filter 0,3703 373 __kmalloc 2,5903 359 svc_recv 0,2609 280 __mod_timer 1,7500 This is actually reproducable. :) - Might be interesting for default values? -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Tue Feb 8 06:26:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 06:26:02 -0800 (PST) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18EQ0Bn011087 for ; Tue, 8 Feb 2005 06:26:00 -0800 Received: from filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) by relay02.roc.ny.frontiernet.net (Postfix) with ESMTP id 3372510549; Tue, 8 Feb 2005 14:25:59 +0000 (UTC) Received: from relay02.roc.ny.frontiernet.net ([66.133.131.35]) by filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) (amavisd-new, port 10024) with LMTP id 12597-43-76; Tue, 8 Feb 2005 14:25:59 +0000 (UTC) Received: from [192.168.1.101] (67-137-96-87.dsl2.brv.mn.frontiernet.net [67.137.96.87]) by relay02.roc.ny.frontiernet.net (Postfix) with ESMTP id 2BB76102B9; Tue, 8 Feb 2005 14:25:54 +0000 (UTC) Message-ID: <4208CBF0.5050303@xfs.org> Date: Tue, 08 Feb 2005 08:25:52 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Saaby Cc: Dave Chinner , linux-xfs@oss.sgi.com Subject: Re: 2.6.11-rc3: 80-95% systime when serving files via NFS References: <222BE5975A4813449559163F8F8CF5030C22D2@cohsrv1.cohaesio.com> <20050208153427.G147390@melbourne.sgi.com> <200502081152.55315.as@cohaesio.com> <200502081310.30303.as@cohaesio.com> In-Reply-To: <200502081310.30303.as@cohaesio.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter02.roc.ny.frontiernet.net X-Virus-Status: Clean X-archive-position: 4908 X-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 Anders Saaby wrote: > > > Extra note: > > As one of my colleagues pointed out, prime numbers are usually better for > hashtable sizes, so I just tried ihashsize=64433 (prime number). > > This resulted in ~20% less systime and the following kernel profiles looks > like prime numbers definetly _is_ a good idea: > To me that usually suggests that a better hash algorithm is called for, using the prime number for a bucket count means you get into doing more complex math to work out the bucket. Steve (who has not looked at this code at all) From owner-linux-xfs Tue Feb 8 07:08:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 07:09:01 -0800 (PST) Received: from mailhub-3.iastate.edu (mailhub-3.iastate.edu [129.186.140.13]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18F8wme013408 for ; Tue, 8 Feb 2005 07:08:58 -0800 Received: from mailout-2.iastate.edu (mailout-2.iastate.edu [129.186.140.2]) by mailhub-3.iastate.edu (8.12.10/8.12.10) with SMTP id j18F8qpY031237 for ; Tue, 8 Feb 2005 09:08:52 -0600 Received: from akrherz-laptop.agron.iastate.edu(129.186.21.61) by mailout-2.iastate.edu via csmap id 93d920c6_79e3_11d9_9ce5_003048290bef_3759; Tue, 08 Feb 2005 09:10:32 -0600 (CST) Date: Tue, 8 Feb 2005 09:08:51 -0600 (CST) From: Daryl Herzmann X-X-Sender: akrherz@akrherz-laptop.agron.iastate.edu To: linux-xfs@oss.sgi.com Subject: xfs_repair Q Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4909 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akrherz@iastate.edu Precedence: bulk X-list: linux-xfs Hi, I have a 3ware hardware RAID array on RHEL Linux that I recently had a drive fail from. When I replaced the drive and rebuilt the array, I ran into a lot of *bad sectors* warnings from the 3ware controller. After the rebuild was done, the single partition was lost. So I just had one big partition, so I remade the partition and was able to mount the XFS filesystem. (whew). But, of course, I really need to run xfs_repair. When I do with the '-n' option. The first message is this... # xfs_repair -n /dev/sda1 Phase 1 - find and verify superblock... sb root inode value 128 inconsistent with calculated value 256 would reset superblock root inode pointer to 256 sb realtime bitmap inode 129 inconsistent with calculated value 257 would reset superblock realtime bitmap ino pointer to 257 sb realtime summary inode 130 inconsistent with calculated value 258 would reset superblock realtime summary ino pointer to 258 Phase 2 - using internal log - scan filesystem freespace and inode maps... bad magic # 0x414256d3 in btcnt block 216/2 block (216,77215) already used, state 7 block (216,639792) already used, state 2 block (216,657396) already used, state 2 block (216,657397) already used, state 2 block (216,657398) already used, state 2 block (216,657399) already used, state 2 block (216,657400) already used, state 2 block (216,657401) already used, state 2 .......... So my question is if I ran without the -n, would my entire filesystem be trashed? Well, it sort of is now, but I only get 'unknown error 990' on those files and directories that are bad. and kernel traces like: Feb 8 08:44:09 pircsds3 kernel: Filesystem "sd(8,1)": corrupt inode 3808429058 (btree). Unmount and run xfs_repair. Feb 8 08:44:09 pircsds3 kernel: Filesystem "sd(8,1)": XFS internal error xfs_iformat_btree at line 761 of file xfs_inode.c. Caller 0xe0a5a2a9 Any thoughts? I am running Scientific Linux's 2.4.21-27.0.2.EL.XFSsmp thanks, daryl From owner-linux-xfs Tue Feb 8 09:08:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 09:08:03 -0800 (PST) Received: from kevlar.burdell.org (dsl027-162-124.atl1.dsl.speakeasy.net [216.27.162.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18H80Hu027060 for ; Tue, 8 Feb 2005 09:08:01 -0800 Received: by kevlar.burdell.org (Postfix, from userid 1189) id A51DC66C82; Tue, 8 Feb 2005 11:54:56 -0500 (EST) Date: Tue, 8 Feb 2005 11:54:56 -0500 From: Sonny Rao To: Dave Chinner Cc: linux-xfs@oss.sgi.com Subject: Re: 2.6.11-rc3: 80-95% systime when serving files via NFS Message-ID: <20050208165456.GA15252@kevlar.burdell.org> References: <222BE5975A4813449559163F8F8CF5030C22D2@cohsrv1.cohaesio.com> <20050208153427.G147390@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050208153427.G147390@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4910 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sonny@burdell.org Precedence: bulk X-list: linux-xfs On Tue, Feb 08, 2005 at 03:34:27PM +1100, Dave Chinner wrote: > Seeing as you are running 2.6.11-rc3, you're in luck. Nathan's > inode hash tweaks were merged into -rc3, so you can increase the > size of the inode hash with a mount option. The mount option > is "ihashsize", and it specifies the width of the hash table. > i.e. `mount -o ihashsize=xxxxx /dev/sdb1 /mntpt` > > I'm not sure what the default your filesystem will be using, but > a maximum of 16*PAGE_SIZE (=64k chains on i386/x86-64) applies to the > default setting. > > If you specify a size this maximum does not apply, but if you > specify a value too large memory allocation for the hash will > silently fail and the size will be halved repeatedly until the > allocation succeeds. > Hmm, I've seen this before too running something which resembles SPEC-SFS where we have millions of inodes in cache. I'm guessing that increasing the hash-size will help us here as well? Sonny Oprofile and slab Data from kernel 2.6.9 Machine is a 4-way Power5 box. Sorry about the long lines. Here's a snippet from Oprofile: CPU: ppc64 POWER5, speed 1904 MHz (estimated) Counted CYCLES events (Processor cycles) with a unit mask of 0x00 (No unit mask) count 100000 samples % image name app name symbol name 27374923 30.6599 vmlinux-autobench-2.6.9-autokern1 vmlinux-autobench-2.6.9-autokern1 .dedicated_idle 8371486 9.3761 xfs.ko xfs .xfs_iget Snippet from slabinfo: xfs_acl 0 0 304 13 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_chashlist 766053 766640 32 112 1 : tunables 120 60 8 : slabdata 6845 6845 3 xfs_ili 779799 4449280 192 20 1 : tunables 120 60 8 : slabdata 222464 222464 480 xfs_ifork 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_efi_item 0 0 352 11 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_efd_item 0 0 360 11 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_buf_item 3682 7350 184 21 1 : tunables 120 60 8 : slabdata 350 350 0 xfs_dabuf 3 576 24 144 1 : tunables 120 60 8 : slabdata 2 4 0 xfs_da_state 5 152 488 8 1 : tunables 54 27 8 : slabdata 5 19 2 xfs_trans 88 468 872 9 2 : tunables 54 27 8 : slabdata 52 52 68 xfs_inode 5435445 6247990 528 7 1 : tunables 54 27 8 : slabdata 892570 892570 216 xfs_btree_cur 0 100 192 20 1 : tunables 120 60 8 : slabdata 0 5 0 xfs_bmap_free_item 0 0 24 144 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_buf_t 5210 6860 512 7 1 : tunables 54 27 8 : slabdata 980 980 216 linvfs_icache 5429958 6130187 584 7 1 : tunables 54 27 8 : slabdata 875741 875741 0 From owner-linux-xfs Tue Feb 8 09:15:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 09:16:00 -0800 (PST) Received: from kevlar.burdell.org (dsl027-162-124.atl1.dsl.speakeasy.net [216.27.162.124]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j18HFwGh027857 for ; Tue, 8 Feb 2005 09:15:59 -0800 Received: by kevlar.burdell.org (Postfix, from userid 1189) id 027D966C82; Tue, 8 Feb 2005 12:02:54 -0500 (EST) Date: Tue, 8 Feb 2005 12:02:55 -0500 From: Sonny Rao To: Dave Chinner Cc: linux-xfs@oss.sgi.com Subject: Re: 2.6.11-rc3: 80-95% systime when serving files via NFS Message-ID: <20050208170254.GB15252@kevlar.burdell.org> References: <222BE5975A4813449559163F8F8CF5030C22D2@cohsrv1.cohaesio.com> <20050208153427.G147390@melbourne.sgi.com> <20050208165456.GA15252@kevlar.burdell.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050208165456.GA15252@kevlar.burdell.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4911 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sonny@burdell.org Precedence: bulk X-list: linux-xfs On Tue, Feb 08, 2005 at 11:54:56AM -0500, Sonny Rao wrote: > On Tue, Feb 08, 2005 at 03:34:27PM +1100, Dave Chinner wrote: > > > Seeing as you are running 2.6.11-rc3, you're in luck. Nathan's > > inode hash tweaks were merged into -rc3, so you can increase the > > size of the inode hash with a mount option. The mount option > > is "ihashsize", and it specifies the width of the hash table. > > i.e. `mount -o ihashsize=xxxxx /dev/sdb1 /mntpt` > > > > I'm not sure what the default your filesystem will be using, but > > a maximum of 16*PAGE_SIZE (=64k chains on i386/x86-64) applies to the > > default setting. > > > > If you specify a size this maximum does not apply, but if you > > specify a value too large memory allocation for the hash will > > silently fail and the size will be halved repeatedly until the > > allocation succeeds. > > > > > Hmm, I've seen this before too running something which resembles > SPEC-SFS where we have millions of inodes in cache. > > I'm guessing that increasing the hash-size will help us here as well? > > Sonny > > Oprofile and slab Data from kernel 2.6.9 > Machine is a 4-way Power5 box. Oh yeah, one other minor detail, I have 112 XFS filesystems mounted. here, not just one big one. Sonny From owner-linux-xfs Tue Feb 8 12:20:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 12:20:21 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j18KKGLU004343 for ; Tue, 8 Feb 2005 12:20:17 -0800 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA15335; Wed, 9 Feb 2005 07:20:06 +1100 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j18KK4RS150053; Wed, 9 Feb 2005 07:20:05 +1100 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j18KK3b8149829; Wed, 9 Feb 2005 07:20:03 +1100 (EST) Date: Wed, 9 Feb 2005 07:20:03 +1100 From: Dave Chinner To: Sonny Rao Cc: linux-xfs@oss.sgi.com Subject: Re: 2.6.11-rc3: 80-95% systime when serving files via NFS Message-ID: <20050209072003.A149519@melbourne.sgi.com> References: <222BE5975A4813449559163F8F8CF5030C22D2@cohsrv1.cohaesio.com> <20050208153427.G147390@melbourne.sgi.com> <20050208165456.GA15252@kevlar.burdell.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: <20050208165456.GA15252@kevlar.burdell.org>; from sonny@burdell.org on Tue, Feb 08, 2005 at 11:54:56AM -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4912 X-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 On Tue, Feb 08, 2005 at 11:54:56AM -0500, Sonny Rao wrote: > On Tue, Feb 08, 2005 at 03:34:27PM +1100, Dave Chinner wrote: > > > Seeing as you are running 2.6.11-rc3, you're in luck. Nathan's > > inode hash tweaks were merged into -rc3, so you can increase the > > size of the inode hash with a mount option. The mount option > > is "ihashsize", and it specifies the width of the hash table. > > i.e. `mount -o ihashsize=xxxxx /dev/sdb1 /mntpt` > > > Hmm, I've seen this before too running something which resembles > SPEC-SFS where we have millions of inodes in cache. > > I'm guessing that increasing the hash-size will help us here as well? Depends on how many filesystems you're using. If this is from a small number of filesystems, then yes. If you are using typical specsfs benchmark techniques using many tens or hundreds of filesystems, then it probably wont make any big difference because each filesystem has it's own hash.... Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs Tue Feb 8 14:46:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 14:46:50 -0800 (PST) Received: from mail.cambrianventures.com (206.173.21.243.ptr.us.xo.net [206.173.21.243]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j18MkkQX013348 for ; Tue, 8 Feb 2005 14:46:46 -0800 Received: (qmail 28369 invoked from network); 8 Feb 2005 22:45:38 -0000 Received: from unknown (HELO wds19.cosmixcorp.com) (206.173.21.85) by ns0.cambrianventures.com with SMTP; 8 Feb 2005 22:45:38 -0000 Subject: Another corrupted filesystem (wds17) From: Douglass Judd To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1107902390.26459.222.camel@sedna.cambrianventures.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Tue, 08 Feb 2005 14:39:50 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4913 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doug@cosmixcorp.com Precedence: bulk X-list: linux-xfs Some background. I'm running a distributed Web crawler on 16 machines, each with 2 TB of disk space. The machines were all formated with XFS. This is the second machine that I've had to roll back to ext3 due to filesystem corruption. Here's my attempt to characterize the latest problem: Hardware: Tyan S2882G3NR Thunder K8S Pro Motherboard Dual AMD Opteron processors 3ware 9500S-8 RAID Controller 8 Western Digital 2500SD 250GB disk drives The drives are all tied together into a single RAID 5 unit. The array is partitioned as follows: 100 MB /boot partition (ext3) 16 GB swap partition the rest is the root (/) partition formatted XFS OS: Fedora Core 3 - 2.6.9 SMP kernel. The crawler application, which is built on top of MySQL, generates the following type of load (iostat): avg-cpu: %user %nice %sys %iowait %idle 7.25 0.00 1.50 48.75 42.50 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 0.00 19.40 224.88 32.34 4195.02 2824.88 2097.51 1412.44 27.29 8.74 41.56 3.87 99.50 sda 0.00 0.00 59.00 89.00 1424.00 4354.50 712.00 2177.25 39.04 6.41 41.63 6.76 100.05 sda 0.00 33.83 108.96 62.69 2288.56 3866.17 1144.28 1933.08 35.86 5.16 31.30 5.80 99.50 I came in one morning about 4 weeks ago and noticed that the filesystem on one machine (wds17) had shut down. Rebooting seemed to fix the problem. A few weeks later, I tried greping through /var/log/messages for XFS error messages and here's what I saw: /var/log# grep -i xfs messages* messages:Jan 26 04:02:08 wds17 kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 4340 of file fs/xfs/xfs_bmap.c. Caller 0xffffffff8020a125 messages:Jan 26 04:02:08 wds17 kernel: Call Trace:{xfs_bmap_read_extents+899} {xfs_iread_extents+197} messages:Jan 26 04:02:08 wds17 kernel: {xfs_dir2_put_dirent64_direct+0} messages:Jan 26 04:02:08 wds17 kernel: {xfs_bmap_last_offset+159} {xfs_dir2_isblock+31} messages:Jan 26 04:02:08 wds17 kernel: {xfs_dir2_getdents+192} {xfs_readdir+102} [...] These messages were being generated once daily at 4:02am which is when the daily cron job gets run. I then tried listing the /var/log directory and here's what I got: /var/log# ls -l total 5112 ?--------- ? ? ? ? ? acp -rw-r----- 1 root root 80 Jan 31 17:15 acpid ?--------- ? ? ? ? ? ama ?--------- ? ? ? ? ? ana ?--------- ? ? ? ? ? anaconda.log ?--------- ? ? ? ? ? boo ?--------- ? ? ? ? ? boo -rw------- 1 root root 3566 Feb 2 19:05 boot.log -rw------- 1 root root 105 Jan 23 04:02 boot.log.1 -rw------- 1 root root 8265 Jan 16 04:02 boot.log.2 drwxr-xr-x 2 canna canna 6 Sep 27 23:28 canna ?--------- ? ? ? ? ? cron -rw------- 1 root root 397138 Jan 23 04:02 cron.1 -rw------- 1 root root 382145 Jan 16 04:02 cron.2 -rw------- 1 root root 396661 Jan 9 04:02 cron.3 -rw------- 1 root root 397080 Jan 2 04:04 cron.4 drwxr-xr-x 2 lp sys 4096 Jan 23 04:02 cups -rw-r--r-- 1 root root 12936 Jan 31 17:14 dmesg drwxr-x--- 2 exim exim 6 Oct 7 03:00 exim drwxr-xr-x 2 root root 6 Jun 15 2004 fax drwxr-xr-x 2 root root 79 Dec 20 16:19 gdm ?--------- ? ? ? ? ? httpd ?--------- ? ? ? ? ? iii drwx------ 2 root root 24 Dec 16 13:29 iptraf ?--------- ? ? ? ? ? las ?--------- ? ? ? ? ? mai ?--------- ? ? ? ? ? mai ?--------- ? ? ? ? ? mai ?--------- ? ? ? ? ? mai drwxr-xr-x 2 root root 23 Dec 16 12:31 mail -rw------- 1 root root 13318 Feb 7 04:07 maillog -rw------- 1 root root 203188 Jan 9 04:02 maillog.3 drwxrwsr-x 2 root mailman 6 Oct 18 10:54 mailman ?--------- ? ? ? ? ? mes -rw------- 1 root root 1312545 Feb 7 10:21 messages -rw------- 1 root root 532217 Jan 23 04:02 messages.1 ?--------- ? ? ? ? ? messages.2 -rw------- 1 root root 535803 Jan 2 04:04 messages.4 -rw-r----- 1 mysql mysql 0 Jan 23 04:02 mysqld.log ?--------- ? ? ? ? ? mysqld.log. ?--------- ? ? ? ? ? mysqld.log. ?--------- ? ? ? ? ? mysqld.log. ?--------- ? ? ? ? ? mysqld.log. drwxr-xr-x 3 news news 65 Dec 16 13:29 news ?--------- ? ? ? ? ? pgsql drwx------ 2 root root 6 Nov 2 07:04 ppp -rw-r--r-- 1 root root 74215 Feb 7 04:03 prelink.log drwxr-xr-x 2 privoxy privoxy 6 Sep 9 15:19 privoxy ?--------- ? ? ? ? ? quagga drwx------ 3 radiusd radiusd 4096 Jan 1 04:04 radius drwxr-xr-x 2 root root 6 Jun 15 2004 routed -rw-r--r-- 1 root root 57666 Feb 7 04:04 rpmpkgs -rw-r--r-- 1 root root 57666 Jan 22 04:10 rpmpkgs.1 -rw-r--r-- 1 root root 57666 Jan 15 04:21 rpmpkgs.2 -rw-r--r-- 1 root root 57586 Jan 8 04:05 rpmpkgs.3 -rw-r--r-- 1 root root 57586 Jan 1 04:08 rpmpkgs.4 drwxr-xr-x 2 root root 4096 Feb 7 00:00 sa drwx------ 2 root root 6 Oct 19 07:53 samba ?--------- ? ? ? ? ? scr -rw------- 1 root root 114845 Feb 7 10:21 secure ?--------- ? ? ? ? ? secure.1 -rw------- 1 root root 9806 Jan 14 16:35 secure.2 -rw------- 1 root root 23535 Jan 9 00:11 secure.3 -rw------- 1 root root 14844 Jan 1 00:02 secure.4 ?--------- ? ? ? ? ? spo ?--------- ? ? ? ? ? spo -rw------- 1 root root 0 Jan 23 04:02 spooler -rw------- 1 root root 0 Jan 9 04:02 spooler.2 ?--------- ? ? ? ? ? spooler.4 drwxr-x--- 2 squid squid 6 Oct 18 14:19 squid -rw-r--r-- 1 root root 149 Jan 25 23:25 tdm_aen_0.bin -rw-rw-r-- 1 root root 0 Jan 23 04:02 up2date -rw-rw-r-- 1 root root 0 Jan 16 04:02 up2date.1 -rw-rw-r-- 1 root root 0 Jan 12 04:02 up2date.2 -rw-rw-r-- 1 root root 69 Jan 11 12:32 up2date.3 drwxr-xr-x 2 uucp uucp 40 Dec 16 13:30 uucp drwxr-xr-x 2 root root 6 Oct 5 07:53 vbox -rw-rw-r-- 1 root utmp 86784 Feb 7 10:20 wtmp ?--------- ? ? ? ? ? wtmp.1 -rw-r--r-- 1 root root 43112 Jan 11 11:12 Xorg.0.log ?--------- ? ? ? ? ? Xorg.0.log. One thing to keep in mind is that I have not noticed any corruption in my database, which comprises a fixed 200 GB InnoDB tablespace file and a few other fixed MyISAM table files (e.g. these files do not move or grow they just get updated in place). This morning, I shut the machine down and it hung while it was trying to unmount the filesystems. There was no disk activity so I did a hard reset. I then booted with a recovery CD and did an xfs_check and xfs_repair -n: # xfs_check /dev/sda3 dir 3758096515 entry LC_MESSAGES bad offset 0 dir 3758096516 entry LC_MESSAGES bad offset 0 dir 3758096516 entry charset bad offset 0 dir 3758096517 entry LC_MESSAGES bad offset 0 dir 3758096518 entry LC_MESSAGES bad offset 0 dir 3758096519 entry LC_MESSAGES bad offset 0 dir 3758096520 entry entry.desktop bad offset 0 dir 3758096521 entry LC_MESSAGES bad offset 0 dir 3758096524 entry README.bonding bad offset 0 dir 3758096527 block 0 extra leaf entry d3a74ed 2f dir 3758096527 block 0 extra leaf entry 1c7c34e2 65 dir 3758096527 block 0 extra leaf entry 3c2df83b b1 dir 3758096527 block 0 extra leaf entry 3c2df83c 14f dir 3758096527 block 0 extra leaf entry 3c2df83d 152 dir 3758096527 block 0 extra leaf entry 3c2df83e 10b dir 3758096527 block 0 extra leaf entry 3e9a84e8 a dir 3758096527 block 0 extra leaf entry 56ed8872 29 dir 3758096527 block 0 extra leaf entry 83781ccf ca dir 3758096527 block 0 extra leaf entry 8ca5f608 5a dir 3758096527 block 0 extra leaf entry 995b180b 6d dir 3758096527 block 0 extra leaf entry 9d9a80e9 129 dir 3758096527 block 0 extra leaf entry a03a7052 76 dir 3758096527 block 0 extra leaf entry a03a7054 126 dir 3758096527 block 0 extra leaf entry a03a7057 9a dir 3758096527 block 0 extra leaf entry a2260673 179 dir 3758096527 block 0 extra leaf entry a2260674 17c dir 3758096527 block 0 extra leaf entry bf5d284d 16a dir 3758096527 block 0 extra leaf entry bf5d284f 170 dir 3758096527 block 0 extra leaf entry dc3bb16f 3c dir ino 3758096527 missing leaf entry for 8363dccf/ca dir ino 3758096527 missing leaf entry for 1c7c0062/65 dir ino 3758096527 missing leaf entry for 501d8872/29 dir ino 3758096527 missing leaf entry for 995ad40b/6d dir ino 3758096527 missing leaf entry for d3a7480/2f dir ino 3758096527 missing leaf entry for 3c2df80f/b1 dir ino 3758096527 missing leaf entry for 301a84e8/a dir ino 3758096527 missing leaf entry for 3c2df80f/10b dir ino 3758096527 missing leaf entry for 3c2df80f/14f dir ino 3758096527 missing leaf entry for dc20316f/3c dir ino 3758096527 missing leaf entry for 3c2df80f/152 dir ino 3758096527 missing leaf entry for 901a80e9/129 dir ino 3758096527 missing leaf entry for a03a7334/126 dir ino 3758096527 missing leaf entry for bf5d2b37/170 dir ino 3758096527 missing leaf entry for 8ca99608/5a dir ino 3758096527 missing leaf entry for bf5d2b35/16a dir ino 3758096527 missing leaf entry for a227d674/17c dir ino 3758096527 missing leaf entry for a227d673/179 dir ino 3758096527 missing leaf entry for a03a7332/76 dir ino 3758096527 missing leaf entry for a03a7337/9a bad magic # 0x7bfaf5bb in inode 3758096532 bmbt block 0/8389223 expected level 0 got 30859 in inode 3758096532 bmbt block 0/8389223 block 0/8389223 expected type unknown got data block 0/8389223 claimed by inode 3758096532, previous inum 2953261983 bad btree nrecs (24735, min=127, max=254) in inode 3758096532 bmap block 8389223 extent count for ino 3758096532 data fork too low (0) for file format bad nblocks 87 for inode 3758096532, counted 2 bad nextents 66 for inode 3758096532, counted 0 no . entry for directory 3758096532 no .. entry for directory 3758096532 dir 3758096534 entry Center bad offset 0 block 14/612 type unknown not expected block 14/721 type unknown not expected block 14/841 type unknown not expected block 14/956 type unknown not expected block 14/2416 type unknown not expected block 14/2561 type unknown not expected block 14/2726 type unknown not expected block 14/2880 type unknown not expected block 14/3047 type unknown not expected block 14/3210 type unknown not expected block 14/3375 type unknown not expected block 14/3540 type unknown not expected block 14/4267 type unknown not expected block 14/5147 type unknown not expected block 14/10899 type unknown not expected block 14/11252 type unknown not expected block 14/11375 type unknown not expected block 14/11518 type unknown not expected block 14/11660 type unknown not expected block 14/11799 type unknown not expected block 14/11937 type unknown not expected block 14/12522 type unknown not expected block 14/12626 type unknown not expected block 14/12751 type unknown not expected block 14/12860 type unknown not expected block 14/12972 type unknown not expected block 14/13062 type unknown not expected block 14/13161 type unknown not expected block 14/13269 type unknown not expected block 14/13388 type unknown not expected block 14/13504 type unknown not expected block 14/13631 type unknown not expected block 14/13796 type unknown not expected block 14/13964 type unknown not expected block 14/14111 type unknown not expected block 14/15983 type unknown not expected block 14/16112 type unknown not expected block 14/17304 type unknown not expected block 14/17578 type unknown not expected block 14/17700 type unknown not expected block 14/17819 type unknown not expected block 14/17942 type unknown not expected block 14/18071 type unknown not expected block 14/18192 type unknown not expected block 14/18326 type unknown not expected block 14/19971 type unknown not expected block 14/20068 type unknown not expected block 14/20186 type unknown not expected block 14/20315 type unknown not expected block 14/23700 type unknown not expected block 14/24648 type unknown not expected block 14/24977 type unknown not expected block 14/25001 type unknown not expected block 14/25023 type unknown not expected block 14/25040 type unknown not expected block 14/25056 type unknown not expected block 14/25185 type unknown not expected block 14/25227 type unknown not expected block 14/25257 type unknown not expected block 14/25635 type unknown not expected block 14/26936 type unknown not expected block 14/27218 type unknown not expected block 14/8389220 type unknown not expected block 14/8389221 type unknown not expected block 14/8389222 type unknown not expected block 14/8389223 type unknown not expected block 14/8389224 type unknown not expected block 14/8389225 type unknown not expected block 14/8389226 type unknown not expected block 14/8389227 type unknown not expected block 14/8389228 type unknown not expected block 14/8389229 type unknown not expected block 14/8389230 type unknown not expected block 14/8389231 type unknown not expected block 14/8389232 type unknown not expected block 14/8389233 type unknown not expected block 14/8389234 type unknown not expected block 14/8389235 type unknown not expected block 14/8389236 type unknown not expected block 14/8389237 type unknown not expected block 14/8389238 type unknown not expected block 14/8389239 type unknown not expected block 14/8389240 type unknown not expected block 14/8389241 type unknown not expected block 14/8389242 type unknown not expected block 14/8389243 type unknown not expected link count mismatch for inode 353681 (name ?), nlink 0, counted 1 link count mismatch for inode 128 (name ?), nlink 26, counted 27 link count mismatch for inode 437972 (name ?), nlink 0, counted 1 link count mismatch for inode 49624 (name ?), nlink 0, counted 1 link count mismatch for inode 18052 (name ?), nlink 0, counted 1 link count mismatch for inode 438996 (name ?), nlink 0, counted 1 link count mismatch for inode 448011 (name ?), nlink 0, counted 1 link count mismatch for inode 448015 (name ?), nlink 0, counted 1 link count mismatch for inode 262530 (name ?), nlink 0, counted 1 link count mismatch for inode 16990 (name ?), nlink 0, counted 1 link count mismatch for inode 368079 (name ?), nlink 0, counted 1 link count mismatch for inode 805306496 (name ?), nlink 25, counted 24 link count mismatch for inode 1073741960 (name ?), nlink 40, counted 39 link count mismatch for inode 1610662360 (name ?), nlink 2, counted 1 link count mismatch for inode 1879310722 (name ?), nlink 2, counted 1 disconnected inode 3758386284, nlink 1 disconnected inode 3758316708, nlink 1 disconnected inode 3758148566, nlink 1 disconnected inode 3758386285, nlink 1 disconnected inode 3758316709, nlink 1 disconnected inode 3758148567, nlink 1 disconnected inode 3758386286, nlink 1 disconnected inode 3758316710, nlink 1 disconnected inode 3758148568, nlink 1 disconnected inode 3758450065, nlink 1 disconnected inode 3758386287, nlink 1 disconnected inode 3758316711, nlink 1 disconnected inode 3758148569, nlink 1 disconnected inode 3758386288, nlink 1 disconnected inode 3758316712, nlink 1 disconnected inode 3758148570, nlink 1 disconnected inode 3758386289, nlink 1 disconnected inode 3758316713, nlink 1 disconnected inode 3758148571, nlink 1 disconnected inode 3758386290, nlink 1 [ ... 6325 of these disconnected lines total ...] Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 entry contains offset out of order in shortform dir 3758096515 would have corrected entry offsets in directory 3758096515 entry contains offset out of order in shortform dir 3758096516 entry contains offset out of order in shortform dir 3758096516 would have corrected entry offsets in directory 3758096516 entry contains offset out of order in shortform dir 3758096517 would have corrected entry offsets in directory 3758096517 entry contains offset out of order in shortform dir 3758096518 would have corrected entry offsets in directory 3758096518 entry contains offset out of order in shortform dir 3758096519 would have corrected entry offsets in directory 3758096519 entry contains offset out of order in shortform dir 3758096520 would have corrected entry offsets in directory 3758096520 entry contains offset out of order in shortform dir 3758096521 would have corrected entry offsets in directory 3758096521 entry contains illegal character in shortform dir 3758096523 would have junked entry "BuiltInSes" in directory inode 3758096523 entry contains offset out of order in shortform dir 3758096524 would have corrected entry offsets in directory 3758096524 entry at block 0 offset 80 in directory inode 3758096527 has illegal name " las": would clear entry entry at block 0 offset 328 in directory inode 3758096527 has illegal name " scr": would clear entry entry at block 0 offset 376 in directory inode 3758096527 has illegal name " iii": would clear entry entry at block 0 offset 480 in directory inode 3758096527 has illegal name " ama": would clear entry entry at block 0 offset 720 in directory inode 3758096527 has illegal name " ana": would clear entry entry at block 0 offset 808 in directory inode 3758096527 has illegal name " acp": would clear entry entry at block 0 offset 872 in directory inode 3758096527 has illegal name " mes": would clear entry entry at block 0 offset 944 in directory inode 3758096527 has illegal name " mai": would clear entry entry at block 0 offset 1232 in directory inode 3758096527 has illegal name " mai": would clear entry entry at block 0 offset 1416 in directory inode 3758096527 has illegal name " mysqld.log.": would clear entry entry at block 0 offset 1616 in directory inode 3758096527 has illegal name " Xorg.0.log.": would clear entry entry at block 0 offset 2136 in directory inode 3758096527 has illegal name " mysqld.log.": would clear entry entry at block 0 offset 2352 in directory inode 3758096527 has illegal name " mai": would clear entry entry at block 0 offset 2376 in directory inode 3758096527 has illegal name " mai": would clear entry entry at block 0 offset 2680 in directory inode 3758096527 has illegal name " mysqld.log.": would clear entry entry at block 0 offset 2704 in directory inode 3758096527 has illegal name " mysqld.log.": would clear entry entry at block 0 offset 2896 in directory inode 3758096527 has illegal name " spo": would clear entry entry at block 0 offset 2944 in directory inode 3758096527 has illegal name " spo": would clear entry entry at block 0 offset 3016 in directory inode 3758096527 has illegal name " boo": would clear entry entry at block 0 offset 3040 in directory inode 3758096527 has illegal name " boo": would clear entry bad magic # 0x7bfaf5bb in inode 3758096532 (data fork) bmbt block 8389223 bad data fork in inode 3758096532 would have cleared inode 3758096532 entry contains offset out of order in shortform dir 3758096534 would have corrected entry offsets in directory 3758096534 - 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... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 entry "man3" at block 0 offset 96 in directory inode 1073741960 references free inode 3758096532 would clear inode number in entry at offset 96... - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 entry contains offset out of order in shortform dir 3758096515 would have corrected entry offsets in directory 3758096515 entry contains offset out of order in shortform dir 3758096516 entry contains offset out of order in shortform dir 3758096516 would have corrected entry offsets in directory 3758096516 entry contains offset out of order in shortform dir 3758096517 entry "charset" in shortform directory 3758096517 references non-existent inode 368079 would have junked entry "charset" in directory inode 3758096517 would have corrected entry offsets in directory 3758096517 entry contains offset out of order in shortform dir 3758096518 would have corrected entry offsets in directory 3758096518 entry contains offset out of order in shortform dir 3758096519 would have corrected entry offsets in directory 3758096519 entry contains offset out of order in shortform dir 3758096520 would have corrected entry offsets in directory 3758096520 entry contains offset out of order in shortform dir 3758096521 would have corrected entry offsets in directory 3758096521 entry contains illegal character in shortform dir 3758096523 would have junked entry "BuiltInSes" in directory inode 3758096523 entry contains offset out of order in shortform dir 3758096524 would have corrected entry offsets in directory 3758096524 entry "httpd" at block 0 offset 280 in directory inode 3758096527 references non-existent inode 49624 would clear inode number in entry at offset 280... entry "quagga" at block 0 offset 408 in directory inode 3758096527 references non-existent inode 262530 would clear inode number in entry at offset 408... entry "pgsql" at block 0 offset 544 in directory inode 3758096527 references non-existent inode 353681 would clear inode number in entry at offset 544... entry "anaconda.log" at block 0 offset 696 in directory inode 3758096527 references non-existent inode 437972 would clear inode number in entry at offset 696... entry "wtmp.1" at block 0 offset 1736 in directory inode 3758096527 references non-existent inode 18052 would clear inode number in entry at offset 1736... entry "messages.2" at block 0 offset 1824 in directory inode 3758096527 references non-existent inode 448011 would clear inode number in entry at offset 1824... entry "cron" at block 0 offset 2496 in directory inode 3758096527 references non-existent inode 438996 would clear inode number in entry at offset 2496... entry "secure.1" at block 0 offset 2824 in directory inode 3758096527 references non-existent inode 16990 would clear inode number in entry at offset 2824... entry "spooler.4" at block 0 offset 2872 in directory inode 3758096527 references non-existent inode 448015 would clear inode number in entry at offset 2872... bad magic # 0x7bfaf5bb in inode 3758096532 (data fork) bmbt block 8389223 bad data fork in inode 3758096532 would have cleared inode 3758096532 entry contains offset out of order in shortform dir 3758096534 would have corrected entry offsets in directory 3758096534 - 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 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... entry "man3" in directory inode 1073741960 points to free inode 3758096532, would junk entry entry "charset" in shortform directory 3758096517 references non-existent inode 368079 would junk entry entry "charset" in shortform directory 3758096517 references non-existent inode 368079 would junk entry entry "log" in dir inode 805306496 inconsistent with .. value (128) in ino 3758096527, would clear entry "log" - traversal finished ... - traversing all unattached subtrees ... entry "httpd" in directory inode 3758096527 points to non-existent inode, would junk entry entry "quagga" in directory inode 3758096527 points to non-existent inode, would junk entry entry "pgsql" in directory inode 3758096527 points to non-existent inode, would junk entry entry "anaconda.log" in directory inode 3758096527 points to non-existent inode, would junk entry entry "wtmp.1" in directory inode 3758096527 points to non-existent inode, would junk entry entry "messages.2" in directory inode 3758096527 points to non-existent inode, would junk entry entry "cron" in directory inode 3758096527 points to non-existent inode, would junk entry entry "secure.1" in directory inode 3758096527 points to non-existent inode, would junk entry entry "spooler.4" in directory inode 3758096527 points to non-existent inode, would junk entry bad hash table for directory inode 3758096527 (hash value mismatch): would rebuild - traversals finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 1610662360, would move to lost+found disconnected dir inode 1879310722, would move to lost+found disconnected dir inode 3758096527, would move to lost+found disconnected inode 3758104518, would move to lost+found disconnected inode 3758105657, would move to lost+found disconnected inode 3758105658, would move to lost+found disconnected inode 3758105659, would move to lost+found disconnected inode 3758105660, would move to lost+found disconnected inode 3758105661, would move to lost+found disconnected inode 3758105662, would move to lost+found disconnected inode 3758105663, would move to lost+found disconnected inode 3758105664, would move to lost+found disconnected inode 3758105665, would move to lost+found disconnected inode 3758105666, would move to lost+found disconnected inode 3758105667, would move to lost+found disconnected inode 3758105668, would move to lost+found disconnected inode 3758105669, would move to lost+found disconnected inode 3758105670, would move to lost+found disconnected inode 3758105671, would move to lost+found disconnected inode 3758105672, would move to lost+found [...] From owner-linux-xfs Tue Feb 8 15:51:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 15:51:53 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j18Npo74016882 for ; Tue, 8 Feb 2005 15:51:51 -0800 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA20746; Wed, 9 Feb 2005 10:51:33 +1100 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j18NpWRS150694; Wed, 9 Feb 2005 10:51:32 +1100 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j18NpUvQ150797; Wed, 9 Feb 2005 10:51:30 +1100 (EST) Date: Wed, 9 Feb 2005 10:51:29 +1100 From: Dave Chinner To: David Sparks Cc: linux-xfs@oss.sgi.com Subject: Re: external log vs internal log and mkfs.xfs options Message-ID: <20050209105129.A150160@melbourne.sgi.com> References: <4202C6DA.1060809@activestate.com> <20050204115943.E1943129@wobbly.melbourne.sgi.com> <42081627.4090307@activestate.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: <42081627.4090307@activestate.com>; from daves@activestate.com on Mon, Feb 07, 2005 at 05:30:15PM -0800 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4914 X-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 On Mon, Feb 07, 2005 at 05:30:15PM -0800, David Sparks wrote: > Nobody commented on this question though, I'll put it up again. Most of > the information I've gathered on external logs dates back to the IRIX > days -- I hope there isn't anything out of date there. > > > Regarding external logs, I've never formatted a XFS with an external > > log. From what I can gather (google, man pages), doing so is supposed > > to reduce disk head seeking hence performance is improved. Is anyone > > aware of any benchmarks that explore internal/external logs and sizes? Anything that is metadata intensive - dbench, postmark, etc. Run the benchmark, recreate the fs with different parameters, run it again and observe the difference. Easily scriptable.... > Is there any advantage to an external log on a separate partition on the > same device, as opposed to an external log on a separate device? No. Often this is a disadvantage because the log is usually placed in the center of the filesystem to minimise _average_ disk seek time for log writes. If it's in a different partition on the same disk, then the seek penalty for log writes on average is going to be greater than if it was internal to the filesystem because seek distances will be greater. > Basically is an external log only for performance benefits or are there > robustness benefits also? With external logs you can use different redundancy strategies to the rest of the filesystem (e.g. mirror instead of RAID5, different hw, etc) that can increase robustness or performance of the log. External logs provide flexibility; how you use that is up to you.... Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs Tue Feb 8 16:37:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Feb 2005 16:37:48 -0800 (PST) Received: from mail23.syd.optusnet.com.au (mail23.syd.optusnet.com.au [211.29.133.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j190bgh1022145 for ; Tue, 8 Feb 2005 16:37:43 -0800 Received: from saturn (c211-28-166-127.eburwd2.vic.optusnet.com.au [211.28.166.127]) by mail23.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j190bRh7007501; Wed, 9 Feb 2005 11:37:27 +1100 Received: from [192.168.1.54] (helo=kennedy ident=Debian-exim) by saturn with esmtp (Exim 3.35 #1 (Debian)) id 1CyfrC-0007h5-00; Wed, 09 Feb 2005 11:37:26 +1100 Received: from localhost ([127.0.0.1] helo=kennedy ident=stewart) by kennedy with esmtp (Exim 4.44) id 1CyfqU-00066N-4w; Wed, 09 Feb 2005 11:36:42 +1100 Subject: Re: ACID Question From: Stewart Smith To: Andi Kleen Cc: Rick Spillane , linux-xfs@oss.sgi.com In-Reply-To: <20050208092345.GB55921@muc.de> References: <1107841758.19311.21.camel@kennedy> <20050208092345.GB55921@muc.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HFfJqHdD7mgwk79Bz1H9" Date: Wed, 09 Feb 2005 11:36:35 +1100 Message-Id: <1107909395.19312.29.camel@kennedy> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4915 X-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 --=-HFfJqHdD7mgwk79Bz1H9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-02-08 at 10:23 +0100, Andi Kleen wrote: > > Linux does sync on fsync(), MacOS X does not (for internal drives at > > least). >=20 > This would sound extremly bad for MacOS X if true. I hope it is not. It's true all right - you have to use a special fcntl to do a 'real fsync'. We (MySQL) found that this was the cause of some table corruption on OSX. Needless to say, we now do the special foo if on OSX. Although I hate to think what other apps are out there thinking they're safe when they're not. --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-HFfJqHdD7mgwk79Bz1H9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iQCVAwUAQglbE4wDm44RooHBAQIpNgP+K0zacfHLAc/o5n5uPOsCbnQ+RL/8WLgF VAnyvUnCf2X0GnH9OLQApxRk0c+MO2z4SiQ0aHhB6OKqmvLF6azuR5/p3r1cpVAr 1LTl5isiu9oAEp0OWvpsIj1GgnxdKCnxdk7Gergw5hnE0EyuelUTsbvg0fXXyeH6 fgGcqKSE7aA= =BMi0 -----END PGP SIGNATURE----- --=-HFfJqHdD7mgwk79Bz1H9-- From owner-linux-xfs Thu Feb 10 16:15:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Feb 2005 16:15:43 -0800 (PST) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B0FbqF019823 for ; Thu, 10 Feb 2005 16:15:38 -0800 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j1B0FRla007103; Fri, 11 Feb 2005 11:15:27 +1100 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j1B0FR1E007101; Fri, 11 Feb 2005 11:15:27 +1100 Date: Fri, 11 Feb 2005 11:15:27 +1100 From: Nathan Scott Message-Id: <200502110015.j1B0FR1E007101@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: PARTIAL TAKE 930364 - osync write issue X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4917 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1016 Lines: 22 Fix a problem where synchronous writes could return EAGAIN incorrectly for pinned inodes. There's more to be done here to speed things up a bit, but this resolves the immediate issue. Date: Fri Feb 11 11:07:46 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: lord@xfs.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:21460a xfs_vnodeops.c - 1.639 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.639&r2=text&tr2=1.638&f=h linux-2.6/xfs_lrw.c - 1.221 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.221&r2=text&tr2=1.220&f=h linux-2.6/xfs_super.c - 1.325 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.325&r2=text&tr2=1.324&f=h linux-2.4/xfs_super.c - 1.300 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.300&r2=text&tr2=1.299&f=h From owner-linux-xfs Thu Feb 10 19:36:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Feb 2005 19:36:02 -0800 (PST) Received: from phxexch01.2wire.com (phxexch01.2wire.com [65.203.128.151]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B3ZvUX002240 for ; Thu, 10 Feb 2005 19:35:58 -0800 Received: from exchange02.corp.2wire.com ([10.0.0.72]) by phxexch01.2wire.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 20:35:53 -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="iso-8859-1" Subject: xfs kernel panic in 2.4.25 with mips Date: Thu, 10 Feb 2005 19:35:48 -0800 Message-ID: <2EC66A66CED84641A69764BF65D877D009F5CC@exchange02.corp.2wire.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xfs kernel panic in 2.4.25 with mips Thread-Index: AcUP6sa4ECQ7oaDeRG2tjfzHUD8ZGQ== From: "Josh Radel" To: X-OriginalArrivalTime: 11 Feb 2005 03:35:53.0899 (UTC) FILETIME=[CA325FB0:01C50FEA] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1B3a0UX002247 X-archive-position: 4918 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jradel@2wire.com Precedence: bulk X-list: linux-xfs Content-Length: 12825 Lines: 281 I'm attempting to use XFS on an embedded mips32 system running the 2.4.25 kernel, and am running into some kernel panics. Here are three different scenarios with different (though 100% reproducible) panics. In all situations, XFS is compiled into the kernel (but no other XFS options, except for case (3)). I've included the kernel oops message as well as the version run through ksymoops for each case at the end of this message. 1) UDF Read Filesystem is also compiled into the kernel; kernel panics when kernel is loading (last printouts: Journalled Block Device driver loaded udf: registering filesystem SGI XFS with no debug enabled ...then the panic... 2) UDF Filesystem NOT compiled into the kernel, kernel (and nfs-mounted root fs) load properly, I can successfully create an XFS filesystem on a partition using mkfs.xfs, I can successfully mount the XFS partition (various combinations of mount options work), I can successfully 'ls' the empty mount point. But when I try to create a file or directory in the XFS partition, the kernel panics. 3) UDF Filesystem NOT compiled into the kernel, XFS Tracing support and Debugging support ARE enabled. Panics at kernel load time (final print statement is "SGI XFS with tracing, debug enabled"), with a different trace than in (1). For reference, in (2), when the kernel successfully loads, the next message after "SGI XFS with no debug enabled" is "pty: 256 Unix98 ptys configured". The XFS source is stock 2.4.25 kernel source, which works fine for me on an x86; and with no XFS enabled, I haven't seen any other problems on the embedded board. Any ideas on where I can start trying to debug this? Thanks, Josh Here are the kernel panics and ksymoops traces for the above cases. (1) Journalled Block Device driver loaded udf: registering filesystem SGI XFS with no debug enabled Break instruction in kernel code in traps.c::do_bp, line 591: $0 : 00000000 10108400 802e0000 8027c650 8027c630 00000188 00000000 00000000 $8 : 000001f0 ffffffe0 00000000 00000000 80320254 fffffffe ffffffff 00000010 $16: 00000000 802bc4cc 00000000 00000188 8ffd7ec4 8ffd1850 8027c630 8febbc90 $24: 00000007 00000001 882de000 882dfeb0 0feb5380 80031d8c Hi : 00000010 Lo : 0000000c epc : 80031d98 Not tainted Status: 10108403 Cause : 00800024 PrId : 0001810b Process swapper (pid: 1, stackpage=882de000) Stack: 802f0000 80032c8c 00800020 8000574c 882c7a28 fffffffd 00000190 80013b98 00000000 802bc4cc 00010f00 8ffbda28 8ffd7ec4 8ffd1850 8ffd7e88 8febbc90 0feb5380 80162c18 00000000 802bc4cc 00000000 802b0ab4 00000000 00000000 801490c8 8ffbda28 00000000 00000000 8015cab8 00000000 802b09b0 802b0978 882c52a0 00000000 00000000 00000040 80268bbc 802ce390 802bc45c 802bc4cc ... Call Trace: [<80032c8c>] [<8000574c>] [<80013b98>] [<80162c18>] [<801490c8>] [<8015cab8>] [<80268bbc>] [<800017b4>] [<800017b4>] [<800017c4>] [<800017b4>] [<8000575c>] [<80013b98>] [<8027bb4c>] [<801645c4>] [<8000574c>] Code: 2c420013 144000df 3c02802e <0000800d> 3c02ffff 34420fff 02421024 1440012d 00000000 Kernel panic: Attempted to kill init! ksymoops: Break instruction in kernel code in traps.c::do_bp, line 591: $0 : 00000000 10108400 802e0000 8027c6a0 8027c680 00000188 00000000 00000000 $8 : 000001f0 ffffffe0 00000000 00000000 80320254 fffffffe ffffffff 00000010 $16: 00000000 802bc4cc 00000000 00000188 8ffd7ec4 8ffd1850 8027c680 8febbc90 $24: 00000007 00000001 882de000 882dfeb0 0feb5380 80031d8c Hi : 00000010 Lo : 0000000c epc : 80031d98 Not tainted Status: 10108403 Cause : 00800024 Process swapper (pid: 1, stackpage=882de000) Stack: 802f0000 80032c8c 00800020 8000574c 882c7a28 fffffffd 00000190 80013b98 00000000 802bc4cc 00010f00 8ffbda28 8ffd7ec4 8ffd1850 8ffd7e88 8febbc90 0feb5380 80162c18 00000000 802bc4cc 00000000 802b0ab4 00000000 00000000 801490c8 8ffbda28 00000000 00000000 8015cab8 00000000 802b09b0 802b0978 882c52a0 00000000 00000000 00000040 80268c0c 802ce390 802bc45c 802bc4cc ... Call Trace: [<80032c8c>] [<8000574c>] [<80013b98>] [<80162c18>] [<801490c8>] [<8015cab8>] [<80268c0c>] [<800017b4>] [<800017b4>] [<800017c4>] [<800017b4>] [<8000575c>] [<80013b98>] [<8027bb9c>] [<801645c4>] [<8000574c>] Code: 2c420013 144000df 3c02802e <0000800d> 3c02ffff 34420fff 02421024 1440012d 00000000 Error (Oops_bfd_perror): /tmp/ksymoops.4lBoYp Invalid bfd target >>$2; 802e0000 >>$3; 8027c6a0 <__clz_tab+13d60/2e424> >>$4; 8027c680 <__clz_tab+13d40/2e424> >>$17; 802bc4cc <__initcall_end+0/b34> >>$22; 8027c680 <__clz_tab+13d40/2e424> >>$31; 80031d8c >>PC; 80031d98 <===== Trace; 80032c8c Trace; 8000574c Trace; 80013b98 Trace; 80162c18 Trace; 801490c8 Trace; 8015cab8 Trace; 80268c0c <__clz_tab+2cc/2e424> Trace; 800017b4 Trace; 800017b4 Trace; 800017c4 Trace; 800017b4 Trace; 8000575c Trace; 80013b98 Trace; 8027bb9c <__clz_tab+1325c/2e424> Trace; 801645c4 Trace; 8000574c Kernel panic: Attempted to kill init! 1 error issued. Results may not be reliable. (2) do_cpu invoked from kernel context! in traps.c::do_cpu, line 676: $0 : 00000000 10108400 0000001e 00000008 8fe2c000 8fe5c000 8ffe7000 882c3d68 $8 : 00108413 dfffffff 00100000 882bb464 802b5bf4 00003f92 88000004 802d0000 $16: 8ffe71a0 882c4200 8fe2c000 8ffe7120 8fe5c000 00000000 8ffe7120 802c87c0 $24: ba2e8ba3 fffffe00 8fe2c000 8fe2deb0 8fe2deb0 800113cc Hi : 00000000 Lo : 00000002 epc : 8000b9a4 Not tainted Status: 10108403 Cause : 1080002c PrId : 0001810b Process mkdir (pid: 136, stackpage=8fe2c000) Stack: ffffffff 000001ed 8fe5c000 80018e14 10108401 00000000 80338200 882c4200 8fe2c000 00000000 802d0000 00407a90 1000dca8 10010000 1000dc70 800191d4 00000001 8ffe71a0 00000041 882c41ed 2ae0bed0 00000000 00000000 00000004 00000002 80019380 00000000 00000004 00000002 00407a90 8000b0e0 80010a34 1000dd00 1000dca8 1000dcb8 1001100f ffffffff 00000000 00000000 2ac76580 ... Call Trace: [<80018e14>] [<800191d4>] [<80019380>] [<8000b0e0>] [<80010a34>] [<8014ec04>] ksymoops: Break instruction in kernel code in traps.c::do_bp, line 591: $0 : 00000000 10108400 802e0000 8027c6a0 8027c680 00000188 00000000 00000000 $8 : 000001f0 ffffffe0 00000000 00000000 80320254 fffffffe ffffffff 00000010 $16: 00000000 802bc4cc 00000000 00000188 8ffd7ec4 8ffd1850 8027c680 8febbc90 $24: 00000007 00000001 882de000 882dfeb0 0feb5380 80031d8c Hi : 00000010 Lo : 0000000c epc : 80031d98 Not tainted Status: 10108403 Cause : 00800024 Process swapper (pid: 1, stackpage=882de000) Stack: 802f0000 80032c8c 00800020 8000574c 882c7a28 fffffffd 00000190 80013b98 00000000 802bc4cc 00010f00 8ffbda28 8ffd7ec4 8ffd1850 8ffd7e88 8febbc90 0feb5380 80162c18 00000000 802bc4cc 00000000 802b0ab4 00000000 00000000 801490c8 8ffbda28 00000000 00000000 8015cab8 00000000 802b09b0 802b0978 882c52a0 00000000 00000000 00000040 80268c0c 802ce390 802bc45c 802bc4cc ... Call Trace: [<80032c8c>] [<8000574c>] [<80013b98>] [<80162c18>] [<801490c8>] [<8015cab8>] [<80268c0c>] [<800017b4>] [<800017b4>] [<800017c4>] [<800017b4>] [<8000575c>] [<80013b98>] [<8027bb9c>] [<801645c4>] [<8000574c>] Code: 2c420013 144000df 3c02802e <0000800d> 3c02ffff 34420fff 02421024 1440012d 00000000 Error (Oops_bfd_perror): /tmp/ksymoops.KNgLfz Invalid bfd target >>$2; 802e0000 >>$3; 8027c6a0 <__clz_tab+29a70/2d370> >>$4; 8027c680 <__clz_tab+29a50/2d370> >>$17; 802bc4cc >>$22; 8027c680 <__clz_tab+29a50/2d370> >>$31; 80031d8c >>PC; 80031d98 <===== Trace; 80032c8c Trace; 8000574c Trace; 80013b98 Trace; 80162c18 Trace; 801490c8 <_pagebuf_lookup_pages+4c/500> Trace; 8015cab8 Trace; 80268c0c <__clz_tab+15fdc/2d370> Trace; 800017b4 Trace; 800017b4 Trace; 800017c4 Trace; 800017b4 Trace; 8000575c Trace; 80013b98 Trace; 8027bb9c <__clz_tab+28f6c/2d370> Trace; 801645c4 Trace; 8000574c Kernel panic: Attempted to kill init! 1 error issued. Results may not be reliable. (3) Starting kswapd Journalled Block Device driver loaded SGI XFS with tracing, debug enabled Break instruction in kernel code in traps.c::do_bp, line 591: $0 : 00000000 10108400 80310000 802a570b 802a56f4 00000010 00000000 00000000 $8 : 00000d38 00000001 80310000 00000d39 80310000 80310000 80310000 80310000 $16: 80320000 80300000 00000000 00000010 8ffd7ec4 8ffd1850 802a56f4 8febbc90 $24: ba2e8ba3 00000001 882ce000 882cfea8 0feb5380 80031d8c Hi : 00000016 Lo : 00000002 epc : 80031d98 Not tainted Status: 10108403 Cause : 00800024 PrId : 0001810b Process swapper (pid: 1, stackpage=882ce000) Stack: fffff2c7 80310000 80310000 0000003c 802f28a8 00000027 10108401 8001567c 80320000 80300000 00010f00 8ffbda28 8ffd7ec4 8ffd1850 8ffd7e88 8febbc90 0feb5380 8017e540 80045cfc 80045c8c 00000000 00000000 00000000 00000000 8017fdfc 802e44c8 00010f00 8ffbda28 8ffd7ec4 8ffd1850 802e4460 802e44c8 802d8964 802d8950 882c52a0 00000000 00000000 00000040 8028497c 802f6390 ... Call Trace: [<8001567c>] [<8017e540>] [<80045cfc>] [<80045c8c>] [<8017fdfc>] [<8028497c>] [<80270150>] [<8027011c>] [<800017b4>] [<800017b4>] [<800017c4>] [<800017b4>] [<8000575c>] [<80013b98>] [<802a4278>] [<80180694>] [<8000574c>] Code: 2c420013 144000df 3c028031 <0000800d> 3c02ffff 34420fff 02421024 1440012d 00000000 Kernel panic: Attempted to kill init! ksymoops: Break instruction in kernel code in traps.c::do_bp, line 591: $0 : 00000000 10108400 802e0000 8027c6a0 8027c680 00000188 00000000 00000000 $8 : 000001f0 ffffffe0 00000000 00000000 80320254 fffffffe ffffffff 00000010 $16: 00000000 802bc4cc 00000000 00000188 8ffd7ec4 8ffd1850 8027c680 8febbc90 $24: 00000007 00000001 882de000 882dfeb0 0feb5380 80031d8c Hi : 00000010 Lo : 0000000c epc : 80031d98 Not tainted Status: 10108403 Cause : 00800024 Process swapper (pid: 1, stackpage=882de000) Stack: 802f0000 80032c8c 00800020 8000574c 882c7a28 fffffffd 00000190 80013b98 00000000 802bc4cc 00010f00 8ffbda28 8ffd7ec4 8ffd1850 8ffd7e88 8febbc90 0feb5380 80162c18 00000000 802bc4cc 00000000 802b0ab4 00000000 00000000 801490c8 8ffbda28 00000000 00000000 8015cab8 00000000 802b09b0 802b0978 882c52a0 00000000 00000000 00000040 80268c0c 802ce390 802bc45c 802bc4cc ... Call Trace: [<80032c8c>] [<8000574c>] [<80013b98>] [<80162c18>] [<801490c8>] [<8015cab8>] [<80268c0c>] [<800017b4>] [<800017b4>] [<800017c4>] [<800017b4>] [<8000575c>] [<80013b98>] [<8027bb9c>] [<801645c4>] [<8000574c>] Code: 2c420013 144000df 3c02802e <0000800d> 3c02ffff 34420fff 02421024 1440012d 00000000 Error (Oops_bfd_perror): /tmp/ksymoops.YBrwSi Invalid bfd target >>$2; 802e0000 >>$3; 8027c6a0 <__udivmoddi4+140/63c> >>$4; 8027c680 <__udivmoddi4+120/63c> >>$12; 80320254 >>$17; 802bc4cc <__clz_tab+37dcc/3ad70> >>$22; 8027c680 <__udivmoddi4+120/63c> >>$31; 80031d8c >>PC; 80031d98 <===== Trace; 80032c8c Trace; 8000574c Trace; 80013b98 Trace; 80162c18 Trace; 801490c8 Trace; 8015cab8 Trace; 80268c0c Trace; 800017b4 Trace; 800017b4 Trace; 800017c4 Trace; 800017b4 Trace; 8000575c Trace; 80013b98 Trace; 8027bb9c Trace; 801645c4 Trace; 8000574c Kernel panic: Attempted to kill init! 1 error issued. Results may not be reliable. From owner-linux-xfs Fri Feb 11 00:25:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 00:25:16 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1B8PDFx018204 for ; Fri, 11 Feb 2005 00:25:13 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1CzW6y-0007xy-1T; Fri, 11 Feb 2005 08:25:12 +0000 Date: Fri, 11 Feb 2005 08:25:11 +0000 From: Christoph Hellwig To: Josh Radel Cc: linux-xfs@oss.sgi.com Subject: Re: xfs kernel panic in 2.4.25 with mips Message-ID: <20050211082511.GA30443@infradead.org> References: <2EC66A66CED84641A69764BF65D877D009F5CC@exchange02.corp.2wire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2EC66A66CED84641A69764BF65D877D009F5CC@exchange02.corp.2wire.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4919 X-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: 582 Lines: 6 On Thu, Feb 10, 2005 at 07:35:48PM -0800, Josh Radel wrote: > I'm attempting to use XFS on an embedded mips32 system running the 2.4.25 kernel, and am running into some kernel panics. Here are three different scenarios with different (though 100% reproducible) panics. In all situations, XFS is compiled into the kernel (but no other XFS options, except for case (3)). I've included the kernel oops message as well as the version run through ksymoops for each case at the end of this message. 2.4.25 is from stoneage. Please retry with 2.4.29 or even better a recent 2.6 kernel. From owner-linux-xfs Fri Feb 11 04:18:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 04:18:26 -0800 (PST) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BCINPT029701 for ; Fri, 11 Feb 2005 04:18:24 -0800 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id 412698C307A for ; Fri, 11 Feb 2005 13:18:23 +0100 (CET) Received: from wing.madduck.net (84-72-25-172.dclient.hispeed.ch [84.72.25.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "wing.madduck.net", Issuer "madduck.net CA" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id 9FC38895D6B for ; Fri, 11 Feb 2005 13:18:22 +0100 (CET) Received: by wing.madduck.net (Postfix, from userid 1000) id 35537602E9A; Fri, 11 Feb 2005 13:18:29 +0100 (CET) Date: Fri, 11 Feb 2005 13:18:29 +0100 From: martin f krafft To: linux xfs mailing list Subject: the thing with the binary zeroes Message-ID: <20050211121829.GA30049@localhost.localdomain> Mail-Followup-To: linux xfs mailing list Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline X-OS: Debian GNU/Linux 3.1 kernel 2.6.10-wing i686 X-Mailer: Mutt 1.5.6+20040907i (CVS) X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by albatross.madduck.net X-Virus-Status: Clean X-archive-position: 4920 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: linux-xfs Content-Length: 2846 Lines: 72 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I am a very happy user of XFS on servers and workstations alike. Nevertheless, I have also been bitten by the "binary zeroes problem"... which may not be a problem but a feature, but it's hard to tell as the information about it is sparse. I am writing this message to create a record for our ancestors which should finally contain all answers. Sorry if I am repeating anything, I really tried to collect all available information for weeks, and while there was plenty relevant to the developers, users are left in the rain (at least I felt so). =46rom what I understand, binary zeroes appear to replace file contents after a system crash. The FAQ says that this is because the file has been allocated, but the system had no time to write, so it was empty. What surprises me here is that XFS nulls the file. Normally, a newly allocated file is garbage to be overwritten, not one zero after the other. Or are the zeroes overlaid on read() when the inode is inconsistent? This would give credit to another explanation I have heard: The nulling is done to prevent a file from potentially exposing contents of another file... in this case, a previously deleted file. So far so good, it seems like this is all based on the infamous "mommy, someone pulled the power plug" problem, and XFS simply does its best to keep the damage low. But then I cannot figure out just why existing files would appear to be nulled out after a crash. Sure, the file could have been opened for write-truncate just when the crash happened, and if that write never completes, XFS will overlay zeroes to the previous file contents. I want to end this email with two questions. First, is the above correct, or is there anything to add/change? And second, if XFS overlays zeroes over existing file contents, is there any way to get the previous data off the disk short of accessing the device directly? Or, put differently: can I temporarily disable or circumvent the nullification if I really need to be able to get at the data before the incomplete truncation? Thanks for your time, --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 due to lack of interest tomorrow has been cancelled. --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCDKKVIgvIgzMMSnURAoX6AJ9AvsYy+NFkThCJVch+zjbMAKmwbwCg1xcW 88MRsDV/XCpnWSXwjQJshig= =uatI -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-linux-xfs Fri Feb 11 05:00:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 05:00:35 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BD0WO6002398 for ; Fri, 11 Feb 2005 05:00:33 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 52660D033E; Fri, 11 Feb 2005 14:00:30 +0100 (CET) To: linux xfs mailing list Cc: madduck@madduck.net Subject: Re: the thing with the binary zeroes References: <20050211121829.GA30049@localhost.localdomain> From: Andi Kleen Date: Fri, 11 Feb 2005 14:00:30 +0100 In-Reply-To: <20050211121829.GA30049@localhost.localdomain> (martin f. krafft's message of "Fri, 11 Feb 2005 13:18:29 +0100") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4921 X-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@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 1506 Lines: 35 martin f krafft writes: [Sorry but that was really explained multiple times. Read the archives again for more details. Here just quick explanation.] > From what I understand, binary zeroes appear to replace file > contents after a system crash. The FAQ says that this is because the > file has been allocated, but the system had no time to write, so it > was empty. What surprises me here is that XFS nulls the file. > Normally, a newly allocated file is garbage to be overwritten, not > one zero after the other. Or are the zeroes overlaid on read() when > the inode is inconsistent? The new file size (=metadata) has been already flushed to disk, but the actual data hasn't yet. Missing data is a "hole" which reads as all zeros. If the system crashes in this window you see the hole. The main reason for this is that the flush delay for file data is much longer (minutes) compared to meta data like file size. Due to the way the XFS log works metadata tends to be flush very often. So you often have the updated metadata on disk, but no matching file data yet. There are various tunables in /prov/sys/vm to make file data be flushed faster (in 2.6 currently /proc/sys/vm/dirty_expire_centisecs, the names of these unfortunately change quite often). You can change that if you want, but in general making it to be flushed as often as the metadata would ruin performance. Of course you can sync any time manually with sync(1) or fsync(2)/fdatasync(2) in a program. -Andi From owner-linux-xfs Fri Feb 11 05:15:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 05:15:48 -0800 (PST) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BDFffh003733 for ; Fri, 11 Feb 2005 05:15:42 -0800 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id DDB668C305D for ; Fri, 11 Feb 2005 14:15:40 +0100 (CET) Received: from wing.madduck.net (84-72-25-172.dclient.hispeed.ch [84.72.25.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "wing.madduck.net", Issuer "madduck.net CA" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id 646BA895D6B for ; Fri, 11 Feb 2005 14:15:40 +0100 (CET) Received: by wing.madduck.net (Postfix, from userid 1000) id A90DD602E9A; Fri, 11 Feb 2005 14:15:46 +0100 (CET) Date: Fri, 11 Feb 2005 14:15:46 +0100 From: martin f krafft To: linux xfs mailing list Subject: Re: the thing with the binary zeroes Message-ID: <20050211131546.GA32336@localhost.localdomain> Mail-Followup-To: linux xfs mailing list References: <20050211121829.GA30049@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: X-OS: Debian GNU/Linux 3.1 kernel 2.6.10-wing i686 X-Mailer: Mutt 1.5.6+20040907i (CVS) X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by albatross.madduck.net X-Virus-Status: Clean X-archive-position: 4922 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: linux-xfs Content-Length: 2378 Lines: 63 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Andi Kleen [2005.02.11.1400 +0100]: > [Sorry but that was really explained multiple times. Read the > archives again for more details. Here just quick explanation.] I am only one of many people that are unable to find answers to questions I posed in my email. Also, I am only one of many people who are still totally confused about XFS' binary nulls. My intention to write this post was simply to sum it all up and work towards a better answer in the FAQ. I believe I stated this, although maybe not clearly. Please do not read this email as a flame or personal attack! You will note that most of my email is a summary of what you just told me. I only ask two questions, none of which you have answered. I still very much appreciate your time, but please try to understand where I am coming from. If you believe that this issue has been sufficiently answered "many times", then I kindly ask you to point me to such an explanation in the archives. I have searched myself and I was not satisfied. And being a proponent of XFS whereever I go, I am always being asked by people for an explanation because they could not find a satisfiable one either. So basically, what I summarised in my first post is correct from the perspective of a user, right? Let's assume that a truncating open() gets interrupted just after the metadata are flushed and before the new contents makes it to the disk. Then, the old file contents is still on the disk, but XFS hides it behind a curtain of zeroes. How can I get at the original data in such a case? --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 micro$oft is to operating systems & security what mcdonalds is to gourmet cuisine. --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCDLACIgvIgzMMSnURAlHVAKDkZYjYuyY8PWQSmjNMbWCZlAigZwCfWoy8 Ve7xEJlBg+A+jpP/EgbesMA= =x8Ur -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-linux-xfs Fri Feb 11 05:29:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 05:29:13 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BDT9vP004313 for ; Fri, 11 Feb 2005 05:29:10 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 8A2B9D033F; Fri, 11 Feb 2005 14:29:08 +0100 (CET) To: linux xfs mailing list Cc: madduck@madduck.net Subject: Re: the thing with the binary zeroes References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> From: Andi Kleen Date: Fri, 11 Feb 2005 14:29:08 +0100 In-Reply-To: <20050211131546.GA32336@localhost.localdomain> (martin f. krafft's message of "Fri, 11 Feb 2005 14:15:46 +0100") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4923 X-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@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 1306 Lines: 29 martin f krafft writes: > You will note that most of my email is a summary of what you just > told me. I only ask two questions, none of which you have answered. > I still very much appreciate your time, but please try to understand > where I am coming from. If you believe that this issue has been > sufficiently answered "many times", then I kindly ask you to point I've read explanations similar to mine several time on the list and also given them occasionally myself. > Let's assume that a truncating open() gets interrupted just after > the metadata are flushed and before the new contents makes it to the > disk. Then, the old file contents is still on the disk, but XFS > hides it behind a curtain of zeroes. How can I get at the original > data in such a case? You could in theory by grepping the block device and searching for the data (it hasn't been physically destroyed unless there is parallel activity on the fs). But the XFS code can't find it anymore because the metadata connecting the inode to the file data is gone. That is why you see the 0s instead. BTW other journaling fs have similar issues, it's just that their flush times for data and metadata are more similar, so the race window where this can happen is much smaller and you rarely see it. -Andi From owner-linux-xfs Fri Feb 11 05:35:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 05:35:55 -0800 (PST) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BDZqL3004858 for ; Fri, 11 Feb 2005 05:35:53 -0800 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id 657C08C3059; Fri, 11 Feb 2005 14:35:51 +0100 (CET) Received: from wing.madduck.net (84-72-25-172.dclient.hispeed.ch [84.72.25.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "wing.madduck.net", Issuer "madduck.net CA" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id E5197895D6B; Fri, 11 Feb 2005 14:35:50 +0100 (CET) Received: by wing.madduck.net (Postfix, from userid 1000) id 2FED5602E9A; Fri, 11 Feb 2005 14:35:58 +0100 (CET) Date: Fri, 11 Feb 2005 14:35:58 +0100 From: martin f krafft To: Andi Kleen Cc: linux xfs mailing list Subject: Re: the thing with the binary zeroes Message-ID: <20050211133558.GA32501@localhost.localdomain> Mail-Followup-To: Andi Kleen , linux xfs mailing list References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: X-OS: Debian GNU/Linux 3.1 kernel 2.6.10-wing i686 X-Mailer: Mutt 1.5.6+20040907i (CVS) X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by albatross.madduck.net X-Virus-Status: Clean X-archive-position: 4924 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: linux-xfs Content-Length: 1960 Lines: 54 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Andi Kleen [2005.02.11.1429 +0100]: > I've read explanations similar to mine several time on the > list and also given them occasionally myself. Again, not to be read as a personal attack, but your explanation is not what I was looking for. It added very little to the description I included in the first post. > You could in theory by grepping the block device and searching for > the data (it hasn't been physically destroyed unless there is > parallel activity on the fs). But the XFS code can't find it > anymore because the metadata connecting the inode to the file data > is gone. That is why you see the 0s instead. Right. So basically you are saying that it's not possible to get at the data anymore other than through direct device access. Maybe this is something that could be considered for future XFS versions? A tool that can ignore the zeroing-precaution and simply give access to the data the inode points to, even though it would not normally connect the two. --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 "our destiny exercises its influence over us even when, as yet, we have not learned its nature; it is our future that lays down the law of our today." - friedrich nietzsche --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCDLS+IgvIgzMMSnURAiaIAKCaJpgVpoI34zLDHk7Hi1FPvOiYYACguZXa aKjmlxCzybGcfOVUrpeu4VE= =mazJ -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-linux-xfs Fri Feb 11 05:55:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 05:55:14 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BDtB1C006083 for ; Fri, 11 Feb 2005 05:55:11 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 6A5DFD033E; Fri, 11 Feb 2005 14:55:10 +0100 (CET) To: linux xfs mailing list Cc: madduck@madduck.net Subject: Re: the thing with the binary zeroes References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> From: Andi Kleen Date: Fri, 11 Feb 2005 14:55:10 +0100 In-Reply-To: <20050211133558.GA32501@localhost.localdomain> (martin f. krafft's message of "Fri, 11 Feb 2005 14:35:58 +0100") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4925 X-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@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 1358 Lines: 34 martin f krafft writes: > also sprach Andi Kleen [2005.02.11.1429 +0100]: >> I've read explanations similar to mine several time on the >> list and also given them occasionally myself. > > Again, not to be read as a personal attack, but your explanation is > not what I was looking for. It added very little to the description > I included in the first post. Well, it's the full story. Nothing to add. > Maybe this is something that could be considered for future XFS > versions? A tool that can ignore the zeroing-precaution and simply > give access to the data the inode points to, even though it would > not normally connect the two. It can't. The pointers from the inode to the extents with the data are overwritten at this point. The only good "fix" probably would be to make XFS flush metadata less aggressively. If the metadata was always flushed at roughly the same time as the file data is written you would rarely see this. But I suspect doing that would need large scale rewrites and redesign in the log module. It currently uses an inefficient format to store log buffers, which prevents the log from buffering too much. You can decrease the flush delay for file data though with the sysctls i pointed out earlier. That will not fix it, but will make the time window where it can happen smaller. -Andi From owner-linux-xfs Fri Feb 11 06:06:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 06:06:17 -0800 (PST) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1BE6FuR006864 for ; Fri, 11 Feb 2005 06:06:16 -0800 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id 3A5D58C3059; Fri, 11 Feb 2005 15:06:14 +0100 (CET) Received: from wing.madduck.net (84-72-25-172.dclient.hispeed.ch [84.72.25.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "wing.madduck.net", Issuer "madduck.net CA" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id EC037895D6B; Fri, 11 Feb 2005 15:06:13 +0100 (CET) Received: by wing.madduck.net (Postfix, from userid 1000) id 25425602E9B; Fri, 11 Feb 2005 15:06:20 +0100 (CET) Date: Fri, 11 Feb 2005 15:06:20 +0100 From: martin f krafft To: Andi Kleen Cc: linux xfs mailing list Subject: Re: the thing with the binary zeroes Message-ID: <20050211140620.GA3932@localhost.localdomain> Mail-Followup-To: Andi Kleen , linux xfs mailing list References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: X-OS: Debian GNU/Linux 3.1 kernel 2.6.10-wing i686 X-Mailer: Mutt 1.5.6+20040907i (CVS) X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by albatross.madduck.net X-Virus-Status: Clean X-archive-position: 4926 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: linux-xfs Content-Length: 1641 Lines: 51 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Andi Kleen [2005.02.11.1455 +0100]: > Well, it's the full story. Nothing to add. Thank you for taking your time to help me understand the whole picture then! Would it be possible to extend the FAQ with some more information? Whom would I have to contact? > It can't. The pointers from the inode to the extents with the data > are overwritten at this point. I have heard of cases where booting another (previous) kernel gave access to the files again. So I guess it can happen that the new data are written to the same extents in which the old data resided (for instance, if the file was shortened). Why would it be possible to access the data with a previous kernel, but only see zeroes with a newer version? --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 "moderation is a fatal thing. enough is as bad as a meal. more than enough is as good as a feast." -- oscar wilde --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCDLvcIgvIgzMMSnURAlIVAJ9Hjxn6Ae74BAXtKhY82NAQmEEhJgCgzH5r ab1adrjEHLPmoCm70/+GJR8= =V1WP -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-linux-xfs Fri Feb 11 06:25:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 06:25:26 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1BEPKOY007668 for ; Fri, 11 Feb 2005 06:25:21 -0800 Received: (qmail 53804 invoked by uid 3709); 11 Feb 2005 14:25:18 -0000 Date: 11 Feb 2005 15:25:18 +0100 Date: Fri, 11 Feb 2005 15:25:18 +0100 From: Andi Kleen To: linux xfs mailing list Subject: Re: the thing with the binary zeroes Message-ID: <20050211142518.GA53693@muc.de> References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> <20050211140620.GA3932@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050211140620.GA3932@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4927 X-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@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 409 Lines: 12 > I have heard of cases where booting another (previous) kernel gave > access to the files again. So I guess it can happen that the new > data are written to the same extents in which the old data resided > (for instance, if the file was shortened). > > Why would it be possible to access the data with a previous kernel, > but only see zeroes with a newer version? Sounds more like a urban legend. -Andi From owner-linux-xfs Fri Feb 11 18:55:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 18:55:06 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C2sxc7016890 for ; Fri, 11 Feb 2005 18:55:00 -0800 Received: by wproxy.gmail.com with SMTP id 63so276047wri for ; Fri, 11 Feb 2005 18:54:54 -0800 (PST) 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; b=dVMSFQyHSYscvrD89bqJCm62k1//uLskQDf5iLg98tcMXGvcXkbN9veNcm3ZrI1VNpiyV6oOKq1wabYJQ/KbSjy7VVROTqUvX61MS9dvOHjxMkgrMHYsKYFzUH+ONarkHHfElwpRfdH9PH7ofNhB4xYfxmvshyVf9z78goe3C1k= Received: by 10.54.17.71 with SMTP id 71mr272130wrq; Fri, 11 Feb 2005 18:54:54 -0800 (PST) Received: by 10.54.19.15 with HTTP; Fri, 11 Feb 2005 18:54:53 -0800 (PST) Message-ID: <410da79f050211185476207122@mail.gmail.com> Date: Sat, 12 Feb 2005 03:54:53 +0100 From: Pablo Cruz Navea Reply-To: Pablo Cruz Navea To: linux-xfs@oss.sgi.com Subject: multithreaded processors and xfs Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1C2t1c7016934 X-archive-position: 4929 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pablo.cruz@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 476 Lines: 16 Dear list, some days ago I've read in a XFS documents that some objects like the Allocation Groups (AG) are multi-threaded. My question is: is the performance improved when we use a multi-threading processor like the Pentium IV? Please make a comparison between Pentium and some other common processors. Thank you very much. -- Pablo Cruz Navea Computer Science Student Universidad Técnica Federico Santa María Valparaíso Chile http://www.alumnos.utfsm.cl/~pablo_cruz/en/ From owner-linux-xfs Fri Feb 11 21:48:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Feb 2005 21:48:50 -0800 (PST) Received: from cooper.uws.edu.au (cooper.uws.edu.au [137.154.210.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1C5mkcR024416 for ; Fri, 11 Feb 2005 21:48:47 -0800 Received: from cooper.uws.edu.au (localhost [127.0.0.1]) by cooper.uws.edu.au (8.12.10/8.12.10/UWS-STF-POST-1.9) with ESMTP id j1C5mjfK018144 for ; Sat, 12 Feb 2005 16:48:45 +1100 (EST) Received: from jekyll.uws.edu.au (jekyll.uws.edu.au [137.154.182.18]) by cooper.uws.edu.au (8.12.10/8.12.10/UWS-STF-PRE-1.9) with ESMTP id j1C5miwF018141 for ; Sat, 12 Feb 2005 16:48:44 +1100 (EST) Received: from jekyll.uws.edu.au (localhost [127.0.0.1]) by jekyll.uws.edu.au (8.12.10+Sun/8.12.10/JEKYLL-$Revision: 1.0 $) with ESMTP id j1C5mhbq025846 for ; Sat, 12 Feb 2005 16:48:44 +1100 (EST) Received: from localhost (david@localhost) by jekyll.uws.edu.au (8.12.10+Sun/8.12.10/Submit) with ESMTP id j1C5mhIq025843 for ; Sat, 12 Feb 2005 16:48:43 +1100 (EST) Date: Sat, 12 Feb 2005 16:48:43 +1100 (EST) From: David J N Begley Reply-To: David J N Begley To: linux xfs mailing list Subject: Re: the thing with the binary zeroes In-Reply-To: Message-ID: References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> X-No-Archive: Yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4930 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: d.begley@uws.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 473 Lines: 12 On Fri, 11 Feb 2005, Andi Kleen wrote: > The only good "fix" probably would be to make XFS flush metadata less > aggressively. If the metadata was always flushed at roughly the same time > as the file data is written you would rarely see this. Are you talking here about implementing an "ordered journal" (similar to ext3) where data is written before metadata updates, or simply reducing the time between data/metadata flushes without imposing any ordering? Thanks.. From owner-linux-xfs Sat Feb 12 03:59:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Feb 2005 03:59:17 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CBxCJj007333 for ; Sat, 12 Feb 2005 03:59:13 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 0D812D033E; Sat, 12 Feb 2005 12:59:12 +0100 (CET) To: David J N Begley Cc: linux-xfs@oss.sgi.com Subject: Re: the thing with the binary zeroes References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> From: Andi Kleen Date: Sat, 12 Feb 2005 12:59:12 +0100 In-Reply-To: (David J. N. Begley's message of "Sat, 12 Feb 2005 16:48:43 +1100 (EST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4931 X-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@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 1259 Lines: 32 David J N Begley writes: > On Fri, 11 Feb 2005, Andi Kleen wrote: > >> The only good "fix" probably would be to make XFS flush metadata less >> aggressively. If the metadata was always flushed at roughly the same time >> as the file data is written you would rarely see this. > > Are you talking here about implementing an "ordered journal" (similar to ext3) > where data is written before metadata updates, Ordered data just guarantees that there is never a window where the machine crashes that you can see "raw" disk blocks after recovery. "Raw" means blocks that are not under control of the file system and can be arbitary old data. This can be a theoretical security hole (although in practice you usually only see some garbage) As far as I know XFS guarantees this already, so it supports "ordered data" in the JBD sense. > or simply reducing the time > between data/metadata flushes without imposing any ordering? There is a defined ordering, but the whole thing is not atomic because data is not written in a transaction (however it usually depends on one when new blocks are getting allocated) I meant "simply" reducing the time between the transactional metadata flush and the non transactional data flush. -Andi From owner-linux-xfs Sat Feb 12 04:07:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Feb 2005 04:07:33 -0800 (PST) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CC7Nws008269 for ; Sat, 12 Feb 2005 04:07:26 -0800 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id 0637D8C24C1 for ; Sat, 12 Feb 2005 13:07:20 +0100 (CET) Received: from cirrus.madduck.net (cirrus.madduck.net [130.60.75.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cirrus.madduck.net", Issuer "madduck.net CA" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id B2816873B39 for ; Sat, 12 Feb 2005 13:07:20 +0100 (CET) Received: by cirrus.madduck.net (Postfix, from userid 1000) id 4FAF520041E; Sat, 12 Feb 2005 13:07:18 +0100 (CET) Date: Sat, 12 Feb 2005 13:07:18 +0100 From: martin f krafft To: linux-xfs@oss.sgi.com Subject: Re: the thing with the binary zeroes Message-ID: <20050212120718.GA30740@cirrus.madduck.net> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: X-OS: Debian GNU/Linux 3.1 kernel 2.6.10-1-k7 i686 X-Mailer: Mutt 1.5.6+20040907i (CVS) X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by albatross.madduck.net X-Virus-Status: Clean X-archive-position: 4932 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: linux-xfs Content-Length: 1502 Lines: 45 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Andi Kleen [2005.02.12.1259 +0100]: > Ordered data just guarantees that there is never a window where > the machine crashes that you can see "raw" disk blocks after > recovery. "Raw" means blocks that are not under control of the > file system and can be arbitary old data. This can be > a theoretical security hole (although in practice you usually only > see some garbage)=20 >=20 > As far as I know XFS guarantees this already, so it supports > "ordered data" in the JBD sense.=20 But that would solve my problem. How does XFS guarantee this? Didn't you just say it is impossible to get at the raw data again as XFS nulls it? --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 "be the change you want to see in the world" -- mahatma gandhi --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCDfF2IgvIgzMMSnURAnkiAKC6IR7f/Te+ftYRm+G3UcXzGgxtpwCg7fQ/ KhEv1GEm3XtOWl4bNhaIQoI= =eUN4 -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-linux-xfs Sat Feb 12 07:53:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Feb 2005 07:53:17 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CFrD6m018786 for ; Sat, 12 Feb 2005 07:53:14 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 308FED033E; Sat, 12 Feb 2005 16:53:12 +0100 (CET) To: linux-xfs@oss.sgi.com Subject: Re: the thing with the binary zeroes References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> <20050212120718.GA30740@cirrus.madduck.net> From: Andi Kleen Date: Sat, 12 Feb 2005 16:53:12 +0100 In-Reply-To: <20050212120718.GA30740@cirrus.madduck.net> (martin f. krafft's message of "Sat, 12 Feb 2005 13:07:18 +0100") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4933 X-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@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 310 Lines: 11 martin f krafft writes: > > But that would solve my problem. How does XFS guarantee this? Didn't > you just say it is impossible to get at the raw data again as XFS > nulls it? No, I didn't say that. I said it overwrites the meta data pointing to the file data in the truncate. -Andi From owner-linux-xfs Sat Feb 12 09:25:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Feb 2005 09:25:15 -0800 (PST) Received: from nirmala.opentrend.net (nirmala.opentrend.net [65.39.131.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1CHPCnB025209 for ; Sat, 12 Feb 2005 09:25:12 -0800 Received: from localhost (localhost [127.0.0.1]) by nirmala.opentrend.net (Postfix) with ESMTP id 1F71DFDB9 for ; Sat, 12 Feb 2005 12:21:36 -0500 (EST) Received: from nirmala.opentrend.net ([127.0.0.1]) by localhost (nirmala.opentrend.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11846-02-2 for ; Sat, 12 Feb 2005 12:21:31 -0500 (EST) Received: by nirmala.opentrend.net (Postfix, from userid 1003) id 2E2E8FDB8; Sat, 12 Feb 2005 12:21:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nirmala.opentrend.net (Postfix) with ESMTP id 2C1EFFDB1 for ; Sat, 12 Feb 2005 17:21:31 +0000 (GMT) Date: Sat, 12 Feb 2005 17:21:31 +0000 (GMT) From: Robert Brockway To: linux-xfs@oss.sgi.com Subject: The Amazing disappearing filesystem (2.4.29) Message-ID: <20050212165919.D11899@nirmala.opentrend.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: amavisd-new at opentrend.net X-Virus-Status: Clean X-archive-position: 4934 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rbrockway@opentrend.net Precedence: bulk X-list: linux-xfs Content-Length: 2872 Lines: 90 Hi all. I was moving filesystems around this morning and I had an odd occurance. Let me take you through step by step. Essentially what I'm doing here is to take an xfsdump of /var/spool/news and move it back on to /var. I had plans to run the box as a news servers but this won't be a big part of its future. I aborted when I ran into a problem or I would have taken a dump of /var & /opt and repartitioned quite a bit. 1. Reboot server 2. Boot into custom 2.4.29 (single user mode) Until moments before the box has been running a custom 2.4.26 for months without any issues. Actual uptime on this box was only a couple of weeks (this is my personal fileserver at home, no UPS). The configs for 2.4.26 & 2.4.29 are identical except where 2.4.29 added new config items. I answered N for each of these during make oldconfig. 3. Take an xfsdump of /var/spool/news (/dev/hdb11) cd /var /sbin/xfsdump -0 -f var.spool.news /dev/hdb11 I made session label and label both news. 4. Go to mv /var/spool/news to the side Silly of course but I guess I was tired. Of course I get a "device or resoruce busy" as /var/spool/news is a mounted filesystem. I mention this as it is the only error that happened in the process and maybe it is important. 5. umount /var/spool/news 6. cd to /var/spool/news xfsrestore -rf /var/var.spool.news . 7. Check the data is there Yes, the directory /var/spool/news looks good. 8. Remove the /var/spool/news entry from /etc/fstab 9. Mount /dev/hdb11 (old /vsr/spool/news) as /mnt mount /dev/hdb11 /mnt I just wanted to have a look at it. Glad I did. Here it is right now: /dev/hdb11 9.8G 320k 9.7G 1% /mnt It's empty. It wasn't empty before. The data got dumped properly and restored properly: zen:~#du -sh /var/spool/news 576k /var/spool/news But the filesystem formerly known as /var/spool/news was empty. I did not do a mkfs and just to be sure I reviewed my command history. Nope, no mkfs. 10. I rebooted into the custom 2.4.26 (single user mode) I attempted to mount /dev/hdb11 again. Still empty. 11. Reconfigured system to default boot the custom 2.4.26 and came up into multi-user mode. I've taken a dd of hdb11 for reference purposes. As a result of this little disappearance I'm going to stay away from 2.4.29 until I hear that something else may have caused the problem. I'm happy to conduct any tests on the dd copy of hdb11 (mounted loop back) or even on the real filesystem although I am going to proceed with the repartitioning soon. Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (http://www.spi-inc.org) From owner-linux-xfs Sat Feb 12 17:13:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Feb 2005 17:13:11 -0800 (PST) Received: from cooper.uws.edu.au (cooper.uws.edu.au [137.154.210.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1D1D7hn017323 for ; Sat, 12 Feb 2005 17:13:08 -0800 Received: from cooper.uws.edu.au (localhost [127.0.0.1]) by cooper.uws.edu.au (8.12.10/8.12.10/UWS-STF-POST-1.9) with ESMTP id j1D1D6fK021654 for ; Sun, 13 Feb 2005 12:13:06 +1100 (EST) Received: from jekyll.uws.edu.au (jekyll.uws.edu.au [137.154.182.18]) by cooper.uws.edu.au (8.12.10/8.12.10/UWS-STF-PRE-1.9) with ESMTP id j1D1D5wF021651 for ; Sun, 13 Feb 2005 12:13:05 +1100 (EST) Received: from jekyll.uws.edu.au (localhost [127.0.0.1]) by jekyll.uws.edu.au (8.12.10+Sun/8.12.10/JEKYLL-$Revision: 1.0 $) with ESMTP id j1D1D3bq026431 for ; Sun, 13 Feb 2005 12:13:05 +1100 (EST) Received: from localhost (david@localhost) by jekyll.uws.edu.au (8.12.10+Sun/8.12.10/Submit) with ESMTP id j1D1CwFV026428 for ; Sun, 13 Feb 2005 12:13:03 +1100 (EST) Date: Sun, 13 Feb 2005 12:12:58 +1100 (EST) From: David J N Begley Reply-To: David J N Begley To: linux-xfs@oss.sgi.com Subject: Re: the thing with the binary zeroes In-Reply-To: Message-ID: References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> X-No-Archive: Yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4935 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: d.begley@uws.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 1681 Lines: 39 On Sat, 12 Feb 2005, Andi Kleen wrote: > David J N Begley writes: > > > Are you talking here about implementing an "ordered journal" (similar to > > ext3) where data is written before metadata updates, > > Ordered data just guarantees that there is never a window where > the machine crashes that you can see "raw" disk blocks after recovery. > "Raw" means blocks that are not under control of the file system > and can be arbitary old data. This can be a theoretical security hole > (although in practice you usually only see some garbage) Agreed, "raw" data in the above sense is most definitely a security hole and something to be avoided. > As far as I know XFS guarantees this already, so it supports "ordered > data" in the JBD sense. This, I believe, is where we get to the heart of people's confusion/concern regarding XFS - the method used to ensure "raw" data is avoided. If an "ordered journal" (as above, in the ext3 sense) ensures data is written before its associated metadata, then any interruption will leave you in one of two states: - either the metadata has not been updated, in which case you point to the old file data (as opposed to "random" raw data from any file); or, - the meta data has been updated, and points to the correct new file data (because it was flushed to disk before the metadata). My understanding was that XFS did not impose this ordering (ie., data first, metadata second) and that was why writing blocks of zeros was so important for stopping potential security/information leaks; if this ordering were imposed, then the extra write-zero step may not be so important. Have I misunderstood? Thanks.. From owner-linux-xfs Sat Feb 12 18:15:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Feb 2005 18:15:50 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1D2Fkdv019660 for ; Sat, 12 Feb 2005 18:15:47 -0800 Received: from elmo.melbourne.sgi.com (elmo.melbourne.sgi.com [134.14.55.238]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA27946; Sun, 13 Feb 2005 13:15:36 +1100 Received: from elmo.melbourne.sgi.com (localhost [127.0.0.1]) by elmo.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j1D2FY0w679915; Sun, 13 Feb 2005 13:15:35 +1100 (AEDT) Message-Id: <200502130215.j1D2FY0w679915@elmo.melbourne.sgi.com> From: Daniel Moore X-URL: http://zoic.org/dxm To: David J N Begley cc: linux-xfs@oss.sgi.com Subject: Re: the thing with the binary zeroes In-Reply-To: References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> Date: Sun, 13 Feb 2005 13:15:34 +1100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4936 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dxm@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2293 Lines: 52 David J N Begley writes: => - either the metadata has not been updated, in which case you point to the => old file data (as opposed to "random" raw data from any file); or, => => - the meta data has been updated, and points to the correct new file data => (because it was flushed to disk before the metadata). XFS' journaling is there to protect the _metadata_. It seems a little harsh to give you back zeroed files after a crash, but the point is that although your new data may not be as intact as you'd hoped, the filesystem as a whole _is_ (and no filesystem check is required). So each change XFS makes to metadata is written to the log before the coresponding change is made in the filesystem. When each transaction (which may affect several blocks of metadata) is completed, the log entry is done with. If the machine dies part way though a transaction, the log is used to complete the transaction so that the filesystem is consistent. XFS will never (1) give you back the old crud left on disk - that would be a secuity hole. So whenever you're reading something that you haven't written, you'll get zeroes. If the file has been extended & not yet written, you'll get zeroes. If blocks have been allocated and not filled, you'll get zeroes. The metadata change is preserved, but unfortunately not the data - that's just the way it works. You could go look through your old data for things you'd lost, but XFS doesn't go out of its way to make that easy (2). Hope that explains it. I think people shy away from answering this as it really has been done to death. I hope there's something decent in the FAQ. If not, maybe someone could propose wording for a new entry? If you want _really_ accurate info, I'm sorry to say the best approach is to go read the code (serious guru stuff down there though). ---- (1) IIRC, unwritten extents can violate this, but there's a restriction on that so root needs to allow that behaviour. (2) there's no xfs_undelete - that's what backups are for ------------------------------------------------------- Daniel Moore dxm@sgi.com 5248209 R&D Software Engineer Phone: +61-3-98348209 SGI Australian Software Group Fax: +61-3-98132378 ------------------------------------------------------- From owner-linux-xfs Sun Feb 13 20:31:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Feb 2005 20:31:56 -0800 (PST) Received: from bruce.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1E4VrhT019167 for ; Sun, 13 Feb 2005 20:31:54 -0800 Received: by bruce.melbourne.sgi.com (Postfix, from userid 38403) id 2542256622; Mon, 14 Feb 2005 15:15:40 +1100 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfstests Message-Id: <20050214041540.2542256622@bruce.melbourne.sgi.com> Date: Mon, 14 Feb 2005 15:15:40 +1100 (EST) From: fsgqa@bruce.melbourne.sgi.com (FSG QA) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4937 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1840 Lines: 36 Add AIO test 113 into the mix, enable AIO testing capability in local fsx. Date: Mon Feb 14 15:31:02 AEDT 2005 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:21487a xfstests/113 - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/113 xfstests/113.out - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/113.out xfstests/m4/package_aiodev.m4 - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/package_aiodev.m4 xfstests/ltp/aio-stress.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/ltp/aio-stress.c xfstests/configure.in - 1.18 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/configure.in.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfstests/group - 1.69 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/group.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h xfstests/include/builddefs.in - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/include/builddefs.in.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfstests/m4/Makefile - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h xfstests/m4/package_utilies.m4 - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/package_utilies.m4.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfstests/ltp/fsx.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/ltp/fsx.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfstests/ltp/Makefile - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/ltp/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h xfstests/aclocal.m4 - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/aclocal.m4.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h From owner-linux-xfs Mon Feb 14 00:29:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 00:29:16 -0800 (PST) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [193.151.36.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1E8TAQW032581 for ; Mon, 14 Feb 2005 00:29:11 -0800 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id EFAF018D3FF; Mon, 14 Feb 2005 09:29:09 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 85FCD18D406; Mon, 14 Feb 2005 09:29:09 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.13.1/8.13.1) with ESMTP id j1E8T6cp004030; Mon, 14 Feb 2005 09:29:07 +0100 Subject: Re: the thing with the binary zeroes From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Daniel Moore Cc: David J N Begley , linux-xfs@oss.sgi.com In-Reply-To: <200502130215.j1D2FY0w679915@elmo.melbourne.sgi.com> References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> <200502130215.j1D2FY0w679915@elmo.melbourne.sgi.com> Content-Type: text/plain; charset=UTF-8 Date: Mon, 14 Feb 2005 09:29:06 +0100 Message-Id: <1108369746.3535.10.camel@venus.local.navi.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4938 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 977 Lines: 24 On Sun, 2005-02-13 at 13:15 +1100, Daniel Moore wrote: > Hope that explains it. I think people shy away from answering this as > it really has been done to death. I hope there's something decent in > the FAQ. If not, maybe someone could propose wording for a new entry? > If you want _really_ accurate info, I'm sorry to say the best approach > is to go read the code (serious guru stuff down there though). Hi, The problem is that people don't understand the difference between the data and metadata journaling. As XFS doesn't do data journaling the whole discussion is pointless. If someone wants data journaling then the ext3 supports it. If an application is written in a sane way then you don't have "zeros problem" even on metadata only journaling filesystem either. The second thing in this topic about zeros is that the zeros don't have to be on-disk. It is just representation of data that are not available. Regards, Olaf -- Olaf FrÄ…czyk From owner-linux-xfs Mon Feb 14 00:56:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 00:56:10 -0800 (PST) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1E8u5Lw001700 for ; Mon, 14 Feb 2005 00:56:06 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id 9A466161F49; Mon, 14 Feb 2005 09:56:04 +0100 (CET) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25347-03; Mon, 14 Feb 2005 09:56:03 +0100 (CET) Received: from [192.9.209.64] (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id E624F161F4C; Mon, 14 Feb 2005 09:56:02 +0100 (CET) Message-ID: <42106769.30305@opticalart.de> Date: Mon, 14 Feb 2005 09:55:05 +0100 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pablo Cruz Navea , linux-xfs@oss.sgi.com Subject: Re: multithreaded processors and xfs References: <410da79f050211185476207122@mail.gmail.com> In-Reply-To: <410da79f050211185476207122@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new at vcc.de X-Virus-Status: Clean X-archive-position: 4939 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 1460 Lines: 38 Hi Pablo! I suppose you mean the performance increase of one Pentium IV with Hyperthreading compared to one Pentium IV without? In reality (at least around here) turning on/off Hyperthreading isn't increasing I/O performance in a way that is noticable. It will help if you are doing heavy computations with the data at the same time, e.g. 3D field simulations of data on XFS partitions. For normal fileserving functionality Hyperthreading won't matter. The point of multi-threading here is, that multi-cpu boxes can run multiple threads at the same time and therefore use XFS parallel on more than just one cpu. If you are in need to get more performance, there is always the option of dual or quad xeon/opteron boxes and better storage adapters and/or RAID subsystems. Cheers, Frank... Pablo Cruz Navea wrote: > Dear list, some days ago I've read in a XFS documents that some > objects like the Allocation Groups (AG) are multi-threaded. My > question is: is the performance improved when we use a multi-threading > processor like the Pentium IV? Please make a comparison between > Pentium and some other common processors. > > Thank you very much. > -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a DI Supervisor http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs Mon Feb 14 02:16:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 02:16:09 -0800 (PST) Received: from cooper.uws.edu.au (cooper.uws.edu.au [137.154.210.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EAG6J2005223 for ; Mon, 14 Feb 2005 02:16:07 -0800 Received: from cooper.uws.edu.au (localhost [127.0.0.1]) by cooper.uws.edu.au (8.12.10/8.12.10/UWS-STF-POST-1.9) with ESMTP id j1EAG4fM018444 for ; Mon, 14 Feb 2005 21:16:05 +1100 (EST) Received: from jekyll.uws.edu.au (jekyll.uws.edu.au [137.154.182.18]) by cooper.uws.edu.au (8.12.10/8.12.10/UWS-STF-PRE-1.9) with ESMTP id j1EAG4wF018436; Mon, 14 Feb 2005 21:16:04 +1100 (EST) Received: from jekyll.uws.edu.au (localhost [127.0.0.1]) by jekyll.uws.edu.au (8.12.10+Sun/8.12.10/JEKYLL-$Revision: 1.0 $) with ESMTP id j1EAG2bq027121; Mon, 14 Feb 2005 21:16:03 +1100 (EST) Received: from localhost (david@localhost) by jekyll.uws.edu.au (8.12.10+Sun/8.12.10/Submit) with ESMTP id j1EAG2Ql027118; Mon, 14 Feb 2005 21:16:02 +1100 (EST) Date: Mon, 14 Feb 2005 21:16:02 +1100 (EST) From: David J N Begley Reply-To: David J N Begley To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= cc: Daniel Moore , linux-xfs@oss.sgi.com Subject: Re: the thing with the binary zeroes In-Reply-To: <1108369746.3535.10.camel@venus.local.navi.pl> Message-ID: References: <20050211121829.GA30049@localhost.localdomain> <20050211131546.GA32336@localhost.localdomain> <20050211133558.GA32501@localhost.localdomain> <200502130215.j1D2FY0w679915@elmo.melbourne.sgi.com> <1108369746.3535.10.camel@venus.local.navi.pl> X-No-Archive: Yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4940 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: d.begley@uws.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 5051 Lines: 108 Earlier today, Olaf Fr?czyk wrote: > On Sun, 2005-02-13 at 13:15 +1100, Daniel Moore wrote: > > Hope that explains it. I think people shy away from answering this as [...] > The problem is that people don't understand the difference between the data > and metadata journaling. As XFS doesn't do data journaling the whole > discussion is pointless. Errm, no and no - believe it or not full file contents/data journalling is not always behind the question (in my case, it's already assumed to not be a part of the equation). The fact that this issue keeps being raised demonstrates that either those asking the questions (myself included) are not using the right words or those answering are too quickly skimming the questions, missing the underlying point and thus answering some closely-related but different question. People hear/read that XFS is a fast, reliable file system - indeed, that is exactly many people's experiences with it. Alas, there are ways in which XFS behaves differently to the other journalling FS options in Linux and this has led to data loss, which is where people cannot reconcile their experiences with those of others (or the claims of XFS' reliability). This is where the problem (and thence the interminable questioning) begins. Either: (a) people's expectations of XFS are misaligned with XFS' intended work environment, in which case the documentaion needs to be updated to include a prominent notice in order to correct people's expectations (eg., cannot use XFS and expect minimal data loss unless apps are written a certain way, full hardware RAID is used and UPS guarantees no power loss); or, (b) there are some ways in which XFS can be improved in which case the only way people are going to be able to contribute anything of value is if there exists an open and frank discussion about how to design and implement any such improvements (rather than dissmissing all questions as being about full data journalling). Despite explicitly mentioning ext3's ordered journalling mechanism a number of times (this is not a full data journal, like XFS it only journals metadata), the responses are still fixated on full data journalling for some reason; it might be easier if I just quote Steve Lord of SGI: "The ordered mode in ext3 is almost certainly a better performing solution than this, it would be nice to get this into xfs, but probably quite a while before it could be worked on." http://oss.sgi.com/archives/linux-xfs/2001-12/msg00108.html Previously I asked (clearly inelegantly) whether with such a mechanism (as Steve noted would be good to get into XFS) the zero-page problem would still be an issue at all? Would that remove all further concern/confusion/doubt regarding XFS? > If an application is written in a sane way then you don't have "zeros > problem" even on metadata only journaling filesystem either. See point (a) above. On Sun Feb 13 2005, Daniel Moore wrote: > David J N Begley writes: > => - either the metadata has not been updated, in which case you point to > => the old file data (as opposed to "random" raw data from any file); > => or, > => > => - the meta data has been updated, and points to the correct new file > => data (because it was flushed to disk before the metadata). > > XFS' journaling is there to protect the _metadata_. It seems a little See first paragraph above - I know; when I talked of metadata being "updated", I meant committed from RAM to the journal on disk. I didn't mention anything about file contents/data also going through the journal, just that it was flushed to the disk prior to its associated metadata. > XFS will never (1) give you back the old crud left on disk - that would > be a secuity hole. So whenever you're reading something that you > haven't written, you'll get zeroes. If by "old crud" you are referring to the old version of a rewritten file (where the metadata has been updated but the associated file data has yet to be flushed to disk from RAM), then it should be possible to make the zeroing of files an option for those willing to carry the security risk (and thus kill the whole problem/questions in a simple step). If by "old crud" you are referring to seemingly random, unrelated data (either on disk or from memory) then I agree, it is a security hole. As noted above though - if data blocks were flushed from RAM prior to the associated meta data being committed from RAM to the on-disk journal, would not this solve both problems at once? (That is, if the metadata has not been updated then you will not get "random" data - but if it _has_ been updated then you can be sure to get the correct data thus no zeros.) If this is something that would run counter to XFS' delayed allocation or other features, then _that's_ what needs to appear in the FAQ (along with see point (a) above), not replies saying something along the lines of, "data is not journalled so stop asking". Hopefully this time I've been clearer (if somewhat long-winded). Thanks.. From owner-linux-xfs Mon Feb 14 02:34:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 02:34:51 -0800 (PST) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EAYfuK007018 for ; Mon, 14 Feb 2005 02:34:44 -0800 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id 7A3468C9216 for ; Mon, 14 Feb 2005 11:34:39 +0100 (CET) Received: from wing.madduck.net (84-72-16-91.dclient.hispeed.ch [84.72.16.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "wing.madduck.net", Issuer "madduck.net CA" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id E28B0895D6D for ; Mon, 14 Feb 2005 11:34:38 +0100 (CET) Received: by wing.madduck.net (Postfix, from userid 1000) id EAB53602E9B; Mon, 14 Feb 2005 11:38:30 +0100 (CET) Date: Mon, 14 Feb 2005 11:38:30 +0100 From: martin f krafft To: linux-xfs@oss.sgi.com Subject: Re: the thing with the binary zeroes Message-ID: <20050214103830.GA6385@localhost.localdomain> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20050211121829.GA30049@localhost.localdomain> <200502130215.j1D2FY0w679915@elmo.melbourne.sgi.com> <1108369746.3535.10.camel@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: X-OS: Debian GNU/Linux 3.1 kernel 2.6.10-wing i686 X-Mailer: Mutt 1.5.6+20040907i (CVS) X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by albatross.madduck.net X-Virus-Status: Clean X-archive-position: 4941 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: linux-xfs Content-Length: 2503 Lines: 64 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach David J N Begley [2005.02.14.1116 +0100]: > The fact that this issue keeps being raised demonstrates that > either those asking the questions (myself included) are not using > the right words or those answering are too quickly skimming the > questions, missing the underlying point and thus answering some > closely-related but different question. Well spotted and stated. > (a) people's expectations of XFS are misaligned with XFS' intended work > environment, in which case the documentaion needs to be updated to > include a prominent notice in order to correct people's expectations > (eg., cannot use XFS and expect minimal data loss unless apps are > written a certain way, full hardware RAID is used and UPS guarantees > no power loss); Is this actually a recommendation? It makes perfect sense, but I have been using XFS on every workstation, including laptops, with success for years now, and I can usually warmly recommend it. Should I maybe stop doing so, considering that XFS seems to be more of a data center filesystem than one for the workstation or "casual server"? > If by "old crud" you are referring to the old version of > a rewritten file (where the metadata has been updated but the > associated file data has yet to be flushed to disk from RAM), then > it should be possible to make the zeroing of files an option for > those willing to carry the security risk (and thus kill the whole > problem/questions in a simple step). Just give a tool to root that can recover the data shadowed by the zeroes. That's not a security hole. And it's as optional as it can get. --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 "glaube hei=DFt nicht wissen wollen, was wahr ist." - friedrich nietzsche --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCEH+mIgvIgzMMSnURAsMyAJ9wDq5oQUZQn9B/UH6NNNloksexWwCfTBug JWI7VVeHKHx8xU+nhLpj2yc= =IKSS -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-linux-xfs Mon Feb 14 13:13:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 13:13:30 -0800 (PST) Received: from note.orchestra.cse.unsw.EDU.AU (root@note.orchestra.cse.unsw.EDU.AU [129.94.242.24]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ELDP5F026518 for ; Mon, 14 Feb 2005 13:13:26 -0800 Received: From wagner With LocalMail ; Tue, 15 Feb 2005 08:13:23 +1100 From: Darren Williams To: linux-xfs@oss.sgi.com Date: Tue, 15 Feb 2005 08:13:23 +1100 Cc: overby@sgi.com Subject: Re: What does "xlog_state_do_callback: looping " mean? Message-ID: <20050214211323.GA14474@cse.unsw.EDU.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4942 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dsw@gelato.unsw.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 1558 Lines: 54 Hi all > I have a server where the `dmesg` is full of: > > Filesystem "hda4": xlog_state_do_callback: looping 10 > Filesystem "hda4": xlog_state_do_callback: looping 20 > Filesystem "hda4": xlog_state_do_callback: looping 10 > Filesystem "hda4": xlog_state_do_callback: looping 10 > Filesystem "hda4": xlog_state_do_callback: looping 10 > Filesystem "hda4": xlog_state_do_callback: looping 20 > [...] > > The hda4 partition contains the /var tree. [...] I have been seeing the same messages in the following config: HP zx8620 16way processor : 7 vendor : GenuineIntel arch : IA-64 family : Itanium 2 model : 1 revision : 5 archrev : 0 features : branchlong cpu number : 0 cpu regs : 4 cpu MHz : 1500.000000 itc MHz : 1500.000000 BogoMIPS : 2239.75 We are currently benchmarking Linux scalablity, so to avoid disk latency issues on filesystem benchmarks we have been generating each filesystem of interest on ramdisk then running osdl-re-aim-7 with disk only tests. With xfs I start seeing the looping messages at about 50 clients, ( using a 2M FILESIZE and 128M DISKDIR in the reaim.config ) with a 8way configuration. (This is just for your records) What effect can this have on the filesystem transactions, does it slow writes down due to the out of order logs. We are currently using the O_SYNC flag on open. Thanks Darren -------------------------------------------------- Darren Williams Gelato@UNSW -------------------------------------------------- From owner-linux-xfs Mon Feb 14 14:55:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 14:55:11 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1EMt8jh007633 for ; Mon, 14 Feb 2005 14:55:08 -0800 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 j1F0Q11O018664 for ; Mon, 14 Feb 2005 16:26:01 -0800 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 j1EMt7R02073564; Mon, 14 Feb 2005 16:55:07 -0600 (CST) Received: (from overby@localhost) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) id j1EMt7PO31634398; Mon, 14 Feb 2005 16:55:07 -0600 (CST) Date: Mon, 14 Feb 2005 16:55:07 -0600 (CST) Message-Id: <200502142255.j1EMt7PO31634398@daisy-e236.americas.sgi.com> From: Glen Overby To: dsw@gelato.unsw.edu.au Cc: linux-xfs@oss.sgi.com Subject: Re: What does "xlog_state_do_callback: looping " mean? In-Reply-To: message from Darren Williams sent 15 February 2005 References: <20050214211323.GA14474@cse.unsw.EDU.AU> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4943 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1379 Lines: 30 On February 15, Darren Williams wrote: > We are currently benchmarking Linux scalablity, so to avoid > disk latency issues on filesystem benchmarks we have been > generating each filesystem of interest on ramdisk then > running osdl-re-aim-7 with disk only tests. With xfs I start > seeing the looping messages at about 50 clients, ( using a 2M > FILESIZE and 128M DISKDIR in the reaim.config ) with a 8way > configuration. (This is just for your records) > > What effect can this have on the filesystem transactions, > does it slow writes down due to the out of order logs. We > are currently using the O_SYNC flag on open. What this message is saying is log buffer writes are coming in as fast as the callbacks on them are being processed. I put this this message in the log i/o completion callback about 5 years ago, when fixing out-of-order callback problems. On some systems, buffer completion callbacks are run from an interrupt thread. I had changed xlog_state_do_callback to potentially be an infinite loop, and I was concerned about the overall impact on the system if it were hold the interrupt thread for a long time and possibly hold off other interrupts. The only thing "wrong" is that your CPU and your I/O system are really fast :-) You can safely delete the printing of this message if the message printing process is interfering with your benchmark. Glen From owner-linux-xfs Mon Feb 14 15:17:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 15:17:20 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ENHGg9016227 for ; Mon, 14 Feb 2005 15:17:17 -0800 Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1ENGrHn018726; Tue, 15 Feb 2005 10:16:53 +1100 Received: from jdc.local (ppp1FAC.dsl.pacific.net.au [203.100.245.172]) by mailproxy1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1ENGqS4006968; Tue, 15 Feb 2005 10:16:53 +1100 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.13.3/8.13.3/Debian-6) with ESMTP id j1ENG1IF006889; Tue, 15 Feb 2005 10:16:01 +1100 Received: (from jason@localhost) by jdc.local (8.13.3/8.13.3/Submit) id j1ENG1mw006881; Tue, 15 Feb 2005 10:16:01 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16913.12592.974397.923897@jdc.local> Date: Tue, 15 Feb 2005 10:16:00 +1100 To: martin f krafft Cc: linux-xfs@oss.sgi.com Subject: Re: the thing with the binary zeroes In-Reply-To: <20050214103830.GA6385@localhost.localdomain> References: <20050211121829.GA30049@localhost.localdomain> <200502130215.j1D2FY0w679915@elmo.melbourne.sgi.com> <1108369746.3535.10.camel@venus.local.navi.pl> <20050214103830.GA6385@localhost.localdomain> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4944 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonjgw@pacific.net.au Precedence: bulk X-list: linux-xfs Content-Length: 1039 Lines: 21 martin f krafft writes: > also sprach David J N Begley [2005.02.14.1116 +0100]: > > > (a) people's expectations of XFS are misaligned with XFS' intended work > > environment, in which case the documentaion needs to be updated to > > include a prominent notice in order to correct people's expectations > > (eg., cannot use XFS and expect minimal data loss unless apps are > > written a certain way, full hardware RAID is used and UPS guarantees > > no power loss); > > Is this actually a recommendation? It makes perfect sense, but > I have been using XFS on every workstation, including laptops, with > success for years now, and I can usually warmly recommend it. Should > I maybe stop doing so, considering that XFS seems to be more of > a data center filesystem than one for the workstation or "casual > server"? No, not at all. I have been happily using xfs on my workstation since 2001 and have never had any files containing binary zeros, despite various power failures. From owner-linux-xfs Mon Feb 14 17:05:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 17:05:51 -0800 (PST) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F15jLq024187 for ; Mon, 14 Feb 2005 17:05:46 -0800 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id EF87E8C0BA2 for ; Tue, 15 Feb 2005 02:05:40 +0100 (CET) Received: from wing.madduck.net (84-72-16-99.dclient.hispeed.ch [84.72.16.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "wing.madduck.net", Issuer "madduck.net CA" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id AC3138C0BA1 for ; Tue, 15 Feb 2005 02:05:40 +0100 (CET) Received: by wing.madduck.net (Postfix, from userid 1000) id 9C61A602E9B; Tue, 15 Feb 2005 02:09:32 +0100 (CET) Date: Tue, 15 Feb 2005 02:09:32 +0100 From: martin f krafft To: linux-xfs@oss.sgi.com Subject: Re: the thing with the binary zeroes Message-ID: <20050215010932.GA17722@localhost.localdomain> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20050211121829.GA30049@localhost.localdomain> <200502130215.j1D2FY0w679915@elmo.melbourne.sgi.com> <1108369746.3535.10.camel@venus.local.navi.pl> <20050214103830.GA6385@localhost.localdomain> <16913.12592.974397.923897@jdc.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <16913.12592.974397.923897@jdc.local> X-OS: Debian GNU/Linux 3.1 kernel 2.6.10-wing i686 X-Mailer: Mutt 1.5.6+20040907i (CVS) X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by albatross.madduck.net X-Virus-Status: Clean X-archive-position: 4945 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: linux-xfs Content-Length: 1336 Lines: 40 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Jason White [2005.02.15.0016 +0100]: > No, not at all. I have been happily using xfs on my workstation since > 2001 and have never had any files containing binary zeros, despite > various power failures. Well, same here. It seems like others have had different experiences; I do not want to advocate a filesystem for laptop/workstation use when I am not 100% sure. --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 "once ... in the wilds of afghanistan, i lost my corkscrew, and we were forced to live on nothing but food and water for days." -- w. c. fields, "my little chickadee" --T4sUOijqQbZv57TR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCEUvMIgvIgzMMSnURAtMQAJwKcblkWHi5X3H+Rp2/3vyEolH0cgCg5LvU U/X2dN1UAmkX/cCLJXUXZos= =l6Y6 -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-linux-xfs Mon Feb 14 17:49:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 17:49:58 -0800 (PST) Received: from mail19.syd.optusnet.com.au (mail19.syd.optusnet.com.au [211.29.132.200]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F1nrwv025605 for ; Mon, 14 Feb 2005 17:49:55 -0800 Received: from mail.chubb.wattle.id.au (c220-237-8-57.randw1.nsw.optusnet.com.au [220.237.8.57]) by mail19.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j1F1njYQ031180; Tue, 15 Feb 2005 12:49:46 +1100 Received: from peterc by mail.chubb.wattle.id.au with local (Exim 3.36 #1 (Debian)) id 1D0rqT-0007rH-00; Tue, 15 Feb 2005 12:49:45 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16913.21817.702372.962991@wombat.chubb.wattle.id.au> Date: Tue, 15 Feb 2005 12:49:45 +1100 From: Peter Chubb To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Repeatable hang with XFS under 2.6.11-rc4 X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid Comments: Hyperbole mail buttons accepted, v04.18. X-Face: GgFg(Z>fx((4\32hvXq<)|jndSniCH~~$D)Ka:P@e@JR1P%Vr}EwUdfwf-4j\rUs#JR{'h# !]])6%Jh~b$VA|ALhnpPiHu[-x~@<"@Iv&|%R)Fq[[,(&Z'O)Q)xCqe1\M[F8#9l8~}#u$S$Rm`S9% \'T@`:&8>Sb*c5d'=eDYI&GF`+t[LfDH="MP5rwOO]w>ALi7'=QJHz&y&C&TE_3j! X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4946 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: peterc@gelato.unsw.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 1350 Lines: 28 Running Reaim-7 on a 4G ram disk with 4 processors on Itanium... Every few runs, as the multiprocessing level increases, we see 22 processes hung in sync(), all except one waiting in sync_filesystems() and that one waiting in pagebuf_iowait(). There's lots of free memory, the ram-disk is not full, ... Load average is low; nothing in the logs or on the console. root@trixie:/proc# vmstat 2 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 23027552 1091472 218496 0 0 1 42107 12 6 1 21 78 0 0 0 0 23027552 1091472 218496 0 0 0 0 4110 10 0 0 100 0 0 0 0 23027552 1091472 218496 0 0 0 0 4109 8 0 0 100 0 0 0 0 23027488 1091472 218496 0 0 0 32 4114 15 0 0 100 0 0 0 0 23027488 1091472 218496 0 0 0 0 4110 9 0 0 100 0 0 0 0 23027488 1091472 218496 0 0 0 0 4109 9 0 0 100 0 root@trixie:/proc/fs/xfs# df /mnt/ram-disk Filesystem 1K-blocks Used Available Use% Mounted on /dev/ram1 1038336 127800 910536 13% /mnt/ram-disk -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au The technical we do immediately, the political takes *forever* From owner-linux-xfs Mon Feb 14 18:30:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 18:30:24 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1F2ULWR027086 for ; Mon, 14 Feb 2005 18:30:22 -0800 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 NAA12323; Tue, 15 Feb 2005 13:30:13 +1100 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 j1F2UBXE2269541; Tue, 15 Feb 2005 13:30:11 +1100 (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 j1F2QJ8p001499; Tue, 15 Feb 2005 13:26:20 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j1F2QIxm001497; Tue, 15 Feb 2005 13:26:18 +1100 Date: Tue, 15 Feb 2005 13:26:18 +1100 From: Nathan Scott To: Peter Chubb Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Repeatable hang with XFS under 2.6.11-rc4 Message-ID: <20050215022617.GB875@frodo> References: <16913.21817.702372.962991@wombat.chubb.wattle.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16913.21817.702372.962991@wombat.chubb.wattle.id.au> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4947 X-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: 811 Lines: 22 Hi Peter, On Tue, Feb 15, 2005 at 12:49:45PM +1100, Peter Chubb wrote: > Running Reaim-7 on a 4G ram disk with 4 processors on > Itanium... Every few runs, as the multiprocessing level increases, we > see 22 processes hung in sync(), all except one waiting in > sync_filesystems() and that one waiting in pagebuf_iowait(). That would indicate either XFS dropped the IO completion for a metadata buffer, or the driver didn't pass it back to us. Hard to say which; is this with default mkfs options? If so, try using -ssize=4k at mkfs time, that'll get rid of some of the more unusual IO patterns which XFS can send down. Also try a blocksize the same as the pagesize (16K there I would guess). If the behaviour changes, these'll give us pointers and help isolate where the problem is. cheers. -- Nathan From owner-linux-xfs Mon Feb 14 21:06:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 21:06:23 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1F56JBe003234 for ; Mon, 14 Feb 2005 21:06:20 -0800 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 QAA15248; Tue, 15 Feb 2005 16:06:10 +1100 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 j1F567XE2275637; Tue, 15 Feb 2005 16:06:08 +1100 (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 j1F52F8p001933; Tue, 15 Feb 2005 16:02:16 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j1F52DZn001931; Tue, 15 Feb 2005 16:02:13 +1100 Date: Tue, 15 Feb 2005 16:02:13 +1100 From: Nathan Scott To: James Foris Cc: linux-xfs@oss.sgi.com Subject: Re: extended attributes, XFS, and 2.6.11-rc1 Message-ID: <20050215050213.GE875@frodo> References: <41F04806.4050603@med.ge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41F04806.4050603@med.ge.com> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4948 X-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: 638 Lines: 20 On Thu, Jan 20, 2005 at 06:08:38PM -0600, James Foris wrote: > Could someone please check and let me know if this is something I have done > to myself, or a bug in the mainline linux kerel release: > ... > No such problems exist on my ext2 partition, and the problem goes away > if I "chattr -R -S /xfs/test". > > This has appeared sometime since 2.6.10-bk3 (the last kernel I > built/tested), > which was built with the same configuration options as 2.6.11-rc1-bk5. This problem is fixed in mainline -bk kernels now, James, will be there for 2.6.11 - thanks for reporting (and for the reproducible test case!). cheers. -- Nathan From owner-linux-xfs Mon Feb 14 21:53:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Feb 2005 21:53:12 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1F5r7sG004561 for ; Mon, 14 Feb 2005 21:53:08 -0800 Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1F5qsA6031394; Tue, 15 Feb 2005 16:52:54 +1100 Received: from jdc.local (ppp1FAC.dsl.pacific.net.au [203.100.245.172]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j1F5qqMp031463; Tue, 15 Feb 2005 16:52:53 +1100 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.13.3/8.13.3/Debian-6) with ESMTP id j1F5q2Bv011801; Tue, 15 Feb 2005 16:52:02 +1100 Received: (from jason@localhost) by jdc.local (8.13.3/8.13.3/Submit) id j1F5q2x4011794; Tue, 15 Feb 2005 16:52:02 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16913.36354.331998.392745@jdc.local> Date: Tue, 15 Feb 2005 16:52:02 +1100 To: martin f krafft Cc: linux-xfs@oss.sgi.com Subject: Re: the thing with the binary zeroes In-Reply-To: <20050215010932.GA17722@localhost.localdomain> References: <20050211121829.GA30049@localhost.localdomain> <200502130215.j1D2FY0w679915@elmo.melbourne.sgi.com> <1108369746.3535.10.camel@venus.local.navi.pl> <20050214103830.GA6385@localhost.localdomain> <16913.12592.974397.923897@jdc.local> <20050215010932.GA17722@localhost.localdomain> X-Mailer: VM 7.19 under Emacs 21.3.1 Reply-To: jasonw@ariel.its.unimelb.edu.au X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4949 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.its.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 354 Lines: 10 martin f krafft writes: > > Well, same here. It seems like others have had different > experiences; I do not want to advocate a filesystem for > laptop/workstation use when I am not 100% sure. I would be perfectly happy to recommend it for both laptops and workstations. I would argue that the binary zeros phenomenon is not worth worrying about. From owner-linux-xfs Tue Feb 15 00:12:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Feb 2005 00:12:52 -0800 (PST) Received: from nabe.tequila.jp (nabe.tequila.jp [211.14.136.221]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1F8Cj0C009068 for ; Tue, 15 Feb 2005 00:12:46 -0800 Received: (qmail 6074 invoked from network); 15 Feb 2005 08:12:40 -0000 Received: from unagi.tequila.jp (HELO ?192.168.12.2?) (211.14.136.222) by nabe.tequila.jp with SMTP; 15 Feb 2005 08:12:40 -0000 Message-ID: <4211AEEA.8040901@tequila.co.jp> Date: Tue, 15 Feb 2005 17:12:26 +0900 From: Clemens Schwaighofer Organization: TEQUILA\Japan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220 Thunderbird/1.0 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: samba on xfs fs, problems with read only X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4950 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cs@tequila.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 1490 Lines: 50 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, some time ago I postet this bug to the samba people: https://bugzilla.samba.org/show_bug.cgi?id=2125 - ----- I have four boxes. - - Debian/testing on XFS - - Debian/unstable on ext3 - - Gentoo/stable on XFS - - Redhat 9.0 with samba 3.0.7 on ext3 I access to this box from - - Windows 2000 SP4 (ja) - - Windows XP Pro SP 2 (en) - - Windows XP Pro SP 1 (en) I can set the read-only flag only on the samba boxes with ext3, I can't do that when the samba runs on an xfs box. then I get an "Access denied" error. But, when I set the file to u-w, then windows sees it (on all boxes), but again, only the samba on ext3 can change the attribut back again. I have no set dos attributes turned on, or ea attributes, etc. xfs is mounted with quota and so is ext3. - ----- could there be any problem with XFS? that it doesn't allow certain read only command sets? - -- [ Clemens Schwaighofer -----=====:::::~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [ 6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jp http://www.tbwajapan.co.jp ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCEa7qjBz/yQjBxz8RAoxyAJoCskfim6zh/zOYOtbNF9tJmWns/QCeOwj5 AVjMq3Vmszf2bmZeNYQ55qQ= =LeeP -----END PGP SIGNATURE----- From owner-linux-xfs Tue Feb 15 05:31:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Feb 2005 05:31:20 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1FDVD9E030030 for ; Tue, 15 Feb 2005 05:31:14 -0800 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 j1FF1qib020884 for ; Tue, 15 Feb 2005 07:02:02 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j1FDUg0F9668915; Tue, 15 Feb 2005 07:30:42 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1D12mn-0000JM-00; Tue, 15 Feb 2005 07:30:41 -0600 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 930402 - Add sparse annotations to dmapi Message-Id: From: Christoph Hellwig Date: Tue, 15 Feb 2005 07:30:41 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4951 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3127 Lines: 83 Date: Tue Feb 15 05:30:22 PST 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: roehrich, nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:187694a fs/xfs/xfs_dmapi.c - 1.116 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dmapi.c.diff?r1=text&tr1=1.116&r2=text&tr2=1.115&f=h - sparse annotations Modid: linux:dmapi:187694b fs/dmapi/dmapi_private.h - 1.22 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_private.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h - sparse annotations fs/dmapi/dmapi.h - 1.14 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h - sparse annotations fs/dmapi/dmapi_attr.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_attr.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - sparse annotations fs/dmapi/dmapi_bulkattr.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_bulkattr.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - sparse annotations fs/dmapi/dmapi_config.c - 1.16 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_config.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h - sparse annotations fs/dmapi/dmapi_dmattr.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_dmattr.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - sparse annotations fs/dmapi/dmapi_event.c - 1.29 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_event.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h - sparse annotations fs/dmapi/dmapi_handle.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_handle.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - sparse annotations fs/dmapi/dmapi_hole.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_hole.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - sparse annotations fs/dmapi/dmapi_io.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_io.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - sparse annotations fs/dmapi/dmapi_kern.h - 1.16 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_kern.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h - sparse annotations fs/dmapi/dmapi_region.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_region.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - sparse annotations fs/dmapi/dmapi_right.c - 1.26 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_right.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h - sparse annotations fs/dmapi/dmapi_sysent.c - 1.33 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_sysent.c.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h - sparse annotations fs/dmapi/dmapi_register.c - 1.42 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_register.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h - sparse annotations fs/dmapi/dmapi_session.c - 1.25 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/fs/dmapi/dmapi_session.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h - sparse annotations From owner-linux-xfs Wed Feb 16 02:04:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Feb 2005 02:04:51 -0800 (PST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GA4liE007995 for ; Wed, 16 Feb 2005 02:04:48 -0800 Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1D1M2z-0002Hq-Pu for linux-xfs@oss.sgi.com; Wed, 16 Feb 2005 11:04:41 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1D1M2z-0001kX-83 for linux-xfs@oss.sgi.com; Wed, 16 Feb 2005 11:04:41 +0100 From: Florian Weimer To: linux-xfs@oss.sgi.com Subject: Atomicity of xfs_fsr -- also isolation? Date: Wed, 16 Feb 2005 11:04:41 +0100 Message-ID: <87ll9obz2e.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4952 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fw@deneb.enyo.de Precedence: bulk X-list: linux-xfs Content-Length: 826 Lines: 16 The xfs_fsr manpage contains the following notes: | xfs_fsr improves the layout of extents for each file by copying the | entire file to a temporary location and then interchanging the data | extents of the target and temporary files in an atomic manner. This | method requires that enough free disk space be available to copy any | given file and that the space be less fragmented then the original | file. It also requires the owner of the file to have enough | remaining filespace quota to do the copy on systems running quotas. | xfs_fsr generates a warning message if space is not suffi- cient to | improve the target file. Is it safe to run xfs_fsr on a file which is regularly updated? It seems that if a copy is made and later linked as the original, updates to the file might be lost. Is this really the case? From owner-linux-xfs Wed Feb 16 02:19:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Feb 2005 02:19:27 -0800 (PST) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GAJLXr009554 for ; Wed, 16 Feb 2005 02:19:22 -0800 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id D2FA88C0BB2 for ; Wed, 16 Feb 2005 11:19:18 +0100 (CET) Received: from wing.madduck.net (84-72-20-45.dclient.hispeed.ch [84.72.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "wing.madduck.net", Issuer "madduck.net CA" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id 6FA3E895D6D for ; Wed, 16 Feb 2005 11:19:18 +0100 (CET) Received: by wing.madduck.net (Postfix, from userid 1000) id 9AA38602E9B; Wed, 16 Feb 2005 11:19:17 +0100 (CET) Date: Wed, 16 Feb 2005 11:19:17 +0100 From: martin f krafft To: linux-xfs@oss.sgi.com Subject: Re: Atomicity of xfs_fsr -- also isolation? Message-ID: <20050216101917.GA21891@localhost.localdomain> Mail-Followup-To: linux-xfs@oss.sgi.com References: <87ll9obz2e.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <87ll9obz2e.fsf@deneb.enyo.de> X-OS: Debian GNU/Linux 3.1 kernel 2.6.10-wing i686 X-Mailer: Mutt 1.5.6+20040907i (CVS) X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by albatross.madduck.net X-Virus-Status: Clean X-archive-position: 4953 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: linux-xfs Content-Length: 1215 Lines: 38 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Florian Weimer [2005.02.16.1104 +0100]: > Is it safe to run xfs_fsr on a file which is regularly updated? It > seems that if a copy is made and later linked as the original, updates > to the file might be lost. Is this really the case? It does say "in an atomic manner", leading me to believe that updates to the file are not going to get in the way. --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 tempt not a desperate man. -- william shakespeare --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCEx4lIgvIgzMMSnURAqUJAJ4mPyT4y1yE/0unQeeG0zvliRUlXgCg3RRT q6poB5lPZUPZtAYevBesS9E= =fK2r -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-linux-xfs Wed Feb 16 05:00:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Feb 2005 05:00:50 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.182.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GD0lg8025823 for ; Wed, 16 Feb 2005 05:00:47 -0800 Received: from filter04.roc.ny.frontiernet.net (filter04.roc.ny.frontiernet.net [66.133.183.71]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id 5BDBB364305 for ; Wed, 16 Feb 2005 13:00:46 +0000 (UTC) Received: from relay01.roc.ny.frontiernet.net ([66.133.182.164]) by filter04.roc.ny.frontiernet.net (filter04.roc.ny.frontiernet.net [66.133.183.71]) (amavisd-new, port 10024) with LMTP id 32227-30-73 for ; Wed, 16 Feb 2005 13:00:46 +0000 (UTC) Received: from [192.168.1.100] (67-137-96-87.dsl2.brv.mn.frontiernet.net [67.137.96.87]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id EAD8E364290 for ; Wed, 16 Feb 2005 13:00:44 +0000 (UTC) Message-ID: <421343FB.7090501@xfs.org> Date: Wed, 16 Feb 2005 07:00:43 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Atomicity of xfs_fsr -- also isolation? References: <87ll9obz2e.fsf@deneb.enyo.de> <20050216101917.GA21891@localhost.localdomain> In-Reply-To: <20050216101917.GA21891@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter04.roc.ny.frontiernet.net X-Virus-Status: Clean X-archive-position: 4954 X-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: 1361 Lines: 35 martin f krafft wrote: > also sprach Florian Weimer [2005.02.16.1104 +0100]: > >>Is it safe to run xfs_fsr on a file which is regularly updated? It >>seems that if a copy is made and later linked as the original, updates >>to the file might be lost. Is this really the case? > > > It does say "in an atomic manner", leading me to believe that > updates to the file are not going to get in the way. > xfs_fsr stats the original inode, allocates a new inode and space, it then copies the contents of the first inode over to the second one. A special call is then used to flip the extents of the two inodes, if and only if the first inode has not changed in any way - this check is performed inside the special call using the stat info from the start of the run. This test is done after the inode is locked - there must also be no other reference to the inode at the time and no cached dirty state. If any of these tests fail, the new inode and data are thrown away. If the extent flip succeeds, then the new inode and the old extents are freed. I cannot remember the exact details on the test conditions used in the extent flip logic, but it is designed to abort the defragment if anything about the original inode has changed. This does mean if a large file is being updated all the time, it is pretty hard to defragment it. Steve From owner-linux-xfs Wed Feb 16 05:07:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Feb 2005 05:07:33 -0800 (PST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GD7TgZ026502 for ; Wed, 16 Feb 2005 05:07:29 -0800 Received: from [212.9.189.177] (helo=deneb.enyo.de) by albireo.enyo.de with esmtp id 1D1Otn-0005JM-6s for linux-xfs@oss.sgi.com; Wed, 16 Feb 2005 14:07:23 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1D1Otm-0000Sg-MK for linux-xfs@oss.sgi.com; Wed, 16 Feb 2005 14:07:22 +0100 From: Florian Weimer To: linux-xfs@oss.sgi.com Subject: Re: Atomicity of xfs_fsr -- also isolation? References: <87ll9obz2e.fsf@deneb.enyo.de> <20050216101917.GA21891@localhost.localdomain> Date: Wed, 16 Feb 2005 14:07:22 +0100 In-Reply-To: <20050216101917.GA21891@localhost.localdomain> (martin f. krafft's message of "Wed, 16 Feb 2005 11:19:17 +0100") Message-ID: <87vf8swt4l.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4955 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fw@deneb.enyo.de Precedence: bulk X-list: linux-xfs Content-Length: 550 Lines: 13 * martin f. krafft: > also sprach Florian Weimer [2005.02.16.1104 +0100]: >> Is it safe to run xfs_fsr on a file which is regularly updated? It >> seems that if a copy is made and later linked as the original, updates >> to the file might be lost. Is this really the case? > > It does say "in an atomic manner", leading me to believe that > updates to the file are not going to get in the way. It's possible to have atomic updates without isolation, at least in the database sense of the term (think ACID). That's why I ask. From owner-linux-xfs Wed Feb 16 05:20:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Feb 2005 05:20:32 -0800 (PST) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GDKQkJ027627 for ; Wed, 16 Feb 2005 05:20:26 -0800 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id 68C888C0BB2 for ; Wed, 16 Feb 2005 14:20:24 +0100 (CET) Received: from wing.madduck.net (84-72-20-45.dclient.hispeed.ch [84.72.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "wing.madduck.net", Issuer "madduck.net CA" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id 03EAD8C0BB0 for ; Wed, 16 Feb 2005 14:20:24 +0100 (CET) Received: by wing.madduck.net (Postfix, from userid 1000) id 1FBC7602E9B; Wed, 16 Feb 2005 14:20:22 +0100 (CET) Date: Wed, 16 Feb 2005 14:20:22 +0100 From: martin f krafft To: linux-xfs@oss.sgi.com Subject: Re: Atomicity of xfs_fsr -- also isolation? Message-ID: <20050216132022.GA8898@localhost.localdomain> Mail-Followup-To: linux-xfs@oss.sgi.com References: <87ll9obz2e.fsf@deneb.enyo.de> <20050216101917.GA21891@localhost.localdomain> <87vf8swt4l.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <87vf8swt4l.fsf@deneb.enyo.de> X-OS: Debian GNU/Linux 3.1 kernel 2.6.10-wing i686 X-Mailer: Mutt 1.5.6+20040907i (CVS) X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: by albatross.madduck.net X-Virus-Status: Clean X-archive-position: 4956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: linux-xfs Content-Length: 1228 Lines: 38 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Florian Weimer [2005.02.16.1407 +0100]: > It's possible to have atomic updates without isolation, at least in > the database sense of the term (think ACID). That's why I ask. ... not if they introduce conflicts or cause data loss, though. --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 "der beruf ist eine schutzwehr, hinter welche man sich erlaubterweise zur=FCckziehen kann, wenn bedenken und sorgen allgemeiner art einen anfallen." - friedrich nietzsche --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCE0iWIgvIgzMMSnURAkQyAJ9TizMVVYz+aQxVBlQzQPij89soswCgqy0S CLGXJQvMjFC8LHnvjMBKpbQ= =kELM -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-linux-xfs Wed Feb 16 11:07:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Feb 2005 11:07:42 -0800 (PST) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1GJ7cIx018692 for ; Wed, 16 Feb 2005 11:07:39 -0800 Received: from [212.9.189.177] (helo=deneb.enyo.de) by albireo.enyo.de with esmtp id 1D1UWG-0007wT-RA for linux-xfs@oss.sgi.com; Wed, 16 Feb 2005 20:07:28 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.44) id 1D1UWF-0007lB-VV for linux-xfs@oss.sgi.com; Wed, 16 Feb 2005 20:07:27 +0100 From: Florian Weimer To: linux-xfs@oss.sgi.com Subject: Re: Atomicity of xfs_fsr -- also isolation? References: <87ll9obz2e.fsf@deneb.enyo.de> <20050216101917.GA21891@localhost.localdomain> <87vf8swt4l.fsf@deneb.enyo.de> <20050216132022.GA8898@localhost.localdomain> Date: Wed, 16 Feb 2005 20:07:27 +0100 In-Reply-To: <20050216132022.GA8898@localhost.localdomain> (martin f. krafft's message of "Wed, 16 Feb 2005 14:20:22 +0100") Message-ID: <874qgc1fyo.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4957 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fw@deneb.enyo.de Precedence: bulk X-list: linux-xfs Content-Length: 698 Lines: 16 * martin f. krafft: > also sprach Florian Weimer [2005.02.16.1407 +0100]: >> It's possible to have atomic updates without isolation, at least in >> the database sense of the term (think ACID). That's why I ask. > > ... not if they introduce conflicts or cause data loss, though. Non-serializable histories can result in wrong data even if all transactions involved are atomic. Of course, this is just a matter of definitions Yours seems to include isolation. *shrug* Steve clarified it (thanks!): xfs_fsr provides isolation, but not in the way I hoped. I have to stop the application anyway. 8-/ OTOH, it's better to regenerate the files at the application level, anyway. From owner-linux-xfs Wed Feb 16 17:10:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Feb 2005 17:10:32 -0800 (PST) Received: from bruce.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1H1ATZW018925 for ; Wed, 16 Feb 2005 17:10:30 -0800 Received: by bruce.melbourne.sgi.com (Postfix, from userid 38403) id A7FBB56623; Thu, 17 Feb 2005 11:53:17 +1100 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfstests Message-Id: <20050217005317.A7FBB56623@bruce.melbourne.sgi.com> Date: Thu, 17 Feb 2005 11:53:17 +1100 (EST) From: fsgqa@bruce.melbourne.sgi.com (FSG QA) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4958 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 764 Lines: 21 Add a test to run fsx with the AIO flag switched on, in combination with various other flags. Date: Thu Feb 17 12:09:50 AEDT 2005 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:21536a xfstests/112.out - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/112.out xfstests/112 - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/112 xfstests/group - 1.71 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/group.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h xfstests/075 - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/075.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h From owner-linux-xfs Fri Feb 18 04:11:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Feb 2005 04:11:24 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1ICB2nv005363 for ; Fri, 18 Feb 2005 04:11:02 -0800 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 j1IDg6fZ017951 for ; Fri, 18 Feb 2005 05:42:17 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j1ICAUR02321885; Fri, 18 Feb 2005 06:10:30 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1D26xq-00042D-00; Fri, 18 Feb 2005 06:10:30 -0600 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 930402 - Don't dereference user pointers in xattr by handle ioctls Message-Id: From: Christoph Hellwig Date: Fri, 18 Feb 2005 06:10:30 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4960 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 735 Lines: 21 Date: Fri Feb 18 04:10:05 PST 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:187995a fs/xfs/linux-2.6/xfs_ioctl.c - 1.119 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.119&r2=text&tr2=1.118&f=h - fix direct user pointer dereferences in xattr by handle ioctls small code cleanup fs/xfs/linux-2.4/xfs_ioctl.c - 1.114 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.114&r2=text&tr2=1.113&f=h - fix direct user pointer dereferences in xattr by handle ioctls small code cleanup From owner-linux-xfs Fri Feb 18 06:24:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Feb 2005 06:24:04 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IENxNl015742 for ; Fri, 18 Feb 2005 06:24:00 -0800 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 j1IENxxT029362 for ; Fri, 18 Feb 2005 08:23:59 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j1IENw0F9858592; Fri, 18 Feb 2005 08:23:58 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1D2930-0005JG-00; Fri, 18 Feb 2005 08:23:58 -0600 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 930401 - Fix and streamline directory inode number handling Message-Id: From: Christoph Hellwig Date: Fri, 18 Feb 2005 08:23:58 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4961 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1345 Lines: 36 Date: Fri Feb 18 06:23:30 PST 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:187996a fs/xfs/xfs_dir.c - 1.160 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir.c.diff?r1=text&tr1=1.160&r2=text&tr2=1.159&f=h - use new directory inode helpers fs/xfs/xfs_arch.h - 1.46 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_arch.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h - remove old INT_GET_UNALIGNED* handlers and directory inode handling code add new inodes stores as arrays helpers fs/xfs/xfs_dir2_sf.h - 1.20 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h - use new directory inode helpers fs/xfs/xfs_dir_leaf.c - 1.123 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.c.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h - use new directory inode helpers fs/xfs/xfs_dir_leaf.h - 1.41 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.h.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h - use new directory inode helpers fs/xfs/xfs_dir_sf.h - 1.27 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_sf.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h - use new directory inode helpers From owner-linux-xfs Fri Feb 18 09:20:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Feb 2005 09:20:12 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1IHK3fj029783 for ; Fri, 18 Feb 2005 09:20:04 -0800 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 j1IIp9J2019447 for ; Fri, 18 Feb 2005 10:51:20 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j1IHIW0F9865640; Fri, 18 Feb 2005 11:18:32 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1D2Blv-0006Er-00; Fri, 18 Feb 2005 11:18:31 -0600 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 930861 - 0 vs NULL noise removal in xfsidb Message-Id: From: Christoph Hellwig Date: Fri, 18 Feb 2005 11:18:31 -0600 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4962 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 418 Lines: 15 Date: Fri Feb 18 09:18:14 PST 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: felixb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:188024a fs/xfs/xfsidbg.c - 1.272 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.272&r2=text&tr2=1.271&f=h - Use NULL not 0 for null pointers. From owner-linux-xfs Sun Feb 20 13:57:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Feb 2005 13:57:41 -0800 (PST) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KLvaLA014786 for ; Sun, 20 Feb 2005 13:57:37 -0800 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j1KLvNdU020359; Mon, 21 Feb 2005 08:57:23 +1100 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j1KLvMlO020357; Mon, 21 Feb 2005 08:57:22 +1100 Date: Mon, 21 Feb 2005 08:57:22 +1100 From: Nathan Scott Message-Id: <200502202157.j1KLvMlO020357@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE 907752 - setfattr fix X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4963 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 857 Lines: 20 setfattr line buffer allocation fix from AndreasG. Date: Mon Feb 21 08:56:23 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:21572a attr/VERSION - 1.52 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/VERSION.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h attr/doc/CHANGES - 1.60 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h attr/debian/changelog - 1.53 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/debian/changelog.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h attr/setfattr/setfattr.c - 1.19 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/setfattr/setfattr.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h From owner-linux-xfs Sun Feb 20 14:23:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Feb 2005 14:23:58 -0800 (PST) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1KMNr4J015764 for ; Sun, 20 Feb 2005 14:23:54 -0800 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j1KMNiEu020908; Mon, 21 Feb 2005 09:23:44 +1100 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j1KMNer8020906; Mon, 21 Feb 2005 09:23:40 +1100 Date: Mon, 21 Feb 2005 09:23:40 +1100 From: Nathan Scott Message-Id: <200502202223.j1KMNer8020906@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE 907752 - setfacl fix X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4964 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 844 Lines: 20 setfacl line buffer allocation fix from AndreasG. Date: Mon Feb 21 09:23:23 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:21574a acl/VERSION - 1.70 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/VERSION.diff?r1=text&tr1=1.70&r2=text&tr2=1.69&f=h acl/doc/CHANGES - 1.77 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.77&r2=text&tr2=1.76&f=h acl/debian/changelog - 1.64 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/debian/changelog.diff?r1=text&tr1=1.64&r2=text&tr2=1.63&f=h acl/setfacl/setfacl.c - 1.16 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/setfacl.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h From owner-linux-xfs Mon Feb 21 00:40:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Feb 2005 00:40:34 -0800 (PST) Received: from sainfoin.extra.cea.fr (sainfoin.extra.cea.fr [132.166.172.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1L8eRW3018812 for ; Mon, 21 Feb 2005 00:40:30 -0800 Received: from araneus.saclay.cea.fr (araneus.saclay.cea.fr [132.166.192.110]) by sainfoin.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j1L8eLEZ000757 for ; Mon, 21 Feb 2005 09:40:21 +0100 (MET) Received: from nenuphar.saclay.cea.fr (unverified) by araneus.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Mon, 21 Feb 2005 09:40:21 +0100 Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j1L8eL5u000311 for ; Mon, 21 Feb 2005 09:40:21 +0100 (MET) Message-ID: <42199E75.8090102@ocre.cea.fr> Date: Mon, 21 Feb 2005 09:40:21 +0100 From: Aurelien DEGREMONT - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040113 X-Accept-Language: fr, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS DMAPI implementation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4965 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 450 Lines: 17 Hello I'm looking for any informations concerning DMAPI implementation. The SGI XFS DMAPI implementation is under developement but no documentation is provided. I did not find a easy way to install it (Kernel part). Does a website concerning SGI DMAPI implementation exist ? Does a DMAPI patch for 2.6.10 exist ? How obtain the latest stable version of the DMAPI code ? Any other information are welcomed. Thanks in advance Aurelien Degremont From owner-linux-xfs Mon Feb 21 13:33:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Feb 2005 13:33:04 -0800 (PST) Received: from mail-h12-03.cc.ksu.edu (mail-h12-03.cc.ksu.edu [129.130.12.152]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LLX28T027853 for ; Mon, 21 Feb 2005 13:33:02 -0800 Received: from unix2.cc.ksu.edu (unix2.cc.ksu.edu [129.130.12.4]) by mail-h12-03.cc.ksu.edu (8.12.9/8.12.9) with ESMTP id j1LLWrsC006327; Mon, 21 Feb 2005 15:32:53 -0600 (CST) Received: from localhost (matts@localhost) by unix2.cc.ksu.edu (8.11.6+Sun/8.11.6) with ESMTP id j1LLWqr17196; Mon, 21 Feb 2005 15:32:53 -0600 (CST) X-Authentication-Warning: unix2.cc.ksu.edu: matts owned process doing -bs Date: Mon, 21 Feb 2005 15:32:52 -0600 (CST) From: Matt Stegman X-X-Sender: matts@unix2.cc.ksu.edu To: David Sparks cc: linux-xfs@oss.sgi.com Subject: Re: external log vs internal log and mkfs.xfs options In-Reply-To: <42081627.4090307@activestate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/718/Mon Feb 21 04:38:57 2005 clamav-milter version 0.80j on virusfilter3.cc.ksu.edu X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4966 X-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: 889 Lines: 22 On Mon, 7 Feb 2005, David Sparks wrote: > > Nobody commented on this question though, I'll put it up again. Most of > the information I've gathered on external logs dates back to the IRIX > days -- I hope there isn't anything out of date there. > > > Regarding external logs, I've never formatted a XFS with an external > > log. From what I can gather (google, man pages), doing so is supposed > > to reduce disk head seeking hence performance is improved. Is anyone > > aware of any benchmarks that explore internal/external logs and sizes? > > My preference is for an internal log as that just simplifies things. > > Is there any advantage to an external log on a separate partition on the > same device, as opposed to an external log on a separate device? > Basically is an external log only for performance benefits or are there > robustness benefits also? -- Matt Stegman From owner-linux-xfs Mon Feb 21 13:41:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Feb 2005 13:41:00 -0800 (PST) Received: from mail-h12-03.cc.ksu.edu (mail-h12-03.cc.ksu.edu [129.130.12.152]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LLexud028799 for ; Mon, 21 Feb 2005 13:40:59 -0800 Received: from unix2.cc.ksu.edu (unix2.cc.ksu.edu [129.130.12.4]) by mail-h12-03.cc.ksu.edu (8.12.9/8.12.9) with ESMTP id j1LLewsC008155 for ; Mon, 21 Feb 2005 15:40:58 -0600 (CST) Received: from localhost (matts@localhost) by unix2.cc.ksu.edu (8.11.6+Sun/8.11.6) with ESMTP id j1LLevN19817 for ; Mon, 21 Feb 2005 15:40:58 -0600 (CST) X-Authentication-Warning: unix2.cc.ksu.edu: matts owned process doing -bs Date: Mon, 21 Feb 2005 15:40:57 -0600 (CST) From: Matt Stegman X-X-Sender: matts@unix2.cc.ksu.edu To: linux-xfs@oss.sgi.com Subject: Re: external log vs internal log and mkfs.xfs options In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/718/Mon Feb 21 04:38:57 2005 clamav-milter version 0.80j on virusfilter2.cc.ksu.edu X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4967 X-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: 1105 Lines: 25 Oops. Ignore my last message, it was sent by mistake. Unfortunately Ctrl+X for "send message" is right next to Ctrl+C for "cancel message." -- Matt Stegman On Mon, 21 Feb 2005, Matt Stegman wrote: > On Mon, 7 Feb 2005, David Sparks wrote: > > > > Nobody commented on this question though, I'll put it up again. Most of > > the information I've gathered on external logs dates back to the IRIX > > days -- I hope there isn't anything out of date there. > > > > > Regarding external logs, I've never formatted a XFS with an external > > > log. From what I can gather (google, man pages), doing so is supposed > > > to reduce disk head seeking hence performance is improved. Is anyone > > > aware of any benchmarks that explore internal/external logs and sizes? > > > My preference is for an internal log as that just simplifies things. > > > > Is there any advantage to an external log on a separate partition on the > > same device, as opposed to an external log on a separate device? > > Basically is an external log only for performance benefits or are there > > robustness benefits also? From owner-linux-xfs Mon Feb 21 15:57:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Feb 2005 15:57:39 -0800 (PST) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1LNvYav003756 for ; Mon, 21 Feb 2005 15:57:35 -0800 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j1LNvSXk022317; Tue, 22 Feb 2005 10:57:28 +1100 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j1LNvRlD022297; Tue, 22 Feb 2005 10:57:27 +1100 Date: Tue, 22 Feb 2005 10:57:27 +1100 From: Nathan Scott Message-Id: <200502212357.j1LNvRlD022297@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE 90775 - acl/atttr update X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4968 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1773 Lines: 42 Updated next_line fix from AndreasG Date: Tue Feb 22 10:56:30 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:21593a acl/libmisc/next_line.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libmisc/next_line.c acl/setfacl/setfacl.c - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/setfacl.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h acl/getfacl/getfacl.c - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/getfacl/getfacl.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h acl/libmisc/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libmisc/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/include/misc.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/include/misc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Updated next_line fix from AndreasG Date: Tue Feb 22 10:57:01 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:21594a attr/libmisc/next_line.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libmisc/next_line.c attr/setfattr/setfattr.c - 1.20 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/setfattr/setfattr.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h attr/include/misc.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/include/misc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h attr/libmisc/Makefile - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libmisc/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs Tue Feb 22 02:15:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Feb 2005 02:15:31 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MAFRxQ008557 for ; Tue, 22 Feb 2005 02:15:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j1MAFRYA008556 for linux-xfs@oss.sgi.com; Tue, 22 Feb 2005 02:15:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MAFPSf008541 for ; Tue, 22 Feb 2005 02:15:26 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j1M9PMwJ005566; Tue, 22 Feb 2005 01:25:22 -0800 Date: Tue, 22 Feb 2005 01:25:22 -0800 Message-Id: <200502220925.j1M9PMwJ005566@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 396] New: No such file or directory X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4969 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1576 Lines: 52 http://oss.sgi.com/bugzilla/show_bug.cgi?id=396 Summary: No such file or directory Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: All Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: oh@storageone.co.kr Hi, After upgrading Linux kernel to 2.6.11-rc3 from 2.6.9, the XFS file system seems corrupted. When doing ls in the XFS FS, i got ww47:/home9/CLUB/AAAA/12789/28502 # ls /bin/ls: Police.Story.1.1985.XviD.AC3.2CD-WAF.nfo: No such file or directory /bin/ls: Police.Story.1.1985.XviD.AC3.CD1-WAF.avi: No such file or directory /bin/ls: Police.Story.1.1985.XviD.AC3.CD2-WAF.smi: No such file or directory . .. If i do, rm -rf * w47:/home9/CLUB/AAAA # rm -rf 12789 rm: cannot remove directory `12789/28502': Directory not empty rm: cannot remove directory `12789/28503': Directory not empty rm: cannot remove directory `12789/28504': Directory not empty rm: cannot remove directory `12789/28850': Directory not empty rm: cannot remove directory `12789/29091': Directory not empty This thing is happening all over the file system. I have noticed this problem, after I upgrade to kernel 2.6.11-rc3. I have downgrade to 2.6.9 again, but that problem still comes. I did xfs_repair for the FS, nothing changed, though. Any help will be appreciated. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Feb 22 05:56:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Feb 2005 05:56:27 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MDuMRE024988 for ; Tue, 22 Feb 2005 05:56:22 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j1MDuM6E024987 for linux-xfs@oss.sgi.com; Tue, 22 Feb 2005 05:56:22 -0800 Received: from webmail.tiscali.de (relay1.tiscali.de [62.26.116.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MDuHt4024968; Tue, 22 Feb 2005 05:56:18 -0800 Received: from [169.254.101.1] (213.54.102.12) by webmail.tiscali.de (7.0.036.1) (authenticated as matthias.christian@tiscali.de) id 41B8A9630038AD2D; Tue, 22 Feb 2005 14:56:23 +0100 Message-ID: <421B3A03.90800@tiscali.de> Date: Tue, 22 Feb 2005 14:56:19 +0100 From: Matthias-Christian Ott User-Agent: Mozilla Thunderbird 1.0 (X11/20050108) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bugzilla-daemon@oss.sgi.com CC: xfs-master@oss.sgi.com Subject: Re: [Bug 396] New: No such file or directory References: <200502220925.j1M9PMwJ005566@oss.sgi.com> In-Reply-To: <200502220925.j1M9PMwJ005566@oss.sgi.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-Virus-Status: Clean X-archive-position: 4970 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matthias.christian@tiscali.de Precedence: bulk X-list: linux-xfs Content-Length: 1748 Lines: 63 bugzilla-daemon@oss.sgi.com wrote: >http://oss.sgi.com/bugzilla/show_bug.cgi?id=396 > > Summary: No such file or directory > Product: Linux XFS > Version: unspecified > Platform: IA32 > OS/Version: All > Status: NEW > Severity: normal > Priority: High > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: oh@storageone.co.kr > > >Hi, > >After upgrading Linux kernel to 2.6.11-rc3 from 2.6.9, the XFS file system >seems corrupted. > >When doing ls in the XFS FS, i got > >ww47:/home9/CLUB/AAAA/12789/28502 # ls >/bin/ls: Police.Story.1.1985.XviD.AC3.2CD-WAF.nfo: No such file or directory >/bin/ls: Police.Story.1.1985.XviD.AC3.CD1-WAF.avi: No such file or directory >/bin/ls: Police.Story.1.1985.XviD.AC3.CD2-WAF.smi: No such file or directory >. .. > >If i do, rm -rf * > >w47:/home9/CLUB/AAAA # rm -rf 12789 >rm: cannot remove directory `12789/28502': Directory not empty >rm: cannot remove directory `12789/28503': Directory not empty >rm: cannot remove directory `12789/28504': Directory not empty >rm: cannot remove directory `12789/28850': Directory not empty >rm: cannot remove directory `12789/29091': Directory not empty > > >This thing is happening all over the file system. > >I have noticed this problem, after I upgrade to kernel 2.6.11-rc3. I have >downgrade to 2.6.9 again, but that problem still comes. > >I did xfs_repair for the FS, nothing changed, though. > >Any help will be appreciated. > > > >------- You are receiving this mail because: ------- >You are the assignee for the bug, or are watching the assignee. > > > > > Hi! Was XFS cleanly unmounted before the upgrade? Mattias-Christian Ott From owner-linux-xfs Tue Feb 22 07:34:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Feb 2005 07:34:11 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1MFXoJ9032085 for ; Tue, 22 Feb 2005 07:33:50 -0800 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 j1MH5U9m000624 for ; Tue, 22 Feb 2005 09:05:41 -0800 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j1MFXIR02588344; Tue, 22 Feb 2005 09:33:18 -0600 (CST) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 5F9BA4FDCA; Tue, 22 Feb 2005 09:33:18 -0600 (CST) To: Aurelien DEGREMONT - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: XFS DMAPI implementation Date: Tue, 22 Feb 2005 09:33:18 -0600 From: Dean Roehrich Message-Id: <20050222153318.5F9BA4FDCA@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4971 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 842 Lines: 31 >From: Aurelien DEGREMONT - Stagiaire >Hello > >I'm looking for any informations concerning DMAPI implementation. >The SGI XFS DMAPI implementation is under developement but no >documentation is provided. >I did not find a easy way to install it (Kernel part). DMAPI docs can be found here: http://www.opengroup.org/onlinepubs/9657099/toc.htm The SGI DMAPI implementation is fairly stable, and has been for a long time. We're always fixing bugs or otherwise tweaking it, though. >Does a website concerning SGI DMAPI implementation exist ? No. >Does a DMAPI patch for 2.6.10 exist ? Not at the moment. >How obtain the latest stable version of the DMAPI code ? Get your 2.6 kernel tree from oss.sgi.com. It'll have DMAPI in it already. Hmm, and that just happens to be a 2.6.10-based tree right now. Dean From owner-linux-xfs Tue Feb 22 10:29:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Feb 2005 10:29:17 -0800 (PST) Received: from mail.cambrianventures.com (206.173.21.243.ptr.us.xo.net [206.173.21.243]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1MITD7x013126 for ; Tue, 22 Feb 2005 10:29:13 -0800 Received: (qmail 15741 invoked from network); 22 Feb 2005 18:26:38 -0000 Received: from unknown (HELO wds19.cosmixcorp.com) (206.173.21.85) by ns0.cambrianventures.com with SMTP; 22 Feb 2005 18:26:38 -0000 Subject: Re: Another corrupted filesystem (wds17) From: Douglass Judd To: linux-xfs@oss.sgi.com In-Reply-To: <1107902390.26459.222.camel@sedna.cambrianventures.com> References: <1107902390.26459.222.camel@sedna.cambrianventures.com> Content-Type: text/plain Message-Id: <1109096458.26459.500.camel@sedna.cambrianventures.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Tue, 22 Feb 2005 10:20:58 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4972 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doug@cosmixcorp.com Precedence: bulk X-list: linux-xfs Content-Length: 28985 Lines: 552 Looks like we're having similar problems with EXT-3. Also, it happened again on the same two machines. We're starting to suspect hardware. - Doug On Tue, 2005-02-08 at 14:39, Douglass Judd wrote: > Some background. I'm running a distributed Web crawler on 16 > machines, each with 2 TB of disk space. The machines were all > formated with XFS. This is the second machine that I've had > to roll back to ext3 due to filesystem corruption. > > Here's my attempt to characterize the latest problem: > > Hardware: > Tyan S2882G3NR Thunder K8S Pro Motherboard > Dual AMD Opteron processors > 3ware 9500S-8 RAID Controller > 8 Western Digital 2500SD 250GB disk drives > > The drives are all tied together into a single RAID 5 unit. > > The array is partitioned as follows: > 100 MB /boot partition (ext3) > 16 GB swap partition > the rest is the root (/) partition formatted XFS > > OS: > Fedora Core 3 - 2.6.9 SMP kernel. > > The crawler application, which is built on top of MySQL, > generates the following type of load (iostat): > > avg-cpu: %user %nice %sys %iowait %idle > 7.25 0.00 1.50 48.75 42.50 > > Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 19.40 224.88 32.34 4195.02 2824.88 2097.51 1412.44 27.29 8.74 41.56 3.87 99.50 > sda 0.00 0.00 59.00 89.00 1424.00 4354.50 712.00 2177.25 39.04 6.41 41.63 6.76 100.05 > sda 0.00 33.83 108.96 62.69 2288.56 3866.17 1144.28 1933.08 35.86 5.16 31.30 5.80 99.50 > > I came in one morning about 4 weeks ago and noticed that > the filesystem on one machine (wds17) had shut down. Rebooting > seemed to fix the problem. A few weeks later, I tried greping > through /var/log/messages for XFS error messages and here's what > I saw: > > /var/log# grep -i xfs messages* > > messages:Jan 26 04:02:08 wds17 kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 4340 of file fs/xfs/xfs_bmap.c. Caller 0xffffffff8020a125 > messages:Jan 26 04:02:08 wds17 kernel: Call Trace:{xfs_bmap_read_extents+899} {xfs_iread_extents+197} > messages:Jan 26 04:02:08 wds17 kernel: {xfs_dir2_put_dirent64_direct+0} > messages:Jan 26 04:02:08 wds17 kernel: {xfs_bmap_last_offset+159} {xfs_dir2_isblock+31} > messages:Jan 26 04:02:08 wds17 kernel: {xfs_dir2_getdents+192} {xfs_readdir+102} > [...] > > These messages were being generated once daily at 4:02am which > is when the daily cron job gets run. I then tried listing the > /var/log directory and here's what I got: > > /var/log# ls -l > total 5112 > ?--------- ? ? ? ? ? acp > -rw-r----- 1 root root 80 Jan 31 17:15 acpid > ?--------- ? ? ? ? ? ama > ?--------- ? ? ? ? ? ana > ?--------- ? ? ? ? ? anaconda.log > ?--------- ? ? ? ? ? boo > ?--------- ? ? ? ? ? boo > -rw------- 1 root root 3566 Feb 2 19:05 boot.log > -rw------- 1 root root 105 Jan 23 04:02 boot.log.1 > -rw------- 1 root root 8265 Jan 16 04:02 boot.log.2 > drwxr-xr-x 2 canna canna 6 Sep 27 23:28 canna > ?--------- ? ? ? ? ? cron > -rw------- 1 root root 397138 Jan 23 04:02 cron.1 > -rw------- 1 root root 382145 Jan 16 04:02 cron.2 > -rw------- 1 root root 396661 Jan 9 04:02 cron.3 > -rw------- 1 root root 397080 Jan 2 04:04 cron.4 > drwxr-xr-x 2 lp sys 4096 Jan 23 04:02 cups > -rw-r--r-- 1 root root 12936 Jan 31 17:14 dmesg > drwxr-x--- 2 exim exim 6 Oct 7 03:00 exim > drwxr-xr-x 2 root root 6 Jun 15 2004 fax > drwxr-xr-x 2 root root 79 Dec 20 16:19 gdm > ?--------- ? ? ? ? ? httpd > ?--------- ? ? ? ? ? iii > drwx------ 2 root root 24 Dec 16 13:29 iptraf > ?--------- ? ? ? ? ? las > ?--------- ? ? ? ? ? mai > ?--------- ? ? ? ? ? mai > ?--------- ? ? ? ? ? mai > ?--------- ? ? ? ? ? mai > drwxr-xr-x 2 root root 23 Dec 16 12:31 mail > -rw------- 1 root root 13318 Feb 7 04:07 maillog > -rw------- 1 root root 203188 Jan 9 04:02 maillog.3 > drwxrwsr-x 2 root mailman 6 Oct 18 10:54 mailman > ?--------- ? ? ? ? ? mes > -rw------- 1 root root 1312545 Feb 7 10:21 messages > -rw------- 1 root root 532217 Jan 23 04:02 messages.1 > ?--------- ? ? ? ? ? messages.2 > -rw------- 1 root root 535803 Jan 2 04:04 messages.4 > -rw-r----- 1 mysql mysql 0 Jan 23 04:02 mysqld.log > ?--------- ? ? ? ? ? mysqld.log. > ?--------- ? ? ? ? ? mysqld.log. > ?--------- ? ? ? ? ? mysqld.log. > ?--------- ? ? ? ? ? mysqld.log. > drwxr-xr-x 3 news news 65 Dec 16 13:29 news > ?--------- ? ? ? ? ? pgsql > drwx------ 2 root root 6 Nov 2 07:04 ppp > -rw-r--r-- 1 root root 74215 Feb 7 04:03 prelink.log > drwxr-xr-x 2 privoxy privoxy 6 Sep 9 15:19 privoxy > ?--------- ? ? ? ? ? quagga > drwx------ 3 radiusd radiusd 4096 Jan 1 04:04 radius > drwxr-xr-x 2 root root 6 Jun 15 2004 routed > -rw-r--r-- 1 root root 57666 Feb 7 04:04 rpmpkgs > -rw-r--r-- 1 root root 57666 Jan 22 04:10 rpmpkgs.1 > -rw-r--r-- 1 root root 57666 Jan 15 04:21 rpmpkgs.2 > -rw-r--r-- 1 root root 57586 Jan 8 04:05 rpmpkgs.3 > -rw-r--r-- 1 root root 57586 Jan 1 04:08 rpmpkgs.4 > drwxr-xr-x 2 root root 4096 Feb 7 00:00 sa > drwx------ 2 root root 6 Oct 19 07:53 samba > ?--------- ? ? ? ? ? scr > -rw------- 1 root root 114845 Feb 7 10:21 secure > ?--------- ? ? ? ? ? secure.1 > -rw------- 1 root root 9806 Jan 14 16:35 secure.2 > -rw------- 1 root root 23535 Jan 9 00:11 secure.3 > -rw------- 1 root root 14844 Jan 1 00:02 secure.4 > ?--------- ? ? ? ? ? spo > ?--------- ? ? ? ? ? spo > -rw------- 1 root root 0 Jan 23 04:02 spooler > -rw------- 1 root root 0 Jan 9 04:02 spooler.2 > ?--------- ? ? ? ? ? spooler.4 > drwxr-x--- 2 squid squid 6 Oct 18 14:19 squid > -rw-r--r-- 1 root root 149 Jan 25 23:25 tdm_aen_0.bin > -rw-rw-r-- 1 root root 0 Jan 23 04:02 up2date > -rw-rw-r-- 1 root root 0 Jan 16 04:02 up2date.1 > -rw-rw-r-- 1 root root 0 Jan 12 04:02 up2date.2 > -rw-rw-r-- 1 root root 69 Jan 11 12:32 up2date.3 > drwxr-xr-x 2 uucp uucp 40 Dec 16 13:30 uucp > drwxr-xr-x 2 root root 6 Oct 5 07:53 vbox > -rw-rw-r-- 1 root utmp 86784 Feb 7 10:20 wtmp > ?--------- ? ? ? ? ? wtmp.1 > -rw-r--r-- 1 root root 43112 Jan 11 11:12 Xorg.0.log > ?--------- ? ? ? ? ? Xorg.0.log. > > One thing to keep in mind is that I have not noticed > any corruption in my database, which comprises a fixed > 200 GB InnoDB tablespace file and a few other fixed > MyISAM table files (e.g. these files do not move or grow > they just get updated in place). > > This morning, I shut the machine down and it hung while > it was trying to unmount the filesystems. There was no disk > activity so I did a hard reset. I then booted with a recovery > CD and did an xfs_check and xfs_repair -n: > > # xfs_check /dev/sda3 > dir 3758096515 entry LC_MESSAGES bad offset 0 > dir 3758096516 entry LC_MESSAGES bad offset 0 > dir 3758096516 entry charset bad offset 0 > dir 3758096517 entry LC_MESSAGES bad offset 0 > dir 3758096518 entry LC_MESSAGES bad offset 0 > dir 3758096519 entry LC_MESSAGES bad offset 0 > dir 3758096520 entry entry.desktop bad offset 0 > dir 3758096521 entry LC_MESSAGES bad offset 0 > dir 3758096524 entry README.bonding bad offset 0 > dir 3758096527 block 0 extra leaf entry d3a74ed 2f > dir 3758096527 block 0 extra leaf entry 1c7c34e2 65 > dir 3758096527 block 0 extra leaf entry 3c2df83b b1 > dir 3758096527 block 0 extra leaf entry 3c2df83c 14f > dir 3758096527 block 0 extra leaf entry 3c2df83d 152 > dir 3758096527 block 0 extra leaf entry 3c2df83e 10b > dir 3758096527 block 0 extra leaf entry 3e9a84e8 a > dir 3758096527 block 0 extra leaf entry 56ed8872 29 > dir 3758096527 block 0 extra leaf entry 83781ccf ca > dir 3758096527 block 0 extra leaf entry 8ca5f608 5a > dir 3758096527 block 0 extra leaf entry 995b180b 6d > dir 3758096527 block 0 extra leaf entry 9d9a80e9 129 > dir 3758096527 block 0 extra leaf entry a03a7052 76 > dir 3758096527 block 0 extra leaf entry a03a7054 126 > dir 3758096527 block 0 extra leaf entry a03a7057 9a > dir 3758096527 block 0 extra leaf entry a2260673 179 > dir 3758096527 block 0 extra leaf entry a2260674 17c > dir 3758096527 block 0 extra leaf entry bf5d284d 16a > dir 3758096527 block 0 extra leaf entry bf5d284f 170 > dir 3758096527 block 0 extra leaf entry dc3bb16f 3c > dir ino 3758096527 missing leaf entry for 8363dccf/ca > dir ino 3758096527 missing leaf entry for 1c7c0062/65 > dir ino 3758096527 missing leaf entry for 501d8872/29 > dir ino 3758096527 missing leaf entry for 995ad40b/6d > dir ino 3758096527 missing leaf entry for d3a7480/2f > dir ino 3758096527 missing leaf entry for 3c2df80f/b1 > dir ino 3758096527 missing leaf entry for 301a84e8/a > dir ino 3758096527 missing leaf entry for 3c2df80f/10b > dir ino 3758096527 missing leaf entry for 3c2df80f/14f > dir ino 3758096527 missing leaf entry for dc20316f/3c > dir ino 3758096527 missing leaf entry for 3c2df80f/152 > dir ino 3758096527 missing leaf entry for 901a80e9/129 > dir ino 3758096527 missing leaf entry for a03a7334/126 > dir ino 3758096527 missing leaf entry for bf5d2b37/170 > dir ino 3758096527 missing leaf entry for 8ca99608/5a > dir ino 3758096527 missing leaf entry for bf5d2b35/16a > dir ino 3758096527 missing leaf entry for a227d674/17c > dir ino 3758096527 missing leaf entry for a227d673/179 > dir ino 3758096527 missing leaf entry for a03a7332/76 > dir ino 3758096527 missing leaf entry for a03a7337/9a > bad magic # 0x7bfaf5bb in inode 3758096532 bmbt block 0/8389223 > expected level 0 got 30859 in inode 3758096532 bmbt block 0/8389223 > block 0/8389223 expected type unknown got data > block 0/8389223 claimed by inode 3758096532, previous inum 2953261983 > bad btree nrecs (24735, min=127, max=254) in inode 3758096532 bmap block 8389223 > extent count for ino 3758096532 data fork too low (0) for file format > bad nblocks 87 for inode 3758096532, counted 2 > bad nextents 66 for inode 3758096532, counted 0 > no . entry for directory 3758096532 > no .. entry for directory 3758096532 > dir 3758096534 entry Center bad offset 0 > block 14/612 type unknown not expected > block 14/721 type unknown not expected > block 14/841 type unknown not expected > block 14/956 type unknown not expected > block 14/2416 type unknown not expected > block 14/2561 type unknown not expected > block 14/2726 type unknown not expected > block 14/2880 type unknown not expected > block 14/3047 type unknown not expected > block 14/3210 type unknown not expected > block 14/3375 type unknown not expected > block 14/3540 type unknown not expected > block 14/4267 type unknown not expected > block 14/5147 type unknown not expected > block 14/10899 type unknown not expected > block 14/11252 type unknown not expected > block 14/11375 type unknown not expected > block 14/11518 type unknown not expected > block 14/11660 type unknown not expected > block 14/11799 type unknown not expected > block 14/11937 type unknown not expected > block 14/12522 type unknown not expected > block 14/12626 type unknown not expected > block 14/12751 type unknown not expected > block 14/12860 type unknown not expected > block 14/12972 type unknown not expected > block 14/13062 type unknown not expected > block 14/13161 type unknown not expected > block 14/13269 type unknown not expected > block 14/13388 type unknown not expected > block 14/13504 type unknown not expected > block 14/13631 type unknown not expected > block 14/13796 type unknown not expected > block 14/13964 type unknown not expected > block 14/14111 type unknown not expected > block 14/15983 type unknown not expected > block 14/16112 type unknown not expected > block 14/17304 type unknown not expected > block 14/17578 type unknown not expected > block 14/17700 type unknown not expected > block 14/17819 type unknown not expected > block 14/17942 type unknown not expected > block 14/18071 type unknown not expected > block 14/18192 type unknown not expected > block 14/18326 type unknown not expected > block 14/19971 type unknown not expected > block 14/20068 type unknown not expected > block 14/20186 type unknown not expected > block 14/20315 type unknown not expected > block 14/23700 type unknown not expected > block 14/24648 type unknown not expected > block 14/24977 type unknown not expected > block 14/25001 type unknown not expected > block 14/25023 type unknown not expected > block 14/25040 type unknown not expected > block 14/25056 type unknown not expected > block 14/25185 type unknown not expected > block 14/25227 type unknown not expected > block 14/25257 type unknown not expected > block 14/25635 type unknown not expected > block 14/26936 type unknown not expected > block 14/27218 type unknown not expected > block 14/8389220 type unknown not expected > block 14/8389221 type unknown not expected > block 14/8389222 type unknown not expected > block 14/8389223 type unknown not expected > block 14/8389224 type unknown not expected > block 14/8389225 type unknown not expected > block 14/8389226 type unknown not expected > block 14/8389227 type unknown not expected > block 14/8389228 type unknown not expected > block 14/8389229 type unknown not expected > block 14/8389230 type unknown not expected > block 14/8389231 type unknown not expected > block 14/8389232 type unknown not expected > block 14/8389233 type unknown not expected > block 14/8389234 type unknown not expected > block 14/8389235 type unknown not expected > block 14/8389236 type unknown not expected > block 14/8389237 type unknown not expected > block 14/8389238 type unknown not expected > block 14/8389239 type unknown not expected > block 14/8389240 type unknown not expected > block 14/8389241 type unknown not expected > block 14/8389242 type unknown not expected > block 14/8389243 type unknown not expected > link count mismatch for inode 353681 (name ?), nlink 0, counted 1 > link count mismatch for inode 128 (name ?), nlink 26, counted 27 > link count mismatch for inode 437972 (name ?), nlink 0, counted 1 > link count mismatch for inode 49624 (name ?), nlink 0, counted 1 > link count mismatch for inode 18052 (name ?), nlink 0, counted 1 > link count mismatch for inode 438996 (name ?), nlink 0, counted 1 > link count mismatch for inode 448011 (name ?), nlink 0, counted 1 > link count mismatch for inode 448015 (name ?), nlink 0, counted 1 > link count mismatch for inode 262530 (name ?), nlink 0, counted 1 > link count mismatch for inode 16990 (name ?), nlink 0, counted 1 > link count mismatch for inode 368079 (name ?), nlink 0, counted 1 > link count mismatch for inode 805306496 (name ?), nlink 25, counted 24 > link count mismatch for inode 1073741960 (name ?), nlink 40, counted 39 > link count mismatch for inode 1610662360 (name ?), nlink 2, counted 1 > link count mismatch for inode 1879310722 (name ?), nlink 2, counted 1 > disconnected inode 3758386284, nlink 1 > disconnected inode 3758316708, nlink 1 > disconnected inode 3758148566, nlink 1 > disconnected inode 3758386285, nlink 1 > disconnected inode 3758316709, nlink 1 > disconnected inode 3758148567, nlink 1 > disconnected inode 3758386286, nlink 1 > disconnected inode 3758316710, nlink 1 > disconnected inode 3758148568, nlink 1 > disconnected inode 3758450065, nlink 1 > disconnected inode 3758386287, nlink 1 > disconnected inode 3758316711, nlink 1 > disconnected inode 3758148569, nlink 1 > disconnected inode 3758386288, nlink 1 > disconnected inode 3758316712, nlink 1 > disconnected inode 3758148570, nlink 1 > disconnected inode 3758386289, nlink 1 > disconnected inode 3758316713, nlink 1 > disconnected inode 3758148571, nlink 1 > disconnected inode 3758386290, nlink 1 > [ ... 6325 of these disconnected lines total ...] > > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan (but don't clear) agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > - agno = 8 > - agno = 9 > - agno = 10 > - agno = 11 > - agno = 12 > - agno = 13 > - agno = 14 > entry contains offset out of order in shortform dir 3758096515 > would have corrected entry offsets in directory 3758096515 > entry contains offset out of order in shortform dir 3758096516 > entry contains offset out of order in shortform dir 3758096516 > would have corrected entry offsets in directory 3758096516 > entry contains offset out of order in shortform dir 3758096517 > would have corrected entry offsets in directory 3758096517 > entry contains offset out of order in shortform dir 3758096518 > would have corrected entry offsets in directory 3758096518 > entry contains offset out of order in shortform dir 3758096519 > would have corrected entry offsets in directory 3758096519 > entry contains offset out of order in shortform dir 3758096520 > would have corrected entry offsets in directory 3758096520 > entry contains offset out of order in shortform dir 3758096521 > would have corrected entry offsets in directory 3758096521 > entry contains illegal character in shortform dir 3758096523 > would have junked entry "BuiltInSes" in directory inode 3758096523 > entry contains offset out of order in shortform dir 3758096524 > would have corrected entry offsets in directory 3758096524 > entry at block 0 offset 80 in directory inode 3758096527 has illegal name " las": would clear entry > entry at block 0 offset 328 in directory inode 3758096527 has illegal name " scr": would clear entry > entry at block 0 offset 376 in directory inode 3758096527 has illegal name " iii": would clear entry > entry at block 0 offset 480 in directory inode 3758096527 has illegal name " ama": would clear entry > entry at block 0 offset 720 in directory inode 3758096527 has illegal name " ana": would clear entry > entry at block 0 offset 808 in directory inode 3758096527 has illegal name " acp": would clear entry > entry at block 0 offset 872 in directory inode 3758096527 has illegal name " mes": would clear entry > entry at block 0 offset 944 in directory inode 3758096527 has illegal name " mai": would clear entry > entry at block 0 offset 1232 in directory inode 3758096527 has illegal name " mai": would clear entry > entry at block 0 offset 1416 in directory inode 3758096527 has illegal name " mysqld.log.": would clear entry > entry at block 0 offset 1616 in directory inode 3758096527 has illegal name " Xorg.0.log.": would clear entry > entry at block 0 offset 2136 in directory inode 3758096527 has illegal name " mysqld.log.": would clear entry > entry at block 0 offset 2352 in directory inode 3758096527 has illegal name " mai": would clear entry > entry at block 0 offset 2376 in directory inode 3758096527 has illegal name " mai": would clear entry > entry at block 0 offset 2680 in directory inode 3758096527 has illegal name " mysqld.log.": would clear entry > entry at block 0 offset 2704 in directory inode 3758096527 has illegal name " mysqld.log.": would clear entry > entry at block 0 offset 2896 in directory inode 3758096527 has illegal name " spo": would clear entry > entry at block 0 offset 2944 in directory inode 3758096527 has illegal name " spo": would clear entry > entry at block 0 offset 3016 in directory inode 3758096527 has illegal name " boo": would clear entry > entry at block 0 offset 3040 in directory inode 3758096527 has illegal name " boo": would clear entry > bad magic # 0x7bfaf5bb in inode 3758096532 (data fork) bmbt block 8389223 > bad data fork in inode 3758096532 > would have cleared inode 3758096532 > entry contains offset out of order in shortform dir 3758096534 > would have corrected entry offsets in directory 3758096534 > - 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... > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > entry "man3" at block 0 offset 96 in directory inode 1073741960 references free inode 3758096532 > would clear inode number in entry at offset 96... > - agno = 5 > - agno = 6 > - agno = 7 > - agno = 8 > - agno = 9 > - agno = 10 > - agno = 11 > - agno = 12 > - agno = 13 > - agno = 14 > entry contains offset out of order in shortform dir 3758096515 > would have corrected entry offsets in directory 3758096515 > entry contains offset out of order in shortform dir 3758096516 > entry contains offset out of order in shortform dir 3758096516 > would have corrected entry offsets in directory 3758096516 > entry contains offset out of order in shortform dir 3758096517 > entry "charset" in shortform directory 3758096517 references non-existent inode 368079 > would have junked entry "charset" in directory inode 3758096517 > would have corrected entry offsets in directory 3758096517 > entry contains offset out of order in shortform dir 3758096518 > would have corrected entry offsets in directory 3758096518 > entry contains offset out of order in shortform dir 3758096519 > would have corrected entry offsets in directory 3758096519 > entry contains offset out of order in shortform dir 3758096520 > would have corrected entry offsets in directory 3758096520 > entry contains offset out of order in shortform dir 3758096521 > would have corrected entry offsets in directory 3758096521 > entry contains illegal character in shortform dir 3758096523 > would have junked entry "BuiltInSes" in directory inode 3758096523 > entry contains offset out of order in shortform dir 3758096524 > would have corrected entry offsets in directory 3758096524 > entry "httpd" at block 0 offset 280 in directory inode 3758096527 references non-existent inode 49624 > would clear inode number in entry at offset 280... > entry "quagga" at block 0 offset 408 in directory inode 3758096527 references non-existent inode 262530 > would clear inode number in entry at offset 408... > entry "pgsql" at block 0 offset 544 in directory inode 3758096527 references non-existent inode 353681 > would clear inode number in entry at offset 544... > entry "anaconda.log" at block 0 offset 696 in directory inode 3758096527 references non-existent inode 437972 > would clear inode number in entry at offset 696... > entry "wtmp.1" at block 0 offset 1736 in directory inode 3758096527 references non-existent inode 18052 > would clear inode number in entry at offset 1736... > entry "messages.2" at block 0 offset 1824 in directory inode 3758096527 references non-existent inode 448011 > would clear inode number in entry at offset 1824... > entry "cron" at block 0 offset 2496 in directory inode 3758096527 references non-existent inode 438996 > would clear inode number in entry at offset 2496... > entry "secure.1" at block 0 offset 2824 in directory inode 3758096527 references non-existent inode 16990 > would clear inode number in entry at offset 2824... > entry "spooler.4" at block 0 offset 2872 in directory inode 3758096527 references non-existent inode 448015 > would clear inode number in entry at offset 2872... > bad magic # 0x7bfaf5bb in inode 3758096532 (data fork) bmbt block 8389223 > bad data fork in inode 3758096532 > would have cleared inode 3758096532 > entry contains offset out of order in shortform dir 3758096534 > would have corrected entry offsets in directory 3758096534 > - 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 > No modify flag set, skipping phase 5 > Phase 6 - check inode connectivity... > - traversing filesystem starting at / ... > entry "man3" in directory inode 1073741960 points to free inode 3758096532, would junk entry > entry "charset" in shortform directory 3758096517 references non-existent inode 368079 > would junk entry > entry "charset" in shortform directory 3758096517 references non-existent inode 368079 > would junk entry > entry "log" in dir inode 805306496 inconsistent with .. value (128) in ino 3758096527, > would clear entry "log" > - traversal finished ... > - traversing all unattached subtrees ... > entry "httpd" in directory inode 3758096527 points to non-existent inode, would junk entry > entry "quagga" in directory inode 3758096527 points to non-existent inode, would junk entry > entry "pgsql" in directory inode 3758096527 points to non-existent inode, would junk entry > entry "anaconda.log" in directory inode 3758096527 points to non-existent inode, would junk entry > entry "wtmp.1" in directory inode 3758096527 points to non-existent inode, would junk entry > entry "messages.2" in directory inode 3758096527 points to non-existent inode, would junk entry > entry "cron" in directory inode 3758096527 points to non-existent inode, would junk entry > entry "secure.1" in directory inode 3758096527 points to non-existent inode, would junk entry > entry "spooler.4" in directory inode 3758096527 points to non-existent inode, would junk entry > bad hash table for directory inode 3758096527 (hash value mismatch): would rebuild > - traversals finished ... > - moving disconnected inodes to lost+found ... > disconnected dir inode 1610662360, would move to lost+found > disconnected dir inode 1879310722, would move to lost+found > disconnected dir inode 3758096527, would move to lost+found > disconnected inode 3758104518, would move to lost+found > disconnected inode 3758105657, would move to lost+found > disconnected inode 3758105658, would move to lost+found > disconnected inode 3758105659, would move to lost+found > disconnected inode 3758105660, would move to lost+found > disconnected inode 3758105661, would move to lost+found > disconnected inode 3758105662, would move to lost+found > disconnected inode 3758105663, would move to lost+found > disconnected inode 3758105664, would move to lost+found > disconnected inode 3758105665, would move to lost+found > disconnected inode 3758105666, would move to lost+found > disconnected inode 3758105667, would move to lost+found > disconnected inode 3758105668, would move to lost+found > disconnected inode 3758105669, would move to lost+found > disconnected inode 3758105670, would move to lost+found > disconnected inode 3758105671, would move to lost+found > disconnected inode 3758105672, would move to lost+found > [...] > > > From owner-linux-xfs Wed Feb 23 02:01:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Feb 2005 02:01:53 -0800 (PST) Received: from sainfoin.extra.cea.fr (sainfoin.extra.cea.fr [132.166.172.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NA1oVL019609 for ; Wed, 23 Feb 2005 02:01:51 -0800 Received: from araneus.saclay.cea.fr (araneus.saclay.cea.fr [132.166.192.110]) by sainfoin.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j1NA1iuR000851 for ; Wed, 23 Feb 2005 11:01:44 +0100 (MET) Received: from nenuphar.saclay.cea.fr (unverified) by araneus.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Wed, 23 Feb 2005 11:01:44 +0100 Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j1NA1h5u003773; Wed, 23 Feb 2005 11:01:43 +0100 (MET) Message-ID: <421C5487.1080305@ocre.cea.fr> Date: Wed, 23 Feb 2005 11:01:43 +0100 From: Aurelien DEGREMONT - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040113 X-Accept-Language: fr, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Dean Roehrich Subject: Re: XFS DMAPI implementation References: <20050222162159.DCE404FDCA@chewtoy.americas.sgi.com> In-Reply-To: <20050222162159.DCE404FDCA@chewtoy.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4973 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 4333 Lines: 92 Dean Roehrich a écrit : > It's all of the 2.6.10 kernel. Is there something else you want? No, in fact, i would like less features (no kdb, but it's not really important). The best solution will be to have a dmapi patch which could be used to build our own version of Kernel 2.6.10 tree. Your CVS tree is not so bad, we just don't know, because its a cvs repository, which code is stable, which modification is not. Unfortunately, we're dependent of your kernel tree... > It's used in production environments. We don't make release snapshots for > DMAPI. I suppose we could, but there's never been a need to do so. Presently, if we want to use dmapi, we must use it with your kernel tree . > Are you using the kernel tree you got from oss.sgi.com? I'd like to know what > you're seeing. In fact, i try to extract a kernel patch from your cvs tree against kernel 2.6 without the kdb patch, only the xfs/dmapi modification. Maybe i missed something. To reproduced it, i've just to - load the dmapi module, (DO NOT load the xfs module) - unload the dmapi module. => modprobe segfault. The module is still considered loaded (still in lsmod list), but not usable (the symbols aren't available). OS : Red Hat Enterprise Linux AS release 3.90 (Nahant) Arch : Itanium Here is the kernel messages : ======================================================= DMAPI assertion failed: dm_fsys_map, file: fs/dmapi/dmapi_mountinfo.c, line: 343 kernel BUG at fs/dmapi/dmapi_port.h:72! modprobe[6149]: bugcheck! 0 [1] Modules linked in: dmapi parport_pc lp parport autofs4 nfs lockd sunrpc vfat fat video button joydev md5 ipv6 uhci_hcd ehci_hcd Pid: 6149, CPU 2, comm: modprobe psr : 0000101008126010 ifs : 800000000000030a ip : [] Not tainted ip is at dm_fsys_vector_free+0x130/0x160 [dmapi] unat: 0000000000000000 pfs : 000000000000030a rsc : 0000000000000003 rnat: 0000000000000000 bsps: 0000000000000000 pr : 0000000005569959 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f csd : 0000000000000000 ssd : 0000000000000000 b0 : a000000200228d50 b6 : a000000100322600 b7 : a000000100174660 f6 : 0fffbccccccccc8c00000 f7 : 0ffdc8dc0000000000000 f8 : 10001e000000000000000 f9 : 10002a000000000000000 f10 : 0fffeb33333332fa80000 f11 : 1003e0000000000000000 r1 : a000000100a6e4f0 r2 : 0000000000003a14 r3 : a00000010086ea90 r8 : 0000000000000028 r9 : a0000001007b7b40 r10 : a0000001007b7b38 r11 : a00000010086e700 r12 : e0000004c9f3fdc0 r13 : e0000004c9f38000 r14 : 0000000000004000 r15 : a00000010080a7d8 r16 : 0000000000000001 r17 : a000000100884430 r18 : e0000003ffdc2680 r19 : a0000001008ea9c0 r20 : a0000001008ea990 r21 : a0000001008ea990 r22 : 0000000000000034 r23 : a0000001008bae09 r24 : 0000000000003a69 r25 : 0000000000003a69 r26 : 000000000000003e r27 : 0000001008126010 r28 : a0000001008bae0a r29 : 0000000000003a6a r30 : 0000000000000000 r31 : a000000100883980 Call Trace: [] show_stack+0x80/0xa0 sp=e0000004c9f3f970 bsp=e0000004c9f38fa8 [] show_regs+0x890/0x8c0 sp=e0000004c9f3fb40 bsp=e0000004c9f38f60 [] die+0x150/0x200 sp=e0000004c9f3fb60 bsp=e0000004c9f38f20 [] die_if_kernel+0x40/0x60 sp=e0000004c9f3fb60 bsp=e0000004c9f38ef0 [] ia64_bad_break+0x430/0x4c0 sp=e0000004c9f3fb60 bsp=e0000004c9f38ec8 [] ia64_leave_kernel+0x0/0x260 sp=e0000004c9f3fbf0 bsp=e0000004c9f38ec8 [] dm_fsys_vector_free+0x130/0x160 [dmapi] sp=e0000004c9f3fdc0 bsp=e0000004c9f38e78 [] cleanup_module+0x120/0x140 [dmapi] sp=e0000004c9f3fdc0 bsp=e0000004c9f38e60 [] sys_delete_module+0x320/0x640 sp=e0000004c9f3fdc0 bsp=e0000004c9f38de0 [] ia64_ret_from_syscall+0x0/0x20 sp=e0000004c9f3fe30 bsp=e0000004c9f38de0 [] 0xa000000000010640 sp=e0000004c9f40000 bsp=e0000004c9f38de0 Aurélien From owner-linux-xfs Wed Feb 23 08:18:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Feb 2005 08:18:34 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NGIGrb017000 for ; Wed, 23 Feb 2005 08:18:16 -0800 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 j1NHo6Zq016469 for ; Wed, 23 Feb 2005 09:50:16 -0800 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j1NGHjR02662245; Wed, 23 Feb 2005 10:17:45 -0600 (CST) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id D3A3F4FD83; Wed, 23 Feb 2005 10:17:44 -0600 (CST) To: Aurelien DEGREMONT - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: XFS DMAPI implementation Date: Wed, 23 Feb 2005 10:17:44 -0600 From: Dean Roehrich Message-Id: <20050223161744.D3A3F4FD83@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4974 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1270 Lines: 35 >From: Aurelien DEGREMONT - Stagiaire >Dean Roehrich a écrit : >> It's all of the 2.6.10 kernel. Is there something else you want? > >No, in fact, i would like less features (no kdb, but it's not really >important). The best solution will be to have a dmapi patch which could >be used to build our own version of Kernel 2.6.10 tree. >Your CVS tree is not so bad, we just don't know, because its a cvs >repository, which code is stable, which modification is not. >Unfortunately, we're dependent of your kernel tree... I agree, a patch would be nice. I have done this a few times in the past. Maybe I'll do it again. >> Are you using the kernel tree you got from oss.sgi.com? I'd like to know wh >at >> you're seeing. > >In fact, i try to extract a kernel patch from your cvs tree against >kernel 2.6 without the kdb patch, only the xfs/dmapi modification. Maybe > i missed something. > >To reproduced it, i've just to >- load the dmapi module, >(DO NOT load the xfs module) >- unload the dmapi module. => modprobe segfault. >The module is still considered loaded (still in lsmod list), but not >usable (the symbols aren't available). I don't do unloads of this module. So I'm sure there are lots of problems in that area. Dean From owner-linux-xfs Wed Feb 23 11:54:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Feb 2005 11:54:03 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NJrxKD001804 for ; Wed, 23 Feb 2005 11:54:00 -0800 Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (sccrmhc13) with ESMTP id <2005022319535001600sjgk7e>; Wed, 23 Feb 2005 19:53:54 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) by h00609772adf0.ne.client2.attbi.com (8.13.1/8.13.1) with ESMTP id j1NJrsd5048584; Wed, 23 Feb 2005 14:53:54 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost) by h00609772adf0.ne.client2.attbi.com (8.13.1/8.13.1/Submit) id j1NJrqLc048583; Wed, 23 Feb 2005 14:53:52 -0500 (EST) (envelope-from rodrigc) Date: Wed, 23 Feb 2005 14:53:46 -0500 From: Craig Rodrigues To: linux-xfs@oss.sgi.com Subject: GNUmakefile patch Message-ID: <20050223195346.GA48574@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4975 X-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: 865 Lines: 33 Hi, I am trying to get xfs-cmds to build on FreeBSD. This minor patch fixes GNUmakefile by not hardcoding the name of the 'make' binary. Index: GNUmakefile =================================================================== RCS file: /cvs/xfs-cmds/GNUmakefile,v retrieving revision 1.1 diff -u -r1.1 GNUmakefile --- GNUmakefile 14 Jan 2005 02:47:20 -0000 1.1 +++ GNUmakefile 23 Feb 2005 19:51:51 -0000 @@ -105,11 +105,11 @@ clean: rm -rf RPMS SRPMS BUILD SOURCES for d in $(COMMANDS); do \ - ( cd $(XFS_CMDS_DIR)/$$d && make -i clean ) \ + ( cd $(XFS_CMDS_DIR)/$$d && $(MAKE) -i clean ) \ done realclean: clean - for d in $(COMMANDS); do ( cd $(XFS_CMDS_DIR)/$$d && make realclean ) done + for d in $(COMMANDS); do ( cd $(XFS_CMDS_DIR)/$$d && $(MAKE) realclean ) done clean-lbs: realclean -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs Wed Feb 23 12:50:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Feb 2005 12:50:12 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NKo3WN008107 for ; Wed, 23 Feb 2005 12:50:08 -0800 Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (sccrmhc12) with ESMTP id <2005022320495701200rrp1ue>; Wed, 23 Feb 2005 20:49:57 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) by h00609772adf0.ne.client2.attbi.com (8.13.1/8.13.1) with ESMTP id j1NKnr7H059490 for ; Wed, 23 Feb 2005 15:49:54 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost) by h00609772adf0.ne.client2.attbi.com (8.13.1/8.13.1/Submit) id j1NKnpx7059489 for linux-xfs@oss.sgi.com; Wed, 23 Feb 2005 15:49:51 -0500 (EST) (envelope-from rodrigc) Date: Wed, 23 Feb 2005 15:49:50 -0500 From: Craig Rodrigues To: linux-xfs@oss.sgi.com Subject: aclocal.m4 patch for gmake Message-ID: <20050223204950.GA59479@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4976 X-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: 759 Lines: 29 Hi, Here is another patch, which I found necessary when trying to compile xfsprogs on FreeBSD. Index: aclocal.m4 =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/aclocal.m4,v retrieving revision 1.15 diff -u -r1.15 aclocal.m4 --- aclocal.m4 21 Feb 2005 02:46:54 -0000 1.15 +++ aclocal.m4 23 Feb 2005 20:48:34 -0000 @@ -82,7 +82,7 @@ AC_PACKAGE_NEED_UTILITY($1, "$cc", cc, [C compiler]) if test -z "$MAKE"; then - AC_PATH_PROG(MAKE, gmake,, /usr/bin:/usr/freeware/bin) + AC_PATH_PROG(MAKE, gmake,, /usr/bin:/usr/local/bin:/usr/freeware/bin) fi if test -z "$MAKE"; then AC_PATH_PROG(MAKE, make,, /usr/bin) -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs Wed Feb 23 13:03:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Feb 2005 13:03:58 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1NL3sfi009372 for ; Wed, 23 Feb 2005 13:03:55 -0800 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 IAA18372; Thu, 24 Feb 2005 08:03:37 +1100 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 j1NL3TXE2526678; Thu, 24 Feb 2005 08:03:29 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j1NL3RcW2526518; Thu, 24 Feb 2005 08:03:27 +1100 (EST) Date: Thu, 24 Feb 2005 08:03:26 +1100 From: Nathan Scott To: Craig Rodrigues Cc: linux-xfs@oss.sgi.com Subject: Re: aclocal.m4 patch for gmake Message-ID: <20050224080326.A2527131@wobbly.melbourne.sgi.com> References: <20050223204950.GA59479@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050223204950.GA59479@crodrigues.org>; from rodrigc@crodrigues.org on Wed, Feb 23, 2005 at 03:49:50PM -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4977 X-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: 300 Lines: 17 On Wed, Feb 23, 2005 at 03:49:50PM -0500, Craig Rodrigues wrote: > Hi, > > Here is another patch, which I found necessary when > trying to compile xfsprogs on FreeBSD. > > > Index: aclocal.m4 This is a generated file, the real change is in the m4 subdir - I'll fix that up. cheers. -- Nathan From owner-linux-xfs Wed Feb 23 13:11:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Feb 2005 13:11:49 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1NLBkj7011001 for ; Wed, 23 Feb 2005 13:11:47 -0800 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 IAA18528; Thu, 24 Feb 2005 08:11:32 +1100 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 j1NLBTXE2526930; Thu, 24 Feb 2005 08:11:30 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j1NLBPYr2526071; Thu, 24 Feb 2005 08:11:25 +1100 (EST) Date: Thu, 24 Feb 2005 08:11:24 +1100 From: Nathan Scott To: Aurelien DEGREMONT - Stagiaire Cc: linux-xfs@oss.sgi.com, Dean Roehrich Subject: Re: XFS DMAPI implementation Message-ID: <20050224081124.B2527131@wobbly.melbourne.sgi.com> References: <20050222162159.DCE404FDCA@chewtoy.americas.sgi.com> <421C5487.1080305@ocre.cea.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <421C5487.1080305@ocre.cea.fr>; from degremont@ocre.cea.fr on Wed, Feb 23, 2005 at 11:01:43AM +0100 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j1NLBmj7011004 X-archive-position: 4978 X-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: 1158 Lines: 31 On Wed, Feb 23, 2005 at 11:01:43AM +0100, Aurelien DEGREMONT - Stagiaire wrote: > Dean Roehrich a écrit : > > It's all of the 2.6.10 kernel. Is there something else you want? > > No, in fact, i would like less features (no kdb, but it's not really > important). The best solution will be to have a dmapi patch which could > be used to build our own version of Kernel 2.6.10 tree. You can reverse apply whichever patches you don't want from the split-patches directory at the top level to get you back to a mainline 2.6.10 kernel with only fs/dmapi and fs/xfs updates in it. > Your CVS tree is not so bad, we just don't know, because its a cvs > repository, which code is stable, which modification is not. Its all good; anything you see there has been tested and reviewed internally before going in, so you really should be able to pick up CVS and run with it just about any time and expect it to work. > In fact, i try to extract a kernel patch from your cvs tree against > kernel 2.6 without the kdb patch, only the xfs/dmapi modification. Maybe > i missed something. See above - this is trivial using split-patches/*. cheers. -- Nathan From owner-linux-xfs Wed Feb 23 13:28:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Feb 2005 13:28:58 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1NLStjU011986 for ; Wed, 23 Feb 2005 13:28:56 -0800 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 IAA18931; Thu, 24 Feb 2005 08:28:24 +1100 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 j1NLSMXE2528774; Thu, 24 Feb 2005 08:28:23 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j1NLSKOV2530248; Thu, 24 Feb 2005 08:28:20 +1100 (EST) Date: Thu, 24 Feb 2005 08:28:20 +1100 From: Nathan Scott To: Craig Rodrigues Cc: linux-xfs@oss.sgi.com Subject: Re: GNUmakefile patch Message-ID: <20050224082820.C2527131@wobbly.melbourne.sgi.com> References: <20050223195346.GA48574@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050223195346.GA48574@crodrigues.org>; from rodrigc@crodrigues.org on Wed, Feb 23, 2005 at 02:53:46PM -0500 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4979 X-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: 523 Lines: 18 On Wed, Feb 23, 2005 at 02:53:46PM -0500, Craig Rodrigues wrote: > Hi, > > I am trying to get xfs-cmds to build on FreeBSD. > This minor patch fixes GNUmakefile by not hardcoding > the name of the 'make' binary. This doesn't really seem useful - that Makefile is really just for internal SGI products, and has all sorts of rpm knowledge. It also wants to build all 5 packages, and I can't see that being too useful for you (FreeBSD will have its own acl and extended attribute userspace code, no?) cheers. -- Nathan From owner-linux-xfs Wed Feb 23 13:32:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Feb 2005 13:32:22 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NLWBYC012968 for ; Wed, 23 Feb 2005 13:32:14 -0800 Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (sccrmhc14) with ESMTP id <2005022321320501400s3ipke>; Wed, 23 Feb 2005 21:32:05 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) by h00609772adf0.ne.client2.attbi.com (8.13.1/8.13.1) with ESMTP id j1NLW1O8062998; Wed, 23 Feb 2005 16:32:02 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost) by h00609772adf0.ne.client2.attbi.com (8.13.1/8.13.1/Submit) id j1NLW0NG062997; Wed, 23 Feb 2005 16:32:00 -0500 (EST) (envelope-from rodrigc) Date: Wed, 23 Feb 2005 16:31:59 -0500 From: Craig Rodrigues To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: GNUmakefile patch Message-ID: <20050223213159.GA62989@crodrigues.org> References: <20050223195346.GA48574@crodrigues.org> <20050224082820.C2527131@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050224082820.C2527131@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4980 X-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: 753 Lines: 22 On Thu, Feb 24, 2005 at 08:28:20AM +1100, Nathan Scott wrote: > On Wed, Feb 23, 2005 at 02:53:46PM -0500, Craig Rodrigues wrote: > > Hi, > > > > I am trying to get xfs-cmds to build on FreeBSD. > > This minor patch fixes GNUmakefile by not hardcoding > > the name of the 'make' binary. > > This doesn't really seem useful - that Makefile is really > just for internal SGI products, and has all sorts of rpm > knowledge. It also wants to build all 5 packages, and I > can't see that being too useful for you (FreeBSD will have > its own acl and extended attribute userspace code, no?) Possibly, but you should always use $(MAKE) instead of hardcoding the name of the make binary in GNU makefiles. -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs Wed Feb 23 14:25:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Feb 2005 14:25:50 -0800 (PST) Received: from ims.2wire.com ([63.203.253.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1NMPjPC018101 for ; Wed, 23 Feb 2005 14:25:45 -0800 Received: from exchange02.corp.2wire.com ([10.0.0.72]) by ims.2wire.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Feb 2005 14:25:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C519F6.9BF1E3EB" Subject: RE: xfs kernel panic in 2.4.25 with mips Date: Wed, 23 Feb 2005 14:25:41 -0800 Message-ID: <2EC66A66CED84641A69764BF65D877D00232D6F6@exchange02.corp.2wire.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: xfs kernel panic in 2.4.25 with mips Thread-Index: AcUQEzoy7oi5m2YFSrCq/cFHvC8GNAJ2tiiA From: "Josh Radel" To: "Christoph Hellwig" Cc: X-OriginalArrivalTime: 23 Feb 2005 22:25:39.0564 (UTC) FILETIME=[9A8F02C0:01C519F6] X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4981 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jradel@2wire.com Precedence: bulk X-list: linux-xfs Content-Length: 10338 Lines: 203 This is a multi-part message in MIME format. ------_=_NextPart_001_01C519F6.9BF1E3EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Fri, Feb 11, 2005 at 00:25:21 -0800, Christoph Hellwig wrote: > 2.4.25 is from stoneage. Please retry with 2.4.29 or even better a=20 > recent 2.6 kernel. Because of kernel-dependent hardware drivers, I can't actually use a stock 2.4.29 or 2.6 kernel. I grabbed the fs/xfs directory (and include/linux/dqblk_xfs.h) from the 2.4.29 tree, dropped it into the 2.4.25 tree, everything compiled, and XFS seems to work perfectly as long as I cleanly umount the fs. While running my test program (writes out data to disk, using XFS_IOC_RESVSP to preallocate space; I am not flagging unwritten extents) and I suddenly cut power, maybe 1 in 5 times the fs will not pass xfs_check (yes, I do a mount and umount first, to replay the journal). So I guess I have a couple questions: - Are the XFS changes between 2.4.25 and 2.4.29 limited to the fs/xfs directory, or are there other kernel pieces that needed to be fixed up? (If so, is there an easy way to figure out what those other required changes were?) - Is it possible there is a journal replay problem with the XFS_IOC_RESVSP ioctl? I haven't been able to reproduce my problems when not using it. Is there some kind of block reclaim operation that needs to take place but doesn't when a file isn't properly closed? I've attached the output from "xfs_logprint -c -t -i -b" from before the journal was replayed, and an abbreviated output from "xfs_check" from after the journal replay. Thanks, Josh -----Original Message----- From: Christoph Hellwig [mailto:hch@infradead.org]=20 Sent: Friday, February 11, 2005 12:25 AM To: Josh Radel Cc: linux-xfs@oss.sgi.com Subject: Re: xfs kernel panic in 2.4.25 with mips On Thu, Feb 10, 2005 at 07:35:48PM -0800, Josh Radel wrote: > I'm attempting to use XFS on an embedded mips32 system running the=20 > 2.4.25 kernel, and am running into some kernel panics. Here are three=20 > different scenarios with different (though 100% reproducible) panics.=20 > In all situations, XFS is compiled into the kernel (but no other XFS=20 > options, except for case (3)). I've included the kernel oops message=20 > as well as the version run through ksymoops for each case at the end=20 > of this message. 2.4.25 is from stoneage. Please retry with 2.4.29 or even better a recent 2.6 kernel. ------_=_NextPart_001_01C519F6.9BF1E3EB Content-Type: text/plain; name="xfs_logprint.txt" Content-Transfer-Encoding: base64 Content-Description: xfs_logprint.txt Content-Disposition: attachment; filename="xfs_logprint.txt" eGZzX2xvZ3ByaW50Og0KICAgIGRhdGEgZGV2aWNlOiAweDMwMw0KICAgIGxv ZyBkZXZpY2U6IDB4MzAzIGRhZGRyOiAxNTkzODM1ODQgbGVuZ3RoOiAxNTI0 NjQNCg0KICAgIGxvZyB0YWlsOiAxNTU2NiBoZWFkOiAxNTU3NCBzdGF0ZTog PERJUlRZPg0KDQoNCkxPRyBSRUMgQVQgTFNOIGN5Y2xlIDEgYmxvY2sgMTU1 NjYgKDB4MSwgMHgzY2NlKQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KVFJBTlM6IHRpZDoweDhmNzQ1ZWUwICB0eXBlOkRJT1NUUkFUICAj aXRlbXM6MiAgdHJhbnM6MHgwICBxOjB4MTAwMDhmOTANCklOTzogY250OjMg dG90YWw6MyBhOjB4MTAwMDhmYjAgbGVuOjU2IGE6MHgxMDAwOTAxMCBsZW46 OTYgYToweDEwMDA5MDc4IGxlbjoxNiANCglJTk9ERTogI3JlZ3M6MyAgIGlu bzoweDgzICBmbGFnczoweDUgICBkc2l6ZToxNg0KCUNPUkUgaW5vZGU6DQoJ CW1hZ2ljOklOICBtb2RlOjB4ODAwMSAgdmVyOjEgIGZvcm1hdDoyICBvbmxp bms6MQ0KCQl1aWQ6MCAgZ2lkOjAgIG5saW5rOjEgcHJvamlkOjANCgkJYXRp bWU6MTEwOTEyNjQzNSAgbXRpbWU6MTEwOTEyNjg1MiAgY3RpbWU6MTEwOTEy Njg1Mg0KCQlmbHVzaGl0ZXI6NzQNCgkJc2l6ZToweGUwNGMwMDAwICBuYmxr czoweGRhZTYwICBleHNpemU6MCAgbmV4dGVudHM6MSAgYW5leHRlbnRzOjAN CgkJZm9ya29mZjowICBkbWV2bWFzazoweDAgIGRtc3RhdGU6MCAgZmxhZ3M6 MHgyICBnZW46MA0KCQlEQVRBIEZPUksgRVhURU5UUyBpbm9kZSBkYXRhOg0K RUZJOiBjbnQ6MSB0b3RhbDoxIGE6MHgxMDAwOTA5MCBsZW46MzIgDQoJRUZJ OiAgI3JlZ3M6MSAgICBudW1fZXh0ZW50czoxICBpZDoweGZmZmZmZmZmODll MjQxYTgNCgkoczogMHg1MGJjLCBsOiAyMDY0KSANCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NClRSQU5TOiB0aWQ6MHg4Zjc0NWVlMCAgdHlw ZTpESU9TVFJBVCAgI2l0ZW1zOjUgIHRyYW5zOjB4MCAgcToweDEwMDA5MGI4 DQpFRkQ6IGNudDoxIHRvdGFsOjEgYToweDEwMDA5MDkwIGxlbjozMiANCglF RkQ6ICAjcmVnczogMSAgICBudW1fZXh0ZW50czogMSAgaWQ6IDB4ZmZmZmZm ZmY4OWUyNDFhOA0KCShzOiAweDUwYmMsIGw6IDIwNjQpIA0KQlVGOiBjbnQ6 MiB0b3RhbDoyIGE6MHgxMDAwOGY5MCBsZW46MjQgYToweDEwMDA5MGU4IGxl bjoxMjggDQoJQlVGOiAgI3JlZ3M6MiAgIHN0YXJ0IGJsa25vOjB4MSAgIGxl bjoxICAgYm1hcCBzaXplOjENCglBR0YgQnVmZmVyOiAoWEFHRikNCgkJdmVy OjEgIHNlcSM6MCAgbGVuOjEwNDg1NzYgIA0KCQlyb290IEJOTzoxICBDTlQ6 Mg0KCQlsZXZlbCBCTk86MSAgQ05UOjENCgkJMXN0OjAgIGxhc3Q6MyAgY250 OjQgIGZyZWVibGtzOjE1MTk1NiAgbG9uZ2VzdDoxMjkyMzYNCkJVRjogY250 OjIgdG90YWw6MiBhOjB4MTAwMDkwMTAgbGVuOjI4IGE6MHgxMDAwOTE3MCBs ZW46MTI4IA0KCUJVRjogICNyZWdzOjIgICBzdGFydCBibGtubzoweDggICBs ZW46OCAgIGJtYXAgc2l6ZToyDQoJQlVGIERBVEENCkJVRjogY250OjIgdG90 YWw6MiBhOjB4MTAwMDkxZjggbGVuOjI4IGE6MHgxMDAwOTI1MCBsZW46MTI4 IA0KCUJVRjogICNyZWdzOjIgICBzdGFydCBibGtubzoweDEwICAgbGVuOjgg ICBibWFwIHNpemU6Mg0KCUJVRiBEQVRBDQpCVUY6IGNudDoyIHRvdGFsOjIg YToweDEwMDA5MmQ4IGxlbjoyNCBhOjB4MTAwMDkzMzAgbGVuOjEyOCANCglC VUY6ICAjcmVnczoyICAgc3RhcnQgYmxrbm86MHgwICAgbGVuOjEgICBibWFw IHNpemU6MQ0KCVNVUEVSIEJsb2NrIEJ1ZmZlcjoNCgkJaWNvdW50OjY0ICBp ZnJlZTo1OSAgZmRibGtzOjM4MTE2MTAzICBmcmV4dDowDQoJCXN1bml0OjAg IHN3aWR0aDowDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpU UkFOUzogdGlkOjB4OGY3NDVmMDAgIHR5cGU6V1JJVEVJRCAgI2l0ZW1zOjEg IHRyYW5zOjB4MCAgcToweDEwMDA5MmY4DQpJTk86IGNudDozIHRvdGFsOjMg YToweDEwMDA4ZmIwIGxlbjo1NiBhOjB4MTAwMDkyNTAgbGVuOjk2IGE6MHgx MDAwOTMxOCBsZW46MTYgDQoJSU5PREU6ICNyZWdzOjMgICBpbm86MHg4MyAg ZmxhZ3M6MHg1ICAgZHNpemU6MTYNCglDT1JFIGlub2RlOg0KCQltYWdpYzpJ TiAgbW9kZToweDgwMDEgIHZlcjoxICBmb3JtYXQ6MiAgb25saW5rOjENCgkJ dWlkOjAgIGdpZDowICBubGluazoxIHByb2ppZDowDQoJCWF0aW1lOjExMDkx MjY0MzUgIG10aW1lOjExMDkxMjY4NTIgIGN0aW1lOjExMDkxMjY4NTINCgkJ Zmx1c2hpdGVyOjc0DQoJCXNpemU6MHhlMDRjMDAwMCAgbmJsa3M6MHhkYWU2 MCAgZXhzaXplOjAgIG5leHRlbnRzOjEgIGFuZXh0ZW50czowDQoJCWZvcmtv ZmY6MCAgZG1ldm1hc2s6MHgwICBkbXN0YXRlOjAgIGZsYWdzOjB4MiAgZ2Vu OjANCgkJREFUQSBGT1JLIEVYVEVOVFMgaW5vZGUgZGF0YToNCg0KTE9HIFJF QyBBVCBMU04gY3ljbGUgMSBibG9jayAxNTU3MCAoMHgxLCAweDNjZDIpDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpUUkFOUzogdGlkOjB4 OGY3NDVmNDAgIHR5cGU6RElPU1RSQVQgICNpdGVtczo1ICB0cmFuczoweDAg IHE6MHgxMDAwOTJmOA0KSU5POiBjbnQ6MyB0b3RhbDozIGE6MHgxMDAwOGZi MCBsZW46NTYgYToweDEwMDA5MjUwIGxlbjo5NiBhOjB4MTAwMDkzMTggbGVu OjE2IA0KCUlOT0RFOiAjcmVnczozICAgaW5vOjB4ODMgIGZsYWdzOjB4NSAg IGRzaXplOjE2DQoJQ09SRSBpbm9kZToNCgkJbWFnaWM6SU4gIG1vZGU6MHg4 MDAxICB2ZXI6MSAgZm9ybWF0OjIgIG9ubGluazoxDQoJCXVpZDowICBnaWQ6 MCAgbmxpbms6MSBwcm9qaWQ6MA0KCQlhdGltZToxMTA5MTI2NDM1ICBtdGlt ZToxMTA5MTI2ODUyICBjdGltZToxMTA5MTI2ODUyDQoJCWZsdXNoaXRlcjo3 NA0KCQlzaXplOjB4ZTA3MDAwMDAgIG5ibGtzOjB4ZGI2NDAgIGV4c2l6ZTow ICBuZXh0ZW50czoxICBhbmV4dGVudHM6MA0KCQlmb3Jrb2ZmOjAgIGRtZXZt YXNrOjB4MCAgZG1zdGF0ZTowICBmbGFnczoweDIgIGdlbjowDQoJCURBVEEg Rk9SSyBFWFRFTlRTIGlub2RlIGRhdGE6DQpCVUY6IGNudDoyIHRvdGFsOjIg YToweDEwMDA5MjE4IGxlbjoyNCBhOjB4MTAwMDkwZTggbGVuOjEyOCANCglC VUY6ICAjcmVnczoyICAgc3RhcnQgYmxrbm86MHgxICAgbGVuOjEgICBibWFw IHNpemU6MQ0KCUFHRiBCdWZmZXI6IChYQUdGKQ0KCQl2ZXI6MSAgc2VxIzow ICBsZW46MTA0ODU3NiAgDQoJCXJvb3QgQk5POjEgIENOVDoyDQoJCWxldmVs IEJOTzoxICBDTlQ6MQ0KCQkxc3Q6MCAgbGFzdDozICBjbnQ6NCAgZnJlZWJs a3M6MTQ5OTQwICBsb25nZXN0OjEyNzIyMA0KQlVGOiBjbnQ6MiB0b3RhbDoy IGE6MHgxMDAwOTAzMCBsZW46MjggYToweDEwMDA5MTcwIGxlbjoxMjggDQoJ QlVGOiAgI3JlZ3M6MiAgIHN0YXJ0IGJsa25vOjB4MTAgICBsZW46OCAgIGJt YXAgc2l6ZToyDQoJQlVGIERBVEENCkJVRjogY250OjIgdG90YWw6MiBhOjB4 MTAwMDhmZjAgbGVuOjI4IGE6MHgxMDAwOTMzMCBsZW46MTI4IA0KCUJVRjog ICNyZWdzOjIgICBzdGFydCBibGtubzoweDggICBsZW46OCAgIGJtYXAgc2l6 ZToyDQoJQlVGIERBVEENCkJVRjogY250OjIgdG90YWw6MiBhOjB4MTAwMDkw YjggbGVuOjI0IGE6MHgxMDAwOTNkMCBsZW46MTI4IA0KCUJVRjogICNyZWdz OjIgICBzdGFydCBibGtubzoweDAgICBsZW46MSAgIGJtYXAgc2l6ZToxDQoJ U1VQRVIgQmxvY2sgQnVmZmVyOg0KCQlpY291bnQ6NjQgIGlmcmVlOjU5ICBm ZGJsa3M6MzgxMTQwODcgIGZyZXh0OjANCgkJc3VuaXQ6MCAgc3dpZHRoOjAN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClRSQU5TOiB0aWQ6 MHg4Zjc0NWY2MCAgdHlwZTpXUklURUlEICAjaXRlbXM6MSAgdHJhbnM6MHgw ICBxOjB4MTAwMDkyYjgNCklOTzogY250OjMgdG90YWw6MyBhOjB4MTAwMDhm YjAgbGVuOjU2IGE6MHgxMDAwOTI1MCBsZW46OTYgYToweDEwMDA5M2I4IGxl bjoxNiANCglJTk9ERTogI3JlZ3M6MyAgIGlubzoweDgzICBmbGFnczoweDUg ICBkc2l6ZToxNg0KCUNPUkUgaW5vZGU6DQoJCW1hZ2ljOklOICBtb2RlOjB4 ODAwMSAgdmVyOjEgIGZvcm1hdDoyICBvbmxpbms6MQ0KCQl1aWQ6MCAgZ2lk OjAgIG5saW5rOjEgcHJvamlkOjANCgkJYXRpbWU6MTEwOTEyNjQzNSAgbXRp bWU6MTEwOTEyNjg1MiAgY3RpbWU6MTEwOTEyNjg1Mg0KCQlmbHVzaGl0ZXI6 NzQNCgkJc2l6ZToweGUwNzAwMDAwICBuYmxrczoweGRiNjQwICBleHNpemU6 MCAgbmV4dGVudHM6MSAgYW5leHRlbnRzOjANCgkJZm9ya29mZjowICBkbWV2 bWFzazoweDAgIGRtc3RhdGU6MCAgZmxhZ3M6MHgyICBnZW46MA0KCQlEQVRB IEZPUksgRVhURU5UUyBpbm9kZSBkYXRhOg0K ------_=_NextPart_001_01C519F6.9BF1E3EB Content-Type: text/plain; name="xfs_check.txt" Content-Transfer-Encoding: base64 Content-Description: xfs_check.txt Content-Disposition: attachment; filename="xfs_check.txt" YmFkIG1hZ2ljICMgMCBpbiBpbm9kZSAxMzEgYm1idCBibG9jayAwLzEzMjU1 NQ0KZXh0ZW50IGNvdW50IGZvciBpbm8gMTMxIGRhdGEgZm9yayB0b28gbG93 ICgwKSBmb3IgZmlsZSBmb3JtYXQNCmJhZCBuYmxvY2tzIDg5ODYyNSBmb3Ig aW5vZGUgMTMxLCBjb3VudGVkIDENCmJhZCBuZXh0ZW50cyAzMyBmb3IgaW5v ZGUgMTMxLCBjb3VudGVkIDANCmJsb2NrIDAvMjI3MzIgdHlwZSB1bmtub3du IG5vdCBleHBlY3RlZA0KYmxvY2sgMC8yMjczMyB0eXBlIHVua25vd24gbm90 IGV4cGVjdGVkDQpibG9jayAwLzIyNzM0IHR5cGUgdW5rbm93biBub3QgZXhw ZWN0ZWQNCmJsb2NrIDAvMjI3MzUgdHlwZSB1bmtub3duIG5vdCBleHBlY3Rl ZA0KYmxvY2sgMC8yMjczNiB0eXBlIHVua25vd24gbm90IGV4cGVjdGVkDQpi bG9jayAwLzIyNzM3IHR5cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmJsb2Nr IDAvMjI3MzggdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KLi4uYWJicmV2 aWF0ZWQ6IGNvbnRpbnVlcyBsaWtlIHRoaXMgdXAgdW50aWwgdGhlIGVuZC4u Lg0KYmxvY2sgMC85MjEzNDggdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0K YmxvY2sgMC85MjEzNDkgdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxv Y2sgMC85MjEzNTAgdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sg MC85MjEzNTEgdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC85 MjEzNTIgdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC85MjEz NTMgdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC85MjEzNTQg dHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC85MjEzNTUgdHlw ZSB1bmtub3duIG5vdCBleHBlY3RlZA0K ------_=_NextPart_001_01C519F6.9BF1E3EB-- From owner-linux-xfs Thu Feb 24 13:22:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Feb 2005 13:22:26 -0800 (PST) Received: from imo-d20.mx.aol.com (imo-d20.mx.aol.com [205.188.139.136]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1OLMJXS025504 for ; Thu, 24 Feb 2005 13:22:19 -0800 Received: from AndyLiebman@aol.com by imo-d20.mx.aol.com (mail_out_v37_r3.8.) id 4.7e.64044ca7 (3924) for ; Thu, 24 Feb 2005 16:21:59 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <7e.64044ca7.2f4f9f77@aol.com> Date: Thu, 24 Feb 2005 16:21:59 EST Subject: 64k block size in 64-bit Linux 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 1200 X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4985 X-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: 574 Lines: 16 Question. I just loaded up a 64-bit distribution of Linux. I compiled the kernel optimized for AMD -- (which is what I have, dual Opterons). When I go to put XFS on my big RAID array, I am able to create the filesystem with a 64k block size. But then I can't mount it. I was under the impression that with 64-bit Linux, one could make xfs partitions with large block sizes -- that with 64-bit Linux, there's no 4K limitation. Am I missing something? What do I have to do to be able to mount this RAID? Thanks in advance for some wisdom. Andy Liebman From owner-linux-xfs Thu Feb 24 13:52:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Feb 2005 13:52:54 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1OLqot3027755 for ; Thu, 24 Feb 2005 13:52:51 -0800 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 IAA16145; Fri, 25 Feb 2005 08:52:39 +1100 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 j1OLqWXE2555438; Fri, 25 Feb 2005 08:52:32 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j1OLqRSF2554323; Fri, 25 Feb 2005 08:52:27 +1100 (EST) Date: Fri, 25 Feb 2005 08:52:27 +1100 From: Nathan Scott To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com Subject: Re: 64k block size in 64-bit Linux Message-ID: <20050225085227.N2527131@wobbly.melbourne.sgi.com> References: <7e.64044ca7.2f4f9f77@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7e.64044ca7.2f4f9f77@aol.com>; from AndyLiebman@aol.com on Thu, Feb 24, 2005 at 04:21:59PM -0500 X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4986 X-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: 803 Lines: 23 On Thu, Feb 24, 2005 at 04:21:59PM -0500, AndyLiebman@aol.com wrote: > Question. > > I just loaded up a 64-bit distribution of Linux. I compiled the kernel > optimized for AMD -- (which is what I have, dual Opterons). When I go to put XFS > on my big RAID array, I am able to create the filesystem with a 64k block > size. But then I can't mount it. > > I was under the impression that with 64-bit Linux, one could make xfs > partitions with large block sizes -- that with 64-bit Linux, there's no 4K > limitation. Am I missing something? What do I have to do to be able to mount this > RAID? > > Thanks in advance for some wisdom. The limitation is the size of a page. If you have a kernel that can support 64K pages (eg. IA64), then you can use 64K blocks. cheers. -- Nathan From owner-linux-xfs Thu Feb 24 13:53:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Feb 2005 13:53:12 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1OLrBgb027880 for ; Thu, 24 Feb 2005 13:53:11 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1D4Quz-0001uo-KY; Thu, 24 Feb 2005 21:53:09 +0000 Date: Thu, 24 Feb 2005 21:53:09 +0000 From: Christoph Hellwig To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com Subject: Re: 64k block size in 64-bit Linux Message-ID: <20050224215309.GA7191@infradead.org> References: <7e.64044ca7.2f4f9f77@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e.64044ca7.2f4f9f77@aol.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4987 X-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: 737 Lines: 16 On Thu, Feb 24, 2005 at 04:21:59PM -0500, AndyLiebman@aol.com wrote: > Question. > > I just loaded up a 64-bit distribution of Linux. I compiled the kernel > optimized for AMD -- (which is what I have, dual Opterons). When I go to put XFS > on my big RAID array, I am able to create the filesystem with a 64k block > size. But then I can't mount it. > > I was under the impression that with 64-bit Linux, one could make xfs > partitions with large block sizes -- that with 64-bit Linux, there's no 4K > limitation. Am I missing something? What do I have to do to be able to mount this > RAID? You'll need support for a 64k pagesize to use a 64k blocksize. 64k page sizes are only support by ia64 and mips currently. From owner-linux-xfs Fri Feb 25 02:06:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Feb 2005 02:06:19 -0800 (PST) Received: from sainfoin.extra.cea.fr (sainfoin.extra.cea.fr [132.166.172.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1PA6GRY008393 for ; Fri, 25 Feb 2005 02:06:17 -0800 Received: from araneus.saclay.cea.fr (araneus.saclay.cea.fr [132.166.192.110]) by sainfoin.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j1PA6446017875 for ; Fri, 25 Feb 2005 11:06:04 +0100 (MET) Received: from nenuphar.saclay.cea.fr (unverified) by araneus.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 25 Feb 2005 11:06:04 +0100 Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j1PA638L029394; Fri, 25 Feb 2005 11:06:04 +0100 (MET) Message-ID: <421EF88B.1010001@ocre.cea.fr> Date: Fri, 25 Feb 2005 11:06:03 +0100 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040113 X-Accept-Language: fr, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com, Dean Roehrich Subject: Re: XFS DMAPI implementation References: <20050222162159.DCE404FDCA@chewtoy.americas.sgi.com> <421C5487.1080305@ocre.cea.fr> <20050224081124.B2527131@wobbly.melbourne.sgi.com> In-Reply-To: <20050224081124.B2527131@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/723/Thu Feb 24 03:54:24 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4989 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 1107 Lines: 29 Nathan Scott a écrit : > You can reverse apply whichever patches you don't want from > the split-patches directory at the top level to get you back > to a mainline 2.6.10 kernel with only fs/dmapi and fs/xfs > updates in it. Ok, i've seen these patches but I was not really sure about their purpose. This is, for example, what we will be a good idea to write a small webpage about this and few other things. It do not need to be really huge, but 2 or 3 explanations about the sources, the code, the patches (there are also some patches in fs/dmapi which could be better explained too) > Its all good; anything you see there has been tested and reviewed > internally before going in, so you really should be able to pick > up CVS and run with it just about any time and expect it to work. Ok. These few lines will be welcomed too. In fact, I just wanted to say that, when you try to used SGI DMAPI code, at first, there is really no documentation, and this could be avoid, writing a small document, explaining what need to be known for starting. This could really help people, amha. Aurelien From owner-linux-xfs Fri Feb 25 09:16:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Feb 2005 09:16:29 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1PHGRDa009754 for ; Fri, 25 Feb 2005 09:16:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j1PHGRMK009753 for linux-xfs@oss.sgi.com; Fri, 25 Feb 2005 09:16:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1PHGP9V009735 for ; Fri, 25 Feb 2005 09:16:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j1PGRiXo005354; Fri, 25 Feb 2005 08:27:44 -0800 Date: Fri, 25 Feb 2005 08:27:44 -0800 Message-Id: <200502251627.j1PGRiXo005354@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 397] New: In XFS file systems with Samba the creation date shows an error X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 03:28:29 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4990 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 756 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=397 Summary: In XFS file systems with Samba the creation date shows an error Product: Linux XFS Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: norman_madden@adaptec.com 1) Create a file via Samba on an XFS file system. 2) When the file is later modified via Samba, the Creation date of the file changes to the date the file was modified. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Feb 27 19:37:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Feb 2005 19:37:33 -0800 (PST) Received: from ns4.sony.co.jp (NS4.Sony.CO.JP [137.153.0.44]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1S3bVep011788 for ; Sun, 27 Feb 2005 19:37:32 -0800 Received: from mail2.sony.co.jp (mail2.sony.co.jp [43.0.1.202]) Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8/Sony) with ESMTP id j1S3bTV22346 for ; Mon, 28 Feb 2005 12:37:29 +0900 (JST) Received: from cpgsgw.sys1.cpg.sony.co.jp ([43.14.53.1]) by mail2.sony.co.jp (R8/Sony) with ESMTP id j1S3bS822339 for ; Mon, 28 Feb 2005 12:37:28 +0900 (JST) Received: from dsf38.sys1.cpg.sony.co.jp ([43.14.15.86]) by cpgsgw.sys1.cpg.sony.co.jp (8.8.8+Sun/3.6W/980617(siva)) with SMTP id MAA28437 for ; Mon, 28 Feb 2005 12:37:28 +0900 (JST) Date: Mon, 28 Feb 2005 12:37:13 +0900 From: Kenji Munakata To: linux-xfs@oss.sgi.com Subject: DMAPI & NOSPACE data corruption. Message-Id: <20050228123713.6373613c.munaken@sys1.cpg.sony.co.jp> X-Mailer: Microsoft Express Outlook Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/730/Sat Feb 26 17:56:54 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4991 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: munaken@sys1.cpg.sony.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 973 Lines: 28 Hi there, I found that data & size corrupting when the ENOSPC(with DMAPI) retrial succeeds. It seems that data offset is not reset at retry. following patches are appended. --- xfs_lrw.c.ORG 2005-02-28 11:56:18.405763312 +0900 +++ xfs_lrw.c 2005-02-28 11:57:07.543293272 +0900 @@ -862,24 +862,25 @@ if ((ret == -ENOSPC) && DM_EVENT_ENABLED(vp->v_vfsp, xip, DM_EVENT_NOSPACE) && !(ioflags & IO_INVIS)) { xfs_rwunlock(bdp, locktype); error = XFS_SEND_NAMESP(xip->i_mount, DM_EVENT_NOSPACE, vp, DM_RIGHT_NULL, vp, DM_RIGHT_NULL, NULL, NULL, 0, 0, 0); /* Delay flag intentionally unused */ if (error) goto out_unlock_isem; xfs_rwlock(bdp, locktype); pos = xip->i_d.di_size; + ret = 0; goto retry; } Regards, Kenji MUNAKATA From owner-linux-xfs Mon Feb 28 08:39:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Feb 2005 08:39:23 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SGd9Xl000676 for ; Mon, 28 Feb 2005 08:39:09 -0800 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 j1SIBiWx009554 for ; Mon, 28 Feb 2005 10:11:54 -0800 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j1SGcbR03000614; Mon, 28 Feb 2005 10:38:37 -0600 (CST) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 877AF4FDD0; Mon, 28 Feb 2005 10:38:37 -0600 (CST) To: Kenji Munakata Cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI & NOSPACE data corruption. Date: Mon, 28 Feb 2005 10:38:37 -0600 From: Dean Roehrich Message-Id: <20050228163837.877AF4FDD0@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4992 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1672 Lines: 45 >From: Kenji Munakata >Hi there, > >I found that data & size corrupting when the ENOSPC(with DMAPI) retrial succee >ds. >It seems that data offset is not reset at retry. >following patches are appended. > >--- xfs_lrw.c.ORG 2005-02-28 11:56:18.405763312 +0900 >+++ xfs_lrw.c 2005-02-28 11:57:07.543293272 +0900 >@@ -862,24 +862,25 @@ > if ((ret == -ENOSPC) && > DM_EVENT_ENABLED(vp->v_vfsp, xip, DM_EVENT_NOSPACE) && > !(ioflags & IO_INVIS)) { > > xfs_rwunlock(bdp, locktype); > error = XFS_SEND_NAMESP(xip->i_mount, DM_EVENT_NOSPACE, vp, > DM_RIGHT_NULL, vp, DM_RIGHT_NULL, NULL, NULL, > 0, 0, 0); /* Delay flag intentionally unused >*/ > if (error) > goto out_unlock_isem; > xfs_rwlock(bdp, locktype); > pos = xip->i_d.di_size; >+ ret = 0; > goto retry; > } This looks like code for the 2.6 kernel. In xfs_write I see that when we jump to 'retry', 'ret' will be used as an lvalue before it is tested again. Maybe 'pos' is not being set properly? Is di_size changing? It can, given that this thread may not hold any locks while it was in the DMAPI queues to deliver the NOSPACE event--there's nothing to prevent another thread from coming in and changing the size of the file before you can fully unwind from delivering the NOSPACE event. It looks like we sometimes hold i_sem while delivering NOSPACE. Have to fix that, too. Do you know if need_isem was set when you delivered NOSPACE? Dean From owner-linux-xfs Mon Feb 28 08:43:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Feb 2005 08:43:55 -0800 (PST) Received: from as1.cineca.com (as1.cineca.com [130.186.84.251]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1SGhovk001182 for ; Mon, 28 Feb 2005 08:43:51 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by as1.cineca.com (Postfix) with ESMTP id 4810865908 for ; Mon, 28 Feb 2005 16:43:44 +0000 (UTC) Received: from cineca.mm.cineca.it (cineca.mm.cineca.it [130.186.10.200]) by as1.cineca.com (Postfix) with ESMTP id ED32665930 for ; Mon, 28 Feb 2005 16:43:42 +0000 (UTC) Received: from dhcp7-213.cineca.it (dhcp7-213.cineca.it [130.186.7.213]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) as user f.capannini@cineca.it by cineca.mm.cineca.it (Postfix) with ESMTP id 64449391676 for ; Mon, 28 Feb 2005 17:43:40 +0100 (MET) Subject: disable ACLs on xfs From: Fabio Capannini To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1109609019.4146.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit Date: Mon, 28 Feb 2005 17:43:40 +0100 (MET) X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Scanned: Cineca AppOs 0.83 at as1.cineca.com X-Virus-Status: Clean X-archive-position: 4993 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: f.capannini@cineca.it Precedence: bulk X-list: linux-xfs Content-Length: 700 Lines: 24 Hi, I would like to know if there is any way to disable ACLs completely on an xfs filesystem. I couldn't find any mount options that permits to accomplish this and, as far as I know, xfs support for ACLs is activated by default. It turns out that some applications don't support xfs ACLs in a correct manner, so I was wondering if I could turn them off. Thanks in advance, Fabio Capannini -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fabio Capannini CINECA Inter-Universitary Computing Centre __System Management Group__ Via Magnanelli 6/3 40033 Casalecchio di Reno (Bologna) - Italy e-mail: f.capannini@cineca.it ph.: +39-051-6171411 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-linux-xfs Mon Feb 28 13:39:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Feb 2005 13:40:01 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1SLdwuH020789 for ; Mon, 28 Feb 2005 13:39:59 -0800 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 IAA14250; Tue, 1 Mar 2005 08:39:20 +1100 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 j1SLdCXE2676355; Tue, 1 Mar 2005 08:39:13 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j1SLdATW2675496; Tue, 1 Mar 2005 08:39:10 +1100 (EST) Date: Tue, 1 Mar 2005 08:39:10 +1100 From: Nathan Scott To: Fabio Capannini Cc: linux-xfs@oss.sgi.com Subject: Re: disable ACLs on xfs Message-ID: <20050301083910.T2644066@wobbly.melbourne.sgi.com> References: <1109609019.4146.24.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1109609019.4146.24.camel@localhost.localdomain>; from f.capannini@cineca.it on Mon, Feb 28, 2005 at 05:43:40PM +0100 X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4994 X-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: 650 Lines: 20 On Mon, Feb 28, 2005 at 05:43:40PM +0100, Fabio Capannini wrote: > Hi, > I would like to know if there is any way to disable ACLs completely on > an xfs filesystem. I couldn't find any mount options that permits to > accomplish this and, as far as I know, xfs support for ACLs is activated > by default. > It turns out that some applications don't support xfs ACLs in a correct > manner, so I was wondering if I could turn them off. > You can switch them off when you compile your kernel, but there isn't a mount option. You can also just not set any ACLs on files (setfacl/chacl) and they wont be used either, of course. cheers. -- Nathan From owner-linux-xfs Mon Feb 28 17:00:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Feb 2005 17:00:08 -0800 (PST) Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [137.153.0.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j211031i003205 for ; Mon, 28 Feb 2005 17:00:04 -0800 Received: from mail20.sony.co.jp (mail20.sony.co.jp [43.0.1.220]) Received: from mail20.sony.co.jp (localhost [127.0.0.1]) by mail20.sony.co.jp (R8/Sony) with ESMTP id j210xwjD028228; Tue, 1 Mar 2005 09:59:58 +0900 (JST) Received: from cpgsgw.sys1.cpg.sony.co.jp ([43.14.53.1]) by mail20.sony.co.jp (R8/Sony) with ESMTP id j210xwJd028218; Tue, 1 Mar 2005 09:59:58 +0900 (JST) Received: from dsf38.sys1.cpg.sony.co.jp ([43.14.15.86]) by cpgsgw.sys1.cpg.sony.co.jp (8.8.8+Sun/3.6W/980617(siva)) with SMTP id JAA19514; Tue, 1 Mar 2005 09:59:58 +0900 (JST) Date: Tue, 1 Mar 2005 09:59:43 +0900 From: Kenji Munakata To: Dean Roehrich Cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI & NOSPACE data corruption. Message-Id: <20050301095943.0d8b8921.munaken@sys1.cpg.sony.co.jp> In-Reply-To: <20050228163837.877AF4FDD0@chewtoy.americas.sgi.com> References: <20050228163837.877AF4FDD0@chewtoy.americas.sgi.com> X-Mailer: Microsoft Express Outlook Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4995 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: munaken@sys1.cpg.sony.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 2507 Lines: 69 Hi Dean, Yes, This code is for the 2.6. If xfs_write isn't direct IO, ret is used as last argment of generic_file_buffered_write(). This argment is data buffer offset. So, when retry happen, data pointer is shift -28(-ENOSPC) bytes. retry: /* We can write back this queue in page reclaim */ current->backing_dev_info = mapping->backing_dev_info; if ((ioflags & IO_ISDIRECT)) { .... .... } else { xfs_rw_enter_trace(XFS_WRITE_ENTER, io, (void *)iovp, segs, *offset, ioflags); ret = generic_file_buffered_write(iocb, iovp, segs, pos, offset, count, ret); <-------- this } Regards, Kenji > >From: Kenji Munakata > >Hi there, > > > >I found that data & size corrupting when the ENOSPC(with DMAPI) retrial succee > >ds. > >It seems that data offset is not reset at retry. > >following patches are appended. > > > >--- xfs_lrw.c.ORG 2005-02-28 11:56:18.405763312 +0900 > >+++ xfs_lrw.c 2005-02-28 11:57:07.543293272 +0900 > >@@ -862,24 +862,25 @@ > > if ((ret == -ENOSPC) && > > DM_EVENT_ENABLED(vp->v_vfsp, xip, DM_EVENT_NOSPACE) && > > !(ioflags & IO_INVIS)) { > > > > xfs_rwunlock(bdp, locktype); > > error = XFS_SEND_NAMESP(xip->i_mount, DM_EVENT_NOSPACE, vp, > > DM_RIGHT_NULL, vp, DM_RIGHT_NULL, NULL, NULL, > > 0, 0, 0); /* Delay flag intentionally unused > >*/ > > if (error) > > goto out_unlock_isem; > > xfs_rwlock(bdp, locktype); > > pos = xip->i_d.di_size; > >+ ret = 0; > > goto retry; > > } > > > This looks like code for the 2.6 kernel. > > In xfs_write I see that when we jump to 'retry', 'ret' will be used as an > lvalue before it is tested again. > > Maybe 'pos' is not being set properly? Is di_size changing? It can, given > that this thread may not hold any locks while it was in the DMAPI queues to > deliver the NOSPACE event--there's nothing to prevent another thread from > coming in and changing the size of the file before you can fully unwind from > delivering the NOSPACE event. > > It looks like we sometimes hold i_sem while delivering NOSPACE. Have to fix > that, too. Do you know if need_isem was set when you delivered NOSPACE? > > Dean > From owner-linux-xfs Mon Feb 28 18:01:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Feb 2005 18:01:11 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2120vXv006711 for ; Mon, 28 Feb 2005 18:00:57 -0800 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 j213Xaqp004414 for ; Mon, 28 Feb 2005 19:33:46 -0800 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j211xQR03031504; Mon, 28 Feb 2005 19:59:26 -0600 (CST) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 9C86F4FDD0; Mon, 28 Feb 2005 19:59:26 -0600 (CST) To: Kenji Munakata Cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI & NOSPACE data corruption. Date: Mon, 28 Feb 2005 19:59:26 -0600 From: Dean Roehrich Message-Id: <20050301015926.9C86F4FDD0@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4996 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 839 Lines: 27 >From: Kenji Munakata >Hi Dean, > >Yes, This code is for the 2.6. >If xfs_write isn't direct IO, ret is used as last argment of generic_file_buff >ered_write(). >This argment is data buffer offset. So, when retry happen, data pointer is shi >ft -28(-ENOSPC) bytes. > >retry: > /* We can write back this queue in page reclaim */ > current->backing_dev_info = mapping->backing_dev_info; > > if ((ioflags & IO_ISDIRECT)) { > .... > .... > } else { > xfs_rw_enter_trace(XFS_WRITE_ENTER, io, (void *)iovp, segs, > *offset, ioflags); > ret = generic_file_buffered_write(iocb, iovp, segs, > pos, offset, count, ret); <-------- this > } Thanks. I missed that one. Dean From owner-linux-xfs Mon Feb 28 18:48:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Feb 2005 18:48:29 -0800 (PST) Received: from localhost.localdomain (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j212mPnL008927 for ; Mon, 28 Feb 2005 18:48:26 -0800 Received: from localhost.localdomain (snap [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id j212k4UX004491; Tue, 1 Mar 2005 13:46:04 +1100 Received: (from fsgqa@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j212k3FU004490; Tue, 1 Mar 2005 13:46:03 +1100 Date: Tue, 1 Mar 2005 13:46:03 +1100 From: FSG QA Message-Id: <200503010246.j212k3FU004490@localhost.localdomain> To: linux-xfs@oss.sgi.com Cc: sgi.bugs.xfs@engr.sgi.com Subject: TAKE 930290 - xfs acl CAPP fix X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4997 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@localhost.localdomain Precedence: bulk X-list: linux-xfs Content-Length: 632 Lines: 19 Checked in as ptools user "tes". Date: Tue Mar 1 13:43:56 AEDT 2005 Workarea: snap.melbourne.sgi.com:/home/fsgqa/qa/xfs-linux Inspected by: nathans@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:21668a xfs_acl.c - 1.52 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h - Revokes revision 1.37 of xfs_acl.c. It caused CAPP evaluation to break as it always requires exec permission for directories when the aim was really meant for non-dir executables. See pv#930290.