From owner-linux-xfs@oss.sgi.com Sat Oct 1 02:14:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Oct 2005 02:14:35 -0700 (PDT) Received: from smtp.pzkagis.cz (gis6.netbox.cz [83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j919EVO0015725 for ; Sat, 1 Oct 2005 02:14:32 -0700 Received: (from luf@localhost) by smtp.pzkagis.cz (8.11.6/8.11.6) id j919BUZ15819; Sat, 1 Oct 2005 11:11:30 +0200 Date: Sat, 1 Oct 2005 11:11:30 +0200 From: Ludek Finstrle To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr Message-ID: <20051001091130.GA15808@soptik.pzkagis.cz> References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050929054410.GA30789@soptik.pzkagis.cz> User-Agent: Mutt/1.4i X-archive-position: 6285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luf@pzkagis.cz Precedence: bulk X-list: linux-xfs Content-Length: 4224 Lines: 161 > > Do you happen to still have the xfs_repair output in scrollback somewhere? Here is xfs_repair output. This is much better then previous run. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 correcting nblocks for inode 47925411, was 327687 - counted 8 correcting nblocks for inode 47925417, was 328911 - counted 1232 correcting nblocks for inode 47925423, was 327710 - counted 31 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 correcting nblocks for inode 172010292, was 1310948 - counted 229 - agno = 42 - agno = 43 LEAFN node level is 1 inode 180355585 bno = 8388608 - agno = 44 - agno = 45 correcting nblocks for inode 189526549, was 1441799 - counted 8 correcting nblocks for inode 189526554, was 1441799 - counted 8 correcting nblocks for inode 189526557, was 1441797 - counted 6 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 correcting nblocks for inode 213911301, was 1638411 - counted 12 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 LEAFN node level is 1 inode 180355585 bno = 8388608 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 256 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Best regards Luf From owner-linux-xfs@oss.sgi.com Sat Oct 1 12:48:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Oct 2005 12:48:11 -0700 (PDT) Received: from halifax.chebucto.ns.ca (chebucto.ns.Ca [192.75.95.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j91Jm2O0008886 for ; Sat, 1 Oct 2005 12:48:02 -0700 Received: from Dyip-172.chebucto.ns.Ca ([192.75.95.172]:42695 "EHLO cerberus.cwmannwn.nowhere" smtp-auth: TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by halifax.chebucto.ns.ca with ESMTP id S56919AbVJAToo (ORCPT ); Sat, 1 Oct 2005 16:44:44 -0300 Date: Sat, 1 Oct 2005 16:44:38 -0300 (ADT) From: "George N. White III" X-X-Sender: gwhite@cerberus.cwmannwn.nowhere Reply-To: "George N. White III" To: Aly Dharshi cc: linux-xfs@oss.sgi.com Subject: Re: grub disaster with FC4 & XFS In-Reply-To: <433D7200.9070702@telus.net> Message-ID: References: <433D68B2.4040309@moving-picture.com> <433D7200.9070702@telus.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aa056@chebucto.ns.ca Precedence: bulk X-list: linux-xfs Content-Length: 2124 Lines: 42 On Fri, 30 Sep 2005, Aly Dharshi wrote: > That would be excellent, I have asked the FC mailing list for ideas on > how to get this in the main stream anaconda without having to type linux > xfs all the time at the install boot prompt to get XFS support. > > I don't understand why they are so resistant to adding XFS and ReiserFS > support to FC and Anaconda. I would be very interested in knowing the > reason. I think someone from RH said "it doesn't add any new capabilities". While this may be true for RH's core market -- web services and transaction processing -- it certainly isn't true for some workloads. Is there an O'Reilly book (or if not, then why not) that discusses the major filesystems and their suitability for different workloads in a way that can be used to plan installations? I don't care whether Anaconda supports XFS because the sure-fire approach is better guidance to help people choose the proper filesystem and partitioning for their workload. If such guidance recommends XFS to important RH customers, Anaconda FC will get XFS so fast you will discover those feelings of shock and awe that went missing in a recent war. I think there are some expanding markets (video surveillance and certain document processing systems) that will create a demand for the capabilities of XFS. Once a big RH customer runs into problems that are best solved with XFS, you will get your wish. In a year or so, a system lots of 2.5 in SAS drives will let people do things for a tiny fraction of the cost of doing it with today's high end configurations. Some of those things will benefit from XFS. Red Hat puts a lot of effort into making sure even FC users don't have bad experiences because their market is all about admins not having bad days. XFS really isn't comfortable on the hardware configuration of this week's typical desktop PC. Making it easy for people to configure XFS may lead to a lot of people having bad experiences because they don't have the right hardware and are doing things that aren't really meant for XFS. -- George N. White III From owner-linux-xfs@oss.sgi.com Sat Oct 1 14:08:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Oct 2005 14:08:20 -0700 (PDT) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j91L8FO0013534 for ; Sat, 1 Oct 2005 14:08:16 -0700 Received: by qproxy.gmail.com with SMTP id f11so150097qba for ; Sat, 01 Oct 2005 14:05:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=e09GJj5eTU3suN19noGpCvIWxNGgYCanjRFKI5LJH4vUtMQTBmHzZTZqSfF0RMZqkPQW3BTV1SGfC+1LpaimhSyvJHRgus7q21NlLNfQILChOhLVvb73VuTHM4DO11PgCQm4mpbjbSYkePaAwTVplrL+zAaqe9WyvsE9ioO6NLA= Received: by 10.65.150.10 with SMTP id c10mr1665828qbo; Sat, 01 Oct 2005 14:05:22 -0700 (PDT) Received: from ?128.227.248.249? ( [128.227.248.249]) by mx.gmail.com with ESMTP id e14sm1150472qbe.2005.10.01.14.05.21; Sat, 01 Oct 2005 14:05:22 -0700 (PDT) Message-ID: <433EFACD.5070600@gmail.com> Date: Sat, 01 Oct 2005 17:08:29 -0400 From: Chandan Talukdar User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen , Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: Contribution to XFS on Linux References: <433C5DEE.6020306@gmail.com> <20050929230058.GD823@frodo> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: chandan.talukdar@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1796 Lines: 52 Hi, Thanks for your responses. I have one more query: My filesystem development experience has been on systems with separate buffer cache and page cache. But Linux has a unified file cache. So, any recommended reading for getting a feel of the differences in implementation would be much appreciated. Thanks, --Chandan Andi Kleen wrote: > Nathan Scott writes: > > The main problem here is that this is more a Linux VM limitation than > a XFS limitation. > > >>The first way would be to allow the PAGE_CACHE_SIZE to be increased, >>which then reduces the problem to ensuring the increased page size >>covers all interesting blocksizes (the core XFS code, & XFS on IRIX, >>allows blocksizes in powers of 2 between 512 bytes to 64 kilobytes >>currently). > > > I don't think it would be a good idea. Allocating so many pages > with order > 0 would very likely bring the VM into a nervous > breakdown. At least you would need to fix the fragmentation > in there first (there have been some approaches for this, but nothing > in mainline) > > Increasing PAGE_SIZE too would avoid that, but that would require > fixing the low level code in each architectures that maps pages from > page cache into user processes. That would be probably a good thing > (there has been long talk to have larger softpagesizes on i386/x86-64 > because it's not really efficient to manage multiple GB of memory in > 4K pieces), but is definitely major work. There have been patches for > that in the past, but they never were remotely usable and quite > complex. > > >>Last time I discussed this with Christoph (a long time back now), >>I think he favoured the first approach above. I suspect the NTFS > > > I don't see how you can make it work without major effort. > > -Andi > From owner-linux-xfs@oss.sgi.com Sat Oct 1 15:53:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Oct 2005 15:53:19 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j91MrDO0018527 for ; Sat, 1 Oct 2005 15:53:14 -0700 Received: (qmail 25870 invoked from network); 1 Oct 2005 22:50:13 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 1 Oct 2005 22:50:13 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 661AF1CE5F5; Sun, 2 Oct 2005 00:50:13 +0200 (CEST) Date: Sun, 2 Oct 2005 00:50:12 +0200 From: Adrian Bunk To: Alexander Nyberg Cc: Neil Brown , Nathan Scott , Chris Wedgwood , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: RFC: i386: kill !4KSTACKS Message-ID: <20051001225012.GE4212@stusta.de> References: <20050902003915.GI3657@stusta.de> <20050902053356.GA20603@taniwha.stupidest.org> <20050902162931.A4496772@wobbly.melbourne.sgi.com> <17175.62454.623678.209697@cse.unsw.edu.au> <20050913080552.GA1815@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050913080552.GA1815@localhost.localdomain> User-Agent: Mutt/1.5.11 X-archive-position: 6291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: linux-xfs Content-Length: 1407 Lines: 41 On Tue, Sep 13, 2005 at 10:05:52AM +0200, Alexander Nyberg wrote: > On Fri, Sep 02, 2005 at 04:40:54PM +1000 Neil Brown wrote: > > > On Friday September 2, nathans@sgi.com wrote: > > > On Thu, Sep 01, 2005 at 10:33:56PM -0700, Chris Wedgwood wrote: > > > > On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote: > > > > > > > > > 4Kb kernel stacks are the future on i386, and it seems the problems > > > > > it initially caused are now sorted out. > > > > > > > > Not entirely. > > > > > > > > XFS when mixed with raid/lvm/nfs still blows up. It's probably not > > > > alone in this respect but worse than ext2/3. > > > > > > To clarify, you mean AND not OR (/) there -- in other words, > > > raid[+raid]+dm[+dm]+xfs+nfs can be fatal, yes. > > > > It should be reasonably simple to remove this problem of stacked > > drivers. > > There really isn't any need for md and dm (or md and md or ..) to use > > the stack and the same time. > > > > Sorry to bump in so late - but there seems to be a reporter who is > suffering from these issues now: > > http://bugzilla.kernel.org/show_bug.cgi?id=5210 Nathan, can you look into this bug? TIA Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From owner-linux-xfs@oss.sgi.com Sun Oct 2 05:50:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Oct 2005 05:50:34 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j92CoQO0022471 for ; Sun, 2 Oct 2005 05:50:26 -0700 Received: from hastur.corp.sgi.com (hastur.corp.sgi.com [198.149.32.33]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j92ClWxT011513 for ; Sun, 2 Oct 2005 07:47:33 -0500 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by hastur.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j92Cl5eS198636851 for ; Sun, 2 Oct 2005 05:47:05 -0700 (PDT) X-ASG-Debug-ID: 1128257251-16128-22-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by cuda.sgi.com (Spam Firewall) with ESMTP id 20C49D102DB3 for ; Sun, 2 Oct 2005 05:47:32 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j92ClTBa013880; Sun, 2 Oct 2005 07:47:30 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j92ClR1H013873; Sun, 2 Oct 2005 07:47:27 -0500 Date: Sun, 2 Oct 2005 07:47:27 -0500 From: Christoph Hellwig Message-Id: <200510021247.j92ClR1H013873@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com X-ASG-Orig-Subj: PARTIAL TAKE 943556 - Fix sparse warnings in ktrace.[ch] Subject: PARTIAL TAKE 943556 - Fix sparse warnings in ktrace.[ch] X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.4256 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 6294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 709 Lines: 17 Date: Sun Oct 2 05:47:06 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.4.x Inspected by: felixb,nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:200113a fs/xfs/support/ktrace.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/ktrace.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h fs/xfs/support/ktrace.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/ktrace.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h fs/xfs/linux-2.4/xfs_linux.h - 1.147 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.147&r2=text&tr2=1.146&f=h From owner-linux-xfs@oss.sgi.com Sun Oct 2 13:39:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Oct 2005 13:39:13 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j92Kd5O0029476 for ; Sun, 2 Oct 2005 13:39:06 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA03853; Mon, 3 Oct 2005 06:36:00 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j92Ka6kt5395884; Mon, 3 Oct 2005 06:36:07 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j92KZwJH5373295; Mon, 3 Oct 2005 06:35:58 +1000 (EST) Date: Mon, 3 Oct 2005 06:35:58 +1000 From: Nathan Scott To: Adrian Bunk Cc: Alexander Nyberg , Neil Brown , Chris Wedgwood , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: RFC: i386: kill !4KSTACKS Message-ID: <20051003063558.A5400701@wobbly.melbourne.sgi.com> References: <20050902003915.GI3657@stusta.de> <20050902053356.GA20603@taniwha.stupidest.org> <20050902162931.A4496772@wobbly.melbourne.sgi.com> <17175.62454.623678.209697@cse.unsw.edu.au> <20050913080552.GA1815@localhost.localdomain> <20051001225012.GE4212@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051001225012.GE4212@stusta.de>; from bunk@stusta.de on Sun, Oct 02, 2005 at 12:50:12AM +0200 X-archive-position: 6297 X-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: 557 Lines: 19 On Sun, Oct 02, 2005 at 12:50:12AM +0200, Adrian Bunk wrote: > On Tue, Sep 13, 2005 at 10:05:52AM +0200, Alexander Nyberg wrote: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=5210 > > Nathan, can you look into this bug? > OK - looks like a scheduling-while-atomic warning on a metdata buffer read, then a panic (sometime later?) at do_page_fault with no useful stack trace (removed by bug reporter? - thats the one you need...). The first stack trace (atomic/shedule) would not be >4K afaict, so thats a red herring I think. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Oct 3 04:31:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Oct 2005 04:31:15 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j93BV8O0031769 for ; Mon, 3 Oct 2005 04:31:09 -0700 Received: from minion.mpc.local ([172.16.11.112] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.43) id 1EMOUP-0006W2-E5; Mon, 03 Oct 2005 12:28:13 +0100 Message-ID: <434115CD.5060402@moving-picture.com> Date: Mon, 03 Oct 2005 12:28:13 +0100 From: James Pearson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Aly Dharshi Subject: Re: grub disaster with FC4 & XFS References: <433D68B2.4040309@moving-picture.com> <433D7200.9070702@telus.net> In-Reply-To: <433D7200.9070702@telus.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 6300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs Content-Length: 1025 Lines: 24 Aly Dharshi wrote: > That would be excellent, I have asked the FC mailing list for ideas on > how to get this in the main stream anaconda without having to type linux > xfs all the time at the install boot prompt to get XFS support. This is a different (but related) issue to the grub problem - RedHat don't support XFS, so they don't provide it as an available file system in the installer by default - but at least anaconda will support XFS - if, as you say, you use 'xfs' on the install boot command line - which is better than no support at all for XFS ... You can also hack the anaconda scripts to make XFS as an available file system, but it's probably quicker for most people to add 'xfs' on the boot command line. > I don't understand why they are so resistant to adding XFS and ReiserFS > support to FC and Anaconda. I would be very interested in knowing the > reason. You will need to search the archives of this list for pointers as to reasons why RedHat may or may not support XFS. James Pearson From owner-linux-xfs@oss.sgi.com Mon Oct 3 11:15:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Oct 2005 11:15:57 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j93IFqO0002053 for ; Mon, 3 Oct 2005 11:15:52 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j93ICwxT024759 for ; Mon, 3 Oct 2005 13:12:58 -0500 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j93ICtDN16938496; Mon, 3 Oct 2005 13:12:56 -0500 (CDT) Message-ID: <434174A7.6010904@sgi.com> Date: Mon, 03 Oct 2005 13:12:55 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludek Finstrle CC: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> In-Reply-To: <20051001091130.GA15808@soptik.pzkagis.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 342 Lines: 15 Ludek Finstrle wrote: >>>Do you happen to still have the xfs_repair output in scrollback somewhere? > > > Here is xfs_repair output. This is much better then previous run. Could you also please send xfs_info output for the filesystem, to see the fs geometry? And just out of curiosity, what sort of storage is this on? Thanks, -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 3 12:46:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Oct 2005 12:47:00 -0700 (PDT) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.196]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j93JktO0013277 for ; Mon, 3 Oct 2005 12:46:55 -0700 Received: by nproxy.gmail.com with SMTP id n15so172349nfc for ; Mon, 03 Oct 2005 12:44:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=ShKdWSvY1Xr0LT3vSu9QkxvDxIJB5OQQwJnxgnLmxpMspgEEKnRx+Id8SNLn5+Tnyh5v1kfhd1GmQaTKu3/Tdy5OhY/bIC1RUECrXJbMUht71mcSRlFLuCQcS3a8WfIjSrxldNBf1jW1bnWnIfIjnSmXxyw12XBiAuPSN5SoquQ= Received: by 10.48.235.3 with SMTP id i3mr61908nfh; Mon, 03 Oct 2005 12:44:00 -0700 (PDT) Received: by 10.48.255.17 with HTTP; Mon, 3 Oct 2005 12:44:00 -0700 (PDT) Message-ID: <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com> Date: Mon, 3 Oct 2005 21:44:00 +0200 From: Mathieu Betrancourt Reply-To: Mathieu Betrancourt To: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr In-Reply-To: <434174A7.6010904@sgi.com> MIME-Version: 1.0 References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> <434174A7.6010904@sgi.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbetrancourt@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1397 Lines: 49 hi, I have the same problem on a xfs on a raid 1 device (mdraid), wich is almost full (97%) and not on other non raid devices (and unfortunately not almost full). This problem appeared under Fedora3 and Suse9.3 Here's the output of xfs_info for the problematic one : > xfs_info /dev/md0 meta-data=/data isize=256 agcount=16, agsize=10051648 blks = sectsz=512 data = bsize=512 blocks=160826368, imaxpct=25 = sunit=64 swidth=128 blks, unwritten=1 naming =version 2 bsize=512 log =internal bsize=512 blocks=65536, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 And the others : > xfs_info /dev/hda3 meta-data=/ isize=256 agcount=16, agsize=7484281 blks = sectsz=512 data = bsize=512 blocks=119748496, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=512 blocks=58470, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 > xfs_info /dev/hdd1 meta-data=/unimportant_data isize=256 agcount=16, agsize=4889780 blks = sectsz=512 data = bsize=512 blocks=78236480, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=512 blocks=38201, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 I've also tried with 4k blocks and it was the same. Hope this helps, Mathieu [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Oct 3 17:52:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Oct 2005 17:52:22 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j940qEO0007564 for ; Mon, 3 Oct 2005 17:52:15 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06497; Tue, 4 Oct 2005 10:49:15 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j940mv8q12006858; Tue, 4 Oct 2005 10:48:57 +1000 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j940mp3311899038; Tue, 4 Oct 2005 10:48:51 +1000 (EST) Date: Tue, 4 Oct 2005 10:48:51 +1000 From: David Chinner To: Chandan Talukdar Cc: Andi Kleen , Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: Contribution to XFS on Linux Message-ID: <20051004004851.GH9519161@melbourne.sgi.com> References: <433C5DEE.6020306@gmail.com> <20050929230058.GD823@frodo> <433EFACD.5070600@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433EFACD.5070600@gmail.com> User-Agent: Mutt/1.4.1i X-archive-position: 6305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2734 Lines: 66 On Sat, Oct 01, 2005 at 05:08:29PM -0400, Chandan Talukdar wrote: > Hi, > > Thanks for your responses. I have one more query: > > My filesystem development experience has been on systems with separate > buffer cache and page cache. And that makes solving this problem a _lot_ easier if the buffer cache supports scatter-gather multi-page constructs that you can map and unmap into kernel vm space. That way the filesystem simply needs to map buffers of filesystem block size and alignment, and the buffer cache does the rest... > But Linux has a unified file cache. And that is the real issue here - there is no greater-than-page-size construct for the filesystems to use when needing to do atomic I/O operations on more than one page at a time. > So, any > recommended reading for getting a feel of the differences in > implementation would be much appreciated. In a different life, XFS relies on a chunk cache that sits above the page cache to provide atomicity and coherency on operations that span multiple pages. The chunk cache contains only the currently active subset of the entire page cache, but the abstraction makes the filesystem block size independent of the system page size. That's the really hard bit about this - guaranteeing atomicity of access across the multiple pages in a filesystem block. There needs to be some way of enforcing this at all levels of operation (read, write, reclaim, etc), and when you have a buffer cache this is typically done simply by locking the buffer. Without a buffer cache and no other method of atomically aggregating pages together and operating on that aggregation, you have to lock each page individually before you can do any operation on the filesystem block. This is deadlock prone and very difficult to prove correct. However, I really don't think that reintroducing a buffer cache like construct for atomic aggregation is the way to go here because it makes many smart things harder to do (e.g. window based readahead) or involve substantially more overhead due to buffer setup and teardown. Perhaps doing something like making the fundamental unit of caching a pagevec rather than a page (i.e. page size independent) would be more appropriate way to abstract this. This would be deeply invasive, though, and as Andi Kleen wrote: >I don't see how you can make it work without major effort. It's a major effort ;) FWIW, one aspect of this multipage caching mechanism still exists in linux XFS - the pagebuf - which is needed because metadata buffers can be larger than a single page and XFS needs to guarantee both transactional and I/O atomicity for metadata buffers..... Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Mon Oct 3 19:26:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Oct 2005 19:26:49 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j942QiO0015773 for ; Mon, 3 Oct 2005 19:26:44 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j943RuKk017903 for ; Mon, 3 Oct 2005 20:27:56 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j942MnsS89087522; Mon, 3 Oct 2005 19:22:49 -0700 (PDT) Message-ID: <4341E780.70803@sgi.com> Date: Mon, 03 Oct 2005 21:22:56 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mathieu Betrancourt CC: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> <434174A7.6010904@sgi.com> <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com> In-Reply-To: <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 667 Lines: 24 Mathieu Betrancourt wrote: > hi, > > I have the same problem on a xfs on a raid 1 device (mdraid), wich is almost > full (97%) > and not on other non raid devices (and unfortunately not almost full). > > This problem appeared under Fedora3 and Suse9.3 > > Here's the output of xfs_info for the problematic one : Thanks, good (I guess!) to know that it's reproducible... so far we have not been able to reproduce it in-house. Mathieu, are you also using acls and/or extended attributes? It would also be interesting to see the xfs_repair output, and xfs_bmap (-v and -a) output of the problematic files prior to running xfs_fsr, if possible. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Tue Oct 4 04:00:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 04:00:31 -0700 (PDT) Received: from hotmail.com (bay110-f27.bay110.hotmail.com [65.54.229.37]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94B0NO0026177 for ; Tue, 4 Oct 2005 04:00:23 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Oct 2005 03:57:28 -0700 Message-ID: Received: from 65.54.229.220 by by110fd.bay110.hotmail.msn.com with HTTP; Tue, 04 Oct 2005 10:57:28 GMT X-Originating-IP: [134.138.128.34] X-Originating-Email: [dmarkic@hotmail.com] X-Sender: dmarkic@hotmail.com From: "Dubravko Markic" To: linux-xfs@oss.sgi.com Subject: The XFS real-time subvolume in Linux Date: Tue, 04 Oct 2005 12:57:28 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 Oct 2005 10:57:28.0852 (UTC) FILETIME=[697E9D40:01C5C8D2] X-archive-position: 6309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dmarkic@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 650 Lines: 16 Hello, My name is Dubravko Markic and i am working with the XFS filesystem as part of my project. I am using a Linux operating system, or better yet, a SuSe CORE 9 system. I have installed XFS filesystem on one of the partitions on my computer. My XFS filesystem has a default configuration, which means that no real-time subvolume is enabled. My question to you is: what do i do in order to enable real-time subvolume on my XFS filesystem? Also if i understood correctly under Linux one does not have the GRIO (guranteed rate I/O) option, this is only available under the IRIX operating system, right? Thanks a bunch Regards, Dubo From owner-linux-xfs@oss.sgi.com Tue Oct 4 08:02:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 08:02:33 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94F2QO0029068 for ; Tue, 4 Oct 2005 08:02:27 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j94G3gLp032703 for ; Tue, 4 Oct 2005 09:03:42 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j94ExVDN17001813; Tue, 4 Oct 2005 09:59:31 -0500 (CDT) Message-ID: <434298D3.4060501@sgi.com> Date: Tue, 04 Oct 2005 09:59:31 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dubravko Markic CC: linux-xfs@oss.sgi.com Subject: Re: The XFS real-time subvolume in Linux References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1255 Lines: 32 Dubravko Markic wrote: > Hello, > My name is Dubravko Markic and i am working with the XFS > filesystem as part of my project. I am using a Linux operating system, > or better yet, a SuSe CORE 9 system. I have installed XFS filesystem on > one of the partitions on my computer. My XFS filesystem has a default > configuration, which means that no real-time subvolume is enabled. > > My question to you is: what do i do in order to enable real-time > subvolume on my XFS filesystem? If it is truly not enabled on your SuSE, then you will need to rebuild xfs after changing CONFIG_XFS_RT. But: penguin3:~ # zcat /proc/config.gz | grep XFS_RT CONFIG_XFS_RT=y penguin3:~ # uname -a Linux penguin3 2.6.5-7.193-debug #1 SMP Wed Jul 20 14:39:18 UTC 2005 i686 i686 i386 GNU/Linux This is a SLES9SP2 box, but it appears that recent SuSE kernels are RT-enabled. > Also if i understood correctly under > Linux one does not have the GRIO (guranteed rate I/O) option, this is > only available under the IRIX operating system, right? Thanks a bunch That is basically true, yes. There is a non-free GRIOV2 product in use with CXFS, but for your purposes, I think it is safe to say that there is no standalone GRIO equivalent on Linux. -Eric From owner-linux-xfs@oss.sgi.com Tue Oct 4 08:21:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 08:21:44 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94FLbO0003149 for ; Tue, 4 Oct 2005 08:21:38 -0700 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 7DBE41C046; Tue, 4 Oct 2005 17:18:42 +0200 (CEST) To: Eric Sandeen Cc: linux-xfs@oss.sgi.com, dmarkic@hotmail.com Subject: Re: The XFS real-time subvolume in Linux References: <434298D3.4060501@sgi.com> From: Andi Kleen Date: 04 Oct 2005 17:18:41 +0200 In-Reply-To: <434298D3.4060501@sgi.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 6312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 495 Lines: 15 Eric Sandeen writes: > > That is basically true, yes. There is a non-free GRIOV2 product in > use with CXFS, but for your purposes, I think it is safe to say that > there is no standalone GRIO equivalent on Linux. It's not. In fact it's a standard feature now. The CFQ2 IO scheduler has IO priorities settable with ionice, including a RT class with 8 priorities. It's not available in SLES9 though, only in newer kernels (2.6.13+) and SUSE releases (like SL10.0) -Andi From owner-linux-xfs@oss.sgi.com Tue Oct 4 08:42:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 08:42:48 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94FggO0005612 for ; Tue, 4 Oct 2005 08:42:42 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j94FdlxT002758 for ; Tue, 4 Oct 2005 10:39:47 -0500 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j94FdksL22865481; Tue, 4 Oct 2005 10:39:46 -0500 (CDT) Message-ID: <4342A242.90102@sgi.com> Date: Tue, 04 Oct 2005 10:39:46 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: linux-xfs@oss.sgi.com, dmarkic@hotmail.com Subject: Re: The XFS real-time subvolume in Linux References: <434298D3.4060501@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1069 Lines: 33 Andi Kleen wrote: > Eric Sandeen writes: > >>That is basically true, yes. There is a non-free GRIOV2 product in >>use with CXFS, but for your purposes, I think it is safe to say that >>there is no standalone GRIO equivalent on Linux. > > > It's not. In fact it's a standard feature now. Well, I stand corrected then :) > The CFQ2 IO scheduler has IO priorities settable with ionice, including > a RT class with 8 priorities. Well, that still sounds a bit different from the original irix GRIO implemenation, FWIW. grio - guaranteed-rate I/O DESCRIPTION Guaranteed-rate I/O (GRIO) refers to a guarantee made by the system to a user process indicating that the given process will receive data from a system resource at a predefined rate regardless of any other activity on the system. While 2.6 can set priorities on IO, it does not offer a hard guaranteed IO rate, does it? Now, I'm not necessarily saying one scheme is necessarily better or worse than the other, but they are different, I think. -Eric From owner-linux-xfs@oss.sgi.com Tue Oct 4 08:44:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 08:44:35 -0700 (PDT) Received: from MAIL01HQ.adic.com (webmail.adic.com [63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94FiVO0006089 for ; Tue, 4 Oct 2005 08:44:32 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 08:41:33 -0700 Message-ID: <4342A2AB.4040700@xfs.org> Date: Tue, 04 Oct 2005 10:41:31 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: Eric Sandeen , linux-xfs@oss.sgi.com, dmarkic@hotmail.com Subject: Re: The XFS real-time subvolume in Linux References: <434298D3.4060501@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2005 15:41:33.0134 (UTC) FILETIME=[18ADA6E0:01C5C8FA] X-archive-position: 6314 X-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: 706 Lines: 25 Andi Kleen wrote: > Eric Sandeen writes: > >>That is basically true, yes. There is a non-free GRIOV2 product in >>use with CXFS, but for your purposes, I think it is safe to say that >>there is no standalone GRIO equivalent on Linux. > > > It's not. In fact it's a standard feature now. > > The CFQ2 IO scheduler has IO priorities settable with ionice, including > a RT class with 8 priorities. > > It's not available in SLES9 though, only in newer kernels (2.6.13+) > and SUSE releases (like SL10.0) > > -Andi > Ah, but is there a bandwidth reservation system to go with it? That is the missing link here, being able to say 'I need 10 Mbytes/sec until further notice'. Steve From owner-linux-xfs@oss.sgi.com Tue Oct 4 09:02:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 09:02:13 -0700 (PDT) Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94G28O0008508 for ; Tue, 4 Oct 2005 09:02:09 -0700 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 01F46E8CB; Tue, 4 Oct 2005 17:59:13 +0200 (CEST) From: Andi Kleen To: Steve Lord Subject: Re: The XFS real-time subvolume in Linux Date: Tue, 4 Oct 2005 17:59:14 +0200 User-Agent: KMail/1.8.2 Cc: Eric Sandeen , linux-xfs@oss.sgi.com, axboe@suse.de References: <4342A2AB.4040700@xfs.org> In-Reply-To: <4342A2AB.4040700@xfs.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510041759.15075.ak@suse.de> X-archive-position: 6315 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1489 Lines: 39 On Tuesday 04 October 2005 17:41, Steve Lord wrote: > Andi Kleen wrote: > > Eric Sandeen writes: > >>That is basically true, yes. There is a non-free GRIOV2 product in > >>use with CXFS, but for your purposes, I think it is safe to say that > >>there is no standalone GRIO equivalent on Linux. > > > > It's not. In fact it's a standard feature now. > > > > The CFQ2 IO scheduler has IO priorities settable with ionice, including > > a RT class with 8 priorities. > > > > It's not available in SLES9 though, only in newer kernels (2.6.13+) > > and SUSE releases (like SL10.0) > > > > -Andi > > Ah, but is there a bandwidth reservation system to go with it? That is > the missing link here, being able to say 'I need 10 Mbytes/sec until > further notice'. Indirectly there is. The RT priority defines how many time slots you get and the length of the timeslots are configurable using sysfs. If you know the bandwidth of the disk you can use that to define an approximation of the guaranteed bandwidth for a specific RT priority. On the other hand I don't really see how you can get real bandwidths. e.g. on most disks the bandwidth varies greatly depending on where the blocks are allocated and how much seeking it does. If you take that all in account you'll probably get a pretty slow worst case as baseline to divide. There is nothing that actually gives out bandwidths, but you could do that in user space. Jens may correct me if I'm wrong on anything. -Andi From owner-linux-xfs@oss.sgi.com Tue Oct 4 09:19:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 09:19:24 -0700 (PDT) Received: from MAIL01HQ.adic.com (mail01hq.adic.com [63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94GJJO0011147 for ; Tue, 4 Oct 2005 09:19:19 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 09:16:24 -0700 Message-ID: <4342AAD3.8060102@xfs.org> Date: Tue, 04 Oct 2005 11:16:19 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: Eric Sandeen , linux-xfs@oss.sgi.com, axboe@suse.de Subject: Re: The XFS real-time subvolume in Linux References: <4342A2AB.4040700@xfs.org> <200510041759.15075.ak@suse.de> In-Reply-To: <200510041759.15075.ak@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2005 16:16:24.0728 (UTC) FILETIME=[F75D9180:01C5C8FE] X-archive-position: 6316 X-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: 2080 Lines: 57 Andi Kleen wrote: > On Tuesday 04 October 2005 17:41, Steve Lord wrote: > >>Andi Kleen wrote: >> >>>Eric Sandeen writes: >>> >>>>That is basically true, yes. There is a non-free GRIOV2 product in >>>>use with CXFS, but for your purposes, I think it is safe to say that >>>>there is no standalone GRIO equivalent on Linux. >>> >>>It's not. In fact it's a standard feature now. >>> >>>The CFQ2 IO scheduler has IO priorities settable with ionice, including >>>a RT class with 8 priorities. >>> >>>It's not available in SLES9 though, only in newer kernels (2.6.13+) >>>and SUSE releases (like SL10.0) >>> >>>-Andi >> >>Ah, but is there a bandwidth reservation system to go with it? That is >>the missing link here, being able to say 'I need 10 Mbytes/sec until >>further notice'. > > > Indirectly there is. The RT priority defines how many time slots you > get and the length of the timeslots are configurable using sysfs. If you know > the bandwidth of the disk you can use that to define an approximation > of the guaranteed bandwidth for a specific RT priority. > > On the other hand I don't really see how you can get real bandwidths. > e.g. on most disks the bandwidth varies greatly depending on where > the blocks are allocated and how much seeking it does. If you take > that all in account you'll probably get a pretty slow worst case > as baseline to divide. If you get into this stuff seriously you have to dedicate hardware all the way from the cpu to the disks, make worst case estimates of how fast your disks will go. Multiply all this out and say that to record n streams of HD video without dropping a frame you need this much hardware. It is a bit of a black magic art, and not something you just go out and buy a PC to do. It tends to waste a lot of the potential bandwidth of the hardware, but you try explaining to CNN why their satellite feed just went black ;-) Steve > > There is nothing that actually gives out bandwidths, but you could > do that in user space. > > Jens may correct me if I'm wrong on anything. > > -Andi > From owner-linux-xfs@oss.sgi.com Tue Oct 4 12:07:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 12:07:09 -0700 (PDT) Received: from smtp.pzkagis.cz (gis6.netbox.cz [83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94J6vO0002867 for ; Tue, 4 Oct 2005 12:07:00 -0700 Received: (from luf@localhost) by smtp.pzkagis.cz (8.11.6/8.11.6) id j94J3cr15376; Tue, 4 Oct 2005 21:03:38 +0200 Date: Tue, 4 Oct 2005 21:03:38 +0200 From: Ludek Finstrle To: Eric Sandeen Cc: Mathieu Betrancourt , linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr Message-ID: <20051004190338.GA15263@soptik.pzkagis.cz> References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> <434174A7.6010904@sgi.com> <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com> <4341E780.70803@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4341E780.70803@sgi.com> User-Agent: Mutt/1.4i X-archive-position: 6317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ludek.finstrle@pzkagis.cz Precedence: bulk X-list: linux-xfs Content-Length: 1436 Lines: 41 > >I have the same problem on a xfs on a raid 1 device (mdraid), wich is > >almost > >full (97%) > >and not on other non raid devices (and unfortunately not almost full). I have raid 1 over raid 0 (it's together raid 10). It's 55% full now. But it was 99% full few months ago. And there were errors in dmesg log. Unfortunetly I don't have them :-( /dev/md9 56G 31G 25G 55% /export > >This problem appeared under Fedora3 and Suse9.3 I have this problem under RedHat 7.2. > >Here's the output of xfs_info for the problematic one : Here is my xfs_info: # xfs_info /dev/md9 meta-data=/ isize=256 agcount=8, agsize=163856 blks = sectsz=512 data = bsize=4096 blocks=1310752, imaxpct=25 = sunit=16 swidth=32 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=131072 blocks=0, rtextents=0 > It would also be interesting to see the xfs_repair output, and xfs_bmap > (-v and -a) output of the problematic files prior to running xfs_fsr, if > possible. I don't know which files will be problematic after xfs_fsr. I'm sorry, I don't have enough time till Friday. Then I'll try to play with the problem. Thanks Luf From owner-linux-xfs@oss.sgi.com Tue Oct 4 12:40:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 12:40:27 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94JeLO0010940 for ; Tue, 4 Oct 2005 12:40:22 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j94JbRxT012713 for ; Tue, 4 Oct 2005 14:37:27 -0500 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j94JbQDN17016958; Tue, 4 Oct 2005 14:37:26 -0500 (CDT) Message-ID: <4342D9F6.8090605@sgi.com> Date: Tue, 04 Oct 2005 14:37:26 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludek Finstrle CC: Mathieu Betrancourt , linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> <434174A7.6010904@sgi.com> <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com> <4341E780.70803@sgi.com> <20051004190338.GA15263@soptik.pzkagis.cz> In-Reply-To: <20051004190338.GA15263@soptik.pzkagis.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1134 Lines: 33 Ludek Finstrle wrote: >>>Here's the output of xfs_info for the problematic one : > > > Here is my xfs_info: > # xfs_info /dev/md9 > meta-data=/ isize=256 agcount=8, agsize=163856 blks > = sectsz=512 > data = bsize=4096 blocks=1310752, imaxpct=25 > = sunit=16 swidth=32 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=1200, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=131072 blocks=0, rtextents=0 Ok, nothing odd about isize, sectsize, bsize.... thanks. >>It would also be interesting to see the xfs_repair output, and xfs_bmap >>(-v and -a) output of the problematic files prior to running xfs_fsr, if >>possible. > > I don't know which files will be problematic after xfs_fsr. Ah, I suppose not :) > I'm sorry, I don't have enough time till Friday. Then I'll try to play > with the problem. Thanks, I appreciate it... we're trying to reproduce it here. -Eric From owner-linux-xfs@oss.sgi.com Tue Oct 4 13:02:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 13:02:58 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94K2rO0013765 for ; Tue, 4 Oct 2005 13:02:53 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j94L48aw023809 for ; Tue, 4 Oct 2005 14:04:08 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j94JxtsL22879575; Tue, 4 Oct 2005 14:59:55 -0500 (CDT) Message-ID: <4342DF3B.1050500@sgi.com> Date: Tue, 04 Oct 2005 14:59:55 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludek Finstrle CC: Mathieu Betrancourt , linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> <434174A7.6010904@sgi.com> <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com> <4341E780.70803@sgi.com> <20051004190338.GA15263@soptik.pzkagis.cz> In-Reply-To: <20051004190338.GA15263@soptik.pzkagis.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 613 Lines: 18 Ludek Finstrle wrote: > I don't know which files will be problematic after xfs_fsr. > > I'm sorry, I don't have enough time till Friday. Then I'll try to play > with the problem. one other thing that might be interesting. If you guys don't mind collecting a bit more information, you could run xfs_repair (with or without -n; -n is probably fine - save the output) before you run xfs_fsr, to see if the filesystem has problems prior to running fsr. In that case, xfs_fsr may be the victim here... running repair requires taking the fs offline though, so perhaps that's not an easy option. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Tue Oct 4 17:17:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Oct 2005 17:17:41 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j950HYO0007492 for ; Tue, 4 Oct 2005 17:17:35 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA03825; Wed, 5 Oct 2005 10:14:33 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 8FBB449E5EEF; Wed, 5 Oct 2005 10:14:32 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 943123 - dquot hash Message-Id: <20051005001432.8FBB449E5EEF@chook.melbourne.sgi.com> Date: Wed, 5 Oct 2005 10:14:32 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6320 X-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: 887 Lines: 20 Rework the dquot hash sizing heuristics. Date: Wed Oct 5 10:14:13 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24012a quota/xfs_qm.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h quota/xfs_qm.c - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h linux-2.6/xfs_linux.h - 1.135 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h linux-2.4/xfs_linux.h - 1.148 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.148&r2=text&tr2=1.147&f=h From owner-linux-xfs@oss.sgi.com Wed Oct 5 01:43:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 01:43:46 -0700 (PDT) Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j958haO0024602 for ; Wed, 5 Oct 2005 01:43:37 -0700 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1EN4pN-0001CP-00; Wed, 05 Oct 2005 10:40:41 +0200 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.22) id 1EN4pL-0003Dn-5l; Wed, 05 Oct 2005 10:40:39 +0200 Received: by kernel.dk (Postfix, from userid 1000) id 665D43ADCD; Wed, 5 Oct 2005 10:41:18 +0200 (CEST) Date: Wed, 5 Oct 2005 10:41:18 +0200 From: Jens Axboe To: Steve Lord Cc: Andi Kleen , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: The XFS real-time subvolume in Linux Message-ID: <20051005084117.GF3511@suse.de> References: <4342A2AB.4040700@xfs.org> <200510041759.15075.ak@suse.de> <4342AAD3.8060102@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4342AAD3.8060102@xfs.org> X-archive-position: 6322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 2514 Lines: 58 On Tue, Oct 04 2005, Steve Lord wrote: > Andi Kleen wrote: > >On Tuesday 04 October 2005 17:41, Steve Lord wrote: > > > >>Andi Kleen wrote: > >> > >>>Eric Sandeen writes: > >>> > >>>>That is basically true, yes. There is a non-free GRIOV2 product in > >>>>use with CXFS, but for your purposes, I think it is safe to say that > >>>>there is no standalone GRIO equivalent on Linux. > >>> > >>>It's not. In fact it's a standard feature now. > >>> > >>>The CFQ2 IO scheduler has IO priorities settable with ionice, including > >>>a RT class with 8 priorities. > >>> > >>>It's not available in SLES9 though, only in newer kernels (2.6.13+) > >>>and SUSE releases (like SL10.0) > >>> > >>>-Andi > >> > >>Ah, but is there a bandwidth reservation system to go with it? That is > >>the missing link here, being able to say 'I need 10 Mbytes/sec until > >>further notice'. > > > > > >Indirectly there is. The RT priority defines how many time slots you > >get and the length of the timeslots are configurable using sysfs. If you > >know the bandwidth of the disk you can use that to define an approximation > >of the guaranteed bandwidth for a specific RT priority. > > > >On the other hand I don't really see how you can get real bandwidths. > >e.g. on most disks the bandwidth varies greatly depending on where > >the blocks are allocated and how much seeking it does. If you take > >that all in account you'll probably get a pretty slow worst case > >as baseline to divide. > > If you get into this stuff seriously you have to dedicate hardware > all the way from the cpu to the disks, make worst case estimates of how > fast your disks will go. Multiply all this out and say that to record n > streams of HD video without dropping a frame you need this much hardware. > It is a bit of a black magic art, and not something you just go out and > buy a PC to do. It tends to waste a lot of the potential bandwidth of > the hardware, but you try explaining to CNN why their satellite feed just > went black ;-) That's exactly why the Linux ioprio stuff has been designed the way it is right now - it's not overengineered for something we cannot support anyways. The CFQ io priorities will work well enough for general use, if you are basing your business on GRIO it's a different game completely. I don't want to add kernel infrastructure for something that is very specialized, especially because the code to do so would be 10 times bigger and more complex that the current stuff.. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Oct 5 04:40:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 04:40:54 -0700 (PDT) Received: from asteria.debian.or.at (asteria.debian.or.at [86.59.5.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95BeiO0022374 for ; Wed, 5 Oct 2005 04:40:44 -0700 Received: by asteria.debian.or.at (Postfix, from userid 1002) id 465B470CD05; Wed, 5 Oct 2005 13:37:46 +0200 (CEST) Date: Wed, 5 Oct 2005 13:37:46 +0200 From: Peter Palfrader To: linux-xfs@oss.sgi.com Subject: Re: Kernel Oopses on 2.6.13 Message-ID: <20051005113746.GE22241@asteria.noreply.org> Mail-Followup-To: Peter Palfrader , linux-xfs@oss.sgi.com References: <20050907143048.GA11805@opium.palfrader.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20050907143048.GA11805@opium.palfrader.org> X-PGP: 1024D/94C09C7F 5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F X-Request-PGP: http://www.palfrader.org/keys/94C09C7F.asc X-Accept-Language: de, en User-Agent: Mutt/1.5.9i X-archive-position: 6323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: peter@palfrader.org Precedence: bulk X-list: linux-xfs Content-Length: 7523 Lines: 99 On Wed, 07 Sep 2005, Peter Palfrader wrote: > I'm running a pristine 2.6.13 and got an Oops. After rebooting when > mounting the filesystem to replay the log (as suggested by xfs_check) I > got another one. > [] xfs_btree_check_sblock+0x77/0xe0 > [] xfs_alloc_lookup+0x143/0x440 > [] xfs_alloc_delete+0x1b/0x80 > [] xfs_free_ag_extent+0x142/0x680 > [] xfs_free_extent+0xc6/0xf0 > [] kmem_zone_zalloc+0x22/0x50 > [] xfs_trans_get_efd+0x22/0x30 > [] xfs_bmap_finish+0x102/0x180 > [] xfs_remove+0x29c/0x440 > [] linvfs_permission+0x1b/0x30 > [] linvfs_unlink+0x1b/0x40 > [] vfs_unlink+0x12d/0x1a0 > [] sys_unlink+0x99/0x110 > [] syscall_call+0x7/0xb Tried it again with 2.6.13.2 and got a similar Oops: Oct 5 01:01:29 nikki kernel: [17209340.020000] Unable to handle kernel NULL pointer dereference at virtual address 00000086 Oct 5 01:01:29 nikki kernel: [17209340.032000] printing eip: Oct 5 01:01:29 nikki kernel: [17209340.036000] c021be3e Oct 5 01:01:29 nikki kernel: [17209340.036000] *pde = 00000000 Oct 5 01:01:29 nikki kernel: [17209340.040000] Oops: 0002 [#1] Oct 5 01:01:29 nikki kernel: [17209340.040000] SMP Oct 5 01:01:29 nikki kernel: [17209340.040000] Modules linked in: autofs4 analog parport_pc parport evdev floppy pcspkr snd_via82xx gameport snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_mpu401_uart +snd_rawmidi snd_seq_device snd soundcore i2c_viapro i2c_core ehci_hcd uhci_hcd usbcore ipt_REDIRECT ip6table_mangle ip6table_filter ip6_tables ipv6 iptable_mangle iptable_nat ip_conntrack iptable_filter +ip_tables dm_mod unix Oct 5 01:01:29 nikki kernel: [17209340.040000] CPU: 0 Oct 5 01:01:29 nikki kernel: [17209340.040000] EIP: 0060:[] Not tainted VLI Oct 5 01:01:29 nikki kernel: [17209340.040000] EFLAGS: 00010283 (2.6.13.2-came32) Oct 5 01:01:29 nikki kernel: [17209340.040000] EIP is at xfs_alloc_delrec+0x8e/0xe60 Oct 5 01:01:29 nikki kernel: [17209340.040000] eax: 00000086 ebx: 0000004d ecx: d36e49dc edx: 00000086 Oct 5 01:01:29 nikki kernel: [17209340.040000] esi: e02f37a8 edi: f7bb9000 ebp: f1dea818 esp: e02f371c Oct 5 01:01:29 nikki kernel: [17209340.040000] ds: 007b es: 007b ss: 0068 Oct 5 01:01:29 nikki kernel: [17209340.040000] Process pdflush (pid: 25838, threadinfo=e02f2000 task=f6973580) Oct 5 01:01:29 nikki kernel: [17209340.040000] Stack: f7cc31a0 017595e8 0004a814 f1dea78c c0236837 f1dea78c f6f70000 00000000 Oct 5 01:01:29 nikki kernel: [17209340.040000] 00000000 f6f70000 c021d343 f1dea78c 00000000 00000000 00000000 f1dea78c Oct 5 01:01:29 nikki kernel: [17209340.040000] 00000000 d36e49dc c05fa2c0 f6f70010 00000000 0000000a f7d56400 00000044 Oct 5 01:01:29 nikki kernel: [17209340.040000] Call Trace: Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_btree_check_sblock+0x77/0xe0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_alloc_lookup+0x143/0x440 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_alloc_delete+0x1b/0x80 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_alloc_fixup_trees+0x71/0x2e0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_alloc_ag_vextent_near+0x943/0xa10 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_alloc_ag_vextent+0x117/0x120 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_alloc_vextent+0x450/0x580 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_bmap_alloc+0xa0d/0x18a0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] activate_task+0x82/0xa0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_bmbt_get_state+0x1e/0x30 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_bmap_do_search_extents+0x114/0x4c0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_bmapi+0x11b9/0x1640 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_bmbt_get_state+0x1e/0x30 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_bmap_do_search_extents+0x114/0x4c0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] mempool_alloc_slab+0xf/0x20 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xlog_grant_push_ail+0x3a/0x110 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xlog_grant_push_ail+0xdf/0x110 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_log_reserve+0xa8/0xc0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_iomap_write_allocate+0x297/0x500 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_iomap+0x359/0x480 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] generic_make_request+0x133/0x200 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_bmap+0x2d/0x40 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_map_blocks+0x35/0x70 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_page_state_convert+0x4c8/0x640 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] submit_bio+0x53/0xd0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] radix_tree_gang_lookup_tag+0x43/0x60 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] find_get_pages_tag+0x32/0x70 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] linvfs_writepage+0x54/0xf0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] mpage_writepages+0x241/0x390 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] linvfs_writepage+0x0/0xf0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] common_interrupt+0x1a/0x20 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] linvfs_write_inode+0x2e/0x60 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] do_writepages+0x29/0x40 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] __sync_single_inode+0x5e/0x210 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] __writeback_single_inode+0x6f/0x140 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] xfs_trans_first_ail+0xe/0x20 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] sync_sb_inodes+0x1ad/0x2b0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] writeback_inodes+0xcb/0xe0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] wb_kupdate+0xbb/0x130 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] pdflush+0x0/0x30 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] __pdflush+0xc0/0x1b0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] pdflush+0x1e/0x30 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] wb_kupdate+0x0/0x130 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] kthread+0xa7/0xb0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] kthread+0x0/0xb0 Oct 5 01:01:29 nikki kernel: [17209340.040000] [] kernel_thread_helper+0x5/0x18 Oct 5 01:01:29 nikki kernel: [17209340.040000] Code: 8b 79 60 66 8b 47 06 25 ff ff 00 00 89 c2 c1 e2 08 c1 e8 08 09 c2 81 e2 ff ff 00 00 39 d3 7e 0b 8b 9c 24 88 00 00 00 c7 03 00 00 <00> 00 eb b8 ba 00 e0 ff ff +b8 c0 a2 5f c0 21 e2 8b 52 10 8b 0c -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred. | : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `- http://www.debian.org/ From owner-linux-xfs@oss.sgi.com Wed Oct 5 06:43:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 06:43:18 -0700 (PDT) Received: from mta2.gsf.de (mta2.gsf.de [146.107.4.111]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95Dh8O0032700 for ; Wed, 5 Oct 2005 06:43:11 -0700 Received: from sw-rz010.gsf.de (sw-rz010.gsf.de [146.107.8.106]) by mta2.gsf.de (Postfix) with ESMTP id 45DB71463E4 for ; Wed, 5 Oct 2005 15:40:08 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: xfs problem Date: Wed, 5 Oct 2005 15:40:02 +0200 Message-ID: <8306780C060A7D4790F8BA02CBA1B6910A94BE@sw-rz010.gsf.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xfs problem Thread-Index: AcXJsknN6ijlEC94QH+eMtI47jzRGg== From: "Bhanu, Yogesh" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j95DhBO0032711 X-archive-position: 6326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yogesh@gsf.de Precedence: bulk X-list: linux-xfs Content-Length: 1171 Lines: 25 Hi , My 3 TB xfs file system spewed few error messages and the whole filesystem has gone offline. The system under question is running Suse SLES9 SP2 and is connexted to an IBM T600 is Dual Opteron with 8 GB RAM (IBM e326). The error messages it spewed are . -------------cut here---------------------------- Filesystem "dm-0": xfs_log_write: reservation ran out. Need to up reservation xfs_force_shutdown(dm-0,0x8) called from line 1689 of file fs/xfs/xfs_log.c. Return address = 0xffffffffa01b45e8 Filesystem "dm-0": Corruption of in-memory data detected. Shutting down filesystem: dm-0 Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(dm-0,0x2) called from line 1284 of file fs/xfs/xfs_log.c. Return address = 0xffffffffa01b45e8 nfsd: last server has exited nfsd: unexporting all filesystems xfs_force_shutdown(dm-0,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xffffffffa01b45e8 xfs_force_shutdown(dm-0,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xffffffffa01b45e8 -------------cut here---------------------------- Any pointers to fix the problem . Thanks in advance yogesh From owner-linux-xfs@oss.sgi.com Wed Oct 5 07:16:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 07:16:06 -0700 (PDT) Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95EG0O0003206 for ; Wed, 5 Oct 2005 07:16:01 -0700 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1ENA13-0006br-00; Wed, 05 Oct 2005 16:13:05 +0200 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.22) id 1ENA10-0007Xp-Sn; Wed, 05 Oct 2005 16:13:02 +0200 Received: by kernel.dk (Postfix, from userid 1000) id EEAB61363DB; Wed, 5 Oct 2005 16:13:41 +0200 (CEST) Date: Wed, 5 Oct 2005 16:13:41 +0200 From: Jens Axboe To: Eric Sandeen Cc: Steve Lord , Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: The XFS real-time subvolume in Linux Message-ID: <20051005141340.GX3511@suse.de> References: <4342A2AB.4040700@xfs.org> <200510041759.15075.ak@suse.de> <4342AAD3.8060102@xfs.org> <20051005084117.GF3511@suse.de> <4343DEFE.9010505@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4343DEFE.9010505@sgi.com> X-archive-position: 6328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 977 Lines: 21 On Wed, Oct 05 2005, Eric Sandeen wrote: > Jens Axboe wrote: > >That's exactly why the Linux ioprio stuff has been designed the way it > >is right now - it's not overengineered for something we cannot support > >anyways. The CFQ io priorities will work well enough for general use, if > >you are basing your business on GRIO it's a different game completely. I > >don't want to add kernel infrastructure for something that is very > >specialized, especially because the code to do so would be 10 times > >bigger and more complex that the current stuff.. > > Jens, I didn't mean to imply that you -should- have done a GRIO-type > design (and I doubt that Steve did, either.) My only point was that > GRIO and ioprio are two different IO control mechanisms. Oh I agree, was mainly trying to clarify that they pertain to two different market segments. Sorry if that wasn't clear, it's not a criticism of GRIO (I don't really know anything about SGI's GRIO). -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Oct 5 07:13:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 07:14:04 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95EDwO0002881 for ; Wed, 5 Oct 2005 07:13:59 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j95EB3xT002427 for ; Wed, 5 Oct 2005 09:11:03 -0500 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j95EB1sS87864345; Wed, 5 Oct 2005 07:11:01 -0700 (PDT) Message-ID: <4343DEFE.9010505@sgi.com> Date: Wed, 05 Oct 2005 09:11:10 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jens Axboe CC: Steve Lord , Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: The XFS real-time subvolume in Linux References: <4342A2AB.4040700@xfs.org> <200510041759.15075.ak@suse.de> <4342AAD3.8060102@xfs.org> <20051005084117.GF3511@suse.de> In-Reply-To: <20051005084117.GF3511@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 710 Lines: 15 Jens Axboe wrote: > That's exactly why the Linux ioprio stuff has been designed the way it > is right now - it's not overengineered for something we cannot support > anyways. The CFQ io priorities will work well enough for general use, if > you are basing your business on GRIO it's a different game completely. I > don't want to add kernel infrastructure for something that is very > specialized, especially because the code to do so would be 10 times > bigger and more complex that the current stuff.. Jens, I didn't mean to imply that you -should- have done a GRIO-type design (and I doubt that Steve did, either.) My only point was that GRIO and ioprio are two different IO control mechanisms. -Eric From owner-linux-xfs@oss.sgi.com Wed Oct 5 07:20:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 07:21:00 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95EKuO0004163 for ; Wed, 5 Oct 2005 07:20:57 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j95FMKed030054 for ; Wed, 5 Oct 2005 08:22:20 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j95EH0sS93718914; Wed, 5 Oct 2005 07:17:01 -0700 (PDT) Message-ID: <4343E066.1030806@sgi.com> Date: Wed, 05 Oct 2005 09:17:10 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dubravko Markic CC: ak@suse.de, linux-xfs@oss.sgi.com Subject: Re: GRIO References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1048 Lines: 25 Dubravko Markic wrote: > Hello again, > I am wondering if you guys have any idea if it possible to have > the High Performance Guaranteed-Rate I/O-Unlimited Streams software > option in SuSE v.10 and linux kernel 2.6.13+? I would need to be able to > have this option for running the video-on-demand service. Do you know if > it is possible to have it? Also do you guys have any clue how much it > costs to have this software option(GRIO-Unlimited Streams)? Or is this > once again a service which is only limited to IRIX OS? Thanks in advance GRIO (V1), as implemented on Irix, will almost certainly never be ported to Linux. The realtime subvolume by itself really doesn't give you much in terms of realtime. It's essentially a more deterministic allocator, which allocates in larger units, and direct IO. It was -part- of the GRIO system on Irix. You should look at the ioprio stuff that Andi & Jens were talking about on the other thread. Or, talk to an SGI sales rep for a full-blown media playout solution :) -Eric From owner-linux-xfs@oss.sgi.com Wed Oct 5 07:21:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 07:21:29 -0700 (PDT) Received: from mx1.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95ELPO0004294 for ; Wed, 5 Oct 2005 07:21:26 -0700 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 3F28DEA9E; Wed, 5 Oct 2005 16:18:30 +0200 (CEST) From: Andi Kleen To: Eric Sandeen Subject: Re: The XFS real-time subvolume in Linux Date: Wed, 5 Oct 2005 16:18:43 +0200 User-Agent: KMail/1.8.2 Cc: Jens Axboe , Steve Lord , linux-xfs@oss.sgi.com References: <20051005084117.GF3511@suse.de> <4343DEFE.9010505@sgi.com> In-Reply-To: <4343DEFE.9010505@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510051618.44230.ak@suse.de> X-archive-position: 6330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 851 Lines: 18 On Wednesday 05 October 2005 16:11, Eric Sandeen wrote: > Jens Axboe wrote: > > That's exactly why the Linux ioprio stuff has been designed the way it > > is right now - it's not overengineered for something we cannot support > > anyways. The CFQ io priorities will work well enough for general use, if > > you are basing your business on GRIO it's a different game completely. I > > don't want to add kernel infrastructure for something that is very > > specialized, especially because the code to do so would be 10 times > > bigger and more complex that the current stuff.. > > Jens, I didn't mean to imply that you -should- have done a GRIO-type > design (and I doubt that Steve did, either.) My only point was that > GRIO and ioprio are two different IO control mechanisms. I suspect for most people they will be pretty much equivalent. -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 5 07:22:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 07:22:29 -0700 (PDT) Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95EMNO0004646 for ; Wed, 5 Oct 2005 07:22:24 -0700 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1ENA7H-0006yU-00; Wed, 05 Oct 2005 16:19:31 +0200 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.22) id 1ENA7E-0007eA-H1; Wed, 05 Oct 2005 16:19:28 +0200 Received: by kernel.dk (Postfix, from userid 1000) id 9DDDC17EDE9; Wed, 5 Oct 2005 16:20:07 +0200 (CEST) Date: Wed, 5 Oct 2005 16:20:07 +0200 From: Jens Axboe To: Andi Kleen Cc: Eric Sandeen , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: The XFS real-time subvolume in Linux Message-ID: <20051005142006.GA3511@suse.de> References: <20051005084117.GF3511@suse.de> <4343DEFE.9010505@sgi.com> <200510051618.44230.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510051618.44230.ak@suse.de> X-archive-position: 6331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1020 Lines: 23 On Wed, Oct 05 2005, Andi Kleen wrote: > On Wednesday 05 October 2005 16:11, Eric Sandeen wrote: > > Jens Axboe wrote: > > > That's exactly why the Linux ioprio stuff has been designed the way it > > > is right now - it's not overengineered for something we cannot support > > > anyways. The CFQ io priorities will work well enough for general use, if > > > you are basing your business on GRIO it's a different game completely. I > > > don't want to add kernel infrastructure for something that is very > > > specialized, especially because the code to do so would be 10 times > > > bigger and more complex that the current stuff.. > > > > Jens, I didn't mean to imply that you -should- have done a GRIO-type > > design (and I doubt that Steve did, either.) My only point was that > > GRIO and ioprio are two different IO control mechanisms. > > I suspect for most people they will be pretty much equivalent. Indeed, only for the 'obscure' life-or-death type setups will there be a real difference. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Oct 5 07:26:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 07:27:07 -0700 (PDT) Received: from mx2.suse.de (ns2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95EQwO0005682 for ; Wed, 5 Oct 2005 07:26:59 -0700 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id A4AE81C7BD; Wed, 5 Oct 2005 16:24:02 +0200 (CEST) From: Andi Kleen To: Jens Axboe Subject: Re: The XFS real-time subvolume in Linux Date: Wed, 5 Oct 2005 16:24:15 +0200 User-Agent: KMail/1.8.2 Cc: Eric Sandeen , Steve Lord , linux-xfs@oss.sgi.com References: <200510051618.44230.ak@suse.de> <20051005142006.GA3511@suse.de> In-Reply-To: <20051005142006.GA3511@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510051624.16213.ak@suse.de> X-archive-position: 6332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 394 Lines: 12 On Wednesday 05 October 2005 16:20, Jens Axboe wrote: > Indeed, only for the 'obscure' life-or-death type setups will there be a > real difference. Even for those you could in theory do bandwidth allocation on top of the RT classes with some tweaking of the time slices and knowing the worst case transfer rate of the HD, couldn't you? Basically it would be an user space problem. -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 5 08:00:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 08:00:42 -0700 (PDT) Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95F0UO0009943 for ; Wed, 5 Oct 2005 08:00:31 -0700 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1ENAi8-0000am-00; Wed, 05 Oct 2005 16:57:36 +0200 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.22) id 1ENAi5-0008Cg-C2; Wed, 05 Oct 2005 16:57:33 +0200 Received: by kernel.dk (Postfix, from userid 1000) id 7309E17EDE9; Wed, 5 Oct 2005 16:58:10 +0200 (CEST) Date: Wed, 5 Oct 2005 16:58:10 +0200 From: Jens Axboe To: Andi Kleen Cc: Eric Sandeen , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: The XFS real-time subvolume in Linux Message-ID: <20051005145808.GC3511@suse.de> References: <200510051618.44230.ak@suse.de> <20051005142006.GA3511@suse.de> <200510051624.16213.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510051624.16213.ak@suse.de> X-archive-position: 6333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 966 Lines: 23 On Wed, Oct 05 2005, Andi Kleen wrote: > On Wednesday 05 October 2005 16:20, Jens Axboe wrote: > > > Indeed, only for the 'obscure' life-or-death type setups will there be a > > real difference. > > Even for those you could in theory do bandwidth allocation on top of > the RT classes with some tweaking of the time slices and knowing the worst > case transfer rate of the HD, couldn't you? Basically it would be an > user space problem. There are still unknowns, the HD still being the biggest one of course. The problem is that you don't know the worst case HD performance, it might be doing all sorts of rewriting, calibration, error correct etc that can still screw you. So I think without definitely knowledge of what the HD will do in case of errors (or a way to control that which you definitely can on some drives), it's still pretty hazy. It gets better, but if you are looking for complete guarantees I don't think it's good enough. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Oct 5 08:13:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 08:13:26 -0700 (PDT) Received: from mx1.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95FDIO0011193 for ; Wed, 5 Oct 2005 08:13:18 -0700 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id BE1BCE9A8; Wed, 5 Oct 2005 17:10:22 +0200 (CEST) From: Andi Kleen To: Jens Axboe Subject: Re: The XFS real-time subvolume in Linux Date: Wed, 5 Oct 2005 17:10:36 +0200 User-Agent: KMail/1.8.2 Cc: Eric Sandeen , Steve Lord , linux-xfs@oss.sgi.com References: <200510051624.16213.ak@suse.de> <20051005145808.GC3511@suse.de> In-Reply-To: <20051005145808.GC3511@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510051710.36778.ak@suse.de> X-archive-position: 6334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 690 Lines: 16 On Wednesday 05 October 2005 16:58, Jens Axboe wrote: > There are still unknowns, the HD still being the biggest one of course. > The problem is that you don't know the worst case HD performance, it > might be doing all sorts of rewriting, calibration, error correct etc > that can still screw you. So I think without definitely knowledge of > what the HD will do in case of errors (or a way to control that which > you definitely can on some drives), it's still pretty hazy. It gets > better, but if you are looking for complete guarantees I don't think > it's good enough. Yes, but GRIO has exactly the same problem. I assume they need custom calibration for each IO subsystem. -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 5 08:23:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 08:23:19 -0700 (PDT) Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95FNAO0016140 for ; Wed, 5 Oct 2005 08:23:12 -0700 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1ENB45-0001vy-00; Wed, 05 Oct 2005 17:20:17 +0200 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.22) id 1ENB42-0008Vq-Me; Wed, 05 Oct 2005 17:20:14 +0200 Received: by kernel.dk (Postfix, from userid 1000) id 3CFCECD8D2; Wed, 5 Oct 2005 17:20:53 +0200 (CEST) Date: Wed, 5 Oct 2005 17:20:52 +0200 From: Jens Axboe To: Andi Kleen Cc: Eric Sandeen , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: The XFS real-time subvolume in Linux Message-ID: <20051005152051.GF3511@suse.de> References: <200510051624.16213.ak@suse.de> <20051005145808.GC3511@suse.de> <200510051710.36778.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510051710.36778.ak@suse.de> X-archive-position: 6335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1159 Lines: 25 On Wed, Oct 05 2005, Andi Kleen wrote: > On Wednesday 05 October 2005 16:58, Jens Axboe wrote: > > > There are still unknowns, the HD still being the biggest one of course. > > The problem is that you don't know the worst case HD performance, it > > might be doing all sorts of rewriting, calibration, error correct etc > > that can still screw you. So I think without definitely knowledge of > > what the HD will do in case of errors (or a way to control that which > > you definitely can on some drives), it's still pretty hazy. It gets > > better, but if you are looking for complete guarantees I don't think > > it's good enough. > > Yes, but GRIO has exactly the same problem. I assume they need custom > calibration for each IO subsystem. Indeed it does, and yes if they really want to provide the type of guarantees that Steve listed, then that needs a custom box with either custom or known disk firmware options. If not you cannot give absolute guarantees and expect to always honor them. That's in addition to anything you may need to change in software, if using Linux you would need to audit/fix lots of things in the io path. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Oct 5 08:33:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 08:33:36 -0700 (PDT) Received: from MAIL01HQ.adic.com (mail01hq.adic.com [63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95FXRO0017337 for ; Wed, 5 Oct 2005 08:33:27 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 08:30:31 -0700 Message-ID: <4343F196.7050605@xfs.org> Date: Wed, 05 Oct 2005 10:30:30 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jens Axboe CC: Andi Kleen , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: The XFS real-time subvolume in Linux References: <200510051624.16213.ak@suse.de> <20051005145808.GC3511@suse.de> <200510051710.36778.ak@suse.de> <20051005152051.GF3511@suse.de> In-Reply-To: <20051005152051.GF3511@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2005 15:30:32.0013 (UTC) FILETIME=[B90857D0:01C5C9C1] X-archive-position: 6336 X-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: 1448 Lines: 34 Jens Axboe wrote: > On Wed, Oct 05 2005, Andi Kleen wrote: > >>On Wednesday 05 October 2005 16:58, Jens Axboe wrote: >> >> >>>There are still unknowns, the HD still being the biggest one of course. >>>The problem is that you don't know the worst case HD performance, it >>>might be doing all sorts of rewriting, calibration, error correct etc >>>that can still screw you. So I think without definitely knowledge of >>>what the HD will do in case of errors (or a way to control that which >>>you definitely can on some drives), it's still pretty hazy. It gets >>>better, but if you are looking for complete guarantees I don't think >>>it's good enough. >> >>Yes, but GRIO has exactly the same problem. I assume they need custom >>calibration for each IO subsystem. > > > Indeed it does, and yes if they really want to provide the type of > guarantees that Steve listed, then that needs a custom box with either > custom or known disk firmware options. If not you cannot give absolute > guarantees and expect to always honor them. That's in addition to > anything you may need to change in software, if using Linux you would > need to audit/fix lots of things in the io path. > Definitely, from my memory, grio had a tool for measuring a disk subsystem. I think reality is closer to overspecing the hardware than to providing an absolute guarantee of bandwidth. Being able to prioritize individual I/O calls is just part of the picture. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 5 08:35:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 08:35:36 -0700 (PDT) Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95FZWO0017909 for ; Wed, 5 Oct 2005 08:35:32 -0700 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1ENBG3-0002vj-00; Wed, 05 Oct 2005 17:32:39 +0200 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.22) id 1ENBG0-0000Fq-KL; Wed, 05 Oct 2005 17:32:36 +0200 Received: by kernel.dk (Postfix, from userid 1000) id C1528CD8D2; Wed, 5 Oct 2005 17:33:15 +0200 (CEST) Date: Wed, 5 Oct 2005 17:33:15 +0200 From: Jens Axboe To: Steve Lord Cc: Andi Kleen , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: The XFS real-time subvolume in Linux Message-ID: <20051005153314.GH3511@suse.de> References: <200510051624.16213.ak@suse.de> <20051005145808.GC3511@suse.de> <200510051710.36778.ak@suse.de> <20051005152051.GF3511@suse.de> <4343F196.7050605@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4343F196.7050605@xfs.org> X-archive-position: 6337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1945 Lines: 44 On Wed, Oct 05 2005, Steve Lord wrote: > Jens Axboe wrote: > >On Wed, Oct 05 2005, Andi Kleen wrote: > > > >>On Wednesday 05 October 2005 16:58, Jens Axboe wrote: > >> > >> > >>>There are still unknowns, the HD still being the biggest one of course. > >>>The problem is that you don't know the worst case HD performance, it > >>>might be doing all sorts of rewriting, calibration, error correct etc > >>>that can still screw you. So I think without definitely knowledge of > >>>what the HD will do in case of errors (or a way to control that which > >>>you definitely can on some drives), it's still pretty hazy. It gets > >>>better, but if you are looking for complete guarantees I don't think > >>>it's good enough. > >> > >>Yes, but GRIO has exactly the same problem. I assume they need custom > >>calibration for each IO subsystem. > > > > > >Indeed it does, and yes if they really want to provide the type of > >guarantees that Steve listed, then that needs a custom box with either > >custom or known disk firmware options. If not you cannot give absolute > >guarantees and expect to always honor them. That's in addition to > >anything you may need to change in software, if using Linux you would > >need to audit/fix lots of things in the io path. > > > > Definitely, from my memory, grio had a tool for measuring a disk subsystem. > I think reality is closer to overspecing the hardware than to providing an > absolute guarantee of bandwidth. Being able to prioritize individual I/O > calls > is just part of the picture. The spec'ing part is the last piece in the puzzle, that will only tell you what the io subsystem will typically do. It wont tell you how it behaves in boundary or error conditions. It's trivial to say "oh the disk does 35MiB/sec at the end zone, lets cap it at 20MiB/sec" and have it work 99.9% of the time, the tricky part is the last 0.1%. Or whatever percentage you want to assign to it :-) -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Oct 5 14:39:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 14:39:54 -0700 (PDT) Received: from host366.ipowerweb.com (host366.ipowerweb.com [72.22.69.51]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j95LdgO0017897 for ; Wed, 5 Oct 2005 14:39:47 -0700 Received: (qmail 50744 invoked from network); 5 Oct 2005 21:36:26 -0000 Received: from unknown (HELO mayaserv) (24.6.236.87) by host366.ipowerweb.com with SMTP; 5 Oct 2005 21:36:26 -0000 Subject: Crossmeta: XFS for Windows Link request From: Crossmeta Solutions To: linux-xfs@oss.sgi.com Cc: info@crossmeta.com Content-Type: text/plain Organization: Crossmeta Solutions Date: Wed, 05 Oct 2005 14:31:03 -0700 Message-Id: <1128547863.3387.11.camel@mayaserv> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-8) Content-Transfer-Encoding: 7bit X-archive-position: 6339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: info@crossmeta.com Precedence: bulk X-list: linux-xfs Content-Length: 489 Lines: 14 Hi, We noticed your link to XFS on Freebsd project in the News category and we would appreciate a similar link to Crossmeta project http://www.crossmeta.com which is XFS plus other file systems EXT2, ffs, nfs and reiserfs on Windows 2000, 2003, XP. Crossmeta XFS for Windows is based on the initial XFS 1.1 release and it comes with all the necessary tools xfs_mkfs, xfs_repair. It can easily survive postmark and bonnie++ stress benchmarks :) Thanks -Sam URL: http://www.crossmeta.com From owner-linux-xfs@oss.sgi.com Wed Oct 5 15:37:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 15:37:44 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j95MbdO0022287 for ; Wed, 5 Oct 2005 15:37:40 -0700 Received: by xproxy.gmail.com with SMTP id t15so169551wxc for ; Wed, 05 Oct 2005 15:34:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P3P36OMff4SgvjF7EPhmLG4FXpJegnNun5uHJjgrG8tH3viTtktlx3U2N+xmvQgJgZOBb9n1D9LlRA5q7AFdTuJ+tk6+Ql/VI3dheUnWHyAVraNfrDi/eOXThbbrOU8MEDvdUPVUxu5CbW3bqUZI7eq4CBmD0o0hKaCocvYgSrw= Received: by 10.70.63.8 with SMTP id l8mr654327wxa; Wed, 05 Oct 2005 15:34:43 -0700 (PDT) Received: by 10.70.59.2 with HTTP; Wed, 5 Oct 2005 15:34:43 -0700 (PDT) Message-ID: <87f94c370510051534t11328ce5web918949c02a71c8@mail.gmail.com> Date: Wed, 5 Oct 2005 18:34:43 -0400 From: Greg Freemyer Reply-To: Greg Freemyer To: linux-xfs@oss.sgi.com Subject: Re: Crossmeta: XFS for Windows Link request In-Reply-To: <1128547863.3387.11.camel@mayaserv> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1128547863.3387.11.camel@mayaserv> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j95MbeO0022291 X-archive-position: 6340 X-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 Content-Length: 852 Lines: 26 On 10/5/05, Crossmeta Solutions wrote: > Hi, > We noticed your link to XFS on Freebsd project in the News category and > we would appreciate a similar link to Crossmeta project > http://www.crossmeta.com which is XFS plus other file systems EXT2, ffs, > nfs and reiserfs on Windows 2000, 2003, XP. > > Crossmeta XFS for Windows is based on the initial XFS 1.1 release and it > comes with all the necessary tools xfs_mkfs, xfs_repair. It can easily > survive postmark and bonnie++ stress benchmarks :) > Thanks > -Sam > URL: http://www.crossmeta.com If anybody has used Crossmeta XFS for Windows I would appreciate hearing about it. Also, would a XFS 1.1 release be compatible with current XFS? I think so, but possibly the on disk structure has changed. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century From owner-linux-xfs@oss.sgi.com Wed Oct 5 16:53:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Oct 2005 16:53:14 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j95Nr5O0031864 for ; Wed, 5 Oct 2005 16:53:06 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA01380; Thu, 6 Oct 2005 09:49:59 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j95No9kt5488680; Thu, 6 Oct 2005 09:50:09 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j95No7xh5484374; Thu, 6 Oct 2005 09:50:07 +1000 (EST) Date: Thu, 6 Oct 2005 09:50:06 +1000 From: Nathan Scott To: Crossmeta Solutions Cc: linux-xfs@oss.sgi.com Subject: Re: Crossmeta: XFS for Windows Link request Message-ID: <20051006095006.E5483061@wobbly.melbourne.sgi.com> References: <1128547863.3387.11.camel@mayaserv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1128547863.3387.11.camel@mayaserv>; from info@crossmeta.com on Wed, Oct 05, 2005 at 02:31:03PM -0700 X-archive-position: 6341 X-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: 901 Lines: 31 On Wed, Oct 05, 2005 at 02:31:03PM -0700, Crossmeta Solutions wrote: > Hi, Hi there, > We noticed your link to XFS on Freebsd project in the News category and > we would appreciate a similar link to Crossmeta project > http://www.crossmeta.com which is XFS plus other file systems EXT2, ffs, > nfs and reiserfs on Windows 2000, 2003, XP. Is this an open source product? If not, it'd probably be more appropriate to link to it from the "Whos Using XFS" page. > Crossmeta XFS for Windows is based on the initial XFS 1.1 release and it Heh, old timers, eh? No 2.6 plans there? There have been a number of XFS ondisk extensions since 1.1 (fwiw). Did you have to modify XFS to get it to work within your system, out of curiousity? > comes with all the necessary tools xfs_mkfs, xfs_repair. It can easily > survive postmark and bonnie++ stress benchmarks :) Er, good stuff! cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 6 08:01:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Oct 2005 08:01:23 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j96F1HO0029103 for ; Thu, 6 Oct 2005 08:01:17 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j96G2nNR004802 for ; Thu, 6 Oct 2005 09:02:49 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j96EwLDN17151790 for ; Thu, 6 Oct 2005 09:58:21 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j96EwHLL9318765; Thu, 6 Oct 2005 09:58:17 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j96EwJvM029934; Thu, 6 Oct 2005 09:58:19 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j96EwJfq029932; Thu, 6 Oct 2005 09:58:19 -0500 Date: Thu, 6 Oct 2005 09:58:19 -0500 From: Eric Sandeen Message-Id: <200510061458.j96EwJfq029932@penguin.americas.sgi.com> To: sgi.bugs.xfs@fido.engr.sgi.com, linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 942658 - X-archive-position: 6344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 925 Lines: 23 Date: Thu Oct 6 07:57:59 PDT 2005 Workarea: penguin.americas.sgi.com:/src/eric/linux-2.6.x Inspected by: nathans,cattelan The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:200295a split-patches/discard-buffer-clear-uptodate - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/discard-buffer-clear-uptodate - patch for local change, clear uptodate in discard-buffer. in mm series fs/buffer.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/buffer.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h - clear uptodate when discarding buffer (truncate path) - otherwise xfs will find this buffer & map it. split-patches/series - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h - update for discard-buffer-clear-uptodate patch From owner-linux-xfs@oss.sgi.com Thu Oct 6 10:29:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Oct 2005 10:29:37 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j96HTPO0012012 for ; Thu, 6 Oct 2005 10:29:25 -0700 Received: by zproxy.gmail.com with SMTP id r28so279021nza for ; Thu, 06 Oct 2005 10:26:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kuF8RAdd+0udwovZIt+ih6uy3MQb1VQiNDE8WDjfmK2EOAYcF3K+vTU5ivDzfynMT2xNYuKu3SQkkEEhTsZAAVxS3Ntr3g2cok0SfiD+K7B1/sYcPcdQGMxAL3KZvxDVd95nf3hOnHLcPb4EIl8920C//98S2simV/NHzfKOnDE= Received: by 10.37.21.19 with SMTP id y19mr92997nzi; Thu, 06 Oct 2005 10:26:29 -0700 (PDT) Received: by 10.36.105.9 with HTTP; Thu, 6 Oct 2005 10:26:29 -0700 (PDT) Message-ID: <5449aac20510061026o69854e8ai16ab5eb3787094f7@mail.gmail.com> Date: Thu, 6 Oct 2005 18:26:29 +0100 From: Alexander Fisher Reply-To: alex@alexfisher.me.uk To: linux-xfs@oss.sgi.com Subject: xfs and lvm snapshots MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j96HTPO0012015 X-archive-position: 6345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alexjfisher@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1001 Lines: 29 Hi. I'm currently trying to write a backup script for my system. I have a number of XFS filesystems on top of LVM2, on top of RAID 1. The idea is to snapshot the logical volumes and then use xfsdump to perform incremental backups. Unfortunately xfs_check finds problems with the snapshots that didn't exist on the original filesystems such as: bad nblocks 41540 for free inode 6291598 bad nlink 1 for free inode 6291598 bad mode 0100644 for free inode 6291598 sb_ifree 360, counted 361 sb_fdblocks 710402, counted 751942 Given these errors, I'm not sure that I want to rely on the backups taken with xfsdump. Can they be ignored?! I was under the impression that xfs_freeze shouldn't be used anymore since it will deadlock (which it does). I'm using Debian Sarge with the 2.6.8 kernel it ships with. I've also tried a 2.6.12 kernel from backports.org. Other than mounting filesystems read-only before snapshoting (which isn't practical), is there anything else I can do? Many thanks, Alex From owner-linux-xfs@oss.sgi.com Thu Oct 6 10:57:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Oct 2005 10:57:50 -0700 (PDT) Received: from host366.ipowerweb.com (host366.ipowerweb.com [72.22.69.51]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j96HvgO0014629 for ; Thu, 6 Oct 2005 10:57:42 -0700 Received: (qmail 9949 invoked from network); 6 Oct 2005 17:54:26 -0000 Received: from unknown (HELO mayaserv) (24.6.222.12) by host366.ipowerweb.com with SMTP; 6 Oct 2005 17:54:26 -0000 Subject: Re: Crossmeta: XFS for Windows Link request From: Crossmeta Solutions To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20051006095006.E5483061@wobbly.melbourne.sgi.com> References: <1128547863.3387.11.camel@mayaserv> <20051006095006.E5483061@wobbly.melbourne.sgi.com> Content-Type: text/plain Organization: Crossmeta Solutions Date: Thu, 06 Oct 2005 10:50:02 -0700 Message-Id: <1128621002.3406.19.camel@mayaserv> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-8) Content-Transfer-Encoding: 7bit X-archive-position: 6346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: info@crossmeta.com Precedence: bulk X-list: linux-xfs Content-Length: 1650 Lines: 46 On Thu, 2005-10-06 at 09:50 +1000, Nathan Scott wrote: > On Wed, Oct 05, 2005 at 02:31:03PM -0700, Crossmeta Solutions wrote: > > Hi, > > Hi there, Nathan, > > > We noticed your link to XFS on Freebsd project in the News category and > > we would appreciate a similar link to Crossmeta project > > http://www.crossmeta.com which is XFS plus other file systems EXT2, ffs, > > nfs and reiserfs on Windows 2000, 2003, XP. > > Is this an open source product? If not, it'd probably be > more appropriate to link to it from the "Whos Using XFS" page. > XFS driver module itself is open-source but the entire crossmeta is not opensource product. This has to do with the Microsoft IFS kit license. Eventually everything will be open-source if we switch to the public ntifs.h Please provide a link wherever you feel is appropriate for this. > > Crossmeta XFS for Windows is based on the initial XFS 1.1 release and it > > Heh, old timers, eh? No 2.6 plans there? There have been a > number of XFS ondisk extensions since 1.1 (fwiw). There is partially merged XFS 1.3 but due to lack of resources it was frozen. > > Did you have to modify XFS to get it to work within your system, > out of curiousity? The crossmeta kernel driver has freebsd 4.2 VFS interface and only required few changes to the platforms defs and support directories. But the XFS 1.1 release was well organized with good macros for BUF_T and kernel apis and made the porting lot simpler. > > > comes with all the necessary tools xfs_mkfs, xfs_repair. It can easily > > survive postmark and bonnie++ stress benchmarks :) > > Er, good stuff! > > cheers. > Thanks and regards. From owner-linux-xfs@oss.sgi.com Thu Oct 6 12:10:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Oct 2005 12:10:51 -0700 (PDT) Received: from flyingAngel.upjs.sk (gate.rudna.net [195.122.192.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j96JAdO0020270 for ; Thu, 6 Oct 2005 12:10:42 -0700 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 59C5B10015C; Thu, 6 Oct 2005 21:07:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 56E2E18011D; Thu, 6 Oct 2005 21:07:15 +0200 (CEST) Date: Thu, 6 Oct 2005 21:07:15 +0200 (CEST) From: Jan Derfinak To: alex@alexfisher.me.uk Cc: linux-xfs@oss.sgi.com Subject: Re: xfs and lvm snapshots In-Reply-To: <5449aac20510061026o69854e8ai16ab5eb3787094f7@mail.gmail.com> Message-ID: References: <5449aac20510061026o69854e8ai16ab5eb3787094f7@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 594 Lines: 19 On Thu, 6 Oct 2005, Alexander Fisher wrote: > Hi. > > I'm currently trying to write a backup script for my system. I have a > number of XFS filesystems on top of LVM2, on top of RAID 1. > The idea is to snapshot the logical volumes and then use xfsdump to > perform incremental backups. Unfortunately xfs_check finds problems > with the snapshots that didn't exist on the original filesystems such > as: I think that if you snapshoting partiton mounted read-write, you get FS which is not correctly unmounted. What happens if you mount snapshot read-write and then unmount it? jan -- From owner-linux-xfs@oss.sgi.com Thu Oct 6 14:03:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Oct 2005 14:03:10 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j96L32O0031749 for ; Thu, 6 Oct 2005 14:03:02 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j96M4apC028301 for ; Thu, 6 Oct 2005 15:04:36 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j96L04sL23004527; Thu, 6 Oct 2005 16:00:04 -0500 (CDT) Message-ID: <43459053.5080801@sgi.com> Date: Thu, 06 Oct 2005 16:00:03 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Crossmeta Solutions CC: linux-xfs@oss.sgi.com Subject: Re: Crossmeta: XFS for Windows Link request References: <1128547863.3387.11.camel@mayaserv> In-Reply-To: <1128547863.3387.11.camel@mayaserv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 710 Lines: 21 Crossmeta Solutions wrote: > Hi, > We noticed your link to XFS on Freebsd project in the News category and > we would appreciate a similar link to Crossmeta project > http://www.crossmeta.com which is XFS plus other file systems EXT2, ffs, > nfs and reiserfs on Windows 2000, 2003, XP. > > Crossmeta XFS for Windows is based on the initial XFS 1.1 release and it > comes with all the necessary tools xfs_mkfs, xfs_repair. It can easily > survive postmark and bonnie++ stress benchmarks :) > Thanks > -Sam > URL: http://www.crossmeta.com Sure, and can we also post a URL that points to the GPL source code used for your project? I've had a few people asking about where they could find it. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Thu Oct 6 15:05:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Oct 2005 15:06:06 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j96M5tO0003616 for ; Thu, 6 Oct 2005 15:05:55 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA28297; Fri, 7 Oct 2005 08:02:55 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j96M36kt5486628; Fri, 7 Oct 2005 08:03:06 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j96Lrljw000821; Fri, 7 Oct 2005 07:53:47 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j96Lrj9p000819; Fri, 7 Oct 2005 07:53:45 +1000 Date: Fri, 7 Oct 2005 07:53:45 +1000 From: Nathan Scott To: Greg Freemyer Cc: linux-xfs@oss.sgi.com Subject: Re: Crossmeta: XFS for Windows Link request Message-ID: <20051006215345.GC722@frodo> References: <1128547863.3387.11.camel@mayaserv> <87f94c370510051534t11328ce5web918949c02a71c8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87f94c370510051534t11328ce5web918949c02a71c8@mail.gmail.com> User-Agent: Mutt/1.5.3i X-archive-position: 6350 X-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: 652 Lines: 21 On Wed, Oct 05, 2005 at 06:34:43PM -0400, Greg Freemyer wrote: > ... > If anybody has used Crossmeta XFS for Windows I would appreciate > hearing about it. > > Also, would a XFS 1.1 release be compatible with current XFS? I think > so, but possibly the on disk structure has changed. There have been numerous extensions, its a few years behind now. But a filesystem created with 1.1 will still be mountable with current XFS, although filesystems created and used now are not necessarily going to mount on 1.1... (depending on which features are in use, etc). No, I don't have a list of all features since 1.1 handy, sorry. ;) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 6 15:24:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Oct 2005 15:24:19 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j96MODO0005185 for ; Thu, 6 Oct 2005 15:24:14 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA28587; Fri, 7 Oct 2005 08:21:15 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j96MLPkt5510565; Fri, 7 Oct 2005 08:21:26 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j96MC5jw000890; Fri, 7 Oct 2005 08:12:05 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j96MC2St000888; Fri, 7 Oct 2005 08:12:02 +1000 Date: Fri, 7 Oct 2005 08:12:02 +1000 From: Nathan Scott To: Crossmeta Solutions Cc: linux-xfs@oss.sgi.com Subject: Re: Crossmeta: XFS for Windows Link request Message-ID: <20051006221202.GD722@frodo> References: <1128547863.3387.11.camel@mayaserv> <20051006095006.E5483061@wobbly.melbourne.sgi.com> <1128621002.3406.19.camel@mayaserv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1128621002.3406.19.camel@mayaserv> User-Agent: Mutt/1.5.3i X-archive-position: 6351 X-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: 2504 Lines: 55 Hi there, On Thu, Oct 06, 2005 at 10:50:02AM -0700, Crossmeta Solutions wrote: > On Thu, 2005-10-06 at 09:50 +1000, Nathan Scott wrote: > > On Wed, Oct 05, 2005 at 02:31:03PM -0700, Crossmeta Solutions wrote: > > > We noticed your link to XFS on Freebsd project in the News category and > > > we would appreciate a similar link to Crossmeta project > > > http://www.crossmeta.com which is XFS plus other file systems EXT2, ffs, > > > nfs and reiserfs on Windows 2000, 2003, XP. > > > > Is this an open source product? If not, it'd probably be > > more appropriate to link to it from the "Whos Using XFS" page. > > > XFS driver module itself is open-source but the entire crossmeta is not > opensource product. This has to do with the Microsoft IFS kit license. > Eventually everything will be open-source if we switch to the public > ntifs.h > > ... There have been a > > number of XFS ondisk extensions since 1.1 (fwiw). > There is partially merged XFS 1.3 but due to lack of resources it was > frozen. Ah, I see. Well, I'd advise not to focus on the 1.x releases - those are really old and moldy at this stage. Its far better to target either a mainline Linux kernel version, or (better) the XFS CVS tree. In fact, if this is indeed a GPL open source XFS port as you say, you could even work with us to have your platform specific code merged into the CVS tree (3rd platform - there's fs/xfs/{linux-2.4/ and linux-2.6/} "platforms" currently). That'd help to keep you from falling years behind as you are now. I also would expect thats a goal the FreeBSD guys might strive toward; they have userspace porting code merged in already... hmm, I guess you have userspace porting changes too, right? You could also get those all merged in and reduce your ongoing maintenance burden there. > > Did you have to modify XFS to get it to work within your system, > > out of curiousity? > The crossmeta kernel driver has freebsd 4.2 VFS interface and only > required few changes to the platforms defs and support directories. > But the XFS 1.1 release was well organized with good macros for BUF_T > and kernel apis and made the porting lot simpler. Yep, still there in CVS on oss.sgi.com; in fact its even more suited to your needs in that it has the core, largely platform-independent XFS code in fs/xfs and then platform-specific code in subdirectories below that. The userspace code has also morphed alot since 1.1 days and is much more portable now than it initially was. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 6 15:56:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Oct 2005 15:56:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j96MuGO0007259 for ; Thu, 6 Oct 2005 15:56:17 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA29198; Fri, 7 Oct 2005 08:53:17 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j96MrSkt5517922; Fri, 7 Oct 2005 08:53:29 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id j96Mi8jw000992; Fri, 7 Oct 2005 08:44:08 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j96Mi7LM000990; Fri, 7 Oct 2005 08:44:07 +1000 Date: Fri, 7 Oct 2005 08:44:07 +1000 From: Nathan Scott To: alex@alexfisher.me.uk Cc: linux-xfs@oss.sgi.com Subject: Re: xfs and lvm snapshots Message-ID: <20051006224407.GF722@frodo> References: <5449aac20510061026o69854e8ai16ab5eb3787094f7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5449aac20510061026o69854e8ai16ab5eb3787094f7@mail.gmail.com> User-Agent: Mutt/1.5.3i X-archive-position: 6352 X-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: 1719 Lines: 45 On Thu, Oct 06, 2005 at 06:26:29PM +0100, Alexander Fisher wrote: > Hi. > > I'm currently trying to write a backup script for my system. I have a > number of XFS filesystems on top of LVM2, on top of RAID 1. > The idea is to snapshot the logical volumes and then use xfsdump to > perform incremental backups. Unfortunately xfs_check finds problems > with the snapshots that didn't exist on the original filesystems such > as: > > bad nblocks 41540 for free inode 6291598 > bad nlink 1 for free inode 6291598 > bad mode 0100644 for free inode 6291598 > sb_ifree 360, counted 361 > sb_fdblocks 710402, counted 751942 > > Given these errors, I'm not sure that I want to rely on the backups > taken with xfsdump. Can they be ignored?! If its a readonly snapshot, yes they can. (are device mapper snapshots always readonly? I dunno) -- these look like the sorts of errors that would come from XFS not processing the unlinked list, which is what we do for a snapshot (XFS assumes it is readonly). > I was under the impression that xfs_freeze shouldn't be used anymore > since it will deadlock (which it does). I'm using Debian Sarge with Right. Its arguably a block layer (bdev_freeze, outside XFS) bug, noones had time/motivation to go fix it up. > Other than mounting filesystems read-only before snapshoting (which > isn't practical), is there anything else I can do? As long as the snapshot is mounted readonly, those check errors are fine. If we want writable snapshots, we have some work to do in XFS to ensure the log is left dirty on the snapshot, so that when its mounted we process the unlinked list... its mainly an issue of not knowing whether the snapshot target is ro/rw. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 7 02:40:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Oct 2005 02:40:13 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j979e4O0020170 for ; Fri, 7 Oct 2005 02:40:05 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA12499; Fri, 7 Oct 2005 19:36:06 +1000 Received: by boing.melbourne.sgi.com (Postfix, from userid 1000) id 11C1810D; Fri, 7 Oct 2005 19:36:44 +1000 (EST) Subject: Re: xfs problem From: timothy shimmin Reply-To: tes@sgi.com To: "Bhanu, Yogesh" Cc: linux-xfs@oss.sgi.com In-Reply-To: <8306780C060A7D4790F8BA02CBA1B6910A94BE@sw-rz010.gsf.de> References: <8306780C060A7D4790F8BA02CBA1B6910A94BE@sw-rz010.gsf.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: sgi Date: Fri, 07 Oct 2005 19:36:43 +1000 Message-Id: <1128677803.26500.19.camel@boing.melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 X-archive-position: 6353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2098 Lines: 53 Hi there, On Wed, 2005-10-05 at 15:40 +0200, Bhanu, Yogesh wrote: > Hi , > My 3 TB xfs file system spewed few error messages and the whole filesystem has gone offline. > The system under question is running Suse SLES9 SP2 and is connexted to an IBM T600 > is Dual Opteron with 8 GB RAM (IBM e326). > > The error messages it spewed are . > -------------cut here---------------------------- > Filesystem "dm-0": xfs_log_write: reservation ran out. Need to up reservation > xfs_force_shutdown(dm-0,0x8) called from line 1689 of file fs/xfs/xfs_log.c. Return address = 0xffffffffa01b45e8 > Filesystem "dm-0": Corruption of in-memory data detected. Shutting down filesystem: dm-0 > Please umount the filesystem, and rectify the problem(s) Don't know if you can really rectify the problem. The "run out of reservation" isn't really supposed to happen - it's a bug:) Basically, before a metadata op is peformed we reserve space in the log for its associated transaction. The reservation should be enough to handle the worst-case in size, form of the transaction. We then do the metadata modification and then write (copy) the transaction into the log buffer. While copying the transaction into the buffer we subtract space from our reservation. This message shows that we either didn't reserve enough space for the transaction or some other bug has happened in the code. I added some code to print out a break-down of the transaction components, to aid in tracking down any of these problems. However, this code is turned off by default using a macro, XFS_LOG_RES_DEBUG. I think I should revisit whether this is a good idea and get a better idea of the overhead in turning this macro on all the time. Otherwise it requires one to be able to reproduce the problem and be in a position of being able to build one's own kernel; often not the case. Sorry, this is no help at the moment. Your last metadata op with this transaction will not have gone through to disk. However, you should be able to remount the filesystem, which will replay the log for previous outstanding transactions. --Tim From owner-linux-xfs@oss.sgi.com Fri Oct 7 11:57:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Oct 2005 11:57:44 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.198.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j97IvdO0001989 for ; Fri, 7 Oct 2005 11:57:40 -0700 Received: from c-66-30-112-178.hsd1.ma.comcast.net ([66.30.112.178]) by comcast.net (rwcrmhc12) with ESMTP id <2005100718544201400l6th2e>; Fri, 7 Oct 2005 18:54:42 +0000 Received: from c-66-30-112-178.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-112-178.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j97Ishvp057756 for ; Fri, 7 Oct 2005 14:54:43 -0400 (EDT) (envelope-from rodrigc@c-66-30-112-178.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-112-178.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j97Isho0057755 for linux-xfs@oss.sgi.com; Fri, 7 Oct 2005 14:54:43 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 7 Oct 2005 14:54:43 -0400 From: Craig Rodrigues To: linux-xfs@oss.sgi.com Subject: xfsprogs patch 1 Message-ID: <20051007185443.GA57747@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 6354 X-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: 967 Lines: 28 Hi, Why is -O1 hardcoded in the CFLAGS for xfsprogs? Since there already is a variable $(OPTIMIZER), can't we just remove it? In the FreeBSD port for xfsprogs, I remove it, since most FreeBSD ports are compiled with a default optimization flag (-O2). ndex: builddefs.in =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/include/builddefs.in,v retrieving revision 1.43 diff -u -r1.43 builddefs.in --- builddefs.in 11 Aug 2005 06:02:16 -0000 1.43 +++ builddefs.in 7 Oct 2005 18:56:09 -0000 @@ -117,7 +117,7 @@ PCFLAGS = -I/usr/local/include endif -GCFLAGS = -O1 $(OPTIMIZER) $(DEBUG) -funsigned-char -fno-strict-aliasing -Wall \ +GCFLAGS = $(OPTIMIZER) $(DEBUG) -funsigned-char -fno-strict-aliasing -Wall \ -DVERSION=\"$(PKG_VERSION)\" -DLOCALEDIR=\"$(PKG_LOCALE_DIR)\" \ -DPACKAGE=\"$(PKG_NAME)\" -I$(TOPDIR)/include -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs@oss.sgi.com Fri Oct 7 13:34:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Oct 2005 13:34:48 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j97KYhO0012644 for ; Fri, 7 Oct 2005 13:34:44 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA24676; Sat, 8 Oct 2005 06:31:35 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j97KVkkt5487816; Sat, 8 Oct 2005 06:31:47 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j97KVjiG5542917; Sat, 8 Oct 2005 06:31:45 +1000 (EST) Date: Sat, 8 Oct 2005 06:31:45 +1000 From: Nathan Scott To: Craig Rodrigues Cc: linux-xfs@oss.sgi.com Subject: Re: xfsprogs patch 1 Message-ID: <20051008063144.B5532956@wobbly.melbourne.sgi.com> References: <20051007185443.GA57747@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: <20051007185443.GA57747@crodrigues.org>; from rodrigc@crodrigues.org on Fri, Oct 07, 2005 at 02:54:43PM -0400 X-archive-position: 6356 X-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: 605 Lines: 19 On Fri, Oct 07, 2005 at 02:54:43PM -0400, Craig Rodrigues wrote: > Hi, > > Why is -O1 hardcoded in the CFLAGS for xfsprogs? > Since there already is a variable $(OPTIMIZER), can't > we just remove it? In the FreeBSD port for xfsprogs, > I remove it, since most FreeBSD ports are compiled with a > default optimization flag (-O2). We should probably fix this up now - the reason was about 4 / 5 years ago, some old version of gcc miscompiled xfs_db at -O2 and caused segfaults. But, its likely noone is using that old a gcc anymore, so we can safely remove this hack now I think. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 7 14:30:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Oct 2005 14:30:26 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j97LUKO0016813 for ; Fri, 7 Oct 2005 14:30:21 -0700 Received: from c-66-30-112-178.hsd1.ma.comcast.net ([66.30.112.178]) by comcast.net (rwcrmhc13) with ESMTP id <2005100721272301500b7gfne>; Fri, 7 Oct 2005 21:27:23 +0000 Received: from c-66-30-112-178.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-112-178.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j97LROeY099855 for ; Fri, 7 Oct 2005 17:27:24 -0400 (EDT) (envelope-from rodrigc@c-66-30-112-178.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-112-178.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j97LRO8W099854 for linux-xfs@oss.sgi.com; Fri, 7 Oct 2005 17:27:24 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 7 Oct 2005 17:27:24 -0400 From: Craig Rodrigues To: linux-xfs@oss.sgi.com Subject: xfsprogs patch 2 Message-ID: <20051007212724.GA99806@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 6357 X-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: 3544 Lines: 127 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, For quite a while, I've been applying some hacks to the xfsprogs Makefiles to work around problems while installing on FreeBSD. This is the problem: === db === ../install-sh -o root -g root -m 755 -d /tmp/foo/bin chown: root: Invalid argument gmake[1]: *** [install] Error 1 gmake: *** [install] Error 2 *** Error code 2 Stop in /opt/home/rodrigc/fbsd/ports/sysutils/xfsprogs. *** Error code 1 Stop in /opt/home/rodrigc/fbsd/ports/sysutils/xfsprogs. The problem is this that "-g root" is invalid on FreeBSD, because "root" is not a group. The line that causes this is in buildmacros: INSTALL = $(TOPDIR)/install-sh -o $(PKG_USER) -g $(PKG_GROUP) PKG_USER and PKG_GROUP can be overridden at compile time, but default to 'root' and 'root'. Since 'root' is not a valid group on FreeBSD, this will fail. 'root' seems to be a valid group on Linux and IRIX. Inside install-sh, we have: OWNER=`id -u` GROUP=`id -g` while getopts "Dcm:d:S:o:g:T:" c $* do case $c in c) ;; g) GROUP=$OPTARG ;; o) OWNER=$OPTARG ;; So, if you don't override these values on the command-line while invoking install-sh, they default to the values of the user and group who typed 'make install'. This seems to be a reasonable convention to follow (and seems to be what other packages do). To avoid this problem on other platforms, I recommend removing PKG_USER and PKG_GROUP from the autoconf files, and just use the OWNER and GROUP of the user that typed 'make install'. -- Craig Rodrigues rodrigc@crodrigues.org --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch2.txt" Index: include/builddefs.in =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/include/builddefs.in,v retrieving revision 1.43 diff -u -r1.43 builddefs.in --- include/builddefs.in 11 Aug 2005 06:02:16 -0000 1.43 +++ include/builddefs.in 7 Oct 2005 20:42:40 -0000 @@ -56,8 +56,6 @@ exec_prefix = @exec_prefix@ PKG_NAME = @pkg_name@ -PKG_USER = @pkg_user@ -PKG_GROUP = @pkg_group@ PKG_RELEASE = @pkg_release@ PKG_VERSION = @pkg_version@ PKG_PLATFORM = @pkg_platform@ Index: include/buildmacros =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/include/buildmacros,v retrieving revision 1.13 diff -u -r1.13 buildmacros --- include/buildmacros 30 Sep 2004 14:52:19 -0000 1.13 +++ include/buildmacros 7 Oct 2005 20:42:40 -0000 @@ -54,7 +54,7 @@ $(LFILES:.l=.o) \ $(YFILES:%.y=%.tab.o) -INSTALL = $(TOPDIR)/install-sh -o $(PKG_USER) -g $(PKG_GROUP) +INSTALL = $(TOPDIR)/install-sh SHELL = /bin/sh IMAGES_DIR = $(TOPDIR)/all-images Index: m4/package_globals.m4 =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/m4/package_globals.m4,v retrieving revision 1.2 diff -u -r1.2 package_globals.m4 --- m4/package_globals.m4 14 May 2003 06:56:59 -0000 1.2 +++ m4/package_globals.m4 7 Oct 2005 20:42:40 -0000 @@ -27,14 +27,6 @@ malloc_lib="$MALLOCLIB" AC_SUBST(malloc_lib) - PKG_USER=${INSTALL_USER:-'root'} - pkg_user="$PKG_USER" - AC_SUBST(pkg_user) - - PKG_GROUP=${INSTALL_GROUP:-'root'} - pkg_group="$PKG_GROUP" - AC_SUBST(pkg_group) - pkg_distribution=`uname -s` test -z "$DISTRIBUTION" || pkg_distribution="$DISTRIBUTION" AC_SUBST(pkg_distribution) --KsGdsel6WgEHnImy-- From owner-linux-xfs@oss.sgi.com Fri Oct 7 14:45:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Oct 2005 14:45:24 -0700 (PDT) Received: from edtnas67.telus.net (edtnas67.telus.net [204.209.193.89]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j97LjGO0018048 for ; Fri, 7 Oct 2005 14:45:16 -0700 Received: from edtnas67.telus.net ([204.209.193.89]) by edtnas67.telus.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50) id 1ENzyt-00074x-An for linux-xfs@oss.sgi.com; Fri, 07 Oct 2005 15:42:19 -0600 Date: Fri, 7 Oct 2005 15:42:19 -0600 (MDT) From: "Aly S.P Dharshi" X-X-Sender: dharshi@edtnas67.telus.net To: linux-xfs@oss.sgi.com Subject: Linux XFS roadmap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aly.dharshi@telus.net Precedence: bulk X-list: linux-xfs Content-Length: 317 Lines: 17 Hello All, Is there a document, or page on the oss.sgi.com site where there is a listing about the road map for XFS ? Thanks. Cheers, Aly. -- Aly S.P Dharshi aly.dharshi@telus.net "A good speech is like a good dress that's short enough to be interesting and long enough to cover the subject" From owner-linux-xfs@oss.sgi.com Fri Oct 7 16:57:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Oct 2005 16:57:54 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j97NvmO0029877 for ; Fri, 7 Oct 2005 16:57:49 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA28133; Sat, 8 Oct 2005 09:54:44 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j97Nstkt5547145; Sat, 8 Oct 2005 09:54:56 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j97NsraE5541209; Sat, 8 Oct 2005 09:54:53 +1000 (EST) Date: Sat, 8 Oct 2005 09:54:52 +1000 From: Nathan Scott To: Craig Rodrigues Cc: linux-xfs@oss.sgi.com Subject: Re: xfsprogs patch 2 Message-ID: <20051008095452.A5545991@wobbly.melbourne.sgi.com> References: <20051007212724.GA99806@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: <20051007212724.GA99806@crodrigues.org>; from rodrigc@crodrigues.org on Fri, Oct 07, 2005 at 05:27:24PM -0400 X-archive-position: 6359 X-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: 1177 Lines: 40 On Fri, Oct 07, 2005 at 05:27:24PM -0400, Craig Rodrigues wrote: > ... > group on Linux and IRIX. Inside install-sh, we have: > > OWNER=`id -u` > GROUP=`id -g` > ... > So, if you don't override these values on the command-line while > invoking install-sh, they default to the values of the > user and group who typed 'make install'. This seems to be a reasonable > convention to follow (and seems to be what other packages do). > To avoid this problem on other platforms, I recommend removing > PKG_USER and PKG_GROUP from the autoconf files, and just > use the OWNER and GROUP of the user that typed 'make install'. Well, someone might be relying on this now - why not just fix: > Index: m4/package_globals.m4 > > - PKG_USER=${INSTALL_USER:-'root'} > - pkg_user="$PKG_USER" > - AC_SUBST(pkg_user) > - > - PKG_GROUP=${INSTALL_GROUP:-'root'} > - pkg_group="$PKG_GROUP" > - AC_SUBST(pkg_group) > - > pkg_distribution=`uname -s` > test -z "$DISTRIBUTION" || pkg_distribution="$DISTRIBUTION" > AC_SUBST(pkg_distribution) ...the first two there to use 'id -u' and 'id -g'? (like the third chunk does for 'uname -s'). thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 7 17:06:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Oct 2005 17:07:01 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.76.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9806uO0030730 for ; Fri, 7 Oct 2005 17:06:57 -0700 Received: from c-66-30-112-178.hsd1.ma.comcast.net ([66.30.112.178]) by comcast.net (sccrmhc13) with ESMTP id <2005100800035901300ba25ge>; Sat, 8 Oct 2005 00:03:59 +0000 Received: from c-66-30-112-178.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-112-178.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j980418s080068 for ; Fri, 7 Oct 2005 20:04:01 -0400 (EDT) (envelope-from rodrigc@c-66-30-112-178.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-112-178.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j98040iv080063 for linux-xfs@oss.sgi.com; Fri, 7 Oct 2005 20:04:00 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 7 Oct 2005 20:03:59 -0400 From: Craig Rodrigues To: linux-xfs@oss.sgi.com Subject: Re: xfsprogs patch 2 Message-ID: <20051008000359.GA76564@crodrigues.org> References: <20051007212724.GA99806@crodrigues.org> <20051008095452.A5545991@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051008095452.A5545991@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 6360 X-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: 725 Lines: 21 On Sat, Oct 08, 2005 at 09:54:52AM +1000, Nathan Scott wrote: > > To avoid this problem on other platforms, I recommend removing > > PKG_USER and PKG_GROUP from the autoconf files, and just > > use the OWNER and GROUP of the user that typed 'make install'. > > Well, someone might be relying on this now - why not just fix: That may be a possibility, but realistically, I doubt it.....I think most people just type "configure; make install" and rely on the defaults which work on Linux and IRIX. But, I've been wrong before about these things. > ...the first two there to use 'id -u' and 'id -g'? (like the > third chunk does for 'uname -s'). That would work for me. -- Craig Rodrigues rodrigc@crodrigues.org From owner-linux-xfs@oss.sgi.com Fri Oct 7 17:57:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Oct 2005 17:57:31 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j980vNO0001576 for ; Fri, 7 Oct 2005 17:57:25 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA29127 for ; Sat, 8 Oct 2005 10:54:24 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4BC2E49E5F2C; Sat, 8 Oct 2005 10:54:23 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfsprogs Message-Id: <20051008005423.4BC2E49E5F2C@chook.melbourne.sgi.com> Date: Sat, 8 Oct 2005 10:54:23 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6361 X-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: 4646 Lines: 96 Merge back some kernel changes to fix warnings from gcc. Date: Sat Oct 8 10:45:03 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24038a xfsprogs/include/xfs_da_btree.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_da_btree.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/include/libxfs.h - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h xfsprogs/libxfs/xfs_da_btree.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_da_btree.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h Fix read/write calls in xfs_io to allow buffers larger than 4GiB on 64 bit platforms. Date: Sat Oct 8 10:47:20 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24039a xfsprogs/io/pread.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/pread.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsprogs/io/truncate.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/truncate.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/io/pwrite.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/pwrite.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/io/prealloc.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/prealloc.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/io/init.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/init.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/io/init.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/init.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/io/fadvise.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/fadvise.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfsprogs/io/io.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/io.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/io/mmap.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/mmap.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/io/sendfile.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/sendfile.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfsprogs/io/madvise.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/madvise.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfsprogs/io/mincore.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/mincore.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfsprogs/libxcmd/input.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxinput.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfsprogs/include/input.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/input.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Merge in minor build tweaks for the FreeBSD porters. Date: Sat Oct 8 10:49:10 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: rodrigc@crodrigues.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24040a xfsprogs/include/builddefs.in - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/builddefs.in.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h xfsprogs/m4/package_globals.m4 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/m4/package_globals.m4.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Bump xfsprogs version number for recent changes. Date: Sat Oct 8 10:52:24 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24041a xfsprogs/VERSION - 1.136 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.136&r2=text&tr2=1.135&f=h xfsprogs/doc/CHANGES - 1.180 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.180&r2=text&tr2=1.179&f=h xfsprogs/debian/changelog - 1.122 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.122&r2=text&tr2=1.121&f=h From owner-linux-xfs@oss.sgi.com Sat Oct 8 00:01:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 Oct 2005 00:02:04 -0700 (PDT) Received: from limso.net ([60.177.60.155]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9871bO0031479; Sat, 8 Oct 2005 00:01:47 -0700 Message-ID: <15DD8255.BF8400F@limso.net> Date: Sat, 08 Oct 2005 17:54:34 +1000 Reply-To: "quinn utley" From: "quinn utley" User-Agent: AspMail 2.31 MIME-Version: 1.0 To: "Wilford Loeppke" Cc: , , , Subject: ashy Lunacy to goes by this. dart Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 6363 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tomazjam@limso.net Precedence: bulk X-list: linux-xfs Content-Length: 1250 Lines: 28 Mediicine that is approved by FDA. We retail effective caapsule for any depressions. Send off to you normally in 40hrs. Our therapeutics are discounted. Our professional at zero cost examines your medicall info. It's proper, reliable & clandestine on-line source. Jen A --WV. http://uk.geocities.com/starsolemnitygreatb/?xnlidkxgomy She stopped to tell us in a whisper as we were going down that the whole house was filled with strange lumber which her landlord had bought piecemeal and had no wish to sell, in consequence of being a little M. This was on the first floor. But she had made a previous stoppage on the second floor and had silently pointed at a dark door there. eserb fbcpu bwy HZ03 etruth fbprintenv Alexander went over and opened the window for her. "Aren't you afraid to let the wind low like that on your neck? Can't I get a scarf or something?" "Ask a theatre lady if she's afraid of drafts." Hilda laughed. "But perhaps, as I'm so warm-- give me your handkerchief. There, just in front." He slipped the corners carefully under her shoulder-straps. "There, that will do. It looks like a bib." She pushed his hand away quickly and stood looking out into the deserted square. "Isn't London a tomb on Sunday night?" From owner-linux-xfs@oss.sgi.com Sun Oct 9 21:36:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Oct 2005 21:36:17 -0700 (PDT) Received: from prnet.org (pppoe240-static-luxdsl-128.pt.lu [213.135.240.128]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9A4aBO0006067 for ; Sun, 9 Oct 2005 21:36:13 -0700 Received: from [127.0.0.1] (win.intern.prnet.org [192.168.1.2]) (authenticated bits=0) by prnet.org (8.13.1/8.13.1) with ESMTP id j9A4XAUs021740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Oct 2005 06:33:10 +0200 Message-ID: <4349EF00.5070306@prnet.org> Date: Mon, 10 Oct 2005 06:33:04 +0200 From: David Arendt User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Crossmeta: XFS for Windows Link request Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6365 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: admin@prnet.org Precedence: bulk X-list: linux-xfs Content-Length: 380 Lines: 7 Well, it's the first time I am hearing about crossmeta and I would be interested in hearing from people using it. I would in particular be interesed in knowing: used memory when using xfs filesystem and nfs client, performance using xfs in comparision with ntfs performance, performance using nfs client in comparision with sharing the drive using samba (windows as client) From owner-linux-xfs@oss.sgi.com Sun Oct 9 21:38:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Oct 2005 21:38:39 -0700 (PDT) Received: from web34602.mail.mud.yahoo.com (web34602.mail.mud.yahoo.com [209.191.68.136]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9A4cXO0006377 for ; Sun, 9 Oct 2005 21:38:33 -0700 Received: (qmail 27686 invoked by uid 60001); 10 Oct 2005 04:35:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=w7PfUay5vXTi47SqU/GrzbOvWi2Hcz3Mk2DzcD6XvWP8s+6ULOUtxy37POABerkFviQt1xDY4DXiFQnAtEpUh32w1w9ogf3790Bhl8BWNLn6lUm5drsJQqviPz0QO3PBlp6YRnGF97yShNH//ufCWPemrLxZOYd8cfMcoqG7NfY= ; Message-ID: <20051010043535.27684.qmail@web34602.mail.mud.yahoo.com> Received: from [24.99.63.238] by web34602.mail.mud.yahoo.com via HTTP; Sun, 09 Oct 2005 21:35:34 PDT Date: Sun, 9 Oct 2005 21:35:34 -0700 (PDT) From: Linux Tard Subject: Xfs file system meta information To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 6366 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linuxtard@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 547 Lines: 19 I'm new to studying XFS file system type. I'm looking to dump meta info for file system (including label, UUID, create date, last mount date, last write date, size of file system, etc.). I haven't found a way to do this using an XFS tool. I see xfs_admin can print label and UUID. But is there a tool to obtain the creation date, last mount date, last write date, size of FS, etc.? kind regards, -lt __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From owner-linux-xfs@oss.sgi.com Sun Oct 9 23:53:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Oct 2005 23:53:36 -0700 (PDT) Received: from smtp.pzkagis.cz (gis6.netbox.cz [83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9A6rVO0017782 for ; Sun, 9 Oct 2005 23:53:32 -0700 Received: (from luf@localhost) by smtp.pzkagis.cz (8.11.6/8.11.6) id j9A6oNN31223; Mon, 10 Oct 2005 08:50:24 +0200 Date: Mon, 10 Oct 2005 08:50:23 +0200 From: Ludek Finstrle To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr Message-ID: <20051010065023.GA30979@soptik.pzkagis.cz> References: <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> <434174A7.6010904@sgi.com> <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com> <4341E780.70803@sgi.com> <20051004190338.GA15263@soptik.pzkagis.cz> <4342D9F6.8090605@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4342D9F6.8090605@sgi.com> User-Agent: Mutt/1.4i X-archive-position: 6368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ludek.finstrle@pzkagis.cz Precedence: bulk X-list: linux-xfs Content-Length: 340 Lines: 11 > >I'm sorry, I don't have enough time till Friday. Then I'll try to play > >with the problem. > > Thanks, I appreciate it... we're trying to reproduce it here. I'm sorry my wife is pregnant and had some problems during weekend. So I didn't try anything. I play with the problem as soon as possible but I don't know time right now. Luf From owner-linux-xfs@oss.sgi.com Mon Oct 10 07:07:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Oct 2005 07:07:19 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9AE7DO0013426 for ; Mon, 10 Oct 2005 07:07:13 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9AF9HJO014036 for ; Mon, 10 Oct 2005 08:09:17 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j9AE3DsS94769189; Mon, 10 Oct 2005 07:03:13 -0700 (PDT) Message-ID: <434A74AC.5060603@sgi.com> Date: Mon, 10 Oct 2005 09:03:24 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux Tard CC: linux-xfs@oss.sgi.com Subject: Re: Xfs file system meta information References: <20051010043535.27684.qmail@web34602.mail.mud.yahoo.com> In-Reply-To: <20051010043535.27684.qmail@web34602.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 849 Lines: 28 Linux Tard wrote: > I'm new to studying XFS file system type. I'm looking > to dump meta info for file system (including label, > UUID, create date, last mount date, last write date, > size of file system, etc.). I haven't found a way to > do this using an XFS tool. I see xfs_admin can print > label and UUID. But is there a tool to obtain the > creation date, last mount date, last write date, size > of FS, etc.? > > kind regards, > -lt Some of the metadata you request is not stored on the filesystem itself (create date, mount date, etc) - although I've always thought that would be a good idea, it's just never been done. But you can use the xfs_db tool to explore all of the information that -is- on disk. For starters: xfs_db -r /dev/device xfs_db> sb 0 xfs_db> p will show you all the fields in the primary superblock. -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 10 07:15:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Oct 2005 07:15:07 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9AEF0O0014248 for ; Mon, 10 Oct 2005 07:15:00 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9AEC1xT002546 for ; Mon, 10 Oct 2005 09:12:01 -0500 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j9AEC0sS94820154; Mon, 10 Oct 2005 07:12:00 -0700 (PDT) Message-ID: <434A76BB.8080400@sgi.com> Date: Mon, 10 Oct 2005 09:12:11 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludek Finstrle CC: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr References: <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> <434174A7.6010904@sgi.com> <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com> <4341E780.70803@sgi.com> <20051004190338.GA15263@soptik.pzkagis.cz> <4342D9F6.8090605@sgi.com> <20051010065023.GA30979@soptik.pzkagis.cz> In-Reply-To: <20051010065023.GA30979@soptik.pzkagis.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 465 Lines: 18 Ludek Finstrle wrote: >>>I'm sorry, I don't have enough time till Friday. Then I'll try to play >>>with the problem. >> >>Thanks, I appreciate it... we're trying to reproduce it here. > > > I'm sorry my wife is pregnant and had some problems during weekend. > So I didn't try anything. I play with the problem as soon as possible > but I don't know time right now. > > Luf We've been able to exactly reproduce this in-house now. Thanks for your help! -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 10 14:26:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Oct 2005 14:27:04 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9ALQuO0019845 for ; Mon, 10 Oct 2005 14:26:57 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA27606 for ; Tue, 11 Oct 2005 07:23:56 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 5E29249E5F2C; Tue, 11 Oct 2005 07:23:55 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - French attr translation Message-Id: <20051010212355.5E29249E5F2C@chook.melbourne.sgi.com> Date: Tue, 11 Oct 2005 07:23:55 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6371 X-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: 1011 Lines: 23 Merge in French translation from debian translation team (thanks to Guilhelm Panaget). Date: Tue Oct 11 07:23:06 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: guilhelm.panaget@free.fr The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24054a attr/po/fr.po - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/po/fr.po attr/VERSION - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/VERSION.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h attr/doc/CHANGES - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h attr/debian/changelog - 1.56 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/debian/changelog.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h attr/po/Makefile - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/po/Makefile.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h From owner-linux-xfs@oss.sgi.com Tue Oct 11 00:15:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Oct 2005 00:15:14 -0700 (PDT) Received: from smtp.pzkagis.cz (gis6.netbox.cz [83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9B7F4O0007681 for ; Tue, 11 Oct 2005 00:15:07 -0700 Received: (from luf@localhost) by smtp.pzkagis.cz (8.11.6/8.11.6) id j9B7Brg08241; Tue, 11 Oct 2005 09:11:53 +0200 Date: Tue, 11 Oct 2005 09:11:53 +0200 From: Ludek Finstrle To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr Message-ID: <20051011071153.GA7530@soptik.pzkagis.cz> References: <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> <434174A7.6010904@sgi.com> <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com> <4341E780.70803@sgi.com> <20051004190338.GA15263@soptik.pzkagis.cz> <4342D9F6.8090605@sgi.com> <20051010065023.GA30979@soptik.pzkagis.cz> <434A76BB.8080400@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <434A76BB.8080400@sgi.com> User-Agent: Mutt/1.4i X-archive-position: 6372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ludek.finstrle@pzkagis.cz Precedence: bulk X-list: linux-xfs Content-Length: 465 Lines: 18 > >>Thanks, I appreciate it... we're trying to reproduce it here. > > We've been able to exactly reproduce this in-house now. Thanks for your > help! It's nice to hear this. May I try something here or it's useless? I find the way to play with it in work time ... So I can react more quickly. My wife is ok but fourteen days before launch space shuttle (baby born date) ... Thanks Luf P.S. If I can help (e.g. test, debug output, ...) just drop me a note. From owner-linux-xfs@oss.sgi.com Tue Oct 11 07:33:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Oct 2005 07:33:58 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9BEXoO0022864 for ; Tue, 11 Oct 2005 07:33:50 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9BEUoxT026741 for ; Tue, 11 Oct 2005 09:30:50 -0500 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id j9BEUmsS94998015; Tue, 11 Oct 2005 07:30:49 -0700 (PDT) Message-ID: <434BCCA7.9040903@sgi.com> Date: Tue, 11 Oct 2005 09:31:03 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludek Finstrle CC: linux-xfs@oss.sgi.com Subject: Re: ls -l versus du -sk after xfs_fsr References: <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> <434174A7.6010904@sgi.com> <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com> <4341E780.70803@sgi.com> <20051004190338.GA15263@soptik.pzkagis.cz> <4342D9F6.8090605@sgi.com> <20051010065023.GA30979@soptik.pzkagis.cz> <434A76BB.8080400@sgi.com> <20051011071153.GA7530@soptik.pzkagis.cz> In-Reply-To: <20051011071153.GA7530@soptik.pzkagis.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6373 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 375 Lines: 18 Ludek Finstrle wrote: > It's nice to hear this. May I try something here or it's useless? > I find the way to play with it in work time ... So I can react > more quickly. I think the problem is well in hand here, look for a fix soon... > My wife is ok but fourteen days before launch space shuttle > (baby born date) ... Good luck with that! :) -Eric > Thanks > > Luf From owner-linux-xfs@oss.sgi.com Wed Oct 12 07:01:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Oct 2005 07:01:24 -0700 (PDT) Received: from trotzky.fisica.unipd.it ([147.162.55.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9CE1EO0027981 for ; Wed, 12 Oct 2005 07:01:18 -0700 Received: from gauss.fisica.unipd.it (gauss.fisica.unipd.it [192.168.1.24]) by trotzky.fisica.unipd.it (8.11.6/8.9.3) with ESMTP id j9CDw0m20389 for ; Wed, 12 Oct 2005 15:58:04 +0200 Received: from gauss.fisica.unipd.it (localhost.localdomain [127.0.0.1]) by gauss.fisica.unipd.it (8.12.11/8.12.11) with ESMTP id j9CDvxVi010360 for ; Wed, 12 Oct 2005 15:58:00 +0200 Received: (from argentie@localhost) by gauss.fisica.unipd.it (8.12.11/8.12.11/Submit) id j9CDvxtN010358 for linux-xfs@oss.sgi.com; Wed, 12 Oct 2005 15:57:59 +0200 Date: Wed, 12 Oct 2005 15:57:59 +0200 From: Giuseppe Argentieri To: linux-xfs@oss.sgi.com Subject: Trying to recover data from an XFS partition Message-ID: <20051012135759.GA9164@gauss.fisica.unipd.it> Reply-To: Giuseppe Argentieri Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: Linux gauss.fisica.unipd.it 2.4.21-15.0.2.EL X-archive-position: 6375 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: giuseppe.argentieri@spiro.fisica.unipd.it Precedence: bulk X-list: linux-xfs Content-Length: 2879 Lines: 67 Hi, Some days ago my hard disk started to show a sector failure in /dev/hda7, which is the only XFS partion: # mount /mnt/space Oct 11 23:34:30 freedom kernel: [4298615.381000] XFS mounting filesystem hda7 Oct 11 23:34:35 freedom kernel: [4298619.894000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Oct 11 23:34:35 freedom kernel: [4298619.894000] hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=45035525, sector=45035525 Oct 11 23:34:35 freedom kernel: [4298619.894000] ide: failed opcode was: unknown Oct 11 23:34:35 freedom kernel: [4298619.894000] end_request: I/O error, dev hda, sector 45035525 Oct 11 23:34:35 freedom kernel: [4298619.896000] I/O error in filesystem ("hda7") meta-data dev hda7 block 0x7775ba ("xlog_bread") error 5 buf count 512 Oct 11 23:34:35 freedom kernel: [4298619.896000] XFS: failed to find log head Oct 11 23:34:35 freedom kernel: [4298619.896000] XFS: log mount/recovery failed: error 5 Oct 11 23:34:35 freedom kernel: [4298619.896000] XFS: log mount failed mount: /dev/hda7: can't read superblock I wish I could access my data before the whole disk fails. I don't know why there is a superblock error, since sector 45035525 is not the first in /dev/hda7 Here's the output of # fdisk -lu /dev/hda Disk /dev/hda: 40.0 GB, 40007761920 bytes 255 heads, 63 sectors/track, 4864 cylinders, total 78140160 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 63 10410119 5205028+ a6 OpenBSD /dev/hda2 10410120 24740099 7164990 a5 FreeBSD /dev/hda3 24740100 36451484 5855692+ a5 FreeBSD /dev/hda4 36451485 78140159 20844337+ 5 Extended /dev/hda5 36451548 36949499 248976 82 Linux swap /dev/hda6 36949563 37206539 128488+ 83 Linux /dev/hda7 37206603 52837784 7815591 83 Linux /dev/hda8 * 52837848 53223344 192748+ 83 Linux /dev/hda9 53223408 54203309 489951 83 Linux /dev/hda10 54203373 57127139 1461883+ 83 Linux /dev/hda11 57127203 64934729 3903763+ 83 Linux /dev/hda12 64934793 65673719 369463+ 83 Linux /dev/hda13 * 65673783 66059279 192748+ 83 Linux /dev/hda14 66059343 71923004 2931831 83 Linux /dev/hda15 71923068 76613984 2345458+ 83 Linux /dev/hda16 76614048 77593949 489951 83 Linux /dev/hda17 77594013 78140159 273073+ 83 Linux It's a laptop and yes, there are five different OS on it, but I hope that someone would give me some help even if this is not a production server. xfs_ncheck lists all inodes and file paths, so I think they're still safe. Would anybody tell me some hints? P.S.: Sorry for my terrible English -- Giuseppe Argentieri From owner-linux-xfs@oss.sgi.com Wed Oct 12 09:32:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Oct 2005 09:32:04 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9CGW1O0013742 for ; Wed, 12 Oct 2005 09:32:01 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9CGT1xT017891 for ; Wed, 12 Oct 2005 11:29:01 -0500 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9CGSxsL23365531; Wed, 12 Oct 2005 11:29:00 -0500 (CDT) Message-ID: <434D39CA.3000408@sgi.com> Date: Wed, 12 Oct 2005 11:28:58 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giuseppe Argentieri CC: linux-xfs@oss.sgi.com Subject: Re: Trying to recover data from an XFS partition References: <20051012135759.GA9164@gauss.fisica.unipd.it> In-Reply-To: <20051012135759.GA9164@gauss.fisica.unipd.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1656 Lines: 33 Giuseppe Argentieri wrote: > Hi, > > Some days ago my hard disk started to show a sector failure in > /dev/hda7, which is the only XFS partion: > > # mount /mnt/space > > Oct 11 23:34:30 freedom kernel: [4298615.381000] XFS mounting filesystem hda7 > Oct 11 23:34:35 freedom kernel: [4298619.894000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } > Oct 11 23:34:35 freedom kernel: [4298619.894000] hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=45035525, sector=45035525 > Oct 11 23:34:35 freedom kernel: [4298619.894000] ide: failed opcode was: unknown > Oct 11 23:34:35 freedom kernel: [4298619.894000] end_request: I/O error, dev hda, sector 45035525 > Oct 11 23:34:35 freedom kernel: [4298619.896000] I/O error in filesystem ("hda7") meta-data dev hda7 block 0x7775ba ("xlog_bread") error 5 buf count 512 > Oct 11 23:34:35 freedom kernel: [4298619.896000] XFS: failed to find log head > Oct 11 23:34:35 freedom kernel: [4298619.896000] XFS: log mount/recovery failed: error 5 > Oct 11 23:34:35 freedom kernel: [4298619.896000] XFS: log mount failed > mount: /dev/hda7: can't read superblock > > > I wish I could access my data before the whole disk fails. > I don't know why there is a superblock error, since sector 45035525 is > not the first in /dev/hda7 I think that "superblock" error is a generic one. the kernel logs tell you what is really going on - xfs cannot read the log due to disk errors. Try mount -o ro,norecovery and copy off what you can... you may hit problems as you copy, though, because if you didn't do a clean unmount then your filesystem will be inconsistent w/o log recovery. -Eric From owner-linux-xfs@oss.sgi.com Thu Oct 13 11:08:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Oct 2005 11:08:11 -0700 (PDT) Received: from mail.nccs.nasa.gov (mail.nccs.nasa.gov [128.183.39.39]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9DI88O0024523 for ; Thu, 13 Oct 2005 11:08:08 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.nccs.nasa.gov (Postfix) with ESMTP id 5FA1583B9; Thu, 13 Oct 2005 14:05:06 -0400 (EDT) Received: from mail.nccs.nasa.gov ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11509-03; Thu, 13 Oct 2005 14:05:06 -0400 (EDT) Received: from nccs.gsfc.nasa.gov (zot.gsfc.nasa.gov [128.183.33.137]) by mail.nccs.nasa.gov (Postfix) with ESMTP id E538F838D; Thu, 13 Oct 2005 14:05:05 -0400 (EDT) Message-ID: <434EA1D1.7010805@nccs.gsfc.nasa.gov> Date: Thu, 13 Oct 2005 14:05:05 -0400 From: Matthew Whitehead User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040530 Debian/1.6-6.backports.org.1 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: "'Kent Kamischke'" , Pamela Kennedy Subject: Extended Attributes Question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6379 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mrw@nccs.gsfc.nasa.gov Precedence: bulk X-list: linux-xfs Content-Length: 702 Lines: 20 Dear SGI, I'm at sysadmin at NASA Goddard Space Flight Center. Our sister site is NASA Ames (Columbia). I have an enhancement idea I wanted to bounce off you. For XFS filesystem extended attributes, I'd like a way to automatically set these attributes. Counting on users to do it themselves just doesn't work. Could you modify the code of sys_creat/sys_open in fs/open.c to check for the existence of environment variables and set the attribute/value pairs automatically? Say, an environment variable with the prefix FILE_XATTR_* ? Also, system wide defaults set in an /etc file would also be nice. Storing the name of the binary running that creates the file would be good. - Matthew From owner-linux-xfs@oss.sgi.com Thu Oct 13 11:43:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Oct 2005 11:43:05 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9DIgvO0028417 for ; Thu, 13 Oct 2005 11:43:00 -0700 Received: from g0f19.g.pppool.de ([80.185.15.25] helo=mail.housecafe.de) by mail.g-house.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EQ81E-00023X-V9; Thu, 13 Oct 2005 20:41:38 +0200 Received: from prinz64.housecafe.de ([192.168.10.11] helo=[127.0.0.1]) by mail.housecafe.de with esmtp (Exim 4.54) id 1EQ7z9-0000ci-VJ; Thu, 13 Oct 2005 20:39:24 +0200 Message-ID: <434EA9DE.5070204@gmx.net> Date: Thu, 13 Oct 2005 20:39:26 +0200 From: "evilninja@gmx.net" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Whitehead CC: linux-xfs@oss.sgi.com, "'Kent Kamischke'" , Pamela Kennedy Subject: Re: Extended Attributes Question References: <434EA1D1.7010805@nccs.gsfc.nasa.gov> In-Reply-To: <434EA1D1.7010805@nccs.gsfc.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0539-6, 02.10.2005), Outbound message X-Antivirus-Status: Clean X-archive-position: 6380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 494 Lines: 17 Matthew Whitehead wrote: > > Could you modify the code of sys_creat/sys_open in fs/open.c to check > for the existence of environment variables and set the attribute/value > pairs automatically? Say, an environment variable with the prefix > FILE_XATTR_* ? Um, can't this be done entirely in userspace? The kernel should not be influnced by environment variables, IMHO. But perhaps I did not understand what you really meant.... Christian. -- BOFH excuse #384: it's an ID-10-T error From owner-linux-xfs@oss.sgi.com Thu Oct 13 19:28:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Oct 2005 19:28:16 -0700 (PDT) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9E2SBO0001682 for ; Thu, 13 Oct 2005 19:28:11 -0700 Received: from saturn (c211-28-165-30.eburwd2.vic.optusnet.com.au [211.28.165.30]) by mail13.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9E2Ox6V018283; Fri, 14 Oct 2005 12:25:00 +1000 Received: from [192.168.1.65] (helo=localhost.localdomain) by saturn with esmtp (Exim 3.36 #1 (Debian)) id 1EQFFj-0002uR-00; Fri, 14 Oct 2005 12:24:59 +1000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 1296C1414827; Fri, 14 Oct 2005 12:25:11 +1000 (EST) Subject: Re: Extended Attributes Question From: Stewart Smith To: "evilninja@gmx.net" Cc: Matthew Whitehead , linux-xfs@oss.sgi.com, "'Kent Kamischke'" , Pamela Kennedy In-Reply-To: <434EA9DE.5070204@gmx.net> References: <434EA1D1.7010805@nccs.gsfc.nasa.gov> <434EA9DE.5070204@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vluujpxr9/AES/oducQA" Date: Fri, 14 Oct 2005 12:25:10 +1000 Message-Id: <1129256710.9794.53.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-archive-position: 6381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: linux-xfs Content-Length: 1226 Lines: 40 --=-vluujpxr9/AES/oducQA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-10-13 at 20:39 +0200, evilninja@gmx.net wrote: > Matthew Whitehead wrote: > >=20 > > Could you modify the code of sys_creat/sys_open in fs/open.c to check= =20 > > for the existence of environment variables and set the attribute/value= =20 > > pairs automatically? Say, an environment variable with the prefix=20 > > FILE_XATTR_* ? >=20 > Um, can't this be done entirely in userspace? The kernel should not be=20 > influnced by environment variables, IMHO. But perhaps I did not=20 > understand what you really meant.... Yes - an LD_PRELOAD could do this. --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-vluujpxr9/AES/oducQA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQCVAwUAQ08XBowDm44RooHBAQKVQwP/SAHRCjSVAPrUFlOEwRQk1oj/Yea7DhNH CLfGZ4wVkj4aYWfl2IsWFZkyrDYUFHE3iJYL2VT0uD28KJhp4KUndeKqBxkSqM4G a5uytlmZl2jrLzRmSkXRLtwXP/8iAa47nguRmGJh5oTBZqZAnW8LmQ57H9hioqNu PwUNK/i/HhU= =XpxL -----END PGP SIGNATURE----- --=-vluujpxr9/AES/oducQA-- From owner-linux-xfs@oss.sgi.com Fri Oct 14 10:51:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Oct 2005 10:52:04 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9EHpwO0026418 for ; Fri, 14 Oct 2005 10:51:58 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9EIsaLF027090 for ; Fri, 14 Oct 2005 11:54:36 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9EHlsDN17733546; Fri, 14 Oct 2005 12:47:55 -0500 (CDT) Message-ID: <434FEF4A.4030409@sgi.com> Date: Fri, 14 Oct 2005 12:47:54 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stewart Smith CC: "evilninja@gmx.net" , Matthew Whitehead , linux-xfs@oss.sgi.com, "'Kent Kamischke'" , Pamela Kennedy Subject: Re: Extended Attributes Question References: <434EA1D1.7010805@nccs.gsfc.nasa.gov> <434EA9DE.5070204@gmx.net> <1129256710.9794.53.camel@localhost.localdomain> In-Reply-To: <1129256710.9794.53.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6382 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 735 Lines: 22 Stewart Smith wrote: > On Thu, 2005-10-13 at 20:39 +0200, evilninja@gmx.net wrote: > >>Matthew Whitehead wrote: >> >>>Could you modify the code of sys_creat/sys_open in fs/open.c to check >>>for the existence of environment variables and set the attribute/value >>>pairs automatically? Say, an environment variable with the prefix >>>FILE_XATTR_* ? >> >>Um, can't this be done entirely in userspace? The kernel should not be >>influnced by environment variables, IMHO. But perhaps I did not >>understand what you really meant.... > > > Yes - an LD_PRELOAD could do this. Yep, I was going to suggest the same. The kernel really has no business interpreting environment variables, or setting any policies like this... -Eric From owner-linux-xfs@oss.sgi.com Sat Oct 15 21:51:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Oct 2005 21:51:09 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9G4p4O0021430 for ; Sat, 15 Oct 2005 21:51:05 -0700 Received: from [10.0.0.1] (adsl-71-131-96-24.dsl.sntc01.pacbell.net [71.131.96.24]) (authenticated bits=0) by mail.linux-sxs.org (8.13.4/8.13.4/Debian-3) with ESMTP id j9G3lxXw011552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 15 Oct 2005 22:48:06 -0500 Message-ID: <4351DB79.6050109@linux-sxs.org> Date: Sat, 15 Oct 2005 21:47:53 -0700 From: "Net Llama!" Organization: HAL V User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: stack size usage Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: milter-sender/0.62.837 (mail.linux-sxs.org [64.116.183.6]); Sat, 15 Oct 2005 22:48:06 -0500 Received-SPF: pass (mail.linux-sxs.org: authenticated connection) receiver=mail.linux-sxs.org; client-ip=71.131.96.24; helo=[10.0.0.1]; envelope-from=netllama@linux-sxs.org; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; X-archive-position: 6384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 539 Lines: 13 This is semi-off topic. I was wondering if there was a way of determining how much stack space was in use at any given time? My motivation is just to monitor kernel stack usage in an effort to avoid or at least anticipate the infamous 4k stack issues that plague RH/FC distros. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org 21:45:01 up 62 days, 7:42, 1 user, load average: 0.64, 0.46, 0.42 From owner-linux-xfs@oss.sgi.com Mon Oct 17 04:32:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Oct 2005 04:32:37 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9HBWQO0005961 for ; Mon, 17 Oct 2005 04:32:26 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9HCZRTY018516 for ; Mon, 17 Oct 2005 05:35:27 -0700 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9HBVQAQ63670800; Mon, 17 Oct 2005 04:31:27 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j9HBSMRU031213; Mon, 17 Oct 2005 06:28:22 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j9HBSLbW031212; Mon, 17 Oct 2005 06:28:21 -0500 Date: Mon, 17 Oct 2005 06:28:21 -0500 From: Christoph Hellwig Message-Id: <200510171128.j9HBSLbW031212@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 908809 - Simplify pagebuf_rele X-archive-position: 6388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 488 Lines: 16 Remove a conditional that can not be true anymore and simplify the final put path a little Date: Mon Oct 17 04:28:10 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: dgc The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:200790a fs/xfs/linux-2.6/xfs_buf.c - 1.210 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.210&r2=text&tr2=1.209&f=h From owner-linux-xfs@oss.sgi.com Mon Oct 17 17:49:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Oct 2005 17:49:53 -0700 (PDT) Received: from american.megatrends.com (american.megatrends.com [155.229.80.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9I0nmO0017315 for ; Mon, 17 Oct 2005 17:49:50 -0700 Received: by american.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Oct 2005 20:46:44 -0400 Message-ID: <3225AF1B8CBF83459982D4987F1549CE055EE3@fre-ops.us.megatrends.com> From: Srikumar Subramanian To: linux-xfs@oss.sgi.com Cc: Srikumar Subramanian , Prabhakar Krishnan Subject: kernel panic with ACL Date: Mon, 17 Oct 2005 20:49:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 6389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: SrikumarS@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 839 Lines: 36 Hi All, I am using FC3: kernel 2.6.9-1.667smp I create a base directory (base/) with 10 access ACL and 10 default ACL. The file system size is 2 GB. Under base/, i have create lot of subdir, sub-subdirs, and files (each 1KB size). The idea is to test the stability of XFS with ACL. During the test, there is no problem in inheriting acl from parent directory. But when the XFS file system goes out of space, it stops with a panic. It is reproducible consistently. I have typein the kernel dump: EIP at 0060 :[44bf9bbc] EIP at xfs_ail_insert xfs_trans_update_ail xfs_trans_chunk_committed xfs_trans_committed xlog_state_do_callback xlog_iodone ... ... The same test went good without any panic in XFS 1.2 (Kernel 2.4.20) Any kernel patch is much appreciated. Please CC me in your reply. Thanks & Regards, Srikumar Subramanian From owner-linux-xfs@oss.sgi.com Tue Oct 18 00:39:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Oct 2005 00:39:14 -0700 (PDT) Received: from american.megatrends.com (american.megatrends.com [155.229.80.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9I7dAO0028113 for ; Tue, 18 Oct 2005 00:39:10 -0700 Received: by american.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Oct 2005 03:36:06 -0400 Message-ID: <3225AF1B8CBF83459982D4987F1549CE055EE8@fre-ops.us.megatrends.com> From: Srikumar Subramanian To: acl-devel-owner@bestbits.at, "'linux-xfs@oss.sgi.com'" Cc: ag@bestbits.at, Srikumar Subramanian , Prabhakar Krishnan Subject: kernel panic with XFS ACL inheritance on a FULL file system Date: Tue, 18 Oct 2005 03:38:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 6390 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: SrikumarS@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 2765 Lines: 78 Hi All, We are testing XFS with ACL and got a issue when file system is full. Scenario: I create a base directory (base/) with 10 access ACL and 10 default ACL. The file system size is 2 GB. Under base/ directory, i have create lot of subdir, sub-subdirs, and files (each 1KB size) to fill the filesystem. Configuration: FC3; XFS 1.3; kernel 2.6.9-1.667smp Problem: During the test, there is no problem in inheriting acl from parent directory. But when the XFS file system goes out of space, it stops with a panic. It is reproducible consistently. It happens both in UP and SMP kernel. kernel stack trace: Unable to handle kernel NULL pointer dereference at virtual address 00000004 printing eip: 8560dbbc *pde = 00004001 Oops: 0002 [#1] SMP Modules linked in: tbiscsi(U) tbblock(U) xfs i2c_i801 cache(U) dvm(U) sg st osst sr_mod md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc iptable_filter ip_tables dm_mod button battery ac uhci_hcd ehci_hcd hw_random e1000 floppy ext3 jbd bcraid aic79xx sd_mod scsi_mod CPU: 0 EIP: 0060:[<8560dbbc>] Tainted: PF VLI EFLAGS: 00010286 (2.6.9-1.667smp) EIP is at xfs_ail_insert+0x83/0x8e [xfs] eax: 00000000 ebx: 76281b40 ecx: 70e244b0 edx: 00000000 esi: fffffc19 edi: ffffffff ebp: 7ebd201c esp: 79f46e58 ds: 007b es: 007b ss: 0068 Process xfslogd/0 (pid: 3682, threadinfo=79f46000 task=7995ce90) Stack: 00008250 00000002 00000000 00000000 7ebd2014 7ebd201c 7ebd2000 754a97d4 8560d9dd 00000000 00008250 00000002 00000002 70e244b0 00008250 00000002 8560d675 00008250 00000002 00000000 00000001 7ebd2000 73b48ad0 00008250 Call Trace: [<8560d9dd>] xfs_trans_update_ail+0x63/0x9e [xfs] [<8560d675>] xfs_trans_chunk_committed+0x141/0x188 [xfs] [<8560d4b3>] xfs_trans_committed+0x38/0xb9 [xfs] [<85602a68>] xlog_state_do_callback+0x16f/0x24e [xfs] [<8560188f>] xlog_iodone+0x7e/0x9b [xfs] [<856193fd>] pagebuf_iodone_work+0xf/0x2f [xfs] [<0212cd9f>] worker_thread+0x168/0x1d5 [<856193ee>] pagebuf_iodone_work+0x0/0x2f [xfs] [<0211cbc5>] default_wake_function+0x0/0xc [<0211cbc5>] default_wake_function+0x0/0xc [<0212cc37>] worker_thread+0x0/0x1d5 [<021300dd>] kthread+0x73/0x9b [<0213006a>] kthread+0x0/0x9b [<021041f1>] kernel_thread_helper+0x5/0xb Code: 74 1e 83 cf ff 39 c2 be 19 fc ff ff 72 07 be e7 03 00 00 31 ff 85 ff 7c 07 7f ae 83 fe 00 77 a9 89 59 04 8b 03 89 01 89 0b 8b 01 <89> 48 04 83 c4 10 5b 5e 5f 5d c3 89 d0 8b 0a 8b 52 04 89 51 04 Comparison: The same test went good without any panic in XFS 1.2 (Kernel 2.4.20) Any help or kernel patch is much appreciated. Please CC me in your reply. Thanks & Regards, Srikumar Subramanian PS: Hi Andreas, we didnt get any response from the mailing list, I hope you will respond. Thanks. From owner-linux-xfs@oss.sgi.com Tue Oct 18 05:11:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Oct 2005 05:11:14 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9ICB8O0022048 for ; Tue, 18 Oct 2005 05:11:09 -0700 Received: from [194.173.12.131] (helo=[192.10.98.49]) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwtQ-1ERqGB1KsT-0000lM; Tue, 18 Oct 2005 14:08:03 +0200 Message-ID: <4354E55E.8040003@gmx.net> Date: Tue, 18 Oct 2005 14:06:54 +0200 From: Klaus Strebel User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: LVM general discussion and development CC: linux-xfs@oss.sgi.com Subject: Re: [linux-lvm] xfs_freeze & lvm2 References: <434FB3D0.5010704@hq.vsaa.lv> In-Reply-To: <434FB3D0.5010704@hq.vsaa.lv> Content-Type: text/plain; charset=ISO-8859-13; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:8a7df7300d3d15a4f701302fdde7adf9 X-archive-position: 6391 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 1595 Lines: 48 Rich schrieb: > i am not subscribed, so i would be thankful if i could get a reply with > cc. thanks. > > i tried making snapshots of xfs filesystem on lvm2. if xfs was frozen, > lvcreate stopped at > > Suspending space-data > dm suspend space-data N > > issuing xfs_freeze -u allowed the process to continue. > in this list, Thu, 09 Jun 2005 Klaus Strebel wrote : > > "with LVM2 the XFS filesystem is 'frozen' automaticly on the mount > -onouuid,ro ( not quite sure, but probably also for LVM1 ..., think it's > in the XFS code ). > So, forget xfs_freeze." > > as i understand it, consistent copy is created when lvcreate is issued, > not when snapshot volume is mounted - is this right ? As i understood things, no. Mounttime matters ;-) see and as example . > if so, shouldn't filesystem also be frozen when a snapshot volume is > created ? ... see above ... > if it actually is done together with snapshot, does this mean that i > really can forget about xfs_freeze and just create snapshots ? > must i specify ro in mount options or is this optional ? Well, if i'm wrong ( and to be honest, i didn't play around with all the stuff for 1 1/2 years now :-( ) somebody might correct me, but if i remember postings from linux-xfs mailing list, rw-snapshots with XFS is not quite unstable ... Cheers Klaus -- Klaus Strebel, Dipl.-Inform. (FH), mailto:klaus.strebel@gmx.net /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \ From owner-linux-xfs@oss.sgi.com Tue Oct 18 07:27:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Oct 2005 07:27:37 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9IERQO0001649 for ; Tue, 18 Oct 2005 07:27:27 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA09196; Wed, 19 Oct 2005 00:23:22 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j9IENYkt5809435; Wed, 19 Oct 2005 00:23:34 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9IEN5nI5852168; Wed, 19 Oct 2005 00:23:05 +1000 (EST) Date: Wed, 19 Oct 2005 00:23:04 +1000 From: Nathan Scott To: Srikumar Subramanian Cc: acl-devel-owner@bestbits.at, "'linux-xfs@oss.sgi.com'" , ag@bestbits.at, Prabhakar Krishnan Subject: Re: kernel panic with XFS ACL inheritance on a FULL file system Message-ID: <20051019002304.C5830881@wobbly.melbourne.sgi.com> References: <3225AF1B8CBF83459982D4987F1549CE055EE8@fre-ops.us.megatrends.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3225AF1B8CBF83459982D4987F1549CE055EE8@fre-ops.us.megatrends.com>; from SrikumarS@ami.com on Tue, Oct 18, 2005 at 03:38:54AM -0400 X-archive-position: 6392 X-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: 15 On Tue, Oct 18, 2005 at 03:38:54AM -0400, Srikumar Subramanian wrote: > Hi All, > > We are testing XFS with ACL and got a issue when file system is full. > > Configuration: > FC3; XFS 1.3; kernel 2.6.9-1.667smp Try a more recent kernel - mainline, or XFS CVS on oss.sgi.com. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 18 10:20:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Oct 2005 10:20:42 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9IHKaO0020316 for ; Tue, 18 Oct 2005 10:20:37 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9IHHWxT029991 for ; Tue, 18 Oct 2005 12:17:32 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9IHHWDN18004252 for ; Tue, 18 Oct 2005 12:17:32 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j9IHHLLL17087953; Tue, 18 Oct 2005 12:17:21 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j9IHHUvM003718; Tue, 18 Oct 2005 12:17:30 -0500 Received: (from yingping@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j9IHHUoQ003716; Tue, 18 Oct 2005 12:17:30 -0500 Date: Tue, 18 Oct 2005 12:17:30 -0500 From: Yingping Lu Message-Id: <200510181717.j9IHHUoQ003716@penguin.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 944075 - Fixed a "hole" report error from running xfs_bmap -a X-archive-position: 6393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yingping@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 539 Lines: 18 Fixed a bug in reporting extent list for attribute fork running xfs_bmap -a. Date: Tue Oct 18 10:14:26 PDT 2005 Workarea: penguin.americas.sgi.com:/src/yingping/xfs-kern Inspected by: sandeen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:200860a xfs_bmap.c - 1.333 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.333&r2=text&tr2=1.332&f=h - Fixed a bug in reporting extent list for attribute fork running xfs_bmap -a. From owner-linux-xfs@oss.sgi.com Tue Oct 18 13:26:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Oct 2005 13:26:47 -0700 (PDT) Received: from american.megatrends.com (american.megatrends.com [155.229.80.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9IKQaO0008042 for ; Tue, 18 Oct 2005 13:26:36 -0700 Received: by american.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Oct 2005 16:23:32 -0400 Message-ID: <3225AF1B8CBF83459982D4987F1549CE055EEC@fre-ops.us.megatrends.com> From: Srikumar Subramanian To: Nathan Scott Cc: acl-devel-owner@bestbits.at, "'linux-xfs@oss.sgi.com'" , ag@bestbits.at, Prabhakar Krishnan , Venkatesh Ramamurthy Subject: RE: kernel panic with XFS ACL inheritance on a FULL file system Date: Tue, 18 Oct 2005 16:26:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 6395 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: SrikumarS@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 701 Lines: 31 Hi Nathan, Thanks for your reply. We will try latest kernel and update you. Regards, Srikumar -----Original Message----- From: Nathan Scott [mailto:nathans@sgi.com] Sent: Tuesday, October 18, 2005 7:23 AM To: Srikumar Subramanian Cc: acl-devel-owner@bestbits.at; 'linux-xfs@oss.sgi.com'; ag@bestbits.at; Prabhakar Krishnan Subject: Re: kernel panic with XFS ACL inheritance on a FULL file system On Tue, Oct 18, 2005 at 03:38:54AM -0400, Srikumar Subramanian wrote: > Hi All, > > We are testing XFS with ACL and got a issue when file system is full. > > Configuration: > FC3; XFS 1.3; kernel 2.6.9-1.667smp Try a more recent kernel - mainline, or XFS CVS on oss.sgi.com. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 18 13:54:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Oct 2005 13:54:05 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9IKs1O0010470 for ; Tue, 18 Oct 2005 13:54:01 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9ILvDJR028951 for ; Tue, 18 Oct 2005 14:57:13 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9IKouDN18018060 for ; Tue, 18 Oct 2005 15:50:56 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j9IKokLL16899853 for ; Tue, 18 Oct 2005 15:50:46 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j9IKotvM004848; Tue, 18 Oct 2005 15:50:55 -0500 Received: (from yingping@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j9IKotSO004845; Tue, 18 Oct 2005 15:50:55 -0500 Date: Tue, 18 Oct 2005 15:50:55 -0500 From: Yingping Lu Message-Id: <200510182050.j9IKotSO004845@penguin.americas.sgi.com> To: linux-xfs@oss.sgi.com Cc: sandeen@sgi.com Subject: TAKE 943908 - Fixing size report discrepancy between ls and du caused by xfs_fsr X-archive-position: 6396 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yingping@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 679 Lines: 17 Fixing size report discrepancy between ls and du caused by xfs_fsr Date: Tue Oct 18 13:49:24 PDT 2005 Workarea: penguin.americas.sgi.com:/src/yingping/xfs-kern Inspected by: sandeen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:200874a xfs_bmap.c - 1.334 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.334&r2=text&tr2=1.333&f=h - Added a new function xfs_bmap_disk_count_leaves so that function xfs_bmap_count_leaves counts the blocks in extent format, while function xfs_bmap_disk_count_leaves handles counting blocks in btree format of the attribute fork. From owner-linux-xfs@oss.sgi.com Tue Oct 18 18:07:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Oct 2005 18:07:17 -0700 (PDT) Received: from OWA.bom.gov.au (OWA.bom.gov.au [134.178.14.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9J178O0001492 for ; Tue, 18 Oct 2005 18:07:11 -0700 Received: from officeho2.bom.gov.au ([134.178.14.21]) by OWA.bom.gov.au with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 11:04:02 +1000 Received: from 134.178.8.202 ([134.178.8.202]) by officeho2.bom.gov.au ([134.178.14.21]) via Exchange Front-End Server owa.bom.gov.au ([134.178.14.16]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Oct 2005 01:04:02 +0000 Received: from bakunin.ho.bom.gov.au by owa.bom.gov.au; 19 Oct 2005 11:04:02 +1000 Subject: Suggested fix for xfsrq under linux From: John Stern To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-8AipsZPaXi0wgJDx3aOh" Date: Wed, 19 Oct 2005 11:04:01 +1000 Message-Id: <1129683842.5171.38.camel@bakunin.ho.bom.gov.au> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-OriginalArrivalTime: 19 Oct 2005 01:04:02.0938 (UTC) FILETIME=[FEE98DA0:01C5D448] X-archive-position: 6397 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: J.Stern@bom.gov.au Precedence: bulk X-list: linux-xfs Content-Length: 1609 Lines: 38 --=-8AipsZPaXi0wgJDx3aOh Content-Type: text/plain Content-Transfer-Encoding: 7bit We discovered with some dismay that xfsrq was broken the other day when testing it. This included testing an SGI Altix running RedHat. I noticed an attempt to fix (the obvious) fault in the setquota call. This fix get rid of the spurious -n option (???) and puts the arguments in the correct order. The problem is that setquota expects the device not the filesystem mount point name.. and the block size doesn't need to be divided by two since linux uses 1024 byte blocks. i.e. /dev/hda1 not /boot or whatever. The patch applies to the version of xfsrq supplied with xfsdump-2.0.3-0, xfsdump-2.2.25-1, and probably several others. --=-8AipsZPaXi0wgJDx3aOh Content-Disposition: attachment; filename=xfsrq.patch Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name=xfsrq.patch; charset=UTF-8 LS0tIHhmc3JxLm9yaWcJVGh1IE5vdiAyMSAyMDoxMjo0OCAyMDAyDQorKysg eGZzcnEJVHVlIE9jdCAxOCAxNjo0Njo0NyAyMDA1DQpAQCAtNjQsOSArNjQs OCBAQA0KIAkJd2hpbGUgcmVhZCBmcyBpZCBic29mdCBiaGFyZCBpc29mdCBp aGFyZDsgZG8NCiAJCQlbICRWRVJCT1NFIF0gJiYgZWNobyBzZXR0aW5nIHF1 b3RhIGZvciBpZD0kaWQgZGV2PSRmcw0KIAkJCSMgYmxrIGNvbnZlcnNpb24g KDUxMiAtPiAxMDI0KQ0KLQkJCWJzb2Z0PWBleHByICRic29mdCAvIDJgDQot CQkJYmhhcmQ9YGV4cHIgJGJoYXJkIC8gMmANCi0JCQlzZXRxdW90YSAkT1BU UyAtbiAkaWQgJGZzICRic29mdCAkYmhhcmQgJGlzb2Z0ICRpaGFyZA0KKwkJ CW1udD1gZ3JlcCAiXiRmcyIgL3Byb2MvbW91bnRzfCBhd2sgJ3twcmludCAk Mn0nYA0KKwkJCXNldHF1b3RhICRPUFRTICRpZCAkYnNvZnQgJGJoYXJkICRp c29mdCAkaWhhcmQgJG1udA0KIAkJZG9uZQ0KIAkJOzsNCiAJKikJZWNobyAk VVNBR0UgMT4mMg0K --=-8AipsZPaXi0wgJDx3aOh-- From owner-linux-xfs@oss.sgi.com Tue Oct 18 20:43:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Oct 2005 20:43:54 -0700 (PDT) Received: from american.megatrends.com (american.megatrends.com [155.229.80.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9J3hmO0019483 for ; Tue, 18 Oct 2005 20:43:49 -0700 Received: by american.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Oct 2005 23:40:44 -0400 Message-ID: <3225AF1B8CBF83459982D4987F1549CE055EF1@fre-ops.us.megatrends.com> From: Prabhakar Krishnan To: "'Nathan Scott'" Cc: "'acl-devel-owner@bestbits.at'" , "'linux-xfs@oss.sgi.com'" , "'ag@bestbits.at'" Subject: XFS- Quotas: setting up project quotas Date: Tue, 18 Oct 2005 23:42:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-archive-position: 6398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpkar@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 1887 Lines: 66 XFS- Quotas: Need some help/working example / working kernel or xfs rpm information to setup directory quotas using project quota . Configuration: Kernel : 2.6.12-1.1378_FC3 XFS : xfsprogs 2.7.3 Quota : 3.12.7 I saw some examples in the man page for xfs_quota (8) to setup project quotas. Problem : xfs_allow allows a set of cmds to run . -using mkfs.xfs created filesystem , with pquota flag enabled. - using xfs_quota , trying to setup and the 'cmd' quota inside the shell doesnt work as advertised in the man page. xfs_quota> help quota quota [-bir] [-gpu] [-hnv] [-f file] [id|name]... -- show usage and limits display usage and quota information -g -- display group quota information -p -- display project quota information -u -- display user quota information -b -- display number of blocks used -i -- display number of inodes used -r -- display number of realtime blocks used -h -- report in a human-readable format -n -- skip identifier-to-name translations, just report IDs -N -- suppress the initial header -v -- increase verbosity in reporting (also dumps zero values) -f -- send output to a file The (optional) user/group/project can be specified either by name or by number (i.e. uid/gid/projid). MAN PAGE : man xfs_quota ... > man xfs_quota EXAMPLE : # mount -o uquota /dev/xvm/home /home # xfs_quota -c 'edit bsoft=500m bhard=550m tanya' /home # xfs_quota -c report /home Enabling directory quota on an XFS filesystem (restrict files in log file directories to only using 1 gigabyte of space). # mount -o pquota /dev/xvm/var /var # echo 42:/var/log >> /etc/projects # echo logfiles:42 >> /etc/projid # xfs_quota -c 'projects -c logfiles' /home # xfs_quota -c 'edit -p bhard=1g logfiles' /home -Prabhakar Krishnan From owner-linux-xfs@oss.sgi.com Tue Oct 18 21:26:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Oct 2005 21:26:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9J4QRO0025131 for ; Tue, 18 Oct 2005 21:26:28 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA27244; Wed, 19 Oct 2005 14:22:52 +1000 Message-ID: <4355CA32.205@sgi.com> Date: Wed, 19 Oct 2005 14:23:14 +1000 From: timothy shimmin User-Agent: Thunderbird 1.4.1 (X11/20051006) MIME-Version: 1.0 To: John Stern CC: linux-xfs@oss.sgi.com, nathans@sgi.com Subject: Re: Suggested fix for xfsrq under linux References: <1129683842.5171.38.camel@bakunin.ho.bom.gov.au> In-Reply-To: <1129683842.5171.38.camel@bakunin.ho.bom.gov.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6399 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1963 Lines: 54 Hi John, As you noticed, the removal of -n option and $fs moved to the end went in for xfsdump-2.2.30 and I noticed it was recommended by Ethan Benson in March 2004 where he mentioned it worked for him :) Looking at Q_XGETQUOTA, xfs_qm_scall_getquota, xfs_qm_export_dquot, it appears that the limits are exported by xfs in BBs or 512 byte blocks. So if setquota wants them in 1024 byte blocks it would need to divide by 2 AFAICS. The mount name istead of a device name seems to work without complaints for setquota when I just tried it (maybe that's not true on all versions??) Nathan looks after this code so I'll let him respond further to this one :-) Thanks, --Tim John Stern wrote: > We discovered with some dismay that xfsrq was broken the other day > when testing it. This included testing an SGI Altix running RedHat. > > I noticed an attempt to fix (the obvious) fault in the setquota call. > This fix get rid of the spurious -n option (???) and puts the arguments > in the correct order. The problem is that setquota expects the device > not the filesystem mount point name.. and the block size doesn't need to > be divided by two since linux uses 1024 byte blocks. > > i.e. /dev/hda1 not /boot or whatever. > > The patch applies to the version of xfsrq supplied with > xfsdump-2.0.3-0, xfsdump-2.2.25-1, and probably several others. > > ------------------------------------------------------------------------ > > --- xfsrq.orig Thu Nov 21 20:12:48 2002 > +++ xfsrq Tue Oct 18 16:46:47 2005 > @@ -64,9 +64,8 @@ > while read fs id bsoft bhard isoft ihard; do > [ $VERBOSE ] && echo setting quota for id=$id dev=$fs > # blk conversion (512 -> 1024) > - bsoft=`expr $bsoft / 2` > - bhard=`expr $bhard / 2` > - setquota $OPTS -n $id $fs $bsoft $bhard $isoft $ihard > + mnt=`grep "^$fs" /proc/mounts| awk '{print $2}'` > + setquota $OPTS $id $bsoft $bhard $isoft $ihard $mnt > done > ;; > *) echo $USAGE 1>&2 > From owner-linux-xfs@oss.sgi.com Wed Oct 19 13:15:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Oct 2005 13:15:54 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9JKFmO0030740 for ; Wed, 19 Oct 2005 13:15:49 -0700 Received: (qmail invoked by alias); 19 Oct 2005 20:12:42 -0000 Received: from G1f86.g.pppool.de (EHLO [192.168.10.11]) [80.185.31.134] by mail.gmx.net (mp004) with SMTP; 19 Oct 2005 22:12:42 +0200 X-Authenticated: #2986359 Message-ID: <4356A8B9.70203@gmx.net> Date: Wed, 19 Oct 2005 22:12:41 +0200 From: evilninja User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "'linux-xfs@oss.sgi.com'" CC: Srikumar Subramanian Subject: Re: kernel panic with XFS ACL inheritance on a FULL file system References: <3225AF1B8CBF83459982D4987F1549CE055EE8@fre-ops.us.megatrends.com> In-Reply-To: <3225AF1B8CBF83459982D4987F1549CE055EE8@fre-ops.us.megatrends.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-archive-position: 6401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 263 Lines: 13 Srikumar Subramanian schrieb: > EIP: 0060:[<8560dbbc>] Tainted: PF VLI > EFLAGS: 00010286 (2.6.9-1.667smp) perhaps you could try to reproduce the error with an untainted kernel too. just to be sure.... Christian. -- BOFH excuse #34: (l)user error From owner-linux-xfs@oss.sgi.com Thu Oct 20 16:19:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Oct 2005 16:20:02 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9KNJsO0011434 for ; Thu, 20 Oct 2005 16:19:55 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA16943; Fri, 21 Oct 2005 09:15:41 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j9KNFqkt5791582; Fri, 21 Oct 2005 09:15:54 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9KNFmnY5910725; Fri, 21 Oct 2005 09:15:48 +1000 (EST) Date: Fri, 21 Oct 2005 09:15:48 +1000 From: Nathan Scott To: Prabhakar Krishnan Cc: "'linux-xfs@oss.sgi.com'" , "'ag@bestbits.at'" Subject: Re: XFS- Quotas: setting up project quotas Message-ID: <20051021091548.D5915885@wobbly.melbourne.sgi.com> References: <3225AF1B8CBF83459982D4987F1549CE055EF1@fre-ops.us.megatrends.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3225AF1B8CBF83459982D4987F1549CE055EF1@fre-ops.us.megatrends.com>; from kpkar@ami.com on Tue, Oct 18, 2005 at 11:42:23PM -0400 X-archive-position: 6404 X-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: 552 Lines: 24 On Tue, Oct 18, 2005 at 11:42:23PM -0400, Prabhakar Krishnan wrote: > XFS- Quotas: > ... > -using mkfs.xfs created filesystem , with pquota flag enabled. [p]quota are not mkfs options, they're mount options. > - using xfs_quota , trying to setup and the 'cmd' quota inside the shell > doesnt work as > advertised in the man page. > ... > > man xfs_quota > EXAMPLE : Looks like I missed -x on the command line for some examples. So, OOC, do all these ACL/quota questions indicate AMI is developing a NAS product using XFS? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 20 18:37:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Oct 2005 18:37:58 -0700 (PDT) Received: from american.megatrends.com (american.megatrends.com [155.229.80.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9L1bmO0019869 for ; Thu, 20 Oct 2005 18:37:49 -0700 Received: by american.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Oct 2005 21:34:43 -0400 Message-ID: <3225AF1B8CBF83459982D4987F1549CE055F00@fre-ops.us.megatrends.com> From: Prabhakar Krishnan To: Nathan Scott , Prabhakar Krishnan Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: XFS- Quotas: setting up project quotas Date: Thu, 20 Oct 2005 21:36:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-archive-position: 6405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpkar@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 5778 Lines: 153 Nathan Xfs_allow '-x' option is now showing a whole set of commands that I was looking for. Though 'edit' is called 'limit' for setting quota limits. This 'limit' command doesn't work as expected. Please comment if there was any configuration/command usage error. Also if there is any new updated xfs in the latest kernel. Thanks -kpkar (PS: Here@AMI ,I am just evaluating XFS right now .cant say about products) Config: ------ [root@localhost ~]# uname -a Linux localhost 2.6.9-1.667smp #1 SMP Thu Oct 6 19:06:02 EDT 2005 i686 i686 i386 GNU/Linux [root@localhost ~]# [root@localhost ~]# rpm -qai xfsprogs Name : xfsprogs Relocations: (not relocatable) Version : 2.7.3 Vendor: Silicon Graphics, Inc. Release : 1 Build Date: Fri 07 Oct 2005 09:55:39 AM PDT Install Date: Wed 12 Oct 2005 03:20:55 PM PDT Build Host: penguin.americas.sgi.com Group : System Environment/Base Source RPM: xfsprogs-2.7.3-1.src.rpm Size : 2741772 License: GPL Signature : (none) Packager : Silicon Graphics, Inc. URL : http://oss.sgi.com/projects/xfs/ Summary : Utilities for managing the XFS filesystem. Description : A set of commands to use the XFS filesystem, including mkfs.xfs. XFS is a high performance journaling filesystem which originated on the SGI IRIX platform. It is completely multi-threaded, can support large files and large filesystems, extended attributes, variable block sizes, is extent based, and makes extensive use of Btrees (directories, extents, free space) to aid both performance and scalability. Refer to the documentation at http://oss.sgi.com/projects/xfs/ for complete details. This implementation is on-disk compatible with the IRIX version of XFS. Command output: --------------- [root@localhost ~]# mount /dev/sda1 on / type ext3 (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) usbfs on /proc/bus/usb type usbfs (rw) none on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) /dev/mapper/stor1_nas on /volumes/stor1_nas type xfs (rw,usrquota) /dev/mapper/stor2_nas on /volumes/stor2_nas type xfs (rw,usrquota) /dev/mapper/stor2_0 on /volumes/stor2_0 type xfs (rw) /dev/mapper/stor2_quota on /kpkar type xfs (rw,pquota) [root@localhost /]# cd /kpkar [root@localhost kpkar]# ls log root [root@localhost kpkar]# ls -l total 0 drwxr-xr-x 3 root root 16 Oct 20 18:07 log dr-xrw-rwt 2 root root 6 Oct 12 16:21 root [root@localhost kpkar]# [root@localhost ~]# xfs_quota -x xfs_quota> ? df [-bir] [-hn] [-f file] -- show free and used counts for blocks and inodes disable [-gpu] [-v] -- disable quota enforcement dump [-gpu] [-f file] -- dump quota information for backup utilities enable [-gpu] [-v] -- enable quota enforcement help [command] -- help for one or all commands limit [-gpu] bsoft|bhard|isoft|ihard|rtbsoft|rtbhard=N -d|id|name -- modify quota limits off [-gpu] [-v] -- permanently switch quota off for a path path [N] -- set current path, or show the list of paths print -- list known mount points and projects project [-c|-s|-C] project ... -- check, setup or clear project quota trees quit -- exit the program quot [-bir] [-gpu] [-acv] [-f file] -- summarize filesystem ownership quota [-bir] [-gpu] [-hnv] [-f file] [id|name]... -- show usage and limits remove [-gpu] [-v] -- remove quota extents from a filesystem report [-bir] [-gpu] [-ahnt] [-f file] -- report filesystem quota information restore [-gpu] [-f file] -- restore quota limits from a backup file state [-gpu] [-f file] -- get overall quota state information timer [-bir] [-gpu] value -d|id|name -- get/set quota enforcement timeouts warn [-bir] [-gpu] value -d|id|name -- get/set enforcement warning counter Use 'help commandname' for extended help. xfs_quota> print Filesystem Pathname /volumes/stor1_nas /dev/mapper/stor1_nas (uquota) /volumes/stor2_nas /dev/mapper/stor2_nas (uquota) /Access.Share/forjasonk /dev/mapper/stor1_nas (uquota) /Access.Share/ftp /dev/mapper/stor2_nas (uquota) /volumes/stor2_0 /dev/mapper/stor2_0 /kpkar /dev/mapper/stor2_quota /kpkar/log /dev/mapper/stor2_quota (project 42, logfile) xfs_quota> project -s logfile Setting up project logfile (path /kpkar/log)... Processed 1 /etc/projects paths for project logfile xfs_quota> project -c logfile Checking project logfile (path /kpkar/log)... /kpkar/log/xfs - project identifier is not set (inode=0, tree=42) /kpkar/log/xfs - project inheritance flag is not set /kpkar/log - project identifier is not set (inode=0, tree=42) /kpkar/log - project inheritance flag is not set Processed 1 /etc/projects paths for project logfile xfs_quota> limit -p bhard=1g logfile xfs_quota: cannot set limits: Invalid argument -----Original Message----- From: Nathan Scott [mailto:nathans@sgi.com] Sent: Thursday, October 20, 2005 4:16 PM To: Prabhakar Krishnan Cc: 'linux-xfs@oss.sgi.com'; 'ag@bestbits.at' Subject: Re: XFS- Quotas: setting up project quotas On Tue, Oct 18, 2005 at 11:42:23PM -0400, Prabhakar Krishnan wrote: > XFS- Quotas: > ... > -using mkfs.xfs created filesystem , with pquota flag enabled. [p]quota are not mkfs options, they're mount options. > - using xfs_quota , trying to setup and the 'cmd' quota inside the > shell doesnt work as advertised in the man page. > ... > > man xfs_quota > EXAMPLE : Looks like I missed -x on the command line for some examples. So, OOC, do all these ACL/quota questions indicate AMI is developing a NAS product using XFS? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 20 19:40:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Oct 2005 19:40:38 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9L2eXO0023309 for ; Thu, 20 Oct 2005 19:40:34 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20823; Fri, 21 Oct 2005 12:37:23 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j9L2bZkt5917168; Fri, 21 Oct 2005 12:37:36 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9L2bVlF5914292; Fri, 21 Oct 2005 12:37:31 +1000 (EST) Date: Fri, 21 Oct 2005 12:37:31 +1000 From: Nathan Scott To: Prabhakar Krishnan Cc: linux-xfs@oss.sgi.com Subject: Re: XFS- Quotas: setting up project quotas Message-ID: <20051021123730.A5919922@wobbly.melbourne.sgi.com> References: <3225AF1B8CBF83459982D4987F1549CE055F00@fre-ops.us.megatrends.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3225AF1B8CBF83459982D4987F1549CE055F00@fre-ops.us.megatrends.com>; from kpkar@ami.com on Thu, Oct 20, 2005 at 09:36:20PM -0400 X-archive-position: 6406 X-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: 619 Lines: 24 On Thu, Oct 20, 2005 at 09:36:20PM -0400, Prabhakar Krishnan wrote: > Xfs_allow '-x' option is now showing a whole set of commands that I was s/allow/quota/g > looking for. > Though 'edit' is called 'limit' for setting quota limits. Ah, right, the docs are incorrect there, I'll fix that up. > This 'limit' command doesn't work as expected. Please comment if there was > any configuration/command usage error. Also if there is any new updated xfs Take a look at the code if its not obvious whats going wrong.. > in the latest kernel. There are frequently XFS updates going into the kernel. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 20 20:28:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Oct 2005 20:29:02 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9L3SwO0030879 for ; Thu, 20 Oct 2005 20:28:58 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9L3PqxT015093 for ; Thu, 20 Oct 2005 22:25:52 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9L3PqDN18180816 for ; Thu, 20 Oct 2005 22:25:52 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j9L3PeLL17336823; Thu, 20 Oct 2005 22:25:40 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j9L3PovM013651; Thu, 20 Oct 2005 22:25:50 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j9L3PoPD013649; Thu, 20 Oct 2005 22:25:50 -0500 Date: Thu, 20 Oct 2005 22:25:50 -0500 From: Eric Sandeen Message-Id: <200510210325.j9L3PoPD013649@penguin.americas.sgi.com> To: sgi.bugs.xfs@fido.engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 944632 - fix old xfs_setattr mis-merge from irix X-archive-position: 6407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 535 Lines: 16 fix old xfs_setattr mis-merge from irix; mostly harmless esp if not using xfs rt Date: Thu Oct 20 20:25:28 PDT 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:200983a xfs_vnodeops.c - 1.655 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.655&r2=text&tr2=1.654&f=h - fix old mis-merge of grove2:irix:150953a in xfs_setattr From owner-linux-xfs@oss.sgi.com Fri Oct 21 04:51:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Oct 2005 04:51:30 -0700 (PDT) Received: from mta2.gsf.de (mta2.gsf.de [146.107.4.111]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LBpMO0013757 for ; Fri, 21 Oct 2005 04:51:24 -0700 Received: from [146.107.217.179] (cavy.gsf.de [146.107.217.179]) by mta2.gsf.de (Postfix) with ESMTP id 7389E146694; Fri, 21 Oct 2005 13:48:06 +0200 (CEST) Message-ID: <4358D4D9.2020905@gsf.de> Date: Fri, 21 Oct 2005 13:45:29 +0200 From: Yogesh Bhanu Reply-To: yogesh@gsf.de Organization: IBI/MIPS User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Fedora/1.7.12-1.5.1 X-Accept-Language: en, de MIME-Version: 1.0 To: tes@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: xfs problem References: <8306780C060A7D4790F8BA02CBA1B6910A94BE@sw-rz010.gsf.de> <1128677803.26500.19.camel@boing.melbourne.sgi.com> In-Reply-To: <1128677803.26500.19.camel@boing.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yogesh@gsf.de Precedence: bulk X-list: linux-xfs Content-Length: 1017 Lines: 22 Hi , Its my second crash in 14 days, again the system spewed a similar error message for reservation failure . This is a bit disconcerting as we are in middle of migration from our old fileservers. Is there a way I can up the reservation. Output of /var/log/messges -------------cut here----------------------- Oct 21 11:58:02 mipsopt-02 kernel: Filesystem "dm-0": xfs_log_write: reservation ran out. Need to up reservation Oct 21 11:58:02 mipsopt-02 kernel: xfs_force_shutdown(dm-0,0x8) called from line 1689 of file fs/xfs/xfs_log.c. Return address = 0xffffffffa01b45e8 Oct 21 11:58:02 mipsopt-02 kernel: Filesystem "dm-0": Corruption of in-memory data detected. Shutting down filesystem: dm-0 Oct 21 11:58:02 mipsopt-02 kernel: Please umount the filesystem, and rectify the problem(s) Oct 21 11:58:02 mipsopt-02 kernel: xfs_force_shutdown(dm-0,0x2) called from line 1284 of file fs/xfs/xfs_log.c. Return address = 0xffffffffa01b45e8 -------------cut here----------------------- Thanks yogesh From owner-linux-xfs@oss.sgi.com Fri Oct 21 06:42:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Oct 2005 06:42:29 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LDgOO0024662 for ; Fri, 21 Oct 2005 06:42:24 -0700 Received: by zproxy.gmail.com with SMTP id r28so81048nza for ; Fri, 21 Oct 2005 06:39:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mJZ24jT7CfmmOx0Eh7hR26EJjFXrvUQmn8kErAyT4mvLog2nWgljpZ5mmGOaM6rUdtnN+ZzvrsO2N53w3St9fhejZqTfIKXoGRpvHuRS62TfBO4Z9003i/tR+Fq47uwhAwHe+vpp3BM6dIV/lJJi5F3rrzWUWtPU1h8iDb1oZeQ= Received: by 10.36.224.76 with SMTP id w76mr3132719nzg; Fri, 21 Oct 2005 06:39:18 -0700 (PDT) Received: by 10.36.105.9 with HTTP; Fri, 21 Oct 2005 06:39:17 -0700 (PDT) Message-ID: <5449aac20510210639t5ee4baf3n83d615715703994c@mail.gmail.com> Date: Fri, 21 Oct 2005 14:39:17 +0100 From: Alexander Fisher Reply-To: alex@alexfisher.me.uk To: Nathan Scott Subject: Re: xfs and lvm snapshots Cc: linux-xfs@oss.sgi.com In-Reply-To: <5449aac20510070716j55e987aega2142d5b26ed1dec@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <5449aac20510061026o69854e8ai16ab5eb3787094f7@mail.gmail.com> <20051006224407.GF722@frodo> <5449aac20510070716j55e987aega2142d5b26ed1dec@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j9LDgPO0024664 X-archive-position: 6410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alexjfisher@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 2026 Lines: 53 On 10/7/05, Alexander Fisher wrote: > On 10/6/05, Nathan Scott wrote: > > On Thu, Oct 06, 2005 at 06:26:29PM +0100, Alexander Fisher wrote: > SNIP > > > Given these errors, I'm not sure that I want to rely on the backups > > > taken with xfsdump. Can they be ignored?! > > > > If its a readonly snapshot, yes they can. (are device mapper > > snapshots always readonly? I dunno) -- these look like the > > sorts of errors that would come from XFS not processing the > > unlinked list, which is what we do for a snapshot (XFS assumes > > it is readonly). > > As far as I can see all LVM2 snapshots are read-write (at least I > can't find an option for lvcreate to make one read-only). > > > > I was under the impression that xfs_freeze shouldn't be used anymore > > > since it will deadlock (which it does). I'm using Debian Sarge with > > > > Right. Its arguably a block layer (bdev_freeze, outside XFS) bug, > > noones had time/motivation to go fix it up. > > > > > Other than mounting filesystems read-only before snapshoting (which > > > isn't practical), is there anything else I can do? > > > > As long as the snapshot is mounted readonly, those check errors > > are fine. If we want writable snapshots, we have some work to > > do in XFS to ensure the log is left dirty on the snapshot, so that > > when its mounted we process the unlinked list... its mainly an > > issue of not knowing whether the snapshot target is ro/rw. > > So, read-write snapshots are fine for backups with xfsdump as long as > I mount them read-only? > > Thanks, > Alex > Hi again. I've mounted my snapshots readonly, but I occasionally get warnings from xfsdump during the backups. I get two different types of warning. xfsdump: WARNING: failed to get bulkstat information for inode 10485897 and xfsdump: WARNING: could not stat dirent .viminfo ino 10485896: No such file or directory: using null generation count in directory entry What's causing these? Can they be ignored? Thanks, Alex From owner-linux-xfs@oss.sgi.com Fri Oct 21 08:53:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Oct 2005 08:53:44 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LFrdO0003149 for ; Fri, 21 Oct 2005 08:53:39 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9LGvEbJ023641 for ; Fri, 21 Oct 2005 09:57:14 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9LFoWDN18215062 for ; Fri, 21 Oct 2005 10:50:33 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j9LFoKLL16954532; Fri, 21 Oct 2005 10:50:20 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j9LFoVvM023621; Fri, 21 Oct 2005 10:50:31 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j9LFoVS6023617; Fri, 21 Oct 2005 10:50:31 -0500 Date: Fri, 21 Oct 2005 10:50:31 -0500 From: Eric Sandeen Message-Id: <200510211550.j9LFoVS6023617@penguin.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 943266 - remove unused code from xfs_iomap_write_direct X-archive-position: 6411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 490 Lines: 16 remove unused code from xfs_iomap_write_direct Date: Fri Oct 21 08:50:16 PDT 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: tes,felixb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:200996a xfs_iomap.c - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h - remove unused code from xfs_iomap_write_direct From owner-linux-xfs@oss.sgi.com Fri Oct 21 11:12:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Oct 2005 11:12:23 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LICIO0011474 for ; Fri, 21 Oct 2005 11:12:18 -0700 Received: from hastur.corp.sgi.com (hastur.corp.sgi.com [198.149.32.33]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9LJFrsK027368 for ; Fri, 21 Oct 2005 12:15:53 -0700 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by hastur.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9LI8neS205633271; Fri, 21 Oct 2005 11:08:49 -0700 (PDT) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id j9LI9AMj008182; Fri, 21 Oct 2005 13:09:10 -0500 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id j9LI9A1r008181; Fri, 21 Oct 2005 13:09:10 -0500 Date: Fri, 21 Oct 2005 13:09:10 -0500 From: Christoph Hellwig Message-Id: <200510211809.j9LI9A1r008181@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 943272 - Endianess annotations for various allocator data structures X-archive-position: 6412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2707 Lines: 45 Date: Fri Oct 21 11:08:47 PDT 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:201006a fs/xfs/xfsidbg.c - 1.287 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.287&r2=text&tr2=1.286&f=h fs/xfs/xfs_ialloc.c - 1.183 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.183&r2=text&tr2=1.182&f=h fs/xfs/xfs_ag.h - 1.56 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ag.h.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h fs/xfs/xfs_itable.c - 1.132 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h fs/xfs/xfs_ialloc_btree.h - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.h.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h fs/xfs/xfs_ialloc_btree.c - 1.82 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.c.diff?r1=text&tr1=1.82&r2=text&tr2=1.81&f=h fs/xfs/xfs_log_recover.c - 1.303 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.303&r2=text&tr2=1.302&f=h fs/xfs/xfs_bmap_btree.h - 1.71 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.h.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h fs/xfs/xfs_bmap_btree.c - 1.150 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.150&r2=text&tr2=1.149&f=h fs/xfs/xfs_btree.c - 1.113 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.c.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h fs/xfs/xfs_btree.h - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.h.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h fs/xfs/xfs_inode.c - 1.421 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.421&r2=text&tr2=1.420&f=h fs/xfs/xfs_alloc.c - 1.177 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.177&r2=text&tr2=1.176&f=h fs/xfs/xfs_fsops.c - 1.108 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.108&r2=text&tr2=1.107&f=h fs/xfs/xfs_bmap.c - 1.335 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.335&r2=text&tr2=1.334&f=h fs/xfs/xfs_alloc_btree.h - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h fs/xfs/xfs_alloc_btree.c - 1.86 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.c.diff?r1=text&tr1=1.86&r2=text&tr2=1.85&f=h From owner-linux-xfs@oss.sgi.com Fri Oct 21 20:16:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Oct 2005 20:17:02 -0700 (PDT) Received: from smtp.ucolick.org (santo.ucolick.org [128.114.23.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9M3GwO0024058 for ; Fri, 21 Oct 2005 20:16:58 -0700 Received: from localhost (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id E9E9A5D715 for ; Fri, 21 Oct 2005 20:13:51 -0700 (PDT) Received: from [128.114.22.49] (griffin.ucolick.org [128.114.22.49]) by smtp.ucolick.org (Postfix) with ESMTP id A093011416 for ; Fri, 21 Oct 2005 20:13:51 -0700 (PDT) Message-ID: <4359AEA6.2000007@ucolick.org> Date: Fri, 21 Oct 2005 20:14:46 -0700 From: Patrik Jonsson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_db to find name of file? X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 6416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: patrik@ucolick.org Precedence: bulk X-list: linux-xfs Content-Length: 1484 Lines: 40 Hi all, I have an xfs file system which has been running fine for quite some time, but on which I now have a media error. I'm trying to track down which file is hit. What I've done so far is: xfs_db> blockget -n -i 393842234 upinode 393842234 add link, now 1 inode 393842234 mode 0100644 fmt extents afmt extents nex 1 anex 0 nblk 445 sz 1821919 inode 393842234 nlink 1 not dir inode 393842234 extent [0,56060208,445,0] setting inode to 393842234 for block 3/5728560 ... and many more such. The plan was to then do ncheck -i 393842234 to get the file name, but at this point xfs_db has been running for 4 hours, is using 5.6GB of memory and since the machine only has 2GB, it's swapping like crazy. Is this normal or is something wrong? I just want to know the name of a file... I'm running a 2.6.11.12 kernel, and xfs_info provides the following, in case it's any help: [root@localhost ~]# xfs_info /data meta-data=/data isize=256 agcount=32, agsize=13326352 blks = sectsz=512 data = bsize=4096 blocks=426443232, imaxpct=25 = sunit=16 swidth=112 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=458752 blocks=0, rtextents=0 Any help would be appreciated. Thanks, /Patrik Jonsson From owner-linux-xfs@oss.sgi.com Sat Oct 22 00:49:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Oct 2005 00:49:11 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9M7n1O0019143 for ; Sat, 22 Oct 2005 00:49:02 -0700 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 3677B1DA71; Sat, 22 Oct 2005 09:45:48 +0200 (CEST) From: Andreas Gruenbacher To: Christoph Hellwig Subject: Re: XFS and AMD64 Date: Sat, 22 Oct 2005 09:46:37 +0200 User-Agent: KMail/1.7.1 Cc: linux-xfs@oss.sgi.com References: <20050808025536.GA2029@plato.local.lan> <20050812094610.B29659413@melbourne.sgi.com> <20050812072344.GA19680@infradead.org> In-Reply-To: <20050812072344.GA19680@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510220946.38197.agruen@suse.de> X-archive-position: 6417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 315 Lines: 10 On Friday 12 August 2005 09:23, Christoph Hellwig wrote: > We have compatibility shims for some ioctls, > but the complicated ones (all the handle stuff, bulkstat) doesn't work > and can't be easily made to work. 32-bit dmapi userspace also won't work with a 64-bit kernel, it's not designed to do. -- Andreas. From owner-linux-xfs@oss.sgi.com Sat Oct 22 13:21:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Oct 2005 13:21:24 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9MKLKO0014868 for ; Sat, 22 Oct 2005 13:21:21 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9MLP5Qp018657 for ; Sat, 22 Oct 2005 14:25:05 -0700 Received: from syntegra.americas.sgi.com (syntegra.americas.sgi.com [128.162.232.81]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9MKHDsL23995246; Sat, 22 Oct 2005 15:17:13 -0500 (CDT) Received: from alkirkco by syntegra.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1ETPnM-00045O-00; Sat, 22 Oct 2005 15:16:48 -0500 To: linux-xfs@oss.sgi.com, patrik@ucolick.org Subject: Re: xfs_db to find name of file? In-Reply-To: <4359AEA6.2000007@ucolick.org> Message-Id: From: Amanda Kirkconnell Date: Sat, 22 Oct 2005 15:16:48 -0500 X-archive-position: 6418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1821 Lines: 49 On October 21 at 22:14 Patrik Jonsson wrote: > Hi all, > > I have an xfs file system which has been running fine for quite some > time, but on which I now have a media error. I'm trying to track down > which file is hit. What I've done so far is: > > xfs_db> blockget -n -i 393842234 > upinode 393842234 add link, now 1 > inode 393842234 mode 0100644 fmt extents afmt extents nex 1 anex 0 nblk > 445 sz 1821919 > inode 393842234 nlink 1 not dir > inode 393842234 extent [0,56060208,445,0] > setting inode to 393842234 for block 3/5728560 > ... > and many more such. > > The plan was to then do ncheck -i 393842234 to get the file name, but at > this point xfs_db has been running for 4 hours, is using 5.6GB of memory > and since the machine only has 2GB, it's swapping like crazy. Is this > normal or is something wrong? Not sure, but this sounds kinda sketchy. Someone else will need to comment on the behavior of xfs_db. > I just want to know the name of a file... Try 'find /data -inum 393842234' to get you moving forward again until we understand what's going on with xfs_db. > I'm running a 2.6.11.12 kernel, and xfs_info provides the following, in > case it's any help: > > [root@localhost ~]# xfs_info /data > meta-data=/data isize=256 agcount=32, > agsize=13326352 blks > = sectsz=512 > data = bsize=4096 blocks=426443232, imaxpct=25 > = sunit=16 swidth=112 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=458752 blocks=0, rtextents=0 > > > Any help would be appreciated. Thanks, > > /Patrik Jonsson From owner-linux-xfs@oss.sgi.com Sun Oct 23 04:42:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Oct 2005 04:42:45 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9NBgfO0023880 for ; Sun, 23 Oct 2005 04:42:42 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 17EE91A124B12; Sun, 23 Oct 2005 07:39:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 17760A0DB18A; Sun, 23 Oct 2005 07:39:34 -0400 (EDT) Date: Sun, 23 Oct 2005 07:39:34 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org cc: debian-user@lists.debian.org Subject: xfs_db -c frag -r /dev/hda1 - Segmentation fault In-Reply-To: <4080C826.F4C53CD@dmministries.org> Message-ID: References: <4080C826.F4C53CD@dmministries.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Content-Length: 1545 Lines: 46 p34:~# xfs_db -c frag -r /dev/hda1 Segmentation fault p34:~# xfs_db -c frag -r /dev/hde1 Segmentation fault p34:~# xfs_db -c frag -r /dev/hdk1 Segmentation fault p34:~# Debian Etch, 2.6.13.4, stopped working a while ago, either before newer debian packages or a newer kernel, does anyone who uses Debian+XFS have this problem as well? Towards the end of the strace: munmap(0xb7fb6000, 4096) = 0 open("/proc/meminfo", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fb6000 read(3, "MemTotal: 1035452 kB\nMemFre"..., 1024) = 598 close(3) = 0 munmap(0xb7fb6000, 4096) = 0 rt_sigaction(SIGINT, {0x80628f4, [], 0}, NULL, 8) = 0 _llseek(4, 512, [512], SEEK_SET) = 0 read(4, "XAGF\0\0\0\1\0\0\0\0\0:pn\0\0\0\1\0\0\0\2\0\0\0\0\0\0\0"..., 512) = 512 _llseek(4, 1024, [1024], SEEK_SET) = 0 read(4, "XAGI\0\0\0\1\0\0\0\0\0:pn\0\0\3@\0\0\0\3\0\0\0\1\0\0\000"..., 512) = 512 _llseek(4, 12288, [12288], SEEK_SET) = 0 read(4, "IABT\0\0\0\r\377\377\377\377\377\377\377\377\0\0\0\200"..., 4096) = 4096 _llseek(4, 32768, [32768], SEEK_SET) = 0 read(4, "INA\355\1\1\0\3\0\0\0\0\0\0\0\0\0\0\0\3\0\0\0\0\0\0\0\0"..., 16384) = 16384 mmap2(NULL, 268443648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa7df7000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ p34:~# Is this a kernel, XFS or Debian problem? Thanks! Justin. From owner-linux-xfs@oss.sgi.com Sun Oct 23 15:58:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Oct 2005 15:58:07 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9NMw1O0014235 for ; Sun, 23 Oct 2005 15:58:02 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA20208; Mon, 24 Oct 2005 08:54:45 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j9NMsukt5999498; Mon, 24 Oct 2005 08:54:56 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9NMsqJn5944377; Mon, 24 Oct 2005 08:54:52 +1000 (EST) Date: Mon, 24 Oct 2005 08:54:51 +1000 From: Nathan Scott To: Justin Piszcz Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, debian-user@lists.debian.org Subject: Re: xfs_db -c frag -r /dev/hda1 - Segmentation fault Message-ID: <20051024085451.C5863161@wobbly.melbourne.sgi.com> References: <4080C826.F4C53CD@dmministries.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jpiszcz@lucidpixels.com on Sun, Oct 23, 2005 at 07:39:34AM -0400 X-archive-position: 6423 X-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: 1198 Lines: 45 On Sun, Oct 23, 2005 at 07:39:34AM -0400, Justin Piszcz wrote: > p34:~# xfs_db -c frag -r /dev/hda1 > Segmentation fault > p34:~# xfs_db -c frag -r /dev/hde1 > Segmentation fault > p34:~# xfs_db -c frag -r /dev/hdk1 > Segmentation fault > p34:~# > > Debian Etch, 2.6.13.4, stopped working a while ago, either before newer > debian packages or a newer kernel, does anyone who uses Debian+XFS have > this problem as well? I see it too - this looks like an endian issue in xfs_db, this patch should fix it (Works For Me). cheers. -- Nathan Index: xfsprogs/db/frag.c =================================================================== --- xfsprogs.orig/db/frag.c +++ xfsprogs/db/frag.c @@ -294,7 +294,7 @@ process_exinode( xfs_bmbt_rec_32_t *rp; rp = (xfs_bmbt_rec_32_t *)XFS_DFORK_PTR(dip, whichfork); - process_bmbt_reclist(rp, XFS_DFORK_NEXTENTS(dip, whichfork), extmapp); + process_bmbt_reclist(rp, XFS_DFORK_NEXTENTS_HOST(dip, whichfork), extmapp); } static void @@ -305,7 +305,7 @@ process_fork( extmap_t *extmap; int nex; - nex = XFS_DFORK_NEXTENTS(dip, whichfork); + nex = XFS_DFORK_NEXTENTS_HOST(dip, whichfork); if (!nex) return; extmap = extmap_alloc(nex); From owner-linux-xfs@oss.sgi.com Sun Oct 23 16:43:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Oct 2005 16:43:30 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9NNhQO0021107 for ; Sun, 23 Oct 2005 16:43:27 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 074B71A11DA40; Sun, 23 Oct 2005 19:40:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 06D52A0D637F; Sun, 23 Oct 2005 19:40:19 -0400 (EDT) Date: Sun, 23 Oct 2005 19:40:19 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: Nathan Scott cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, debian-user@lists.debian.org Subject: Re: xfs_db -c frag -r /dev/hda1 - Segmentation fault In-Reply-To: <20051024085451.C5863161@wobbly.melbourne.sgi.com> Message-ID: References: <4080C826.F4C53CD@dmministries.org> <20051024085451.C5863161@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Content-Length: 1332 Lines: 52 Thanks, I will give this a try. On Mon, 24 Oct 2005, Nathan Scott wrote: > On Sun, Oct 23, 2005 at 07:39:34AM -0400, Justin Piszcz wrote: >> p34:~# xfs_db -c frag -r /dev/hda1 >> Segmentation fault >> p34:~# xfs_db -c frag -r /dev/hde1 >> Segmentation fault >> p34:~# xfs_db -c frag -r /dev/hdk1 >> Segmentation fault >> p34:~# >> >> Debian Etch, 2.6.13.4, stopped working a while ago, either before newer >> debian packages or a newer kernel, does anyone who uses Debian+XFS have >> this problem as well? > > I see it too - this looks like an endian issue in xfs_db, this patch > should fix it (Works For Me). > > cheers. > > -- > Nathan > > > Index: xfsprogs/db/frag.c > =================================================================== > --- xfsprogs.orig/db/frag.c > +++ xfsprogs/db/frag.c > @@ -294,7 +294,7 @@ process_exinode( > xfs_bmbt_rec_32_t *rp; > > rp = (xfs_bmbt_rec_32_t *)XFS_DFORK_PTR(dip, whichfork); > - process_bmbt_reclist(rp, XFS_DFORK_NEXTENTS(dip, whichfork), extmapp); > + process_bmbt_reclist(rp, XFS_DFORK_NEXTENTS_HOST(dip, whichfork), extmapp); > } > > static void > @@ -305,7 +305,7 @@ process_fork( > extmap_t *extmap; > int nex; > > - nex = XFS_DFORK_NEXTENTS(dip, whichfork); > + nex = XFS_DFORK_NEXTENTS_HOST(dip, whichfork); > if (!nex) > return; > extmap = extmap_alloc(nex); > > From owner-linux-xfs@oss.sgi.com Mon Oct 24 00:40:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Oct 2005 00:40:41 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9O7eYO0004310 for ; Mon, 24 Oct 2005 00:40:35 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA27990; Mon, 24 Oct 2005 17:36:37 +1000 Message-ID: <435C8F14.1010609@sgi.com> Date: Mon, 24 Oct 2005 17:36:52 +1000 From: Timothy Shimmin User-Agent: Thunderbird 1.4.1 (X11/20051006) MIME-Version: 1.0 To: yogesh@gsf.de CC: linux-xfs@oss.sgi.com Subject: Re: xfs problem References: <8306780C060A7D4790F8BA02CBA1B6910A94BE@sw-rz010.gsf.de> <1128677803.26500.19.camel@boing.melbourne.sgi.com> <4358D4D9.2020905@gsf.de> In-Reply-To: <4358D4D9.2020905@gsf.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1571 Lines: 40 Hi Yogesh, I'm sorry for your 2nd crash :( It's not so simple to "up the reservation" because we really need to know why this was a problem and we don't have a sense of by how much it needs to be increased. Can you build a kernel with XFS_LOG_RES_DEBUG defined? If this is defined then a lot more information will be printed out on the next such error: e.g. the transaction type, reservation size and the component regions and their sizes which make up the transaction etc. --Tim Yogesh Bhanu wrote: > Hi , > Its my second crash in 14 days, again the system spewed a > similar error message for reservation failure . > This is a bit disconcerting as we are in middle of migration from our > old fileservers. Is there a way I can up the reservation. > Output of /var/log/messges > -------------cut here----------------------- > Oct 21 11:58:02 mipsopt-02 kernel: Filesystem "dm-0": xfs_log_write: > reservation ran out. Need to up reservation > Oct 21 11:58:02 mipsopt-02 kernel: xfs_force_shutdown(dm-0,0x8) called > from line 1689 of file fs/xfs/xfs_log.c. Return address = > 0xffffffffa01b45e8 > Oct 21 11:58:02 mipsopt-02 kernel: Filesystem "dm-0": Corruption of > in-memory data detected. Shutting down filesystem: dm-0 > Oct 21 11:58:02 mipsopt-02 kernel: Please umount the filesystem, and > rectify the problem(s) > Oct 21 11:58:02 mipsopt-02 kernel: xfs_force_shutdown(dm-0,0x2) called > from line 1284 of file fs/xfs/xfs_log.c. Return address = > 0xffffffffa01b45e8 > -------------cut here----------------------- > Thanks > yogesh > > From owner-linux-xfs@oss.sgi.com Mon Oct 24 20:57:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Oct 2005 20:57:18 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9P3vBO0019094 for ; Mon, 24 Oct 2005 20:57:14 -0700 Received: from [134.14.52.214] (shiva214.melbourne.sgi.com [134.14.52.214]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA19362; Tue, 25 Oct 2005 13:53:47 +1000 Message-ID: <435DAB4F.8060501@sgi.com> Date: Tue, 25 Oct 2005 13:49:35 +1000 From: tim shimmin User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: alex@alexfisher.me.uk CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: xfs and lvm snapshots References: <5449aac20510061026o69854e8ai16ab5eb3787094f7@mail.gmail.com> <20051006224407.GF722@frodo> <5449aac20510070716j55e987aega2142d5b26ed1dec@mail.gmail.com> <5449aac20510210639t5ee4baf3n83d615715703994c@mail.gmail.com> In-Reply-To: <5449aac20510210639t5ee4baf3n83d615715703994c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2546 Lines: 73 Hi Alex, Alexander Fisher wrote: > Hi again. > > I've mounted my snapshots readonly, but I occasionally get warnings > from xfsdump during the backups. I get two different types of > warning. > > xfsdump: WARNING: failed to get bulkstat information for inode 10485897 > and > xfsdump: WARNING: could not stat dirent .viminfo ino 10485896: No such > file or directory: using null generation count in directory entry > > What's causing these? Can they be ignored? > > Thanks, > Alex > > The messages probably relate to you dumping an active file system - one where files are being modified/removed as the dump is going on (I didn't look at your context). The first warning happens when we are dumping files and processing bulkstat information. The bulkstat data is the ondisk-inode data (a buffers worth of inodes) which may not reflect the latest in-memory data. For instance, the inode may be being deleted and the link count has been zeroed. If dump detects this then it makes another call which effectively gets the in-memory data for the inode (bulkstat-single call). When it did this it failed and so the inode has probably been deleted. Since the file-system is active, it is reasonable to notify you about the inode. In the 2nd case, it is dumping out directory entries (dirents) for a directory. In the dump of dirents it also stores the inode generation number (gen#), and since the dirent structure has the inode# but not the gen#, it does a stat call to get back the gen#. When it does this it fails to get the inode, so it uses a value of zero for the gen#. In your case .viminfo existed when it read the dirents into the buffer but then as it processed each entry and did a stat on the inode for .viminfo, it was no longer there. I almost would have thought it might skip this directory entry. I presume it stores the gen# because the dumping is done in 2 stages - dumping of the directory entries and then dumping of the non-directories (files). And by the time we come around to dumping the file (which includes the ino# and gen#) it would be good to know that this is the same file as the one referenced in the directory entry and not another file reusing the inode#. Using a gen# of zero in this case would likely do the job as a new inode with the same inode# will have a non-zero gen# and will not match with this entry. My 2 cents explanation :) Anyway, yes, I think they can be ignored. As these messages have often caused grief, I guess it would be nice if they were a bit more helpful. --Tim From owner-linux-xfs@oss.sgi.com Mon Oct 24 21:08:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Oct 2005 21:08:40 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9P48aO0020605 for ; Mon, 24 Oct 2005 21:08:37 -0700 Received: from [134.14.52.215] (shiva215.melbourne.sgi.com [134.14.52.215]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA19587; Tue, 25 Oct 2005 14:05:11 +1000 Message-ID: <435DADFC.1080100@sgi.com> Date: Tue, 25 Oct 2005 14:01:00 +1000 From: tim shimmin User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: alex@alexfisher.me.uk CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: xfs and lvm snapshots References: <5449aac20510061026o69854e8ai16ab5eb3787094f7@mail.gmail.com> <20051006224407.GF722@frodo> <5449aac20510070716j55e987aega2142d5b26ed1dec@mail.gmail.com> <5449aac20510210639t5ee4baf3n83d615715703994c@mail.gmail.com> <435DAB4F.8060501@sgi.com> In-Reply-To: <435DAB4F.8060501@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 619 Lines: 26 tim shimmin wrote: > Hi Alex, > > Alexander Fisher wrote: >> Hi again. >> >> I've mounted my snapshots readonly, but I occasionally get warnings >> from xfsdump during the backups. I get two different types of >> warning. >> >> xfsdump: WARNING: failed to get bulkstat information for inode 10485897 >> and >> xfsdump: WARNING: could not stat dirent .viminfo ino 10485896: No such >> file or directory: using null generation count in directory entry >> >> What's causing these? Can they be ignored? >> >> Thanks, >> Alex >> >> Rereading. Hmmm, I wouldn't have expected these msgs from readonly snapshots. --Tim From owner-linux-xfs@oss.sgi.com Mon Oct 24 21:31:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Oct 2005 21:31:27 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9P4VMO0022864 for ; Mon, 24 Oct 2005 21:31:23 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA19939; Tue, 25 Oct 2005 14:28:04 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j9P4S7kt5102247; Tue, 25 Oct 2005 14:28:12 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9P4S0HD6036834; Tue, 25 Oct 2005 14:28:00 +1000 (EST) Date: Tue, 25 Oct 2005 14:28:00 +1000 From: Nathan Scott To: alex@alexfisher.me.uk, tim shimmin Cc: linux-xfs@oss.sgi.com Subject: Re: xfs and lvm snapshots Message-ID: <20051025142800.F6002974@wobbly.melbourne.sgi.com> References: <5449aac20510061026o69854e8ai16ab5eb3787094f7@mail.gmail.com> <20051006224407.GF722@frodo> <5449aac20510070716j55e987aega2142d5b26ed1dec@mail.gmail.com> <5449aac20510210639t5ee4baf3n83d615715703994c@mail.gmail.com> <435DAB4F.8060501@sgi.com> <435DADFC.1080100@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <435DADFC.1080100@sgi.com>; from tes@sgi.com on Tue, Oct 25, 2005 at 02:01:00PM +1000 X-archive-position: 6430 X-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: 1207 Lines: 41 On Tue, Oct 25, 2005 at 02:01:00PM +1000, tim shimmin wrote: > tim shimmin wrote: > > Hi Alex, > > > > Alexander Fisher wrote: > >> Hi again. > >> > >> I've mounted my snapshots readonly, but I occasionally get warnings > >> from xfsdump during the backups. I get two different types of > >> warning. > >> > >> xfsdump: WARNING: failed to get bulkstat information for inode 10485897 > >> and > >> xfsdump: WARNING: could not stat dirent .viminfo ino 10485896: No such > >> file or directory: using null generation count in directory entry > >> > >> What's causing these? Can they be ignored? They can be ignored - they are inodes that were previously unlinked, but are still partially there on the snapshot volume, and visible to the by-handle interfaces that xfsdump is using to extract all of the inodes in the snapshot. > >> Thanks, > >> Alex > >> > >> > Rereading. > Hmmm, I wouldn't have expected these msgs from readonly snapshots. > We don't process the unlinked lists on a snapshot atm (no recovery is done, as we don't leave a dirty log on the snapshot, on Linux). We probably should be doing that, then these unlinked inodes would not still be visible to bulkstat. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 25 10:34:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Oct 2005 10:34:37 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9PHYWO0014468 for ; Tue, 25 Oct 2005 10:34:32 -0700 Received: by xproxy.gmail.com with SMTP id t15so326184wxc for ; Tue, 25 Oct 2005 10:31:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Xc0f2EzICXn3nhqHl73wXBi5NZ9rSm9Rvl5vOS1W1qEypuH1IL7/TErdha3LfCLLqbZ37kdrsv5liQKUxR85fdsVpK1M9th2Hv0Vi/UAdI2zLN/khNJkyirFWLeSUEfUZFVXIovebw7hd9GVIzZhGA6pHETlFoMafhe6gDobfjA= Received: by 10.70.103.15 with SMTP id a15mr4365137wxc; Tue, 25 Oct 2005 10:31:23 -0700 (PDT) Received: by 10.70.70.9 with HTTP; Tue, 25 Oct 2005 10:31:23 -0700 (PDT) Message-ID: Date: Tue, 25 Oct 2005 11:31:23 -0600 From: Nick I To: linux-xfs@oss.sgi.com Subject: Ask the Cluster Expert MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6432 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: clusterbuilder@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1028 Lines: 26 Hi. Thanks to the response from many in the community I have added sections about diskless clusters and information on 32-bit and 64-bit processors at the site I help run, www.ClusterBuilder.org.I also added a section called Ask the Cluster Expert ( http://www.clusterbuilder.org/pages/ask-the-expert.php) for people to submit questions they have about cluster and grid computing. I post the questions at an FAQ page (http://www.clusterbuilder.org/pages/ask-the-expert/faq.php) and then research the answer as well as allow those knowledgeable in the community to submit a response to the question. I want to build a valuable knowledgebase of high performance computing information. I need you to share your knowledge by adding to the question responses and also submitting questions/answers to common problems you've experienced in the past and are experiencing now. A sample question could be about the file systems running on a cluster. Thanks, Nick [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Oct 25 19:00:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Oct 2005 19:00:38 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9Q20VO0025953 for ; Tue, 25 Oct 2005 19:00:32 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA14439; Wed, 26 Oct 2005 11:56:57 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 1F47A49E5F12; Wed, 26 Oct 2005 11:56:56 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 944818 - xfs_db frag command fix Message-Id: <20051026015656.1F47A49E5F12@chook.melbourne.sgi.com> Date: Wed, 26 Oct 2005 11:56:56 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6433 X-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: 467 Lines: 14 Fix an endian-related regression in the xfs_db frag command. Date: Wed Oct 26 11:56:28 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: sandeen,hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24209a xfsprogs/db/frag.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/frag.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h From owner-linux-xfs@oss.sgi.com Tue Oct 25 20:18:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Oct 2005 20:18:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9Q3IiO0031524 for ; Tue, 25 Oct 2005 20:18:45 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA15772; Wed, 26 Oct 2005 13:15:30 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 0809149E5F48; Wed, 26 Oct 2005 13:15:29 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 944821 - minor cleanup Message-Id: <20051026031529.0809149E5F48@chook.melbourne.sgi.com> Date: Wed, 26 Oct 2005 13:15:29 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6434 X-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: 1389 Lines: 36 Remove old, broken nolog-mode code - noone plans to ever fix it. Date: Wed Oct 26 13:12:17 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen,overby The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24213a xfs_log.c - 1.312 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.312&r2=text&tr2=1.311&f=h xfs_log_priv.h - 1.110 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.110&r2=text&tr2=1.109&f=h xfs_vfsops.c - 1.484 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.484&r2=text&tr2=1.483&f=h xfs_trans.c - 1.167 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.167&r2=text&tr2=1.166&f=h Remove an unhelpful ifdef, the comment above the routine explains the purpose well enough here. Date: Wed Oct 26 13:14:13 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen,overby The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24214a xfs_da_btree.c - 1.158 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.158&r2=text&tr2=1.157&f=h From owner-linux-xfs@oss.sgi.com Tue Oct 25 23:42:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Oct 2005 23:42:28 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9Q6gMO0016625 for ; Tue, 25 Oct 2005 23:42:23 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19501; Wed, 26 Oct 2005 16:39:08 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 9FF8449E5EED; Wed, 26 Oct 2005 16:39:07 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 944820 - fix large direct IOs Message-Id: <20051026063907.9FF8449E5EED@chook.melbourne.sgi.com> Date: Wed, 26 Oct 2005 16:39:07 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6435 X-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: 496 Lines: 15 Fix boundary conditions when issuing direct IOs from large userspace buffers (>4GiB). Date: Wed Oct 26 16:38:30 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24223a linux-2.6/xfs_aops.c - 1.98 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.98&r2=text&tr2=1.97&f=h From owner-linux-xfs@oss.sgi.com Wed Oct 26 05:57:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Oct 2005 05:57:52 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9QCvlO0021476 for ; Wed, 26 Oct 2005 05:57:47 -0700 Received: by wproxy.gmail.com with SMTP id i30so51130wra for ; Wed, 26 Oct 2005 05:54:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=uMSpm3hQtpvJFu6ujkJXUpdVq8C5+7YI4sBoKVM33EGXnKXab27SmWmkySoLQjrmJC99cMJD8PIMR9FlXFGbcRkcqR1nFjhW9zOm5uDIZ/D3Fnc83rjOnyO41nGCUhel+d0lP++4MXi8a1NAdCthlX2mnV3NjeHuKI90wd6iLiw= Received: by 10.54.153.16 with SMTP id a16mr441496wre; Wed, 26 Oct 2005 05:53:00 -0700 (PDT) Received: by 10.54.77.11 with HTTP; Wed, 26 Oct 2005 05:54:37 -0700 (PDT) Message-ID: Date: Wed, 26 Oct 2005 13:54:37 +0100 From: Roger Willcocks To: linux-xfs@oss.sgi.com Subject: bad calc for flagging pagf_metadata MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j9QCvmO0021481 X-archive-position: 6436 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: willcor@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 863 Lines: 19 When XFS_MOUNT_32BITINODES is true and imaxpct is set, the calculation for max_metadata in xfs_initialize_perag is incorrect, yielding a value that's tens of thousands of times too large. This results in the entire area of the disk that's available for inodes being flagged as preferred for metadata. The allocator won't touch that area until all the other ag's are full. Patch-like fix below. Since this only sets a runtime ag preference flag, it's safe for existing file systems. -- Roger xfs_mount.c / xfs_initialize_perag: icount = sbp->sb_dblocks * sbp->sb_imax_pct; do_div(icount, 100); icount += sbp->sb_agblocks - 1; - do_div(icount, mp->m_ialloc_blks); + do_div(icount, sbp->sb_agblocks); max_metadata = icount; From owner-linux-xfs@oss.sgi.com Wed Oct 26 09:23:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Oct 2005 09:23:31 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9QGNRO0008823 for ; Wed, 26 Oct 2005 09:23:27 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9QHRhXv016178 for ; Wed, 26 Oct 2005 10:27:43 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9QGJGsL24231431; Wed, 26 Oct 2005 11:19:16 -0500 (CDT) Message-ID: <435FAC83.3030607@sgi.com> Date: Wed, 26 Oct 2005 11:19:15 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Willcocks CC: linux-xfs@oss.sgi.com Subject: Re: bad calc for flagging pagf_metadata References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1076 Lines: 28 Roger Willcocks wrote: > When XFS_MOUNT_32BITINODES is true and imaxpct is set, the calculation > for max_metadata in xfs_initialize_perag is incorrect, yielding a > value that's tens of thousands of times too large. This results in the > entire area of the disk that's available for inodes being flagged as > preferred for metadata. The allocator won't touch that area until all > the other ag's are full. Patch-like fix below. Since this only sets a > runtime ag preference flag, it's safe for existing file systems. > > -- > Roger > > xfs_mount.c / xfs_initialize_perag: > icount = sbp->sb_dblocks * sbp->sb_imax_pct; > do_div(icount, 100); > icount += sbp->sb_agblocks - 1; > - do_div(icount, mp->m_ialloc_blks); > + do_div(icount, sbp->sb_agblocks); > max_metadata = icount; > You are right, and in fact Irix does this correctly - looks like something was missed in the translation. :( We'll get that fixed. Thanks! -Eric From owner-linux-xfs@oss.sgi.com Wed Oct 26 09:36:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Oct 2005 09:36:25 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9QGaKO0009786 for ; Wed, 26 Oct 2005 09:36:20 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j9QHeaUX018271 for ; Wed, 26 Oct 2005 10:40:36 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9QGXADN18564933 for ; Wed, 26 Oct 2005 11:33:10 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j9QGWsLL15813504; Wed, 26 Oct 2005 11:32:54 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j9QGX9vM018161; Wed, 26 Oct 2005 11:33:09 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j9QGX8w0018159; Wed, 26 Oct 2005 11:33:08 -0500 Date: Wed, 26 Oct 2005 11:33:08 -0500 From: Eric Sandeen Message-Id: <200510261633.j9QGX8w0018159@penguin.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 944858 - Fix calculation of reserved AGs for inodes in 32-bit inode mode X-archive-position: 6438 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 617 Lines: 18 Fix calculation of reserved AGs for inodes in 32-bit inode mode Spotted by Roger Willcocks Date: Wed Oct 26 09:32:51 PDT 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: overby The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:201213a xfs_mount.c - 1.366 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.366&r2=text&tr2=1.365&f=h - Fix calculation of reserved AGs for inodes in 32-bit inode mode Mis-merge from Irix xfs implementation From owner-linux-xfs@oss.sgi.com Wed Oct 26 21:08:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Oct 2005 21:08:25 -0700 (PDT) Received: from mail.belkam.com (relay1.belkam.com [217.14.198.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9R480O0029906 for ; Wed, 26 Oct 2005 21:08:21 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.belkam.com (Postfix) with ESMTP id 9CC1611DDD2 for ; Thu, 27 Oct 2005 09:04:45 +0500 (SAMST) Received: from mail.belkam.com ([127.0.0.1]) by localhost (gopher [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03254-07 for ; Thu, 27 Oct 2005 09:04:44 +0500 (SAMST) Received: from vader.belkam.com (dm.p98.belkam.com [192.168.22.229]) by mail.belkam.com (Postfix) with ESMTP id AA52811DCEE for ; Thu, 27 Oct 2005 09:04:44 +0500 (SAMST) Message-ID: <436051DC.8040203@vader.belkam.com> Date: Thu, 27 Oct 2005 09:04:44 +0500 From: Dmitry Melekhov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs oops with full partition Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dm@vader.belkam.com Precedence: bulk X-list: linux-xfs Content-Length: 3464 Lines: 86 Hello! I don't know which xfs version is in suse kernel. We get following oopses when users write to 100% full partition: Unable to handle kernel NULL pointer dereference at virtual address 00000004 f945a5d4 *pde = 00000000 Oops: 0002 [#1] CPU: 0 EIP: 0060:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 (2.6.5-7.201-smp SLES9_SP2_BRANCH-200508250620450000) eax: 00000000 ebx: ffffffff ecx: fffffc19 edx: ffffffff esi: cafe2218 edi: e2f47648 ebp: f60bb018 esp: cdc83e10 ds: 007b es: 007b ss: 0068 Stack: d7c76804 e2f47648 f60bb000 000017d4 00001cea 00000000 00000000 000017d4 e2f47648 000017d4 00001cea f9459278 000017d4 00001cea 00000000 00000001 f60bb000 ee7085f0 000017d4 00001cea ee7085e0 000017cc 00001cea 000017d4 Call Trace: [] xfs_trans_chunk_committed+0x168/0x200 [xfs] [] xfs_trans_committed+0x3c/0x100 [xfs] [] xlog_state_do_callback+0x24c/0x3e0 [xfs] [] schedule+0x65a/0xe40 [] xlog_iodone+0x9f/0x130 [xfs] [] pagebuf_iodone_work+0x27/0x40 [xfs] [] worker_thread+0x187/0x230 [] pagebuf_iodone_work+0x0/0x40 [xfs] [] default_wake_function+0x0/0x10 [] default_wake_function+0x0/0x10 [] worker_thread+0x0/0x230 [] kthread+0xd4/0x118 [] kthread+0x0/0x118 [] kernel_thread_helper+0x5/0x10 Code: 89 78 04 8b 44 24 08 ff 40 20 8b 54 24 04 39 14 24 74 3e b0 >>EIP; f945a5d4 <__crc_dma_pool_free+4de965/69c753> <===== >>ebx; ffffffff <__kernel_rt_sigreturn+1bbf/????> >>ecx; fffffc19 <__kernel_rt_sigreturn+17d9/????> >>edx; ffffffff <__kernel_rt_sigreturn+1bbf/????> >>esi; cafe2218 <__crc_dev_change_flags+33aa1/20bfbe> >>edi; e2f47648 <__crc_class_simple_device_remove+2911c/4eed5b> >>ebp; f60bb018 <__crc___ip_select_ident+461513/65b400> >>esp; cdc83e10 <__crc_fsync_buffers_list+34509f/856d01> Trace; f9459278 <__crc_dma_pool_free+4dd609/69c753> Trace; f945934c <__crc_dma_pool_free+4dd6dd/69c753> Trace; f944c16c <__crc_dma_pool_free+4d04fd/69c753> Trace; c012677a Trace; f944c39f <__crc_dma_pool_free+4d0730/69c753> Trace; f9472257 <__crc_dma_pool_free+4f65e8/69c753> Trace; c013bfe7 Trace; f9472230 <__crc_dma_pool_free+4f65c1/69c753> Trace; c0123e80 Trace; c0123e80 Trace; c013be60 Trace; c013fc54 Trace; c013fb80 Trace; c0107005 Code; f945a5d4 <__crc_dma_pool_free+4de965/69c753> 00000000 <_EIP>: Code; f945a5d4 <__crc_dma_pool_free+4de965/69c753> <===== 0: 89 78 04 mov %edi,0x4(%eax) <===== Code; f945a5d7 <__crc_dma_pool_free+4de968/69c753> 3: 8b 44 24 08 mov 0x8(%esp),%eax Code; f945a5db <__crc_dma_pool_free+4de96c/69c753> 7: ff 40 20 incl 0x20(%eax) Code; f945a5de <__crc_dma_pool_free+4de96f/69c753> a: 8b 54 24 04 mov 0x4(%esp),%edx Code; f945a5e2 <__crc_dma_pool_free+4de973/69c753> e: 39 14 24 cmp %edx,(%esp) Code; f945a5e5 <__crc_dma_pool_free+4de976/69c753> 11: 74 3e je 51 <_EIP+0x51> Code; f945a5e7 <__crc_dma_pool_free+4de978/69c753> 13: b0 00 mov $0x0,%al Is this problem already fixed in lates xfs code? From owner-linux-xfs@oss.sgi.com Wed Oct 26 22:43:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Oct 2005 22:43:44 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9R5heO0002754 for ; Wed, 26 Oct 2005 22:43:41 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA15915; Thu, 27 Oct 2005 15:40:18 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id E499E49E5F48; Thu, 27 Oct 2005 15:40:17 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 944819 - fsync fix Message-Id: <20051027054017.E499E49E5F48@chook.melbourne.sgi.com> Date: Thu, 27 Oct 2005 15:40:17 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6440 X-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: 631 Lines: 16 Ensure fsync does not incorrectly return EIO for pages beyond EOF. Date: Thu Oct 27 15:39:25 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24236a linux-2.6/xfs_aops.c - 1.99 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.99&r2=text&tr2=1.98&f=h linux-2.4/xfs_aops.c - 1.94 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.94&r2=text&tr2=1.93&f=h From owner-linux-xfs@oss.sgi.com Thu Oct 27 20:45:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Oct 2005 20:45:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9S3jRO0008668 for ; Thu, 27 Oct 2005 20:45:28 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA10461 for ; Fri, 28 Oct 2005 13:42:15 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 8E3AA49E5EF3; Fri, 28 Oct 2005 13:42:09 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - docs update Message-Id: <20051028034209.8E3AA49E5EF3@chook.melbourne.sgi.com> Date: Fri, 28 Oct 2005 13:42:09 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6444 X-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: 660 Lines: 16 Update XFS mount option documentation (and split-out patch). Date: Fri Oct 28 13:41:54 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: 2.6.x-xfs-melb:linux:24249a Documentation/filesystems/xfs.txt - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/filesystems/xfs.txt.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h split-patches/docs-update - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/docs-update.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h From owner-linux-xfs@oss.sgi.com Fri Oct 28 12:07:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Oct 2005 12:07:37 -0700 (PDT) Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9SJ7XO0016249 for ; Fri, 28 Oct 2005 12:07:34 -0700 Received: from AndyLiebman@aol.com by imo-d04.mx.aol.com (mail_out_v38_r6.3.) id 4.190.4ba4a2cb (3850); Fri, 28 Oct 2005 15:04:10 -0400 (EDT) From: AndyLiebman@aol.com Message-ID: <190.4ba4a2cb.3093d02a@aol.com> Date: Fri, 28 Oct 2005 15:04:10 EDT Subject: What happened to XFS Quota Support? To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 Security Edition for Windows sub 2340 X-archive-position: 6448 X-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: 814 Lines: 18 In previous Linux kernels -- 2.6.13 and below -- XFS quota could be set "statically" -- that is, in "make xconfig" you could put a "check mark" in the XFS_quota support box even though you had a "dot" (module) in the Overall XFS_Filesystem support box . In 2.6.14, not only has XFS support moved under filesystems with all the other filesystems, but you can no longer put a "checkmark" in the "quota support" box if you compile XFS support as a module. Is this by design? Looking back at all of my past kernels, xfs is enabled as a module but quota support is enabled statically. This is how config files have been coming from Mandrake for at least the past year. Is there a reason why this option is no longer available? If you compile xfs_quota as a module, how do you load it? Andy From owner-linux-xfs@oss.sgi.com Fri Oct 28 12:49:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Oct 2005 12:49:35 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9SJnRO0023161 for ; Fri, 28 Oct 2005 12:49:30 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA28443; Sat, 29 Oct 2005 05:46:11 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j9SJkLkt6123689; Sat, 29 Oct 2005 05:46:21 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9SJkJgi6126066; Sat, 29 Oct 2005 05:46:19 +1000 (EST) Date: Sat, 29 Oct 2005 05:46:18 +1000 From: Nathan Scott To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: What happened to XFS Quota Support? Message-ID: <20051029054618.A6139565@wobbly.melbourne.sgi.com> References: <190.4ba4a2cb.3093d02a@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: <190.4ba4a2cb.3093d02a@aol.com>; from AndyLiebman@aol.com on Fri, Oct 28, 2005 at 03:04:10PM -0400 X-archive-position: 6449 X-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: 391 Lines: 22 Hi Andy, On Fri, Oct 28, 2005 at 03:04:10PM -0400, AndyLiebman@aol.com wrote: > ... > Is there a reason why this option is no longer available? If you compile > xfs_quota as a module, how do you load it? Oh, bother - the option: config XFS_QUOTA tristate "XFS Quota support" should be: config XFS_QUOTA bool "XFS Quota support" I'll get that fixed up, thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 28 13:23:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Oct 2005 13:23:19 -0700 (PDT) Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9SKNDO0025649 for ; Fri, 28 Oct 2005 13:23:16 -0700 Received: from [192.168.0.10] (83-216-143-24.alista342.adsl.metronet.co.uk [83.216.143.24]) by mail.metronet.co.uk (MetroNet Mail) with ESMTP id 5E5914182A8; Fri, 28 Oct 2005 21:17:15 +0100 (BST) From: Alistair John Strachan To: Nathan Scott Subject: Re: What happened to XFS Quota Support? Date: Fri, 28 Oct 2005 21:18:45 +0100 User-Agent: KMail/1.8.92 Cc: AndyLiebman@aol.com, linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <190.4ba4a2cb.3093d02a@aol.com> <20051029054618.A6139565@wobbly.melbourne.sgi.com> In-Reply-To: <20051029054618.A6139565@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: <200510282118.45167.s0348365@sms.ed.ac.uk> X-archive-position: 6450 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: s0348365@sms.ed.ac.uk Precedence: bulk X-list: linux-xfs Content-Length: 680 Lines: 30 On Friday 28 October 2005 20:46, Nathan Scott wrote: > Hi Andy, > > On Fri, Oct 28, 2005 at 03:04:10PM -0400, AndyLiebman@aol.com wrote: > > ... > > Is there a reason why this option is no longer available? If you compile > > xfs_quota as a module, how do you load it? > > Oh, bother - the option: > > config XFS_QUOTA > tristate "XFS Quota support" > > should be: > > config XFS_QUOTA > bool "XFS Quota support" > > I'll get that fixed up, thanks. This might be a good thing to put in 2.6.14.1. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. From owner-linux-xfs@oss.sgi.com Fri Oct 28 13:36:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Oct 2005 13:36:46 -0700 (PDT) Received: from imo-m15.mx.aol.com (imo-m15.mx.aol.com [64.12.138.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9SKagO0026585 for ; Fri, 28 Oct 2005 13:36:42 -0700 Received: from AndyLiebman@aol.com by imo-m15.mx.aol.com (mail_out_v38_r6.3.) id 5.46.74cc8004 (3850); Fri, 28 Oct 2005 16:33:21 -0400 (EDT) From: AndyLiebman@aol.com Message-ID: <46.74cc8004.3093e511@aol.com> Date: Fri, 28 Oct 2005 16:33:21 EDT Subject: Re: What happened to XFS Quota Support? To: nathans@sgi.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com MIME-Version: 1.0 X-Mailer: 9.0 Security Edition for Windows sub 2340 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6451 X-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: 676 Lines: 35 In a message dated 10/28/2005 3:46:36 P.M. Eastern Standard Time, nathans@sgi.com writes: Oh, bother - the option: config XFS_QUOTA tristate "XFS Quota support" should be: config XFS_QUOTA bool "XFS Quota support" I'll get that fixed up, thanks. Nathan, I tried compiling XFS statically into the kernel and it's also a "no go" on quota support. So, am I to conclude that 2.6.14 as it currently stands cannot support XFS quotas? As you know, we have quite a few users who have been waiting for the XFS changes that went into 2.6.14 (as you and I have discussed). Hope the fix comes along soon. Best, Andy [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Oct 28 13:36:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Oct 2005 13:36:58 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9SKalO0026580 for ; Fri, 28 Oct 2005 13:36:48 -0700 Received: (qmail 21900 invoked from network); 28 Oct 2005 20:33:25 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 28 Oct 2005 20:33:25 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 8DAADBC212; Fri, 28 Oct 2005 22:33:25 +0200 (CEST) Date: Fri, 28 Oct 2005 22:33:25 +0200 From: Adrian Bunk To: Andrew Morton , stable@kernel.org Cc: linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, nathans@sgi.com, linux-xfs@oss.sgi.com, Dimitri Puzin Subject: [2.6 patch] fix XFS_QUOTA for modular XFS Message-ID: <20051028203325.GD4180@stusta.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-archive-position: 6452 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: linux-xfs Content-Length: 1117 Lines: 31 This patch by Dimitri Puzin submitted through kernel Bugzilla #5514 fixes the following issue: Cannot build XFS filesystem support as module with quota support. It works only when the XFS filesystem support is compiled into the kernel. Menuconfig prevents from setting CONFIG_XFS_FS=m and CONFIG_XFS_QUOTA=y. How to reproduce: configure the XFS filesystem with quota support as module. The resulting kernel won't have quota support compiled into xfs.ko. Fix: Changing the fs/xfs/Kconfig file from tristate to bool lets you configure the quota support to be compiled into the XFS module. The Makefile-linux-2.6 checks only for CONFIG_XFS_QUOTA=y. From: Dimitri Puzin Signed-off-by: Adrian Bunk --- linux-2.6.14-rc5-mm1/fs/xfs/Kconfig.old 2005-10-28 19:51:02.000000000 +0200 +++ linux-2.6.14-rc5-mm1/fs/xfs/Kconfig 2005-10-28 19:51:12.000000000 +0200 @@ -24,7 +24,7 @@ default y config XFS_QUOTA - tristate "XFS Quota support" + bool "XFS Quota support" depends on XFS_FS help If you say Y here, you will be able to set limits for disk usage on From owner-linux-xfs@oss.sgi.com Fri Oct 28 14:20:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Oct 2005 14:20:51 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9SLKfO0030745 for ; Fri, 28 Oct 2005 14:20:42 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA00127; Sat, 29 Oct 2005 07:15:48 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j9SLFwkt6126496; Sat, 29 Oct 2005 07:15:59 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9SLFq4A6139416; Sat, 29 Oct 2005 07:15:52 +1000 (EST) Date: Sat, 29 Oct 2005 07:15:52 +1000 From: Nathan Scott To: Adrian Bunk , Dimitri Puzin Cc: Andrew Morton , stable@kernel.org, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.6 patch] fix XFS_QUOTA for modular XFS Message-ID: <20051029071552.A6135176@wobbly.melbourne.sgi.com> References: <20051028203325.GD4180@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051028203325.GD4180@stusta.de>; from bunk@stusta.de on Fri, Oct 28, 2005 at 10:33:25PM +0200 X-archive-position: 6453 X-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: 394 Lines: 17 On Fri, Oct 28, 2005 at 10:33:25PM +0200, Adrian Bunk wrote: > This patch by Dimitri Puzin submitted through kernel Bugzilla #5514 > fixes the following issue: > ... > From: Dimitri Puzin > Signed-off-by: Adrian Bunk Thanks guys; feel free to add: Signed-off-by: Nathan Scott (Or Acked-by: or whatever). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 28 14:28:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Oct 2005 14:28:47 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9SLSgO0031716 for ; Fri, 28 Oct 2005 14:28:43 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA00319; Sat, 29 Oct 2005 07:25:26 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j9SLPckt6143122; Sat, 29 Oct 2005 07:25:38 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9SLPYid6142260; Sat, 29 Oct 2005 07:25:34 +1000 (EST) Date: Sat, 29 Oct 2005 07:25:34 +1000 From: Nathan Scott To: AndyLiebman@aol.com Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: What happened to XFS Quota Support? Message-ID: <20051029072533.A6139033@wobbly.melbourne.sgi.com> References: <46.74cc8004.3093e511@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: <46.74cc8004.3093e511@aol.com>; from AndyLiebman@aol.com on Fri, Oct 28, 2005 at 04:33:21PM -0400 X-archive-position: 6454 X-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: 682 Lines: 20 On Fri, Oct 28, 2005 at 04:33:21PM -0400, AndyLiebman@aol.com wrote: > I tried compiling XFS statically into the kernel and it's also a "no go" on > quota support. So, am I to conclude that 2.6.14 as it currently stands cannot > support XFS quotas? Hmm, I'd have thought it'd work builtin, thats how I tend to use it. Either way, the code is all there, its just an annoying config issue. > As you know, we have quite a few users who have been waiting for the XFS > changes that went into 2.6.14 (as you and I have discussed). Hope the fix comes > along soon. Theres a patch already floating around that will resolve it, let me know how that goes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 28 15:18:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Oct 2005 15:18:43 -0700 (PDT) Received: from imo-m23.mail.aol.com (imo-m23.mx.aol.com [64.12.137.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9SMIdO0002025 for ; Fri, 28 Oct 2005 15:18:40 -0700 Received: from AndyLiebman@aol.com by imo-m23.mx.aol.com (mail_out_v38_r6.3.) id 5.79.50cb86c7 (3850); Fri, 28 Oct 2005 18:15:23 -0400 (EDT) From: AndyLiebman@aol.com Message-ID: <79.50cb86c7.3093fcfa@aol.com> Date: Fri, 28 Oct 2005 18:15:22 EDT Subject: Re: What happened to XFS Quota Support? To: nathans@sgi.com CC: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com MIME-Version: 1.0 X-Mailer: 9.0 Security Edition for Windows sub 2340 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6455 X-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: 1147 Lines: 40 In a message dated 10/28/2005 5:25:49 P.M. Eastern Standard Time, nathans@sgi.com writes: On Fri, Oct 28, 2005 at 04:33:21PM -0400, AndyLiebman@aol.com wrote: > I tried compiling XFS statically into the kernel and it's also a "no go" on > quota support. So, am I to conclude that 2.6.14 as it currently stands cannot > support XFS quotas? Hmm, I'd have thought it'd work builtin, thats how I tend to use it. Either way, the code is all there, its just an annoying config issue. > As you know, we have quite a few users who have been waiting for the XFS > changes that went into 2.6.14 (as you and I have discussed). Hope the fix comes > along soon. Theres a patch already floating around that will resolve it, let me know how that goes. cheers. Nathan, could you be a little clearer on this. What do you mean by "there's a patch already floating around". If I knew where to get the patch, I would have installed it already rather than wasting half a day compiling various flavors of the new kernel (no preemption, voluntary preemption, high preemption). Andy [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Oct 28 15:49:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Oct 2005 15:50:04 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9SMntO0004027 for ; Fri, 28 Oct 2005 15:49:56 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA02256; Sat, 29 Oct 2005 08:46:24 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j9SMkbkt6143959; Sat, 29 Oct 2005 08:46:37 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9SMkY1I6109796; Sat, 29 Oct 2005 08:46:34 +1000 (EST) Date: Sat, 29 Oct 2005 08:46:33 +1000 From: Nathan Scott To: AndyLiebman@aol.com Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: What happened to XFS Quota Support? Message-ID: <20051029084633.A6142170@wobbly.melbourne.sgi.com> References: <79.50cb86c7.3093fcfa@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: <79.50cb86c7.3093fcfa@aol.com>; from AndyLiebman@aol.com on Fri, Oct 28, 2005 at 06:15:22PM -0400 X-archive-position: 6456 X-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: 2016 Lines: 58 On Fri, Oct 28, 2005 at 06:15:22PM -0400, AndyLiebman@aol.com wrote: > could you be a little clearer on this. What do you mean by "there's a patch > already floating around". If I knew where to get the patch, I would have > installed it already rather than wasting half a day compiling various flavors of > the new kernel (no preemption, voluntary preemption, high preemption). > Oh, sorry - I was refering to this... cheers. -- Nathan ----- Forwarded message from Adrian Bunk ----- Date: Fri, 28 Oct 2005 22:33:25 +0200 To: Andrew Morton , stable@kernel.org Cc: linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, nathans@sgi.com, linux-xfs@oss.sgi.com, Dimitri Puzin User-Agent: Mutt/1.5.11 From: Adrian Bunk Subject: [2.6 patch] fix XFS_QUOTA for modular XFS This patch by Dimitri Puzin submitted through kernel Bugzilla #5514 fixes the following issue: Cannot build XFS filesystem support as module with quota support. It works only when the XFS filesystem support is compiled into the kernel. Menuconfig prevents from setting CONFIG_XFS_FS=m and CONFIG_XFS_QUOTA=y. How to reproduce: configure the XFS filesystem with quota support as module. The resulting kernel won't have quota support compiled into xfs.ko. Fix: Changing the fs/xfs/Kconfig file from tristate to bool lets you configure the quota support to be compiled into the XFS module. The Makefile-linux-2.6 checks only for CONFIG_XFS_QUOTA=y. From: Dimitri Puzin Signed-off-by: Adrian Bunk --- linux-2.6.14-rc5-mm1/fs/xfs/Kconfig.old 2005-10-28 19:51:02.000000000 +0200 +++ linux-2.6.14-rc5-mm1/fs/xfs/Kconfig 2005-10-28 19:51:12.000000000 +0200 @@ -24,7 +24,7 @@ default y config XFS_QUOTA - tristate "XFS Quota support" + bool "XFS Quota support" depends on XFS_FS help If you say Y here, you will be able to set limits for disk usage on ----- End forwarded message ----- From owner-linux-xfs@oss.sgi.com Sat Oct 29 08:40:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Oct 2005 08:40:14 -0700 (PDT) Received: from imo-d23.mx.aol.com (imo-d23.mx.aol.com [205.188.139.137]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9TFe9O0028969 for ; Sat, 29 Oct 2005 08:40:10 -0700 Received: from AndyLiebman@aol.com by imo-d23.mx.aol.com (mail_out_v38_r6.3.) id 5.74.5fcdf18f (48624); Sat, 29 Oct 2005 11:36:50 -0400 (EDT) From: AndyLiebman@aol.com Message-ID: <74.5fcdf18f.3094f111@aol.com> Date: Sat, 29 Oct 2005 11:36:49 EDT Subject: Re: What happened to XFS Quota Support? To: nathans@sgi.com CC: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 Security Edition for Windows sub 2340 X-archive-position: 6457 X-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: 688 Lines: 20 >In a message dated 10/28/2005 6:47:02 P.M. Eastern Standard Time, nathans@sgi.com >writes: >This patch by Dimitri Puzin submitted through kernel Bugzilla #5514 >fixes the following issue: > >Cannot build XFS filesystem support as module with quota support. It >works only when the XFS filesystem support is compiled into the kernel. >Menuconfig prevents from setting CONFIG_XFS_FS=m and CONFIG_XFS_QUOTA=y. > >Fix: Changing the fs/xfs/Kconfig file from tristate to bool lets you >configure the quota support to be compiled into the XFS module. The >Makefile-linux-2.6 checks only for CONFIG_XFS_QUOTA=y. Just wanted to let you know this works fine. Andy Liebman From owner-linux-xfs@oss.sgi.com Sat Oct 29 15:44:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Oct 2005 15:44:55 -0700 (PDT) Received: from american.megatrends.com (american.megatrends.com [155.229.80.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9TMieO0003917 for ; Sat, 29 Oct 2005 15:44:45 -0700 Received: by american.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Oct 2005 18:41:23 -0400 Message-ID: <3225AF1B8CBF83459982D4987F1549CE055F2C@fre-ops.us.megatrends.com> From: Srikumar Subramanian To: Nathan Scott Cc: acl-devel-owner@bestbits.at, "'linux-xfs@oss.sgi.com'" , ag@bestbits.at, Prabhakar Krishnan Subject: RE: kernel panic with XFS ACL inheritance on a FULL file system Date: Sat, 29 Oct 2005 18:44:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 6459 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: SrikumarS@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 931 Lines: 41 Hi Nathan, I took 2.6.13.4 from kernel.org and I could able to reproduce the problem. Kernal panic appeared at the same location. In xfs_trans_ail.c, xfs_ail_insert() causes the panic. Based on objdump, "lip->li_ail.ail_forw->li_ail.ail_back = lip;" causes panic because lip->li_ail.ail_forw is NULL Regards, Srikumar -----Original Message----- From: Nathan Scott [mailto:nathans@sgi.com] Sent: Tuesday, October 18, 2005 7:23 AM To: Srikumar Subramanian Cc: acl-devel-owner@bestbits.at; 'linux-xfs@oss.sgi.com'; ag@bestbits.at; Prabhakar Krishnan Subject: Re: kernel panic with XFS ACL inheritance on a FULL file system On Tue, Oct 18, 2005 at 03:38:54AM -0400, Srikumar Subramanian wrote: > Hi All, > > We are testing XFS with ACL and got a issue when file system is full. > > Configuration: > FC3; XFS 1.3; kernel 2.6.9-1.667smp Try a more recent kernel - mainline, or XFS CVS on oss.sgi.com. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 30 14:53:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Oct 2005 14:53:45 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9UMrdO0022692 for ; Sun, 30 Oct 2005 14:53:40 -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 JAA14829; Mon, 31 Oct 2005 09:49:35 +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 j9UMnlkt6197314; Mon, 31 Oct 2005 09:49:48 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9UMnhqx6137436; Mon, 31 Oct 2005 09:49:43 +1100 (EST) Date: Mon, 31 Oct 2005 09:49:43 +1100 From: Nathan Scott To: Srikumar Subramanian , tes@melbourne.sgi.com Cc: acl-devel-owner@bestbits.at, "'linux-xfs@oss.sgi.com'" , ag@bestbits.at, Prabhakar Krishnan Subject: Re: kernel panic with XFS ACL inheritance on a FULL file system Message-ID: <20051031094943.B6197967@wobbly.melbourne.sgi.com> References: <3225AF1B8CBF83459982D4987F1549CE055F2C@fre-ops.us.megatrends.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3225AF1B8CBF83459982D4987F1549CE055F2C@fre-ops.us.megatrends.com>; from SrikumarS@ami.com on Sat, Oct 29, 2005 at 06:44:13PM -0400 X-archive-position: 6460 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 511 Lines: 23 On Sat, Oct 29, 2005 at 06:44:13PM -0400, Srikumar Subramanian wrote: > Hi Nathan, > > I took 2.6.13.4 from kernel.org and I could able to reproduce the problem. > > Kernal panic appeared at the same location. > > In xfs_trans_ail.c, xfs_ail_insert() causes the panic. > > Based on objdump, "lip->li_ail.ail_forw->li_ail.ail_back = lip;" causes > panic because > lip->li_ail.ail_forw is NULL > Thanks Srikumar, Tim, looks like there remains a log bug here for you to look into...? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 30 15:29:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Oct 2005 15:29:31 -0800 (PST) Received: from outmx013.isp.belgacom.be (outmx013.isp.belgacom.be [195.238.3.64]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9UNTQO0025399 for ; Sun, 30 Oct 2005 15:29:27 -0800 Received: from outmx013.isp.belgacom.be (localhost [127.0.0.1]) by outmx013.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j9UNQ54S005161 for ; Mon, 31 Oct 2005 00:26:05 +0100 (envelope-from ) Received: from OVERDRIVE (144.158-201-80.adsl.skynet.be [80.201.158.144]) by outmx013.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j9UNPw4u005031 for ; Mon, 31 Oct 2005 00:26:00 +0100 (envelope-from ) Message-Id: <200510302326.j9UNPw4u005031@outmx013.isp.belgacom.be> From: "Renaat Dumon" To: Subject: XFS corruption on 2.4.28 Date: Mon, 31 Oct 2005 00:25:58 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXdqQIXhs0UadrLSFSTZ7ajN2aTLg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6461 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: renaat.dumon@belbone.be Precedence: bulk X-list: linux-xfs Content-Length: 2486 Lines: 133 Hi, I'm encountering errors with an XFS filesystem on a couple of production servers, and although I can't really reproduce this in a snap, I have had this issue on multiple running identical configurations. I'm running 2.4.28. Basically what happens is that although new data is put on the filesystem, the use% actually goes DOWN! After a while this results in -64Z Used :s . attempting to repair usually lead to everying in lost+found :s server2 root # df -h Filesystem Size Used Avail Use% Mounted on /dev/root 8.0G 924M 7.1G 12% / /dev/md0 46M 9.6M 34M 23% /boot /dev/md3 224G -64Z 282G 101% /Storage none 251M 0 251M 0% /dev/shm When I do a du -k on a directory on /Storage, I gives back strange values, that are impossible really if you add up the results of an 'ls -al'. As I do this, you notice immediately that the filesystem has gotten really slow... bacardi data # du -k 60129557224 ./0/0/0 68719491392 ./0/0/1 ... When I then cd into 0/0/0 and I do a 'du -sk *' : .. 16 000fdaaaa3a98db10cf3a51711371b27.65536 4 000fdaaaa3a98db10cf3a51711371b27.65536.db 8 000fe1c2b17a7b4b4d2c4eea341cfb08.65536 2147483532 000fe1c2b17a7b4b4d2c4eea341cfb08.65536.db 4 000fe28ec79372d78098abd1bcf23dbf.888 4 000fe28ec79372d78098abd1bcf23dbf.888.db 4 000fea029f9026e02223f2243ce02118.65536 4 000fea029f9026e02223f2243ce02118.65536.db 4 000fee378f6e08700b09442b191a9872.65536 4 000fee378f6e08700b09442b191a9872.65536.db .. Although: bacardi 0 # ls -al 000fe1c2b17a7b4b4d2c4eea341cfb08.65536.db -rw------- 1 root root 28 Oct 30 18:53 000fe1c2b17a7b4b4d2c4eea341cfb08.65536.db The correct filesize is indeed 28 bytes! The file mentioned here is just an example, but there are quite some files like that actually :( Unmounting/remounting the filesystem makes the issue go away temporarily, it is back after a couple of hours of operation. I did a xfs_check / xfs_repair before ; but that just dumped (ALMOST) EVERYTHING in lost+found , so I'm losing data :( The fact that I'm having this on multiple systems is what worries me, the filesystems are created with default options, but are mounted with su=256,sw=128 Does this sound familiar to any of you ? Thanks a bunch! Regards, Renaat Dumon [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Oct 30 21:13:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Oct 2005 21:13:10 -0800 (PST) Received: from american.megatrends.com (american.megatrends.com [155.229.80.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9V5D3O0029705 for ; Sun, 30 Oct 2005 21:13:04 -0800 Received: by american.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Oct 2005 00:09:51 -0500 Message-ID: <3225AF1B8CBF83459982D4987F1549CE055F34@fre-ops.us.megatrends.com> From: Srikumar Subramanian To: Nathan Scott , tes@melbourne.sgi.com Cc: acl-devel-owner@bestbits.at, "'linux-xfs@oss.sgi.com'" , ag@bestbits.at, Prabhakar Krishnan Subject: Re: kernel panic with XFS ACL inheritance on a FULL file system - Bayesian Filter detected spam Date: Mon, 31 Oct 2005 00:12:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C5DDD9.B3456B80" X-archive-position: 6462 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: SrikumarS@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 8904 Lines: 401 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C5DDD9.B3456B80 Content-Type: text/plain; charset="iso-8859-1" Hi Natham, Tim, Herewith I have attached the C program & shell script which I used to reproduce the issue. Hope this might be useful. Thanks & Regards, Srikumar -----Original Message----- From: Nathan Scott [mailto:nathans@sgi.com] Sent: Sunday, October 30, 2005 2:50 PM To: Srikumar Subramanian; tes@melbourne.sgi.com Cc: acl-devel-owner@bestbits.at; 'linux-xfs@oss.sgi.com'; ag@bestbits.at; Prabhakar Krishnan Subject: [SPAM] - Re: kernel panic with XFS ACL inheritance on a FULL file system - Bayesian Filter detected spam On Sat, Oct 29, 2005 at 06:44:13PM -0400, Srikumar Subramanian wrote: > Hi Nathan, > > I took 2.6.13.4 from kernel.org and I could able to reproduce the problem. > > Kernal panic appeared at the same location. > > In xfs_trans_ail.c, xfs_ail_insert() causes the panic. > > Based on objdump, "lip->li_ail.ail_forw->li_ail.ail_back = lip;" causes > panic because > lip->li_ail.ail_forw is NULL > Thanks Srikumar, Tim, looks like there remains a log bug here for you to look into...? cheers. -- Nathan ------_=_NextPart_000_01C5DDD9.B3456B80 Content-Type: application/octet-stream; name="homepound.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="homepound.c" //Srikumar - This tools is to test filesystem. It is single=20 //threaded and simply creates dirs/files of various size. //American Megatrends. Copyright (2000-2004) All rights reserved #define __USE_LARGEFILE64 1 #include #include #include #include #include #include #include #include #include #include #include typedef unsigned long long int u_longlong_t; #define BLOCK_SIZE (32 * 1024) //File will be written in blocks of 32KB u_longlong_t byteswritten =3D 0; u_longlong_t createfile (char * path, u_longlong_t filesize, u_longlong_t t= otalsize) { int fd; u_longlong_t leftSize =3D 0; size_t size =3D 0; static char fileBuffer [BLOCK_SIZE]; =09 if (path =3D=3D NULL || filesize < 0) { printf ("Error invalid argument\n"); return -1; } if (byteswritten + filesize > totalsize) { printf ("Skipping file <%s> because it exceeds the space\n", path); return -1; } =09 if ((fd =3D open64(path, O_RDWR|O_CREAT, 0777)) < 0) { printf ("Error in opening/creating file <%s> :<%s>\n", path, strerror(err= no)); return -1; } =09=09 if (filesize <=3D 0) { close(fd); return 0; } leftSize =3D filesize; // do multiple write to complete the dump. while( leftSize > 0 ) { if (leftSize > BLOCK_SIZE) size =3D BLOCK_SIZE; else size =3D (size_t) leftSize; // copy the fileBuffer to file=09 if( write(fd, fileBuffer, size) < 0 ) { printf ("Error writing date into file <%s> :<%s>\n", path, strerror(errn= o)); (void)close(fd); return (-1); } =09=09 leftSize -=3D size; } byteswritten =3D byteswritten + filesize; =09 printf ("Path <%s>:<%lld \n", path, filesize); printf ("Bytewritten so far <%lld>", byteswritten); close(fd); printf ("... Done.\n"); return 0; } u_longlong_t createset (char * path, u_longlong_t count, u_longlong_t curre= ntdepth,=20 u_longlong_t min, u_longlong_t max, u_longlong_t total) { u_longlong_t incr; u_longlong_t i; char * mypath =3D malloc (strlen (path) + 64); char * command; =09 if (count =3D=3D 1) incr =3D 0; else incr =3D (max - min) / (count - 1); =09=09 //Creating files for (i =3D 0; i < count; i++) { sprintf (mypath, "%s/%s%lld", path, "file", i); createfile (mypath, min + (incr * i), total); } if (currentdepth <=3D 0) { free (mypath); return 0; } //Creating files for (i =3D 0; i < count; i++) { sprintf (mypath, "%s/%s%lld", path, "dir", i); command =3D malloc (strlen (mypath) + 64); sprintf (command, "mkdir --mode=3D%o -p \"%s\"", 0777, mypath); if (!system (command)) { free (command);=09=09 //mypath is created. createset (mypath, count, (currentdepth-1), min, max, total); } else free (command); } free (mypath); return 0; } void usage() { printf ("American Megatrends. Copyright (2000-2004) All rights reserved.\n= "); printf ("This Utility is to dump Volume with thousands of files and direct= ories\n"); printf ("usage: homepound path dcount depth min_size max_size total_size\n= "); printf (" path - name of the (relative or obsolete) directory = to pound\n"); printf (" dcount - number of files and subdirectories\n"); printf (" depth - subdirectory level\n"); printf (" min_size - min size per file to start with. in KB/MB/GB\= n"); printf (" max_size - max size per file to end with. in KB/MB/GB\n"= ); printf (" total_size - Total size in KB/MB/GB\n"); printf (" Also, max>=3D0 min>=3D0 count>0 depth>=3D0 max>=3Dmin tota= l>0\n\n"); printf ("Sample: homepound /root/Dump 100 10 20KB 100MB 2GB\n"); printf ("Program will exit automatically once it reaches total_size\n"); } int main (int argc, char *argv[]) { int min, max, count, depth, total; u_longlong_t lmin, lmax, ltotal; u_longlong_t lminfactor, lmaxfactor, ltotalfactor; struct stat mstat; char * command; char unit[16]; =09 if (argc !=3D 7) { printf ("Invalid Parameter\n"); usage(); return -1; } count =3D atol (argv[2]); depth =3D atol (argv[3]); //Calculate min sscanf (argv[4], "%d%s", &min, unit); if (0 =3D=3D strcasecmp (unit, "KB")) lminfactor =3D 1024; else if (0 =3D=3D strcasecmp (unit, "MB")) lminfactor =3D 1024 * 1024; else if (0 =3D=3D strcasecmp (unit, "GB")) lminfactor =3D 1024 * 1024 * 1024; else { min =3D -1; lminfactor =3D 0; } =09 //Calculate max sscanf (argv[5], "%d%s", &max, unit); if (0 =3D=3D strcasecmp (unit, "KB")) lmaxfactor =3D 1024; else if (0 =3D=3D strcasecmp (unit, "MB")) lmaxfactor =3D 1024 * 1024; else if (0 =3D=3D strcasecmp (unit, "GB")) lmaxfactor =3D 1024 * 1024 * 1024; else { max =3D -1; lmaxfactor =3D 0; } =09 //Calculate total sscanf (argv[6], "%d%s", &total, unit); if (0 =3D=3D strcasecmp (unit, "KB")) ltotalfactor =3D 1024; else if (0 =3D=3D strcasecmp (unit, "MB")) ltotalfactor =3D 1024 * 1024; else if (0 =3D=3D strcasecmp (unit, "GB")) ltotalfactor =3D 1024 * 1024 * 1024; else { total =3D -1; ltotalfactor =3D 0; } if (count < 1 || max < 0 || min < 0 || count < 1 || depth < 0 || total <= =3D 0) { printf ("Invalid Parameter\n\n"); usage(); return -1; } if (count =3D=3D 1) { //If only one file, no stepping is requied. min =3D max; lminfactor =3D lmaxfactor; } lmin =3D (u_longlong_t)min * lminfactor ; //convert to byte lmax =3D (u_longlong_t)max * lmaxfactor ; //convert to byte ltotal =3D (u_longlong_t)total * ltotalfactor; //conver to byte printf ("C[%d] D[%d] MIN[%lld] MAX[%lld] T[%lld]\n", count, depth, lmin, l= max, ltotal); if (lmax < lmin) { printf ("max_size should be Greater than min_size. Invalid Parameter\n\n"= ); usage(); return -1; } //Create Directory if not exists... if (0 =3D=3D stat (argv[1], &mstat)) { //path already exists. check whether it is a directory if (!(mstat.st_mode & S_IFDIR)) { //NOT a directory printf ("Invalid directory <%s>\n", argv[1]); usage(); return -1; } } else { //path argv[1] is not exists. So create the path command =3D malloc (strlen (argv[1]) + 64); sprintf (command, "mkdir --mode=3D%o -p \"%s\"", 0777, argv[1]); if (system(command)) { free (command); printf ("Could not create initial path <%s>\n", argv[1]); return -1; } else free (command); } createset (argv[1], count, depth, lmin, lmax, ltotal); return 0; } ------_=_NextPart_000_01C5DDD9.B3456B80 Content-Type: application/octet-stream; name="acl_test.sh" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="acl_test.sh" set -xv db=3D"/dev" dn=3D"hda5" #let hda5 partition size be 100 MB #mount point base dir mp=3D"/xfs" #--------------------------------------------------------------------------= ---- mkdir $mp umount $mp/$dn rm -rf $mp/$dn mkfs.xfs -f -L stortrends $db/$dn=20 mkdir $mp/$dn if [ $? !=3D 0 ]; then echo "umount failed" exit 0 fi mount -t xfs -o rw,usrquota $db/$dn $mp/$dn mkdir $mp/$dn/hp ls=3D1 le=3D100 while [ $ls -le $le ] do s=3D1 e=3D20 while [ $s -le $e ] do setfacl -m u:u$s:rwx $mp/$dn/hp setfacl -d -m u:u$s:rwx $mp/$dn/hp let "s=3Ds+1" done /root/homepound $mp/$dn/hp 200 5 1KB 1KB 3GB =09 echo "times completed $ls " > /root/times_completed let "ls=3Dls+1" done ------_=_NextPart_000_01C5DDD9.B3456B80-- From owner-linux-xfs@oss.sgi.com Mon Oct 31 01:08:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 01:08:30 -0800 (PST) Received: from smtp.pzkagis.cz (gis6.netbox.cz [83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9V983O0002392 for ; Mon, 31 Oct 2005 01:08:06 -0800 Received: (from luf@localhost) by smtp.pzkagis.cz (8.11.6/8.11.6) id j9V94Te17291; Mon, 31 Oct 2005 10:04:29 +0100 Date: Mon, 31 Oct 2005 10:04:29 +0100 From: Ludek Finstrle To: Renaat Dumon Cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 Message-ID: <20051031090429.GA17240@soptik.pzkagis.cz> References: <200510302326.j9UNPw4u005031@outmx013.isp.belgacom.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510302326.j9UNPw4u005031@outmx013.isp.belgacom.be> User-Agent: Mutt/1.4i X-archive-position: 6464 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luf@pzkagis.cz Precedence: bulk X-list: linux-xfs Content-Length: 408 Lines: 11 > When I do a du -k on a directory on /Storage, I gives back strange values, > that are impossible really if you add up the results of an 'ls -al'. As I do > this, you notice immediately that the filesystem has gotten really slow... I notice this behaviour few weeks ago (max. 4 weeks). There is a patch for it in CVS. Try search through mail-archiv for "df vs du -sk" (or similar). I hope it helps Luf From owner-linux-xfs@oss.sgi.com Mon Oct 31 01:05:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 01:06:09 -0800 (PST) Received: from mail.belkam.com (ns2.belkam.com [217.14.198.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9V95WO0001839 for ; Mon, 31 Oct 2005 01:05:39 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.belkam.com (Postfix) with ESMTP id E6D8E11DDC0 for ; Mon, 31 Oct 2005 13:02:15 +0400 (SAMT) Received: from mail.belkam.com ([127.0.0.1]) by localhost (gopher [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24079-01 for ; Mon, 31 Oct 2005 13:02:14 +0400 (SAMT) Received: from vader.belkam.com (dm.p98.belkam.com [192.168.22.229]) by mail.belkam.com (Postfix) with ESMTP id 93B4511DCEE for ; Mon, 31 Oct 2005 13:02:14 +0400 (SAMT) Message-ID: <4365DD96.1000700@vader.belkam.com> Date: Mon, 31 Oct 2005 13:02:14 +0400 From: Dmitry Melekhov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfs oops with full partition References: <436051DC.8040203@vader.belkam.com> In-Reply-To: <436051DC.8040203@vader.belkam.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6463 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dm@vader.belkam.com Precedence: bulk X-list: linux-xfs Content-Length: 3778 Lines: 98 Really, this oops happens when there are mey changes in metadata, i.e. when many files are written. Looks like logs steps on it's tail and fall ;-) Dmitry Melekhov wrote: > Hello! > > I don't know which xfs version is in suse kernel. > > We get following oopses when users write to 100% full partition: > > Unable to handle kernel NULL pointer dereference at virtual address > 00000004 > f945a5d4 > *pde = 00000000 > Oops: 0002 [#1] > CPU: 0 > EIP: 0060:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010286 (2.6.5-7.201-smp SLES9_SP2_BRANCH-200508250620450000) > eax: 00000000 ebx: ffffffff ecx: fffffc19 edx: ffffffff > esi: cafe2218 edi: e2f47648 ebp: f60bb018 esp: cdc83e10 > ds: 007b es: 007b ss: 0068 > Stack: d7c76804 e2f47648 f60bb000 000017d4 00001cea 00000000 00000000 > 000017d4 > e2f47648 000017d4 00001cea f9459278 000017d4 00001cea 00000000 > 00000001 > f60bb000 ee7085f0 000017d4 00001cea ee7085e0 000017cc 00001cea > 000017d4 > Call Trace: > [] xfs_trans_chunk_committed+0x168/0x200 [xfs] > [] xfs_trans_committed+0x3c/0x100 [xfs] > [] xlog_state_do_callback+0x24c/0x3e0 [xfs] > [] schedule+0x65a/0xe40 > [] xlog_iodone+0x9f/0x130 [xfs] > [] pagebuf_iodone_work+0x27/0x40 [xfs] > [] worker_thread+0x187/0x230 > [] pagebuf_iodone_work+0x0/0x40 [xfs] > [] default_wake_function+0x0/0x10 > [] default_wake_function+0x0/0x10 > [] worker_thread+0x0/0x230 > [] kthread+0xd4/0x118 > [] kthread+0x0/0x118 > [] kernel_thread_helper+0x5/0x10 > Code: 89 78 04 8b 44 24 08 ff 40 20 8b 54 24 04 39 14 24 74 3e b0 > > > >>EIP; f945a5d4 <__crc_dma_pool_free+4de965/69c753> <===== > > >>ebx; ffffffff <__kernel_rt_sigreturn+1bbf/????> > >>ecx; fffffc19 <__kernel_rt_sigreturn+17d9/????> > >>edx; ffffffff <__kernel_rt_sigreturn+1bbf/????> > >>esi; cafe2218 <__crc_dev_change_flags+33aa1/20bfbe> > >>edi; e2f47648 <__crc_class_simple_device_remove+2911c/4eed5b> > >>ebp; f60bb018 <__crc___ip_select_ident+461513/65b400> > >>esp; cdc83e10 <__crc_fsync_buffers_list+34509f/856d01> > > Trace; f9459278 <__crc_dma_pool_free+4dd609/69c753> > Trace; f945934c <__crc_dma_pool_free+4dd6dd/69c753> > Trace; f944c16c <__crc_dma_pool_free+4d04fd/69c753> > Trace; c012677a > Trace; f944c39f <__crc_dma_pool_free+4d0730/69c753> > Trace; f9472257 <__crc_dma_pool_free+4f65e8/69c753> > Trace; c013bfe7 > Trace; f9472230 <__crc_dma_pool_free+4f65c1/69c753> > Trace; c0123e80 > Trace; c0123e80 > Trace; c013be60 > Trace; c013fc54 > Trace; c013fb80 > Trace; c0107005 > > Code; f945a5d4 <__crc_dma_pool_free+4de965/69c753> > 00000000 <_EIP>: > Code; f945a5d4 <__crc_dma_pool_free+4de965/69c753> <===== > 0: 89 78 04 mov %edi,0x4(%eax) <===== > Code; f945a5d7 <__crc_dma_pool_free+4de968/69c753> > 3: 8b 44 24 08 mov 0x8(%esp),%eax > Code; f945a5db <__crc_dma_pool_free+4de96c/69c753> > 7: ff 40 20 incl 0x20(%eax) > Code; f945a5de <__crc_dma_pool_free+4de96f/69c753> > a: 8b 54 24 04 mov 0x4(%esp),%edx > Code; f945a5e2 <__crc_dma_pool_free+4de973/69c753> > e: 39 14 24 cmp %edx,(%esp) > Code; f945a5e5 <__crc_dma_pool_free+4de976/69c753> > 11: 74 3e je 51 <_EIP+0x51> > Code; f945a5e7 <__crc_dma_pool_free+4de978/69c753> > 13: b0 00 mov $0x0,%al > > > > Is this problem already fixed in lates xfs code? > > From owner-linux-xfs@oss.sgi.com Mon Oct 31 09:18:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 09:18:23 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VHICO0025560 for ; Mon, 31 Oct 2005 09:18:12 -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 j9VIN9PH024536 for ; Mon, 31 Oct 2005 10:23:09 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9VHDuDN18922218; Mon, 31 Oct 2005 11:13:57 -0600 (CST) Message-ID: <436650D4.9000307@sgi.com> Date: Mon, 31 Oct 2005 11:13:56 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludek Finstrle CC: Renaat Dumon , linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 References: <200510302326.j9UNPw4u005031@outmx013.isp.belgacom.be> <20051031090429.GA17240@soptik.pzkagis.cz> In-Reply-To: <20051031090429.GA17240@soptik.pzkagis.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6466 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 351 Lines: 10 Ludek Finstrle wrote: > I notice this behaviour few weeks ago (max. 4 weeks). There is a patch for > it in CVS. Try search through mail-archiv for "df vs du -sk" (or similar). I -think- that that fix is for a different problem... in that previous case, xfs_repair could correctly repair the filesystem, without moving files to lost+found. -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 31 09:27:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 09:27:47 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VHRiO0026651 for ; Mon, 31 Oct 2005 09:27:45 -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 j9VIWgaU026044 for ; Mon, 31 Oct 2005 10:32:42 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9VHNUDN18922510; Mon, 31 Oct 2005 11:23:31 -0600 (CST) Message-ID: <43665311.60904@sgi.com> Date: Mon, 31 Oct 2005 11:23:29 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Renaat Dumon CC: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 References: <200510302326.j9UNPw4u005031@outmx013.isp.belgacom.be> In-Reply-To: <200510302326.j9UNPw4u005031@outmx013.isp.belgacom.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2027 Lines: 75 Renaat Dumon wrote: A couple questions early on - is this stock 2.4.28 from kernel.org? Are you using extended attributes? Have you run xfs_fsr on this filesystem? I doubt that fsr is the culprit here, because your files are only 28 bytes long, so fsr would not touch them. > When I then cd into 0/0/0 and I do a 'du -sk *' : > 2147483532 000fe1c2b17a7b4b4d2c4eea341cfb08.65536.db 0x7FFFFF8C - hm, a lot of binary 1's in there... > bacardi 0 # ls -al 000fe1c2b17a7b4b4d2c4eea341cfb08.65536.db > > -rw------- 1 root root 28 Oct 30 18:53 > 000fe1c2b17a7b4b4d2c4eea341cfb08.65536.db 0x1C can you try an xfs_bmap -v, and xfs_bmap -a -v of this file? Just out of curiosity. > > > > The correct filesize is indeed 28 bytes! The file mentioned here is just an > example, but there are quite some files like that actually :( > It might be interesting to gather the reported/correct values for several files, so we can possibly identify a pattern. > > Unmounting/remounting the filesystem makes the issue go away temporarily, it > is back after a couple of hours of operation. > so a file which shows up as bad is ok after a remount? So at least this problem is not on-disk, but... > > I did a xfs_check / xfs_repair before ; but that just dumped (ALMOST) > EVERYTHING in lost+found , so I'm losing data :( > ... something -is- bad on disk. What is the output of xfs_repair? > > > > The fact that I'm having this on multiple systems is what worries me, the > filesystems are created with default options, but are mounted with > su=256,sw=128 what volume manager are you using? Can you verify whether using the stripe geometry contributes to the problem? Without su,sw does the problem go away? > > Does this sound familiar to any of you ? Thanks a bunch! not quite, the last du reporting problem was only on files with extended attributes, and only after an xfs_fsr run - but in your case the files are small enough that fsr probably ignores them. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 31 10:12:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 10:12:51 -0800 (PST) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VICiO0030280 for ; Mon, 31 Oct 2005 10:12:45 -0800 Message-Id: <200510311812.j9VICiO0030280@oss.sgi.com> Received: from host217-37-158-157.in-addr.btopenworld.com ([217.37.158.157] helo=ChrisElston) by s14.s14avahost.net with esmtp (Exim 4.52) id 1EWe4G-0006YR-2i; Mon, 31 Oct 2005 12:07:36 -0600 From: "Chris Elston" To: Cc: , , Subject: [PATCH] Re: Files >4GB in XFS realtime partition Date: Mon, 31 Oct 2005 18:09:28 -0000 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXeRjuivP+7rfWkSaCvjRA47VCw3w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PopBeforeSMTPSenders: celston@katalix.com,jchapman@katalix.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 6468 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: celston@katalix.com Precedence: bulk X-list: linux-xfs Content-Length: 3588 Lines: 86 See http://marc.theaimsgroup.com/?t=111642565400004&r=1&w=2 for original report. Summary ------- When reading a large (>4Gb) file from an XFS realtime partition which has been opened with the O_DIRECT flag, it has been observed that reads above the 4Gb point sometimes return data from the wrong location in the file. This problem only occurs when the file has been written to the disk under a particular set of conditions which cause XFS to write it in a sequence of contiguous filesystem extents. These conditions are: - The data is being written to a realtime subvolume. - No other processes are writing data to the disk concurrently. - The file was opened with the O_DIRECT flag. - There is a contiguous block of >4Gb of available filesystem extents (For example, on a freshly formatted XFS partition). - The XFS filesystem has been created with a blocksize of 4kb or greater. Symptoms -------- Reads from a file with offsets larger than 4Gb point up to 8Gb wrap around to the beginning of the file, reads from the 12Gb point until the 16Gb point wrap around to the 12Gb point etc... These symptoms have been reproduced on Linux 2.4.29 compiled for MIPS and on Linux 2.4.29 compiled for x86. Detail ------ The maximum number of blocks that an XFS extent record may refer to is MAXEXTLEN, which is defined as 0x1FFFFF blocks. The maximum size of data that this can be is MAXEXTLEN * blocksize (which mkfs.xfs sets as 4kb by default). This default gives a total maximum size of 0x1FFFFFFF0 for each extent record. When a request is made to read from an offset in a file, XFS translates this offset into an extent record and a delta (offset within the extent) (see xfs_bmap_do_search_extents in xfs_bmap.c, and xfs_imap_to_bmap in xfs_iomap.c). The delta is stored inside xfs_iomap_t (see xfs_iomap.h) and is 32 bits. When the blocksize is set to 4kb, this delta value is no longer large enough to contain the offset inside the extent and wraps back down to zero. This produces the anomalous read results. This problem also does not occur on XFS data partitions because they make use of allocation groups, across which extents records may not span. Allocation groups have a maximum size of just under 4Gb. A patch is attached which resolves this problem by increasing the storage size of iomap_delta to loff_t. Please also see the comment attached to revision 1.2 of xfs_iomap.h in the SGI CVS at http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/xfs/xfs_iomap.h I believe that iomap_delta should probably have been increased at the same time that the iomap_bsize was. Thanks, -- Chris Elston Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development begin 666 XFS_RT_4GB.patch M+2TM(%1$0S&9S+WAF71E MF5?=" @(" @(" @(" @(" @(" @(&EO;6%P7V1E M;'1A.R @(" O*B!O9F9S970@:6YT;R!M87!P:6YG+"!B>71E71E; Mon, 31 Oct 2005 11:37:12 -0800 Received: from overdrive (overdrive.ops.belbone.be [192.168.20.80]) by postit.belbone.be (Postfix) with ESMTP id EABCF1774ED; Mon, 31 Oct 2005 20:33:58 +0100 (CET) From: "Renaat Dumon" To: "'Eric Sandeen'" Cc: Subject: RE: XFS corruption on 2.4.28 Date: Mon, 31 Oct 2005 20:33:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcXeP9NYr9O58zN4TvOoHK4vHLyiWAADmDEQ In-Reply-To: <43665311.60904@sgi.com> Message-Id: <20051031193358.EABCF1774ED@postit.belbone.be> X-archive-position: 6469 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: renaat.dumon@belbone.be Precedence: bulk X-list: linux-xfs Content-Length: 6972 Lines: 206 I don't think I'm using extended attribs, I just do mkfs.xfs and mount :) And I don't know what xfs_fsr is :s I'm running a Gentoo kernel 2.4.28 , but I'm not sure of it's a stock one or not. For what it's worth: bacardi 1 # emerge -s xfs Searching... [ Results for search key : xfs ] [ Applications found : 1 ] * sys-apps/xfsprogs Latest version available: 2.3.9 Latest version installed: 2.3.9 Size of downloaded files: 750 kB Homepage: http://oss.sgi.com/projects/xfs Description: xfs filesystem utilities I unmount/remounted the filesystem, and after a while the problem re-appears, albeit for other files. While the one previously mentioned is still good (for now anyway) One file: bacardi 0 # ls -al 0006825d9eea315d1db6193f7095f895.353.db -rw------- 1 root root 44 Oct 31 18:33 0006825d9eea315d1db6193f7095f895.353.db bacardi 0 # du -sk 0006825d9eea315d1db6193f7095f895.353.db 2147483532 0006825d9eea315d1db6193f7095f895.353.db bacardi 0 # xfs_bmap -v 0006825d9eea315d1db6193f7095f895.353.db 0006825d9eea315d1db6193f7095f895.353.db: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 145927304..145927311 17 (3320968..3320975) 8 bacardi 0 # xfs_bmap -a -v 0006825d9eea315d1db6193f7095f895.353.db 0006825d9eea315d1db6193f7095f895.353.db: no extents Another file: bacardi 0 # du -sk 000686957ffc98b67b53cb9d67d5b37e.269.db 2147483532 000686957ffc98b67b53cb9d67d5b37e.269.db bacardi 0 # xfs_bmap -v 000686957ffc98b67b53cb9d67d5b37e.269.db 000686957ffc98b67b53cb9d67d5b37e.269.db: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 145994376..145994383 17 (3388040..3388047) 8 bacardi 0 # xfs_bmap -a -v 000686957ffc98b67b53cb9d67d5b37e.269.db 000686957ffc98b67b53cb9d67d5b37e.269.db: no extents I haven't tried mounting the filesystem without the geometry options, my solution vendor insists that these parameters are "performance enhancing" and that the application involved is not guaranteed to work as well without these... The output of an xfs_repair is squeaky clean, but when I wait really long before doing an unmount/Remount, I get the move to lost+found again. The hardware is just fine, I tried dd over & over again to check the disks. I have 2 disks mirrored using mdadm. I just realized something you talking about small files, I have a dir structure [0-9a-f]/[0-9a-f]/[0-9a-f] where all these files reside. I did the following to easily detect which files were currently affected: bacardi 0 # du -sk * |sort -n < .. Cut .. > 2147483532 00005d697a5a05795f53cb7b081f242d.65536.db 2147483532 00007ed327608e3263372b751dd3bdf3.65536.db 2147483532 0001129845438970777067e99b440123.65536.db 2147483532 0002511297400034364acb5e62c3b04c.65536.db 2147483532 0002525115de4daa012fd9453846c0ab.353.db 2147483532 0002b490e8d2b3ed1d8a7c2bf5c622dd.65536.db 2147483532 0002cf7afa259d56df746769000df7ed.2290.db 2147483532 00030b50559133bdd4189b2114dd56fc.65536.db 2147483532 000311cac771d6745d836d0cb13c5f38.65536.db 2147483532 0003131c2f484c01315a2d6f77b8d036.65536.db 2147483532 0003161725e7f00fcbac96536c09c76c.65536.db 2147483532 0004fd9823a98abeb9b4836432f16085.65536.db 2147483532 000585cd18eeeebd2313681f77cac815.65536.db 2147483532 00064742bc5ba0fe41c3ef38cc5bf250.65536.db 2147483532 0006825d9eea315d1db6193f7095f895.353.db 2147483532 000686957ffc98b67b53cb9d67d5b37e.269.db 2147483532 00079f69432f3aaf071c8305186ac508.65536.db 2147483532 00093637366cbd6da3a99d3e0d9f7afc.65536.db 2147483532 00096d5b955d0d71d0f6ed5823cfeeb4.65536.db 2147483532 0009bbac9ce5bfef3a80bdcd8d1b00e8.65536.db 2147483532 000aa5dcab569b899bcc19d66ece6e51.65536.db 2147483532 000c9447411e4fc7f931fbc79104a8eb.65536.db 2147483532 000cd9b389a17bafa77bd8bf5d045118.65536.db 2147483532 000d54e31742ef5fd847fa715218b418.65536.db 2147483532 000d84c59cb65e30c4dd079fbc5dfa4b.65536.db 2147483532 000dc9c7eb627821dc52b4d82f8fe3bb.65536.db 2147483532 000e02d2078fab322f13972337e2d844.65536.db 2147483532 000f5f2304e482dbc4af0e80331da36f.353.db 2147483532 000f9b244ecdf330dafcb1dc94d146d3.269.db 2147483532 000fcf428f92a1cba92ae11d8ca7d6c2.65536.db bacardi 0 # All these files should be 28 bytes !!! Maybe there's a problem with writing small files ?! Note that not EVERY .db shows up bad, there are lots of them that are OK. For every .db file there is a corresponding "data" file, these are always created together (1 "data" file, and 1 db containing the metadata). The "data" files all show up correctly. Thanks for your comments! Renaat -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: 31 October 2005 18:23 To: Renaat Dumon Cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 Renaat Dumon wrote: A couple questions early on - is this stock 2.4.28 from kernel.org? Are you using extended attributes? Have you run xfs_fsr on this filesystem? I doubt that fsr is the culprit here, because your files are only 28 bytes long, so fsr would not touch them. > When I then cd into 0/0/0 and I do a 'du -sk *' : > 2147483532 000fe1c2b17a7b4b4d2c4eea341cfb08.65536.db 0x7FFFFF8C - hm, a lot of binary 1's in there... > bacardi 0 # ls -al 000fe1c2b17a7b4b4d2c4eea341cfb08.65536.db > > -rw------- 1 root root 28 Oct 30 18:53 > 000fe1c2b17a7b4b4d2c4eea341cfb08.65536.db 0x1C can you try an xfs_bmap -v, and xfs_bmap -a -v of this file? Just out of curiosity. > > > > The correct filesize is indeed 28 bytes! The file mentioned here is > just an example, but there are quite some files like that actually :( > It might be interesting to gather the reported/correct values for several files, so we can possibly identify a pattern. > > Unmounting/remounting the filesystem makes the issue go away > temporarily, it is back after a couple of hours of operation. > so a file which shows up as bad is ok after a remount? So at least this problem is not on-disk, but... > > I did a xfs_check / xfs_repair before ; but that just dumped (ALMOST) > EVERYTHING in lost+found , so I'm losing data :( > ... something -is- bad on disk. What is the output of xfs_repair? > > > > The fact that I'm having this on multiple systems is what worries me, > the filesystems are created with default options, but are mounted with > su=256,sw=128 what volume manager are you using? Can you verify whether using the stripe geometry contributes to the problem? Without su,sw does the problem go away? > > Does this sound familiar to any of you ? Thanks a bunch! not quite, the last du reporting problem was only on files with extended attributes, and only after an xfs_fsr run - but in your case the files are small enough that fsr probably ignores them. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 31 12:07:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 12:07:51 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9VK7kO0008074 for ; Mon, 31 Oct 2005 12:07: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 HAA09485; Tue, 1 Nov 2005 07:04:25 +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 j9VK4ckt6195039; Tue, 1 Nov 2005 07:04:39 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j9VK4bI96222896; Tue, 1 Nov 2005 07:04:37 +1100 (EST) Date: Tue, 1 Nov 2005 07:04:37 +1100 From: Nathan Scott To: Chris Elston Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Re: Files >4GB in XFS realtime partition Message-ID: <20051101070437.A6221502@wobbly.melbourne.sgi.com> References: <20051031180932.16895D0289E4@cuda.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051031180932.16895D0289E4@cuda.sgi.com>; from celston@katalix.com on Mon, Oct 31, 2005 at 06:09:28PM -0000 X-archive-position: 6470 X-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: 1572 Lines: 39 Hi Chris, On Mon, Oct 31, 2005 at 06:09:28PM -0000, Chris Elston wrote: > See > http://marc.theaimsgroup.com/?t=111642565400004&r=1&w=2 > for original report. > ... > A patch is attached which resolves this problem by increasing the storage > size of iomap_delta to loff_t. Please also see the comment attached to > revision 1.2 of xfs_iomap.h in the SGI CVS at > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/xfs/xfs_iomap.h > I believe that iomap_delta should probably have been increased at the same > time that the iomap_bsize was. > ... > begin 666 XFS_RT_4GB.patch > M+2TM(%1$0S&9S+WAF M,3 M,S$@,34Z,S M+WAF M,# @*S P,# *0$ @+3@V+#<@*S@V+#<@0$ *(" @(" @("!X9G-?8G5F=&%R > M9U]T(" @(" @(" @(" J:6]M87!?=&%R9V5T.PH@(" @(" @(&QO9F9?=" @ > M(" @(" @(" @(" @(" @(&EO;6%P7V]F9G-E=#L@(" O*B!O9F9S970@;V8@ > M;6%P<&EN9RP@8GET97,@*B\*(" @(" @("!L;V9F7W0@(" @(" @(" @(" @ > M(" @("!I;VUA<%]B71E > MF5?=" @(" @(" @(" @(" @(" @(&EO;6%P7V1E > M;'1A.R @(" O*B!O9F9S970@:6YT;R!M87!P:6YG+"!B>71E M(" @(&QO9F9?=" @(" @(" @(" @(" @(" @(&EO;6%P7V1E;'1A.R @(" O > M*B!O9F9S970@:6YT;R!M87!P:6YG+"!B>71E M7V9L86=S7W0@(" @(" @(" @(&EO;6%P7V9L86=S.PH@?2!X9G-?:6]M87!? > $=#L*"@`` > ` Thanks! Could you resend that patch as just a regular text file (inline text at the end of your mail would be fine)? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Oct 31 13:17:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 13:17:11 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VLH6O0018586 for ; Mon, 31 Oct 2005 13:17:07 -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 j9VLDsxT001341 for ; Mon, 31 Oct 2005 15:13:54 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9VLDnsL24552922; Mon, 31 Oct 2005 15:13:50 -0600 (CST) Message-ID: <4366890D.2030802@sgi.com> Date: Mon, 31 Oct 2005 15:13:49 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Elston CC: linux-xfs@oss.sgi.com, nathans@sgi.com, jchapman@katalix.com Subject: Re: [PATCH] Re: Files >4GB in XFS realtime partition References: <200510311812.j9VICiO0030280@oss.sgi.com> In-Reply-To: <200510311812.j9VICiO0030280@oss.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1187 Lines: 29 Chris Elston wrote: > This problem also does not occur on XFS data partitions because they make > use of allocation groups, across which extents records may not span. > Allocation groups have a maximum size of just under 4Gb. FWIW, this is not the case any longer; AGs can now be > 4Gb. However, I still haven't shown this problem on the data subvol... I made a fs with 2 AGs, first is 5gb. Then I pre-allocated 5G into a file, and got -almost- 1 extent ;-) but first extent is nearly 5g. I wrote "1" to 0 bytes and "2" to 2^32+4097 bytes, and read it back. Seems ok, oddly enough. penguin3:~ # ./allocsp /mnt/test/bigfile pwrite at offset 0 pwrite at offset 4294972296 penguin3:~ # xfs_bmap -v /mnt/test/bigfile /mnt/test/bigfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..10485663]: 96..10485759 0 (96..10485759) 10485664 10000 1: [10485664..10485759]: 10506304..10506399 1 (20544..20639) 96 10000 penguin3:~ # hexdump /mnt/test/bigfile 0000000 0031 0000 0000 0000 0000 0000 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 * 100001380 0000 0000 0000 0000 0032 100001389 penguin3:~ # From owner-linux-xfs@oss.sgi.com Mon Oct 31 13:16:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 13:16:05 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VLG2O0018337 for ; Mon, 31 Oct 2005 13:16:02 -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 j9VLCnxT001233 for ; Mon, 31 Oct 2005 15:12:49 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9VLCmsL24553650; Mon, 31 Oct 2005 15:12:48 -0600 (CST) Message-ID: <436688CF.9050204@sgi.com> Date: Mon, 31 Oct 2005 15:12:47 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Renaat Dumon CC: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 References: <20051031193358.EABCF1774ED@postit.belbone.be> In-Reply-To: <20051031193358.EABCF1774ED@postit.belbone.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2060 Lines: 64 Renaat Dumon wrote: > > I don't think I'm using extended attribs, I just do mkfs.xfs and mount :) > And I don't know what xfs_fsr is :s > I'm running a Gentoo kernel 2.4.28 , but I'm not sure of it's a stock one or > not. any chance you could try a stock kernel from 2.4.28, untouched by our friends at gentoo.... ? > I unmount/remounted the filesystem, and after a while the problem > re-appears, albeit for other files. While the one previously mentioned is > still good (for now anyway) > > One file: > Another file: Ok, no attributes. And the "wrong" du output is always 0x7FFFFF8C in both cases, odd. > I haven't tried mounting the filesystem without the geometry options, my > solution vendor insists that these parameters are "performance enhancing" > and that the application involved is not guaranteed to work as well without > these... it will probably slow things down, yes... but that should be the worst of it. Depending on how easily/quickly you can normally reproduce, it might be a good data point. Alternatively, perhaps a test that replicates what your application is doing could be devised to reproduce the problem... can you say which application this is, or what its IO pattern looks like? > > The output of an xfs_repair is squeaky clean, but when I wait really long > before doing an unmount/Remount, I get the move to lost+found again. Well, xfs_repair should say -something- if it's going to move everything to lost+found/ .... > The hardware is just fine, I tried dd over & over again to check the disks. > I have 2 disks mirrored using mdadm. > > I just realized something you talking about small files, > > I have a dir structure [0-9a-f]/[0-9a-f]/[0-9a-f] where all these files > reside. I did the following to easily detect which files were currently > affected: > > bacardi 0 # du -sk * |sort -n > < .. Cut .. > > 2147483532 00005d697a5a05795f53cb7b081f242d.65536.db ... > All these files should be 28 bytes !!! And they are always reported as 2147483532 / 0x7FFFFF8C Hmmmm... thinking. -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 31 14:00:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 14:00:18 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VM0EO0022005 for ; Mon, 31 Oct 2005 14:00: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 j9VN5C88007166 for ; Mon, 31 Oct 2005 15:05:13 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j9VLv0sL24550359; Mon, 31 Oct 2005 15:57:00 -0600 (CST) Message-ID: <4366932C.9070601@sgi.com> Date: Mon, 31 Oct 2005 15:57:00 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Renaat Dumon CC: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 References: <20051031193358.EABCF1774ED@postit.belbone.be> In-Reply-To: <20051031193358.EABCF1774ED@postit.belbone.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 169 Lines: 6 One other thing, could you send xfs_info output for one of the problematic filesystems? That way we can see exactly what filesystem geometry you have. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 31 15:05:39 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 15:05:42 -0800 (PST) Received: from postit.belbone.be (postit.belbone.be [195.13.1.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VN5cO0026776 for ; Mon, 31 Oct 2005 15:05:39 -0800 Received: from overdrive (overdrive.ops.belbone.be [192.168.20.80]) by postit.belbone.be (Postfix) with ESMTP id DFF021774EF; Tue, 1 Nov 2005 00:02:25 +0100 (CET) From: "Renaat Dumon" To: "'Eric Sandeen'" Cc: Subject: RE: XFS corruption on 2.4.28 Date: Tue, 1 Nov 2005 00:02:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4366932C.9070601@sgi.com> Thread-Index: AcXeZgfenKwlTcc0TO6gq/mVOxtnpwACQu7w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20051031230225.DFF021774EF@postit.belbone.be> X-archive-position: 6474 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: renaat.dumon@belbone.be Precedence: bulk X-list: linux-xfs Content-Length: 978 Lines: 33 Hi Eric, Thanks for taking the time to look at this. bacardi root # xfs_info /Storage meta-data=/Storage isize=256 agcount=56, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=58663328, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=7161, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Kind regards, Renaat -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: 31 October 2005 22:57 To: Renaat Dumon Cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 One other thing, could you send xfs_info output for one of the problematic filesystems? That way we can see exactly what filesystem geometry you have. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 31 15:11:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 15:11:05 -0800 (PST) Received: from postit.belbone.be (postit.belbone.be [195.13.1.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VNB2O0028111 for ; Mon, 31 Oct 2005 15:11:03 -0800 Received: from overdrive (overdrive.ops.belbone.be [192.168.20.80]) by postit.belbone.be (Postfix) with ESMTP id 3F3731774EF; Tue, 1 Nov 2005 00:07:50 +0100 (CET) From: "Renaat Dumon" To: "'Eric Sandeen'" Cc: Subject: RE: XFS corruption on 2.4.28 Date: Tue, 1 Nov 2005 00:07:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <436688CF.9050204@sgi.com> Thread-Index: AcXeX9sn5JvZ5dHhQSuTWLaNKLBCFAAD1lBQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20051031230750.3F3731774EF@postit.belbone.be> X-archive-position: 6475 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: renaat.dumon@belbone.be Precedence: bulk X-list: linux-xfs Content-Length: 2912 Lines: 90 Well , about trying a stock kernel, I'm affraid this is going to be hard. I get these systems installed - we're talking about a backup appliance here - and the software is set up around gentoo ... About the lost+found , that happens when I leave the system accumulating the errors for a week or so. If I don't wait that long and then remount, I'm good for another day... That's why xfs_repair isn't spewing stuff... I will mount the filesystem without the geometry options, and see how that goes. Since this is a backup appliance and it's now 00:06 AM here, you can imagine I can't do that just right now with all these backups going on.. Kind regards, Renaat -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: 31 October 2005 22:13 To: Renaat Dumon Cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 Renaat Dumon wrote: > > I don't think I'm using extended attribs, I just do mkfs.xfs and mount > :) And I don't know what xfs_fsr is :s I'm running a Gentoo kernel > 2.4.28 , but I'm not sure of it's a stock one or not. any chance you could try a stock kernel from 2.4.28, untouched by our friends at gentoo.... ? > I unmount/remounted the filesystem, and after a while the problem > re-appears, albeit for other files. While the one previously mentioned > is still good (for now anyway) > > One file: > Another file: Ok, no attributes. And the "wrong" du output is always 0x7FFFFF8C in both cases, odd. > I haven't tried mounting the filesystem without the geometry options, > my solution vendor insists that these parameters are "performance enhancing" > and that the application involved is not guaranteed to work as well > without these... it will probably slow things down, yes... but that should be the worst of it. Depending on how easily/quickly you can normally reproduce, it might be a good data point. Alternatively, perhaps a test that replicates what your application is doing could be devised to reproduce the problem... can you say which application this is, or what its IO pattern looks like? > > The output of an xfs_repair is squeaky clean, but when I wait really > long before doing an unmount/Remount, I get the move to lost+found again. Well, xfs_repair should say -something- if it's going to move everything to lost+found/ .... > The hardware is just fine, I tried dd over & over again to check the disks. > I have 2 disks mirrored using mdadm. > > I just realized something you talking about small files, > > I have a dir structure [0-9a-f]/[0-9a-f]/[0-9a-f] where all these > files reside. I did the following to easily detect which files were > currently > affected: > > bacardi 0 # du -sk * |sort -n > < .. Cut .. > > 2147483532 00005d697a5a05795f53cb7b081f242d.65536.db ... > All these files should be 28 bytes !!! And they are always reported as 2147483532 / 0x7FFFFF8C Hmmmm... thinking. -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 31 15:15:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 15:16:00 -0800 (PST) Received: from postit.belbone.be (postit.belbone.be [195.13.1.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VNFvO0028831 for ; Mon, 31 Oct 2005 15:15:57 -0800 Received: from overdrive (overdrive.ops.belbone.be [192.168.20.80]) by postit.belbone.be (Postfix) with ESMTP id 8BE4F1774EF; Tue, 1 Nov 2005 00:12:44 +0100 (CET) From: "Renaat Dumon" To: "'Eric Sandeen'" Cc: Subject: RE: XFS corruption on 2.4.28 Date: Tue, 1 Nov 2005 00:12:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <436688CF.9050204@sgi.com> Thread-Index: AcXeX9sn5JvZ5dHhQSuTWLaNKLBCFAAEHaHw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20051031231244.8BE4F1774EF@postit.belbone.be> X-archive-position: 6476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: renaat.dumon@belbone.be Precedence: bulk X-list: linux-xfs Content-Length: 2512 Lines: 86 I managed to find another systems had already occurred or not yet. I changed the line for /Storage in /etc/fstab From: /dev/md3 /Storage xfs rw,noatime,sunit=128,swidth=256 0 0 To: /dev/md3 /Storage xfs rw,noatime 0 0 Now waiting for some activity ... Renaat -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: 31 October 2005 22:13 To: Renaat Dumon Cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 Renaat Dumon wrote: > > I don't think I'm using extended attribs, I just do mkfs.xfs and mount > :) And I don't know what xfs_fsr is :s I'm running a Gentoo kernel > 2.4.28 , but I'm not sure of it's a stock one or not. any chance you could try a stock kernel from 2.4.28, untouched by our friends at gentoo.... ? > I unmount/remounted the filesystem, and after a while the problem > re-appears, albeit for other files. While the one previously mentioned > is still good (for now anyway) > > One file: > Another file: Ok, no attributes. And the "wrong" du output is always 0x7FFFFF8C in both cases, odd. > I haven't tried mounting the filesystem without the geometry options, > my solution vendor insists that these parameters are "performance enhancing" > and that the application involved is not guaranteed to work as well > without these... it will probably slow things down, yes... but that should be the worst of it. Depending on how easily/quickly you can normally reproduce, it might be a good data point. Alternatively, perhaps a test that replicates what your application is doing could be devised to reproduce the problem... can you say which application this is, or what its IO pattern looks like? > > The output of an xfs_repair is squeaky clean, but when I wait really > long before doing an unmount/Remount, I get the move to lost+found again. Well, xfs_repair should say -something- if it's going to move everything to lost+found/ .... > The hardware is just fine, I tried dd over & over again to check the disks. > I have 2 disks mirrored using mdadm. > > I just realized something you talking about small files, > > I have a dir structure [0-9a-f]/[0-9a-f]/[0-9a-f] where all these > files reside. I did the following to easily detect which files were > currently > affected: > > bacardi 0 # du -sk * |sort -n > < .. Cut .. > > 2147483532 00005d697a5a05795f53cb7b081f242d.65536.db ... > All these files should be 28 bytes !!! And they are always reported as 2147483532 / 0x7FFFFF8C Hmmmm... thinking. -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 31 19:01:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 19:01:34 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA131VO0013701 for ; Mon, 31 Oct 2005 19:01:31 -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 jA146Wlx019242 for ; Mon, 31 Oct 2005 20:06:32 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA12wIDN18946529; Mon, 31 Oct 2005 20:58:18 -0600 (CST) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id jA12wGlo7190676; Mon, 31 Oct 2005 20:58:16 -0600 (CST) Date: Mon, 31 Oct 2005 20:58:17 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@penguin.americas.sgi.com To: Renaat Dumon cc: linux-xfs@oss.sgi.com Subject: RE: XFS corruption on 2.4.28 In-Reply-To: <20051031231244.8BE4F1774EF@postit.belbone.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1443 Lines: 34 Renaat Dumon wrote: > Well , about trying a stock kernel, I'm affraid this is going to be hard. I > get these systems installed - we're talking about a backup appliance here - > and the software is set up around gentoo ... Ah, ok - did not know it was an appliance. What is it, out of curiosity? :) > About the lost+found , that happens when I leave the system accumulating the > errors for a week or so. If I don't wait that long and then remount, I'm > good for another day... That's why xfs_repair isn't spewing stuff... Ok, I was interested in what repair -did- say when it moves stuff to lost&found/.... > I will mount the filesystem without the geometry options, and see how that > goes. Since this is a backup appliance and it's now 00:06 AM here, you can > imagine I can't do that just right now with all these backups going on.. That's fine, I don't want to impede your workflow... > I managed to find another systems had already occurred or not yet. > > I changed the line for /Storage in /etc/fstab > > From: /dev/md3 /Storage xfs rw,noatime,sunit=128,swidth=256 0 0 > To: /dev/md3 /Storage xfs rw,noatime 0 0 > > > Now waiting for some activity ... Hm, if you haven't remounted it then it won't take affect yet... but that's ok. I'll see if I can reproduce anything here w/ your fs geometry - you may as well put it back with swidth/sunit until then (unless you feel like experimenting with your backups) :) -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 31 20:08:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 20:08:32 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA148QO0018954 for ; Mon, 31 Oct 2005 20:08:27 -0800 Received: (qmail 22435 invoked by uid 1000); 31 Oct 2005 23:05:13 -0500 Date: 31 Oct 2005 23:05:13 -0500 Message-ID: <20051101040513.22434.qmail@science.horizon.com> From: linux@horizon.com To: linux-xfs@oss.sgi.com Subject: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid X-archive-position: 6478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 21817 Lines: 373 I've been having hard-to-reproduce sata_sil24 driver problems, and the most recent lockup appears to have taken out my root file system. (Hooray for emergency boot partitions!) # mount -r /dev/md4 /mnt mount: /dev/md4: can't read superblock With the following appended to the kernel log: XFS mounting filesystem md4 Starting XFS recovery on filesystem: md4 (dev: md4) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed: error 5 XFS: log mount failed I haven't put this server into production yet (due to aforementioned libata issues), so I'm experiementing with XFS, but this failure isn't confidence-inspiring. It was running pcbackup, a disk-based backup system that generates lots of files and lots of hard links. (It also prepends all file names with "f" to prevent collisions with its own files.) Emergency kernel not mounting is Linus 2.6.13.2 + libata patch 2.6.13-rc7-libata1.patch.bz2 Kernel not booting is libata development git based on 2.6.14-rc3. md4 is a RAID10 array: md4 : active raid10 sdf3[4] sde3[3] sdd3[2] sdc3[1] sdb3[0] sda3[5] 131837184 blocks 256K chunks 2 near-copies [6/6] [UUUUUU] Unfortunately, being unable to mount the file system, I can't give xfs_info output. xfs_db version gives versionnum [0x3184] = V4,ALIGN,DALIGN,DIRV2,EXTFLG xfs_logprint /dev/md4 produces: xfs_logprint: data device: 0x904 log device: 0x904 daddr: 131838464 length: 129024 Header 0x30c wanted 0xfeedbabe ********************************************************************** * ERROR: header cycle=780 block=72440 * ********************************************************************** Bad log record header xfs_repair -n produces rather a lot of info. I'm not used to what sort of errors are "harmless", so I'm not sure if it's a good idea to run the recovery for real. The number of bad .. entries is a bit alarming. I have compressed out ("[...]") runs of very similar lines with (what appear to be) sequential block or inode numbers. (Perhaps xfs_check could be amended to compress those lines down to one range?) Anyway, can anyone suggest how to proceed? The file system isn't cirtical, but it would be annoying to rebuild. Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... block (0,914473) multiply claimed by bno space tree, state - 1 [...] block (0,914495) multiply claimed by bno space tree, state - 1 block (0,969351) already used, state 2 [...] block (0,969407) already used, state 2 block (4,2557) already used, state 2 [...] block (4,155647) already used, state 2 block (8,299639) multiply claimed by bno space tree, state - 1 block (10,1223238) already used, state 2 [...] block (10,1223294) already used, state 2 - 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 imap claims a free inode 15509544 is in use, would correct imap and clear inode imap claims a free inode 15509545 is in use, would correct imap and clear inode - agno = 1 imap claims a free inode 51346438 is in use, would correct imap and clear inode - agno = 2 data fork in ino 69496886 claims free block 4352910 - agno = 3 imap claims a free inode 129571903 is in use, would correct imap and clear inode - agno = 4 data fork in ino 134219837 claims free block 8391159 [...] data fork in ino 134219837 claims free block 8544227 imap claims a free inode 155289632 is in use, would correct imap and clear inode [...] imap claims a free inode 155289649 is in use, would correct imap and clear inode - agno = 5 imap claims in-use inode 193486864 is free, would correct imap imap claims in-use inode 193486865 is free, would correct imap imap claims a free inode 193852455 is in use, would correct imap and clear inode - agno = 6 - agno = 7 data fork in ino 248475688 claims free block 15529735 data fork in ino 248475689 claims free block 15529725 - agno = 8 imap claims a free inode 287203328 is in use, would correct imap and clear inode [...] imap claims a free inode 287203343 is in use, would correct imap and clear inode imap claims in-use inode 287203344 is free, would correct imap - agno = 9 imap claims in-use inode 313304070 is free, would correct imap - agno = 10 imap claims a free inode 349614096 is in use, would correct imap and clear inode [...] imap claims a free inode 349614109 is in use, would correct imap and clear inode - agno = 11 imap claims in-use inode 386031670 is free, would correct imap data fork in ino 386031671 claims free block 24126990 imap claims in-use inode 386031671 is free, would correct imap - agno = 12 imap claims a free inode 424609824 is in use, would correct imap and clear inode [...] imap claims a free inode 424609839 is in use, would correct imap and clear inode - agno = 13 imap claims a free inode 448496640 is in use, would correct imap and clear inode [...] imap claims a free inode 448496654 is in use, would correct imap and clear inode - agno = 14 imap claims a free inode 486567939 is in use, would correct imap and clear inode - agno = 15 imap claims in-use inode 523361317 is free, would correct imap - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 entry ".." at block 0 offset 32 in directory inode 15509541 references free inode 448496649 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 15509542 references free inode 424609837 would clear inode number in entry at offset 32... - agno = 1 entry "fimkr6_1" at block 0 offset 168 in directory inode 51345453 references free inode 287203337 would clear inode number in entry at offset 168... entry ".." at block 0 offset 32 in directory inode 51346433 references free inode 448496647 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 51346435 references free inode 448496649 would clear inode number in entry at offset 32... - agno = 2 entry "fbasic_ofstream" at block 0 offset 264 in directory inode 84868115 references free inode 287203330 would clear inode number in entry at offset 264... entry "fbasic_ostringstream" at block 0 offset 328 in directory inode 84868115 references free inode 448496640 would clear inode number in entry at offset 328... entry "fbasic_streambuf" at block 0 offset 360 in directory inode 84868115 references free inode 155289638 would clear inode number in entry at offset 360... entry "fbasic_stringstream" at block 0 offset 424 in directory inode 84868115 references free inode 448496644 would clear inode number in entry at offset 424... entry "fios_base" at block 0 offset 472 in directory inode 84868115 references free inode 155289642 would clear inode number in entry at offset 472... entry "fmanipulators" at block 0 offset 496 in directory inode 84868115 references free inode 424609831 would clear inode number in entry at offset 496... entry "fpod" in shortform directory 84868120 references free inode 155289633 would have junked entry "fpod" in directory inode 84868120 entry ".." at block 0 offset 32 in directory inode 84868136 references free inode 424609838 would clear inode number in entry at offset 32... - agno = 3 entry "fchar" in shortform directory 129571885 references free inode 155289632 would have junked entry "fchar" in directory inode 129571885 entry "fchar" in shortform directory 129571887 references free inode 155289634 would have junked entry "fchar" in directory inode 129571887 entry "frdbuf" in shortform directory 129571888 references free inode 155289635 would have junked entry "frdbuf" in directory inode 129571888 entry "fchar" in shortform directory 129571893 references free inode 155289640 would have junked entry "fchar" in directory inode 129571893 entry "fchar" in shortform directory 129571894 references free inode 155289641 would have junked entry "fchar" in directory inode 129571894 entry "fchar" in shortform directory 129571896 references free inode 155289643 would have junked entry "fchar" in directory inode 129571896 entry ".." at block 0 offset 32 in directory inode 129571901 references free inode 448496649 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 129571902 references free inode 349614102 would clear inode number in entry at offset 32... - agno = 4 - agno = 5 entry "finf" at block 0 offset 3536 in directory inode 193483808 references free inode 349614101 would clear inode number in entry at offset 3536... entry "fres" in shortform directory 193486858 references free inode 349614100 would have junked entry "fres" in directory inode 193486858 entry ".." at block 0 offset 32 in directory inode 193486859 references free inode 287203340 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 193486860 references free inode 424609836 would clear inode number in entry at offset 32... - agno = 6 entry "fzlib" at block 0 offset 1304 in directory inode 225607728 references free inode 287203340 would clear inode number in entry at offset 1304... entry "fpod" in shortform directory 225609755 references free inode 287203332 would have junked entry "fpod" in directory inode 225609755 - agno = 7 entry "fchar" in shortform directory 248475672 references free inode 287203329 would have junked entry "fchar" in directory inode 248475672 entry "fchar" in shortform directory 248475676 references free inode 287203333 would have junked entry "fchar" in directory inode 248475676 entry "fchar" in shortform directory 248475678 references free inode 287203335 would have junked entry "fchar" in directory inode 248475678 entry "fchar" in shortform directory 248475679 references free inode 287203336 would have junked entry "fchar" in directory inode 248475679 entry ".." at block 0 offset 32 in directory inode 248475686 references free inode 349614102 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 248475688 references free inode 424609838 would clear inode number in entry at offset 32... - agno = 8 - agno = 9 entry ".." at block 0 offset 32 in directory inode 313303087 references free inode 287203328 would clear inode number in entry at offset 32... entry "fchar" in shortform directory 313303095 references free inode 349614096 would have junked entry "fchar" in directory inode 313303095 entry ".." at block 0 offset 32 in directory inode 313304068 references free inode 287203342 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 313304069 references free inode 287203343 would clear inode number in entry at offset 32... - agno = 10 entry "fwchar_t" in shortform directory 349614091 references free inode 424609825 would have junked entry "fwchar_t" in directory inode 349614091 entry "fimbue" at block 0 offset 144 in directory inode 349614094 references free inode 448496642 would clear inode number in entry at offset 144... entry "fsgetn" at block 0 offset 336 in directory inode 349614094 references free inode 448496643 would clear inode number in entry at offset 336... - agno = 11 entry "fchar" in shortform directory 386031657 references free inode 424609824 would have junked entry "fchar" in directory inode 386031657 entry "fchar" in shortform directory 386031659 references free inode 424609826 would have junked entry "fchar" in directory inode 386031659 entry "fchar" in shortform directory 386031661 references free inode 424609828 would have junked entry "fchar" in directory inode 386031661 entry "fchar" in shortform directory 386031662 references free inode 424609829 would have junked entry "fchar" in directory inode 386031662 entry "fchar" in shortform directory 386031663 references free inode 424609830 would have junked entry "fchar" in directory inode 386031663 entry ".." at block 0 offset 32 in directory inode 386031665 references free inode 349614098 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 386031667 references free inode 287203340 would clear inode number in entry at offset 32... entry "fasm386" at block 0 offset 80 in directory inode 386031667 references free inode 424609834 would clear inode number in entry at offset 80... entry "fasm586" at block 0 offset 104 in directory inode 386031667 references free inode 448496648 would clear inode number in entry at offset 104... entry "funtgz" at block 0 offset 272 in directory inode 386031667 references free inode 155289646 would clear inode number in entry at offset 272... entry "fbuild" in shortform directory 386031668 references free inode 424609836 would have junked entry "fbuild" in directory inode 386031668 entry "fdebian" in shortform directory 386031668 references free inode 287203342 would have junked entry "fdebian" in directory inode 386031668 entry "fsrc" in shortform directory 386031668 references free inode 349614102 would have junked entry "fsrc" in directory inode 386031668 entry ".." at block 0 offset 32 in directory inode 386031669 references free inode 349614102 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 386031671 references free inode 424609838 would clear inode number in entry at offset 32... - agno = 12 entry "fgcc-arm-linux_3.3.3-1.dsc.asc" at block 0 offset 2584 in directory inode 424606730 references free inode 424609835 would clear inode number in entry at offset 2584... entry "fgcc-m68k-elf-3.4.1" at block 0 offset 2944 in directory inode 424606730 references free inode 287203341 would clear inode number in entry at offset 2944... - agno = 13 - agno = 14 entry "fconfig" at block 0 offset 432 in directory inode 486566933 references free inode 287203338 would clear inode number in entry at offset 432... entry "fdemangle" at block 0 offset 472 in directory inode 486566933 references free inode 349614098 would clear inode number in entry at offset 472... entry "flibstdc++-dg" at block 0 offset 528 in directory inode 486566933 references free inode 424609833 would clear inode number in entry at offset 528... entry "fperformance" at block 0 offset 552 in directory inode 486566933 references free inode 448496647 would clear inode number in entry at offset 552... entry "fstdio_filebuf" at block 0 offset 312 in directory inode 486566973 references free inode 155289644 would clear inode number in entry at offset 312... entry ".." at block 0 offset 32 in directory inode 486567936 references free inode 448496649 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 486567937 references free inode 424609837 would clear inode number in entry at offset 32... - agno = 15 entry "fextractors_other" at block 0 offset 208 in directory inode 523361301 references free inode 287203328 would clear inode number in entry at offset 208... entry "fends" at block 0 offset 144 in directory inode 523361304 references free inode 155289636 would clear inode number in entry at offset 144... entry "fflush" at block 0 offset 184 in directory inode 523361304 references free inode 287203331 would clear inode number in entry at offset 184... entry "fseekp" at block 0 offset 320 in directory inode 523361304 references free inode 155289637 would clear inode number in entry at offset 320... entry ".." at block 0 offset 32 in directory inode 523361316 references free inode 424609837 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 523361317 references free inode 424609838 would clear inode number in entry at offset 32... No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... entry "fgcc-arm-linux_3.3.3-1.dsc.asc" in directory inode 424606730 points to free inode 424609835, would junk entry entry "fgcc-m68k-elf-3.4.1" in directory inode 424606730 points to free inode 287203341, would junk entry entry "fbuild" in shortform directory inode 386031668 points to free inode 424609836 would junk entry "fbuild" entry "fdebian" in shortform directory inode 386031668 points to free inode 287203342 would junk entry "fdebian" entry "fsrc" in shortform directory inode 386031668 points to free inode 349614102 would junk entry "fsrc" entry "fzlib" in directory inode 225607728 points to free inode 287203340, would junk entry entry "fconfig" in directory inode 486566933 points to free inode 287203338, would junk entry entry "fdemangle" in directory inode 486566933 points to free inode 349614098, would junk entry entry "flibstdc++-dg" in directory inode 486566933 points to free inode 424609833, would junk entry entry "fperformance" in directory inode 486566933 points to free inode 448496647, would junk entry entry "fstdio_filebuf" in directory inode 486566973 points to free inode 155289644, would junk entry entry "fbasic_ofstream" in directory inode 84868115 points to free inode 287203330, would junk entry entry "fbasic_ostringstream" in directory inode 84868115 points to free inode 448496640, would junk entry entry "fbasic_streambuf" in directory inode 84868115 points to free inode 155289638, would junk entry entry "fbasic_stringstream" in directory inode 84868115 points to free inode 448496644, would junk entry entry "fios_base" in directory inode 84868115 points to free inode 155289642, would junk entry entry "fmanipulators" in directory inode 84868115 points to free inode 424609831, would junk entry entry "fchar" in shortform directory inode 129571896 points to free inode 155289643 would junk entry "fchar" entry "fimbue" in directory inode 349614094 points to free inode 448496642, would junk entry entry "fsgetn" in directory inode 349614094 points to free inode 448496643, would junk entry entry "fchar" in shortform directory inode 386031663 points to free inode 424609830 would junk entry "fchar" entry "fchar" in shortform directory inode 313303095 points to free inode 349614096 would junk entry "fchar" entry "fchar" in shortform directory inode 248475679 points to free inode 287203336 would junk entry "fchar" entry "fchar" in shortform directory inode 129571894 points to free inode 155289641 would junk entry "fchar" entry "fchar" in shortform directory inode 386031662 points to free inode 424609829 would junk entry "fchar" entry "fchar" in shortform directory inode 248475678 points to free inode 287203335 would junk entry "fchar" entry "fchar" in shortform directory inode 129571893 points to free inode 155289640 would junk entry "fchar" entry "fchar" in shortform directory inode 386031661 points to free inode 424609828 would junk entry "fchar" entry "fends" in directory inode 523361304 points to free inode 155289636, would junk entry entry "fflush" in directory inode 523361304 points to free inode 287203331, would junk entry entry "fseekp" in directory inode 523361304 points to free inode 155289637, would junk entry entry "fchar" in shortform directory inode 386031659 points to free inode 424609826 would junk entry "fchar" entry "fpod" in shortform directory inode 225609755 points to free inode 287203332 would junk entry "fpod" entry "fwchar_t" in shortform directory inode 349614091 points to free inode 424609825 would junk entry "fwchar_t" entry "frdbuf" in shortform directory inode 129571888 points to free inode 155289635 would junk entry "frdbuf" entry "fextractors_other" in directory inode 523361301 points to free inode 287203328, would junk entry entry "fchar" in shortform directory inode 248475672 points to free inode 287203329 would junk entry "fchar" entry "fchar" in shortform directory inode 129571887 points to free inode 155289634 would junk entry "fchar" entry "fpod" in shortform directory inode 84868120 points to free inode 155289633 would junk entry "fpod" entry "fchar" in shortform directory inode 129571885 points to free inode 155289632 would junk entry "fchar" entry "finf" in directory inode 193483808 points to free inode 349614101, would junk entry entry "fimkr6_1" in directory inode 51345453 points to free inode 287203337, would junk entry entry "fres" in shortform directory inode 193486858 points to free inode 349614100 would junk entry "fres" [Whoops... missed a bit... history is full of "would have resent inode X nlinks from Y to Z" messages. It ends with:] would have reset inode 515105802 nlinks from 46 to 45 would have reset inode 515270693 nlinks from 6 to 5 would have reset inode 515270694 nlinks from 6 to 5 would have reset inode 515270695 nlinks from 6 to 5 would have reset inode 515270696 nlinks from 6 to 5 would have reset inode 515270697 nlinks from 4 to 3 would have reset inode 515270710 nlinks from 4 to 3 would have reset inode 515272704 nlinks from 4 to 3 would have reset inode 515272705 nlinks from 4 to 3 would have reset inode 523361301 nlinks from 17 to 16 would have reset inode 523361304 nlinks from 15 to 12 No modify flag set, skipping filesystem flush and exiting. From owner-linux-xfs@oss.sgi.com Mon Oct 31 21:02:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 Oct 2005 21:02:59 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA152tO0025613 for ; Mon, 31 Oct 2005 21:02: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 jA167uoS002357 for ; Mon, 31 Oct 2005 22:07:57 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA14xgDN18956618; Mon, 31 Oct 2005 22:59:42 -0600 (CST) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id jA14xelo7211089; Mon, 31 Oct 2005 22:59:40 -0600 (CST) Date: Mon, 31 Oct 2005 22:59:41 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@penguin.americas.sgi.com To: linux@horizon.com cc: linux-xfs@oss.sgi.com Subject: Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid In-Reply-To: <20051101040513.22434.qmail@science.horizon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 865 Lines: 28 linux@horizon.com wrote: > I've been having hard-to-reproduce sata_sil24 driver problems, and > the most recent lockup appears to have taken out my root file system. > (Hooray for emergency boot partitions!) > > # mount -r /dev/md4 /mnt > mount: /dev/md4: can't read superblock > > With the following appended to the kernel log: > > XFS mounting filesystem md4 > Starting XFS recovery on filesystem: md4 (dev: md4) > XFS: xlog_recover_process_data: bad clientid > XFS: log mount/recovery failed: error 5 > XFS: log mount failed > > I haven't put this server into production yet (due to aforementioned > libata issues), so I'm experiementing with XFS, but this failure isn't > confidence-inspiring. Is the problematic filesystem on the aforementioned flakey driver? Any kernel messages prior to the fs problems? (related to underlying IO problems?) -Eric