From owner-linux-xfs Fri Apr 1 04:58:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Apr 2005 04:58:32 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31CwVkc001137 for ; Fri, 1 Apr 2005 04:58:31 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j31CwUiv001136 for linux-xfs@oss.sgi.com; Fri, 1 Apr 2005 04:58:30 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31CwSLD001123 for ; Fri, 1 Apr 2005 04:58:28 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j31CkQBj000921; Fri, 1 Apr 2005 04:46:26 -0800 Date: Fri, 1 Apr 2005 04:46:26 -0800 Message-Id: <200504011246.j31CkQBj000921@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 400] lvm2 snapshots? X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=400 ------- Additional Comments From walter@sara.nl 2005-01-04 04:46 PDT ------- I found out that xfs_freeze results in an XFS_IOC_FREEZE in xfs/linux-2.6/xfs_ioctl.c This calls freeze_bdev() We are using device mapper and I suspect that dm_suspend() should be called instead. dm_suspend() is in drivers/md/dm.c and the comments for this function describe exactly what you want xfs_freeze to do: /* * We need to be able to change a mapping table under a mounted * filesystem. For example we might want to move some data in * the background. Before the table can be swapped with * dm_bind_table, dm_suspend must be called to flush any in * flight bios and ensure that any further io gets deferred. */ int dm_suspend(struct mapped_device *md) This function is also called when you do 'dmsetup suspend /dev/mapper/some_lv' from the shell. As a workaround, I am now using 'dmsetup suspend' rather than 'xfs_freeze -f'. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Apr 1 10:32:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Apr 2005 10:32:37 -0800 (PST) Received: from postoffice6.mail.cornell.edu (postoffice6.mail.cornell.edu [132.236.56.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31IWZC0021336 for ; Fri, 1 Apr 2005 10:32:35 -0800 Received: from [132.236.157.122] ([132.236.157.122]) by postoffice6.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id j31IWYgl006390 for ; Fri, 1 Apr 2005 13:32:34 -0500 (EST) Message-ID: <424D93BF.8060003@cornell.edu> Date: Fri, 01 Apr 2005 13:32:31 -0500 From: Robert Buels User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsdump __alloc_pages failures and (maybe) kernel panics on debian stable/vanilla 2.4.29 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5214 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rmb32@cornell.edu Precedence: bulk X-list: linux-xfs Hi all, Summary: On a pretty fast server running debian stable and vanilla linux 2.4.29, xfsdump is very slow to write media files and produces "__alloc_pages: 0-order allocation failed (gfp=0x0/0)" kernel error messages when backing up a 1/3 full 915GB partition, and may be causing the machine to hard lock. Any ideas what the problem could be here? Extended info: I have a new server, dual 2.4GHz xeon, 2GB RAM, with an LSI SATA hardware raid 5 ('megaraid' kernel driver), running debian stable, with a 2.4.29 vanilla kernel, connected to an exabyte LTO2 tape changer through a SCSI card using the sym53c8xx. On the big raid 5 (appearing to the OS as /dev/sda), there is a large (915GB) XFS partition mounted at /data. I am running backups of this large partition onto the tape changer using xfsdump. During testing of this new setup, I had about 300GB on the partition, with a handful of directories and mostly in one large 250GB file that was a ext3 dump of one of our old fileservers. xfsdump worked just fine, backing up the 250 gigs overnight with no problem, writing files to the tapes at about 16MB/sec, which is near spec for the tape drive. Following the successful testing of the xfsdump-based backup system, I have now started transitioning this machine into production use, filling the /data partition with about 384 GB in 2,129,850 files and about 9,000 directories. Now, xfsdump seems to be having some significant difficulties backing up this partition. It now seems to take upwards of 3 minutes to assemble a single media file of about 300MB, while the tape drive sits idly, then writes the media file to the tape drive at what seems to be near-spec speed. This may be normal for xfsdump, I don't know, since this is my first experience with it. HOWEVER, while this is going on, error messages from the kernel pop up, 2 or 3 at a time, saying: __alloc_pages: 0-order allocation failed (gfp=0x0/0) The gfp number there what it actually says is real, and is always 0x0/0. These are the only kernel error messages I have seen. Worse, the machine hard-locked sometime last night, and I was unable to recover any console output and there was nothing in the system or kernel logs, it just stopped and hung. I started a level 0 dump four days ago that I expect probably finished last night, and I have a suspicion that xfsdump may have caused the hard lock, but I have no evidence to confirm this, but it seems to me like a pretty good bet. What could be the problem here? More Info: Operating System: Linux Debian stable (woody) solanine:/data/shared# uname -a Linux solanine 2.4.29 #7 SMP Fri Feb 18 17:33:29 EST 2005 i686 unknown solanine:/data/shared# apt-cache show xfsdump Package: xfsdump Priority: optional Section: admin Installed-Size: 636 Maintainer: Nathan Scott Architecture: i386 Version: 2.0.1-2 Depends: attr (>= 2.0.0), dmapi (>= 2.0.0), libc6 (>= 2.2.4-4), xfsprogs (>= 2.0.0) Filename: pool/main/x/xfsdump/xfsdump_2.0.1-2_i386.deb Size: 250276 MD5sum: 360961a6f9d54222c6c08385592e8a33 example xfsdump output on a root console: xfsdump: media file size 376438784 bytes xfsdump: creating dump session media file 1156 (media 1, file 229) xfsdump: dumping ino map xfsdump: dumping directories __alloc_pages: 0-order allocation failed (gfp=0x0/0) __alloc_pages: 0-order allocation failed (gfp=0x0/0) __alloc_pages: 0-order allocation failed (gfp=0x0/0) xfsdump: dumping non-directory files xfsdump: ending media file xfsdump: media file size 376438784 bytes xfsdump: creating dump session media file 1157 (media 1, file 230) xfsdump: dumping ino map xfsdump: dumping directories -- Robert Buels SGN Bioinformatics Analyst 252A Emerson Hall, Cornell University Ithaca, NY 14853 Tel: 607-255-2360 rmb32@cornell.edu http://www.sgn.cornell.edu From owner-linux-xfs Fri Apr 1 15:05:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Apr 2005 15:05:55 -0800 (PST) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j31N5q2f006874 for ; Fri, 1 Apr 2005 15:05:53 -0800 Received: from taniwha.stupidest.org (adsl-63-202-174-57.dsl.snfc21.pacbell.net [63.202.174.57]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j31N5m28445862; Fri, 1 Apr 2005 18:05:49 -0500 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 6A38C11A435F; Fri, 1 Apr 2005 15:05:48 -0800 (PST) Date: Fri, 1 Apr 2005 15:05:48 -0800 From: Chris Wedgwood To: Robert Buels Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump __alloc_pages failures and (maybe) kernel panics on debian stable/vanilla 2.4.29 Message-ID: <20050401230548.GB19140@taniwha.stupidest.org> References: <424D93BF.8060003@cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424D93BF.8060003@cornell.edu> X-Virus-Scanned: ClamAV 0.83/799/Fri Apr 1 02:49:13 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Apr 01, 2005 at 01:32:31PM -0500, Robert Buels wrote: > On a pretty fast server running debian stable and vanilla linux > 2.4.29, xfsdump is very slow to write media files and produces > "__alloc_pages: 0-order allocation failed (gfp=0x0/0)" kernel error > messages when backing up a 1/3 full 915GB partition, and may be > causing the machine to hard lock. you ran out of memory check /proc/meminfo and make sure it looks sane --- it's possible something is leaking > I have a new server, dual 2.4GHz xeon, 2GB RAM, with an LSI SATA > hardware raid 5 ('megaraid' kernel driver), running debian stable, > with a 2.4.29 vanilla kernel, connected to an exabyte LTO2 tape > changer through a SCSI card using the sym53c8xx. On the big raid 5 > (appearing to the OS as /dev/sda), there is a large (915GB) XFS > partition mounted at /data. I am running backups of this large > partition onto the tape changer using xfsdump. i wonder if page-cache pressure here is making things worse. i saw pretty unreasonable behaviour using xfsdump under 2.4.x a while ago 2.6.x is better but the problem can still occur, mostly you fill the page-cache and things start to swap and get crappy --- but i never got OOM as you are maybe xfsdump should use posix_fadvise and see if that helps? > Now, xfsdump seems to be having some significant difficulties > backing up this partition. It now seems to take upwards of 3 > minutes to assemble a single media file of about 300MB, while the > tape drive sits idly, then writes the media file to the tape drive > at what seems to be near-spec speed. what does 'vmstat 1' look like during this? From owner-linux-xfs Sat Apr 2 16:46:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Apr 2005 16:47:00 -0800 (PST) Received: from rain.plan9.de (schmorp@rain.plan9.de [193.108.181.162]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j330kv05016640 for ; Sat, 2 Apr 2005 16:46:58 -0800 Received: from [10.0.0.5] (helo=mailout.schmorp.de ident=schmorp) by rain.plan9.de with esmtp (Exim 4.34) id 1DHtGR-0003s9-DG for linux-xfs@oss.sgi.com; Sun, 03 Apr 2005 02:46:55 +0200 Received: from [10.0.0.1] (helo=cerebro.laendle) by mailout.schmorp.de with esmtp (Exim 4.44) id 1DHtGP-00012q-Vp for linux-xfs@oss.sgi.com; Sun, 03 Apr 2005 02:46:54 +0200 Received: from root by cerebro.laendle with local (Exim 4.34) id 1DHtGP-0000HM-I1 for linux-xfs@oss.sgi.com; Sun, 03 Apr 2005 02:46:53 +0200 Date: Sun, 3 Apr 2005 02:46:53 +0200 From: Marc Lehmann To: linux-xfs@oss.sgi.com Subject: unexpected high fragmentation, any ideas? Message-ID: <20050403004653.GA981@schmorp.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP: "1024D/DA743396 1999-01-26 Marc Alexander Lehmann Key fingerprint = 475A FE9B D1D4 039E 01AC C217 A1E8 0270 DA74 3396" X-Virus-Scanned: ClamAV 0.83/801/Sat Apr 2 02:36:25 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5216 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: schmorp@schmorp.de Precedence: bulk X-list: linux-xfs Hi! (I am not on this list) As one of the advertised features of XFS is reducing (external) fragmentation in multple-writer cases, I thought I'd give it a try on my Personal Video Recorder. The typical workload of my PVR includes writing files of a few gigabytes in size over the duration of a few hours (roughly 1-2mb/s video recording), plus transcoding processes that read previously recorded shows and re-encode them to mpeg4, which is a slow (non-realtime) process and usually involves writing around 200-300kb/s. At any one point in time, I have a maximum of two video recording streams and two transcoding processes (plus up to 5 readers). When I run xfs_fsr, I get very high extent counts: extents before:1903 after:1 DONE ino=537176316 (this was a one-hour show, longer shows easily reach 3000-5000 extents). This looks very high, compared to ext3 which I previously used (I used a simple tool that analyzed the block numbers returned by the fibmap ioctl), where I usually had less than 200 "holes" per gigabyte, many of which were caused by ext2's layout itself). I/O speed also seems to be affected: while I can read&write defragmented files with near disk speed (~30MB/s), I am unable to read newly recorded or transcoded streams with more than about 8mb/s (However, this was on a live system, so it's hard to measure actual throughput). I am using the XFS that came with the (unpatched) 2.6.11 kernel; the disk is a 160GB disk that is _only_ being used for these recordings, which are all stored in the same directory. The disk had always 50GB or more of free space, and the initial contents were simply untar'ed, so there shouldn't be much fragmentation onm the actual disk. Is this behaviour to be expected (and my usage pattern is simply bad for XFS), or can this behaviour somehow be tuned, or am I doing sth. wrong? Running xfs_fsr is possible in my setup (there is usually a time where no recordings take place, although this is not deterministic, and running xfs_fsr during recordings might introduce a too-high load), but most of the files get created/deleted in less than 24 hours, so when xfs_fsr runs it's already a bit late. Thanks a lot for any insights, and thanks a lot for bringing XFS to linux! -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE From owner-linux-xfs Sun Apr 3 06:58:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Apr 2005 06:58:11 -0700 (PDT) Received: from rain.plan9.de (schmorp@rain.plan9.de [193.108.181.162]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33Dw8vO021863 for ; Sun, 3 Apr 2005 06:58:09 -0700 Received: from [10.0.0.5] (helo=mailout.schmorp.de ident=schmorp) by rain.plan9.de with esmtp (Exim 4.34) id 1DI5c6-0004v2-4Y for linux-xfs@oss.sgi.com; Sun, 03 Apr 2005 15:58:06 +0200 Received: from [10.0.0.2] (helo=fuji.laendle) by mailout.schmorp.de with esmtp (Exim 4.44) id 1DI5c5-00088s-Mn for linux-xfs@oss.sgi.com; Sun, 03 Apr 2005 15:58:05 +0200 Received: from root by fuji.laendle with local (Exim 4.34) id 1DI5c5-0006oc-LK for linux-xfs@oss.sgi.com; Sun, 03 Apr 2005 15:58:05 +0200 Date: Sun, 3 Apr 2005 15:58:05 +0200 From: Marc Lehmann To: linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? Message-ID: <20050403135805.GC24559@schmorp.de> References: <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050403004653.GA981@schmorp.de> X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: schmorp@schmorp.de Precedence: bulk X-list: linux-xfs I was contacted in private to offer more information, and thoguht it might be a good idea to let the list know: * all files are being written into the same directory. like 2-4 slow "dd of=/xfs/video.dat"'s * the disk is used exclusively for this application, no other writers are present. (fragmentation reduces i/o performance) I just mentioned that in case xfs would display a high extent count but the file would, in fact, be almost contiguous. I now used xfs_bmap on a recently-written file (2.2GB), it looks like this: 17_20050403135800_20050403150000.nuv: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..895]: 161889248..161890143 8 (5598368..5599263) 896 1: [896..1151]: 161882848..161883103 8 (5591968..5592223) 256 2: [1152..101119]: 173099520..173199487 8 (16808640..16908607) 99968 3: [101120..511231]: 195363656..195773767 10 (56..410167) 410112 4: [511232..910975]: 214936240..215335983 11 (36280..436023) 399744 5: [910976..987903]: 243994088..244071015 12 (9557768..9634695) 76928 6: [987904..988927]: 238584712..238585735 12 (4148392..4149415) 1024 7: [988928..989951]: 238583688..238584711 12 (4147368..4148391) 1024 8: [989952..991999]: 238581640..238583687 12 (4145320..4147367) 2048 9: [992000..994175]: 238579464..238581639 12 (4143144..4145319) 2176 10: [994176..996351]: 238577280..238579455 12 (4140960..4143135) 2176 11: [996352..998399]: 238575232..238577279 12 (4138912..4140959) 2048 12: [998400..1000575]: 238573056..238575231 12 (4136736..4138911) 2176 13: [1000576..1002623]: 238571008..238573055 12 (4134688..4136735) 2048 14: [1002624..1003775]: 238569856..238571007 12 (4133536..4134687) 1152 15: [1003776..1004799]: 238568832..238569855 12 (4132512..4133535) 1024 16: [1004800..1005823]: 238567808..238568831 12 (4131488..4132511) 1024 17: [1005824..1006847]: 238566784..238567807 12 (4130464..4131487) 1024 18: [1006848..1007871]: 238565760..238566783 12 (4129440..4130463) 1024 19: [1007872..1009023]: 238564608..238565759 12 (4128288..4129439) 1152 20: [1009024..1010047]: 238563584..238564607 12 (4127264..4128287) 1024 21: [1010048..1011071]: 238562560..238563583 12 (4126240..4127263) 1024 22: [1011072..1012095]: 238561536..238562559 12 (4125216..4126239) 1024 23: [1012096..1013119]: 238560512..238561535 12 (4124192..4125215) 1024 24: [1013120..1014271]: 238559360..238560511 12 (4123040..4124191) 1152 25: [1014272..1015295]: 238558336..238559359 12 (4122016..4123039) 1024 26: [1015296..1016319]: 238557312..238558335 12 (4120992..4122015) 1024 27: [1016320..1018367]: 238555264..238557311 12 (4118944..4120991) 2048 28: [1018368..1019391]: 238554240..238555263 12 (4117920..4118943) 1024 ... the remaining ~500 extents look very similar (~1024 block). it looks as if there was only one writer initially (that's just a conjecture), and that xfs simply interleaves write()'s by multiple writers (1024 blocks is probably the i/o size the writers use, they use rather large write()s). looking at the extent above map, i also see this pattern quite often: when the block order is abcdefghi then xfs allocates extents in this order: abdcefhgi i.e. it often swaps adjacent blocks, see, for example, pairs 6&7, 13&14. Looking at some other files this is quite common. ext3 looks much better as it (seemingly) tries to allocate the files in different block groups when multiple files are being written. xfs_fsr, OTOH, does a perfect job - all files are single-extent files after it ran, even when I run it while there are three other writers! I'd run xfs_fsr continuously, but the i/o bandwidth lost is immense, and xfs_fsr tends to copy gigabytes of a file and then detects that the file is being modified, which somewhat precludes it's use on a busy filesystem. -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE From owner-linux-xfs Sun Apr 3 08:39:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Apr 2005 08:39:19 -0700 (PDT) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33FdITX029693 for ; Sun, 3 Apr 2005 08:39:18 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 3 Apr 2005 08:39:13 -0700 Received: from [127.0.0.1] ([172.16.82.13]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 3 Apr 2005 08:39:12 -0700 Message-ID: <4250000C.5070709@xfs.org> Date: Sun, 03 Apr 2005 09:39:08 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Lehmann CC: linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? References: <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> In-Reply-To: <20050403135805.GC24559@schmorp.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2005 15:39:12.0831 (UTC) FILETIME=[490B1CF0:01C53863] X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5218 X-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 Marc Lehmann wrote: > I was contacted in private to offer more information, and thoguht it might be > a good idea to let the list know: > > * all files are being written into the same directory. like 2-4 slow "dd > of=/xfs/video.dat"'s Hi Marc, Do you know if the app is using buffered or direct I/O ? This is important when it comes to what is doing the actual allocations. If it really is dd then it is obviously buffered. Also, is there an O_SYNC on the writes? How much memory do you have in the box, and what kernel are you running. I just tried two streams of dd using 1M byte writes of 2G files - on my laptop with 512M of memory and a single partition which has my whole system on it, so the layout is non optimal. One file got 49 extents, the other got 25. Combined throughput was 25 M/sec which is not too bad for my laptop. Just running one stream on its own ended up with 13 extents - which shows the state of the free space on my disk. If I switch to O_SYNC for writes it all goes to pot very quickly, the files checkerboard with each other, but the extents do come out in order. It may be the fact that your data is actually coming in slower than this that is causing part of the problem. If the streams are getting synced out before they have a chance to build a large chunk of in memory data that might do it. If you have enough control, try making each incoming stream live in its own directory, that will make the allocator start them off in different allocation groups by default. Are you replaying or transcoding from the same streams as are being recorded or from different ones? The reverse ordering you notice is a little odd, it is definitely supposed to prefer going the other way. Steve From owner-linux-xfs Sun Apr 3 08:45:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Apr 2005 08:45:50 -0700 (PDT) Received: from slurp.thebarn.com (cattelan-host201.dsl.visi.com [208.42.117.201]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33FjlBh030244 for ; Sun, 3 Apr 2005 08:45:47 -0700 Received: from [10.0.0.12] (c-24-118-241-175.hsd1.mn.comcast.net [24.118.241.175]) (authenticated bits=0) by slurp.thebarn.com (8.13.3/8.13.1) with ESMTP id j33FjZIr038257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2005 10:45:41 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <42500F94.1070603@thebarn.com> Date: Sun, 03 Apr 2005 10:45:24 -0500 From: Russell Cattelan User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Lehmann CC: linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? References: <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> In-Reply-To: <20050403135805.GC24559@schmorp.de> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7AFDD8AEB4CCDAD89E55D5F6" X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/803/Sun Apr 3 07:32:43 2005 on slurp.thebarn.com X-Virus-Status: Clean X-archive-position: 5219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7AFDD8AEB4CCDAD89E55D5F6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit You are right about one thing multiple writers will cause file interleaving. It's interesting that delayed allocation is not helping as well as it should XFS should be able to cluster delayed allocate pages together and thus ask the allocator for larger contiguous block at one go. I think the problem you are running into is that with a slow writing app pdflush is pushing pages out to disk to quickly. A way to test that is to increase the pdflush interval, don't remember which proc value you need to change for that dirty_writback_centisecs I think. Marc Lehmann wrote: >I was contacted in private to offer more information, and thoguht it might be >a good idea to let the list know: > >* all files are being written into the same directory. like 2-4 slow "dd > of=/xfs/video.dat"'s > >* the disk is used exclusively for this application, no other writers > are present. > >(fragmentation reduces i/o performance) > >I just mentioned that in case xfs would display a high extent count but >the file would, in fact, be almost contiguous. I now used xfs_bmap on a >recently-written file (2.2GB), it looks like this: > >17_20050403135800_20050403150000.nuv: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > 0: [0..895]: 161889248..161890143 8 (5598368..5599263) 896 > 1: [896..1151]: 161882848..161883103 8 (5591968..5592223) 256 > 2: [1152..101119]: 173099520..173199487 8 (16808640..16908607) 99968 > 3: [101120..511231]: 195363656..195773767 10 (56..410167) 410112 > 4: [511232..910975]: 214936240..215335983 11 (36280..436023) 399744 > 5: [910976..987903]: 243994088..244071015 12 (9557768..9634695) 76928 > 6: [987904..988927]: 238584712..238585735 12 (4148392..4149415) 1024 > 7: [988928..989951]: 238583688..238584711 12 (4147368..4148391) 1024 > 8: [989952..991999]: 238581640..238583687 12 (4145320..4147367) 2048 > 9: [992000..994175]: 238579464..238581639 12 (4143144..4145319) 2176 > 10: [994176..996351]: 238577280..238579455 12 (4140960..4143135) 2176 > 11: [996352..998399]: 238575232..238577279 12 (4138912..4140959) 2048 > 12: [998400..1000575]: 238573056..238575231 12 (4136736..4138911) 2176 > 13: [1000576..1002623]: 238571008..238573055 12 (4134688..4136735) 2048 > 14: [1002624..1003775]: 238569856..238571007 12 (4133536..4134687) 1152 > 15: [1003776..1004799]: 238568832..238569855 12 (4132512..4133535) 1024 > 16: [1004800..1005823]: 238567808..238568831 12 (4131488..4132511) 1024 > 17: [1005824..1006847]: 238566784..238567807 12 (4130464..4131487) 1024 > 18: [1006848..1007871]: 238565760..238566783 12 (4129440..4130463) 1024 > 19: [1007872..1009023]: 238564608..238565759 12 (4128288..4129439) 1152 > 20: [1009024..1010047]: 238563584..238564607 12 (4127264..4128287) 1024 > 21: [1010048..1011071]: 238562560..238563583 12 (4126240..4127263) 1024 > 22: [1011072..1012095]: 238561536..238562559 12 (4125216..4126239) 1024 > 23: [1012096..1013119]: 238560512..238561535 12 (4124192..4125215) 1024 > 24: [1013120..1014271]: 238559360..238560511 12 (4123040..4124191) 1152 > 25: [1014272..1015295]: 238558336..238559359 12 (4122016..4123039) 1024 > 26: [1015296..1016319]: 238557312..238558335 12 (4120992..4122015) 1024 > 27: [1016320..1018367]: 238555264..238557311 12 (4118944..4120991) 2048 > 28: [1018368..1019391]: 238554240..238555263 12 (4117920..4118943) 1024 > >... the remaining ~500 extents look very similar (~1024 block). > >it looks as if there was only one writer initially (that's just a >conjecture), and that xfs simply interleaves write()'s by multiple writers >(1024 blocks is probably the i/o size the writers use, they use rather >large write()s). > >looking at the extent above map, i also see this pattern quite often: > > when the block order is abcdefghi > then xfs allocates extents in this order: abdcefhgi > >i.e. it often swaps adjacent blocks, see, for example, pairs 6&7, >13&14. Looking at some other files this is quite common. > >ext3 looks much better as it (seemingly) tries to allocate the files in >different block groups when multiple files are being written. > >xfs_fsr, OTOH, does a perfect job - all files are single-extent files >after it ran, even when I run it while there are three other writers! > >I'd run xfs_fsr continuously, but the i/o bandwidth lost is immense, and >xfs_fsr tends to copy gigabytes of a file and then detects that the file >is being modified, which somewhat precludes it's use on a busy filesystem. > > > --------------enig7AFDD8AEB4CCDAD89E55D5F6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFCUA+ZNRmM+OaGhBgRAlYfAJd/FE9p0gyd9hcKpBrp7CfqEdzgAJ9RtT/B 5N1e9aM2WLkOa9UkmvilMg== =Yre+ -----END PGP SIGNATURE----- --------------enig7AFDD8AEB4CCDAD89E55D5F6-- From owner-linux-xfs Sun Apr 3 12:03:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Apr 2005 12:03:34 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33J3WgQ007524 for ; Sun, 3 Apr 2005 12:03:33 -0700 Received: from taniwha.stupidest.org (adsl-68-120-152-202.dsl.snfc21.pacbell.net [68.120.152.202]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j33J3ReU012630; Sun, 3 Apr 2005 15:03:29 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 0C6E4111CCC0; Sun, 3 Apr 2005 12:03:27 -0700 (PDT) Date: Sun, 3 Apr 2005 12:03:27 -0700 From: Chris Wedgwood To: Russell Cattelan Cc: Marc Lehmann , linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? Message-ID: <20050403190327.GA13211@taniwha.stupidest.org> References: <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <42500F94.1070603@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42500F94.1070603@thebarn.com> X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sun, Apr 03, 2005 at 10:45:24AM -0500, Russell Cattelan wrote: > I think the problem you are running into is that with a slow writing > app pdflush is pushing pages out to disk to quickly. A way to test > that is to increase the pdflush interval, don't remember which proc > value you need to change for that dirty_writback_centisecs I think. for really slow writes i found a large biosize helped. i've had this in my quilt series for a long time now and use it (with appropriate mount option): # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/30 18:58:10-07:00 cw@f00f.org # xfs_mount.h: # [PATCH] XFS allow large biosize on mount # # fs/xfs/xfs_mount.h # 2004/09/30 18:57:59-07:00 cw@f00f.org +1 -1 # [PATCH] XFS allow large biosize on mount # diff -Nru a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h --- a/fs/xfs/xfs_mount.h 2004-10-22 13:43:53 -07:00 +++ b/fs/xfs/xfs_mount.h 2004-10-22 13:43:53 -07:00 @@ -429,7 +429,7 @@ * Max and min values for UIO and mount-option defined I/O sizes; * min value can't be less than a page. Currently unused. */ -#define XFS_MAX_IO_LOG 16 /* 64K */ +#define XFS_MAX_IO_LOG 24 /* 16MB */ #define XFS_MIN_IO_LOG PAGE_SHIFT /* From owner-linux-xfs Sun Apr 3 14:52:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Apr 2005 14:52:57 -0700 (PDT) Received: from rain.plan9.de (schmorp@rain.plan9.de [193.108.181.162]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j33LqroQ020285 for ; Sun, 3 Apr 2005 14:52:54 -0700 Received: from [10.0.0.5] (helo=mailout.schmorp.de ident=schmorp) by rain.plan9.de with esmtp (Exim 4.34) id 1DID1F-0007J0-7n; Sun, 03 Apr 2005 23:52:33 +0200 Received: from [10.0.0.1] (helo=cerebro.laendle) by mailout.schmorp.de with esmtp (Exim 4.44) id 1DID1D-0004EC-Io; Sun, 03 Apr 2005 23:52:31 +0200 Received: from root by cerebro.laendle with local (Exim 4.34) id 1DID1C-0000UA-U3; Sun, 03 Apr 2005 23:52:30 +0200 Date: Sun, 3 Apr 2005 23:52:30 +0200 From: Marc Lehmann To: Steve Lord , Russell Cattelan , Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? Message-ID: <20050403215230.GA919@schmorp.de> References: <20050403135415.GB24559@schmorp.de> <20050403173940.GA12673@taniwha.stupidest.org> <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <42500F94.1070603@thebarn.com> <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <4250000C.5070709@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050403190327.GA13211@taniwha.stupidest.org> <20050403173940.GA12673@taniwha.stupidest.org> <42500F94.1070603@thebarn.com> <4250000C.5070709@xfs.org> X-PGP: "1024D/DA743396 1999-01-26 Marc Alexander Lehmann Key fingerprint = 475A FE9B D1D4 039E 01AC C217 A1E8 0270 DA74 3396" X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: schmorp@schmorp.de Precedence: bulk X-list: linux-xfs Hi, I am answering these mails in one go. First of all, thanks for the many suggestions, there are lots of ideas to try out. BTW, this is not a real _big_ problem, as the new disk I now use XFS on is just fast enough to record/transcode/read two streams at the same time without skips, so my quest for less fragmentation is mainly an academic one (I'd also like to let the machine do other things at the same time, which would be helped by less fragmentation). XFS so far performs quite adequate. On Sun, Apr 03, 2005 at 09:39:08AM -0500, Steve Lord wrote: > Do you know if the app is using buffered or direct I/O ? This is > an O_SYNC on the writes? buffered I/O. it just opens, write's with large blocksizes, and closes, no O_SYNC, no O_DIRECT. > How much memory do you have in the box, and what kernel are you > running. 640MB, pristine 2.6.11 free usually shows around 200MB free without buffers. > I just tried two streams of dd using 1M byte writes of 2G > files - on my laptop with 512M of memory and a single partition > which has my whole system on it, so the layout is non optimal. The difference is that my "dd's" are very slow, 500-1500kb/s, over a few hours. > One file got 49 extents, the other got 25. Combined throughput was > 25 M/sec which is not too bad for my laptop. It certainly would be good for mine :-> > on its own ended up with 13 extents - which shows the state of the > free space on my disk. The conditions should be much much better on my disk, there are 127 files _total_ on that disk, and almost all of them are larger than 800MB. The disk contents were recently copied from a JFS disk and xfs_fsr was run, so there was no external fragmentation, and I'd think it is very unlikely that there are many (relatively) small fragments. > If I switch to O_SYNC for writes it all goes > to pot very quickly, the files checkerboard with each other, but > the extents do come out in order. Very interesting, I wonder why they checkerboard at all - I'd hoped XFS was smart enough not to do this, as even ext3 is, to a certain extent, and AFAIK, ext3 doesn't do allocate-on-flush. > It may be the fact that your data is actually coming in slower than > this that is causing part of the problem. If the streams are getting > synced out before they have a chance to build a large chunk of in > memory data that might do it. Yes, very likely. > If you have enough control, try making each incoming stream live in > its own directory, that will make the allocator start them off in > different allocation groups by default. Well... involves quite a bit of hackery in the app I use (mythtv, btw.), but I might be able to control the transcoding. I'll try to implement that. > Are you replaying or transcoding from the same streams as are being > recorded or from different ones? It's possible, but rare, that I watch a stream while it is recording, so streams that are being wirtten are not usually being read at the same time, but there is read activity while there is write activity, usually at a similar speed as the writers. > The reverse ordering you notice is a little odd, it is definitely > supposed to prefer going the other way. Yupp. On Sun, Apr 03, 2005 at 10:45:24AM -0500, Russell Cattelan wrote: > You are right about one thing multiple writers will cause file interleaving. Ok. > It's interesting that delayed allocation is not helping as well as it should > XFS should be able to cluster delayed allocate pages together and thus > ask the allocator for larger contiguous block at one go. Hmm... that could be what is going on, actually. If *only* blocks that are in-memory will be clustered together then it's easily explainable, as the kernel will flush data blocks every 50 seconds minimum, which corresponds to about 30MB of data that, in best circumstances, can be clustered together. > I think the problem you are running into is that with a slow writing app > pdflush is pushing pages out to disk to quickly. Yupp. > A way to test that is to increase the pdflush interval, don't remember which > proc value you need to change for that dirty_writback_centisecs I think. Just did that (increased dirty_writeback_centisecs from 500 to 1800) and will check on wether this affects fragmentation (the machine might not have enough memory for this to work effectively at all times, but it could have a noticable effect). I also increased dirty_background_ratio and dirty_ratio to 30 and 60, respectively. On Sun, Apr 03, 2005 at 10:39:40AM -0700, Chris Wedgwood wrote: > > yes, same directory. imagine 2-4 slow "dd of=/xfs/video.dat"'s > > the allocator tries to place files in the same ag (near their parent > directory) Ok, that explains the fragmentation. > > ext3 looks much better as it (seemingly) tries to allocate the files > > in different block groups when multiple files are being written. > > we could put a sysctl or something mount option --- im not sure on the > whole it's useful Well, it would be useful to have a filesystem that works fine with streaming media applications, but it's not typical usage, indeed, and might not be worth the effort. (and xfs_fsr remedies that to a great deal. btw., how would, if it were ported, the realtime subvolume allocator handle that?) What could be useful would be a mount option to force the block allocator to treats files in the same directory like files in different directories. > the current behaviour is pretty nice for smaller files in the same > directory like source-trees for example as they are closer together > reducing seeks making some IO patterns better Indeed. However, even when I mkfs.xfs a partition and then untar some files onto it, all the files have 2 extents (i.e. only one, fast, writer), which I also find a bit peculiar. (again, xfs_fsr makes all complaints about that go away completely. I think an online-defragmenter is the way to go, even a simple one like xfs_fsr, especially when volumes start to become full and fragmentation is unavoidable even with the best allocator). > > xfs_fsr, OTOH, does a perfect job - all files are single-extent > > files after it ran, even when I run it while there are three other > > writers! > > fsr preallocates space in as large-chunks as it can... it's not always > going to be a single extent but with enough free space you will > usually get that It would be interesting to teach mythtv to tell that to XFS, i.e. preallocate all files to, say 3GB when recording and transcoding. As long as enough "3GB slots" are free, this should work nicely. Too bad this can't be done with other filesystems :-> > > I'd run xfs_fsr continuously, but the i/o bandwidth lost is immense, > > and xfs_fsr tends to copy gigabytes of a file and then detects that > > the file is being modified, which somewhat precludes it's use on a > > busy filesystem. > > two things you can try > > (1) create the files in different directories (you can move them > onces created to the same place if you like) I'll try to implement that for the transcoders. > (2) preallocate space --- this is XFS specific though. this will > end up giving you more-or-less the same result as what yoiu end > up with after running xfs_fsr Would probably be easier to hack into mythtv, will think about that (XFS_IOC_RESVSP64?). > are you able to try either of those? it would be nice to know if (1) I don't know when I can get around trying that, but I'll certainly want to try (1). > makes a differnce as that behaviour is something that could be > tweaked/changed as a mount option maybe Would it be easier to just disable it in the kernel? Patching kernel code would be certainly easier for me than implementing it inside mythtv. I'd look myself, but do you have any pointers at which file to look? That would be great, thanks! On Sun, Apr 03, 2005 at 12:03:27PM -0700, Chris Wedgwood wrote: > for really slow writes i found a large biosize helped. i've had this Is this somewthing inside xfs or is this just setting the st_blksize stat data field? If the latter, then its unlikely to help, as I configured mythtv to use fairly large write's already (minimum 512KB, usually around 2MB). But thanks for the tip, it might help some other XFS filesystems I have (although it isn't a problem there). -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE From owner-linux-xfs Sun Apr 3 21:50:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Apr 2005 21:50:16 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j344oCOa018342 for ; Sun, 3 Apr 2005 21:50:13 -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 OAA12286; Mon, 4 Apr 2005 14:50:01 +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 j344nukt030232; Mon, 4 Apr 2005 14:49:56 +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 j344j1vZ001889; Mon, 4 Apr 2005 14:45:01 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j344ixU4001887; Mon, 4 Apr 2005 14:44:59 +1000 Date: Mon, 4 Apr 2005 14:44:59 +1000 From: Nathan Scott To: Robert Buels Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump __alloc_pages failures and (maybe) kernel panics on debian stable/vanilla 2.4.29 Message-ID: <20050404044459.GA1859@frodo> References: <424D93BF.8060003@cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424D93BF.8060003@cornell.edu> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Fri, Apr 01, 2005 at 01:32:31PM -0500, Robert Buels wrote: > Hi all, > > Summary: > > On a pretty fast server running debian stable and vanilla linux 2.4.29, > xfsdump is very slow to write media files and produces "__alloc_pages: > 0-order allocation failed (gfp=0x0/0)" kernel error messages when > backing up a 1/3 full 915GB partition, and may be causing the machine to > hard lock. > > Any ideas what the problem could be here? I'd hazard a guess that your page cache has become filled with XFS metadata buffers, and the memory they are using is not being made reclaimable sufficiently quickly to avoid OOM situations. The CVS tree on oss.sgi.com has a kernel patch (split-patches/cache_defs) which the XFS code in the CVS tree uses to push on that memory and free it up much more quickly when we are getting low on memory. So, you may have more success with a CVS 2.4 kernel, which is also at 2.4.29 presently. cheers. -- Nathan From owner-linux-xfs Sun Apr 3 22:09:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Apr 2005 22:09:39 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3459aSE019389 for ; Sun, 3 Apr 2005 22:09:37 -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 PAA12608; Mon, 4 Apr 2005 15:09:25 +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 j3459Ikt030797; Mon, 4 Apr 2005 15:09:18 +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 j3454KvZ001948; Mon, 4 Apr 2005 15:04:20 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j3454DKj001946; Mon, 4 Apr 2005 15:04:13 +1000 Date: Mon, 4 Apr 2005 15:04:13 +1000 From: Nathan Scott To: Marc Lehmann Cc: Steve Lord , Russell Cattelan , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? Message-ID: <20050404050413.GB1859@frodo> References: <20050403173940.GA12673@taniwha.stupidest.org> <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <42500F94.1070603@thebarn.com> <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <4250000C.5070709@xfs.org> <20050403215230.GA919@schmorp.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050403215230.GA919@schmorp.de> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV 0.83/802/Sat Apr 2 06:49:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Sun, Apr 03, 2005 at 11:52:30PM +0200, Marc Lehmann wrote: > > The reverse ordering you notice is a little odd, it is definitely > > supposed to prefer going the other way. This could be the effect of being called from a memory reclaim path rather than the regular pdflush path. > > > ext3 looks much better as it (seemingly) tries to allocate the files > > > in different block groups when multiple files are being written. > > > > we could put a sysctl or something mount option --- im not sure on the > > whole it's useful Certainly sounds useful, at the very least as an option, if not by default. IIRC, Dave Chinner did some experiments awhile back along these lines, and came up with the same conclusion, but not sure he's coded up a solution there yet. > What could be useful would be a mount option to force the block allocator > to treats files in the same directory like files in different directories. Or perhaps a per-directory flag/attribute. > Would probably be easier to hack into mythtv, will think about that > (XFS_IOC_RESVSP64?). Right. You can experiment with xfs_io, which knows how to issue that command (as well as how to do buffered vs. direct, etc, etc). > > makes a differnce as that behaviour is something that could be > > tweaked/changed as a mount option maybe > > Would it be easier to just disable it in the kernel? Patching kernel code > would be certainly easier for me than implementing it inside mythtv. I'd > look myself, but do you have any pointers at which file to look? That > would be great, thanks! > > On Sun, Apr 03, 2005 at 12:03:27PM -0700, Chris Wedgwood wrote: > > for really slow writes i found a large biosize helped. i've had this > > Is this somewthing inside xfs or is this just setting the st_blksize stat This is inside XFS, it sets the amount preallocated beyond EOF for buffered file writes. Something along these lines will probably be merged soon, as we're seeing needs for it on at least two other fronts. cheers. -- Nathan From owner-linux-xfs Mon Apr 4 08:58:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Apr 2005 08:58:37 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34FwaFA023844 for ; Mon, 4 Apr 2005 08:58:36 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j34FwaU3023843 for linux-xfs@oss.sgi.com; Mon, 4 Apr 2005 08:58:36 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34FwYss023830 for ; Mon, 4 Apr 2005 08:58:34 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j34FPCmo022206; Mon, 4 Apr 2005 08:25:12 -0700 Date: Mon, 4 Apr 2005 08:25:12 -0700 Message-Id: <200504041525.j34FPCmo022206@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 400] lvm2 snapshots? X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=400 walter@sara.nl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From walter@sara.nl 2005-04-04 08:25 PDT ------- OK suspend is definately not the correct way to do it. I found an e-mail on the web from Alasdair Kergon saying that it's a problem with the LVM2 userspace tools. But this was from Oct 2004 and apparently has not been fixed yet. Altogether it doesn't seem to be an XFS problem (at least, as far as I can see). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Apr 4 11:23:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Apr 2005 11:23:25 -0700 (PDT) Received: from mail00hq.adic.com (mail00hq.adic.com [63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34INMQZ011439 for ; Mon, 4 Apr 2005 11:23:22 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Apr 2005 11:23:16 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Apr 2005 11:23:16 -0700 Message-ID: <42518613.2060103@xfs.org> Date: Mon, 04 Apr 2005 13:23:15 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Lehmann CC: Russell Cattelan , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? References: <20050403135415.GB24559@schmorp.de> <20050403173940.GA12673@taniwha.stupidest.org> <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <42500F94.1070603@thebarn.com> <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <4250000C.5070709@xfs.org> <20050403215230.GA919@schmorp.de> In-Reply-To: <20050403215230.GA919@schmorp.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2005 18:23:16.0538 (UTC) FILETIME=[5EC359A0:01C53943] X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5225 X-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 Marc Lehmann wrote: > > On Sun, Apr 03, 2005 at 12:03:27PM -0700, Chris Wedgwood wrote: > >>for really slow writes i found a large biosize helped. i've had this > > > Is this somewthing inside xfs or is this just setting the st_blksize stat > data field? If the latter, then its unlikely to help, as I configured > mythtv to use fairly large write's already (minimum 512KB, usually around > 2MB). But thanks for the tip, it might help some other XFS filesystems I > have (although it isn't a problem there). > This is inside XFS and is different than doing a large I/O. What is happening to you is your writes (independent of size) and just going into cache and no specific disk space is being allocated at write time. XFS is creating a delayed allocation extent, this will be a single extent for the range of data which has not been flushed yet. At some point the kernel decides to flush a page in this range. XFS will determine it is within a delayed allocate extent, and allocate space for the whole thing. However, if you exceed a fairly small size, you will end up just allocating that space, and not preallocating anything else out beyond eof. The patch Chris sent lets the code use a larger value for this preallocation out beyond eof, used in combination with the biosize mount option, it will let xfs do optimistic allocation for future writes. Note this space is freed when the file goes inactive. Also note that this will affect the size returned in st_blksize which may confuse libc if absurdly large values are used. Allocation groups in xfs are basically the units of parallelism within the allocator. You can have one thread active at once in an allocation group. The basic placement rules are file inodes are placed in the same group as their parent directory, directory inodes are placed in a different group than their parent. Extents start out in the same group as the inode, they will scan around allocation groups looking for free space after this. When allocating an extent for an inode, xfs will attempt to place the data as close as it can to the end of the previous extent (it should use increasing block offsets). Now, if you have multiple inodes in the same allocation group allocating extents, they are competing for free space. The algorithm here could be better as the chances are on a filesystem like yours, they will be carving space off the front of the free space in the allocation group. This is where the checkerboarding comes from. The realtime allocator uses a different binary chop algorithm which while wasteful, makes it very hard to fragment realtime files. Hmm, buffered works on realtime, maybe you could try hacking mythtv to set the realtime flag in inodes and see what happens. It occurs to me that while it would fragment up the free space more quickly, having the allocator use a binary chop to carve up the free space rather than always starting at the beginning of it would make it more likely for there to be unused space just beyond the last extent allocated for a file. Implementing that would take some time by someone experienced inside the allocator (Glen are you reading this ;-) at the end of the day, there may actually not be much of a payoff. Steve From owner-linux-xfs Mon Apr 4 12:10:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Apr 2005 12:10:13 -0700 (PDT) Received: from rain.plan9.de (schmorp@rain.plan9.de [193.108.181.162]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34JABbc014998 for ; Mon, 4 Apr 2005 12:10:11 -0700 Received: from [10.0.0.5] (helo=mailout.schmorp.de ident=schmorp) by rain.plan9.de with esmtp (Exim 4.34) id 1DIWxS-0000N1-D7; Mon, 04 Apr 2005 21:09:58 +0200 Received: from [10.0.0.1] (helo=cerebro.laendle) by mailout.schmorp.de with esmtp (Exim 4.44) id 1DIWxR-0000af-WB; Mon, 04 Apr 2005 21:09:58 +0200 Received: from root by cerebro.laendle with local (Exim 4.34) id 1DIWxR-0000BT-T1; Mon, 04 Apr 2005 21:09:57 +0200 Date: Mon, 4 Apr 2005 21:09:57 +0200 From: Marc Lehmann To: Steve Lord Cc: Russell Cattelan , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? Message-ID: <20050404190957.GA576@schmorp.de> References: <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <42500F94.1070603@thebarn.com> <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <4250000C.5070709@xfs.org> <20050403215230.GA919@schmorp.de> <42518613.2060103@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42518613.2060103@xfs.org> X-PGP: "1024D/DA743396 1999-01-26 Marc Alexander Lehmann Key fingerprint = 475A FE9B D1D4 039E 01AC C217 A1E8 0270 DA74 3396" X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5226 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: schmorp@schmorp.de Precedence: bulk X-list: linux-xfs On Mon, Apr 04, 2005 at 01:23:15PM -0500, Steve Lord wrote: > Marc Lehmann wrote: > >Is this somewthing inside xfs or is this just setting the st_blksize stat > >data field? If the latter, then its unlikely to help, as I configured > >mythtv to use fairly large write's already (minimum 512KB, usually around > >2MB). But thanks for the tip, it might help some other XFS filesystems I > >have (although it isn't a problem there). > > > > This is inside XFS and is different than doing a large I/O. What is > happening [very detailed explanations skipped] Thanks a lot for explaining it in that detail! I'll try chris's patch and see how that improves things. > The realtime allocator uses a different binary chop algorithm which while > wasteful, makes it very hard to fragment realtime files. Hmm, buffered works Hmm, is the realtime code ready for use then? I was under the (likely wrong) impression that the realtime code is not yet ready. However, I *guess* I could easily live with, say, 128MB (or even 1GB) realtime extents and live with the internal frgamentation that will occur: If my interpretation is right (not likely) the realtime allocator more-or-less treats these realtime extents as the basic unit of allocation, so internal fragmentation will be extremely high, but external fragmentation is low? > on realtime, maybe you could try hacking mythtv to set the realtime flag in > inodes and see what happens. I'll try. > make it more likely for there to be unused space just beyond the last > extent allocated for a file. Implementing that would take some time by > someone experienced inside the allocator (Glen are you reading this ;-) > at the end of the day, there may actually not be much of a payoff. Quite possible. I think both suggestions might work out. Thanks again! -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE From owner-linux-xfs Mon Apr 4 12:38:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Apr 2005 12:38:30 -0700 (PDT) Received: from mail00hq.adic.com (mail00hq.adic.com [63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j34JcSWE019894 for ; Mon, 4 Apr 2005 12:38:28 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Apr 2005 12:38:23 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Apr 2005 12:38:22 -0700 Message-ID: <425197AC.203@xfs.org> Date: Mon, 04 Apr 2005 14:38:20 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Lehmann CC: Russell Cattelan , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? References: <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <42500F94.1070603@thebarn.com> <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <4250000C.5070709@xfs.org> <20050403215230.GA919@schmorp.de> <42518613.2060103@xfs.org> <20050404190957.GA576@schmorp.de> In-Reply-To: <20050404190957.GA576@schmorp.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2005 19:38:23.0102 (UTC) FILETIME=[DCE271E0:01C5394D] X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5227 X-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 Marc Lehmann wrote: > > >>The realtime allocator uses a different binary chop algorithm which while >>wasteful, makes it very hard to fragment realtime files. Hmm, buffered works > > > Hmm, is the realtime code ready for use then? I was under the (likely > wrong) impression that the realtime code is not yet ready. Let's see if someone answers that, I have no used the buffered over realtime path, just seen the code. > > However, I *guess* I could easily live with, say, 128MB (or even > 1GB) realtime extents and live with the internal frgamentation that > will occur: If my interpretation is right (not likely) the realtime > allocator more-or-less treats these realtime extents as the basic unit of > allocation, so internal fragmentation will be extremely high, but external > fragmentation is low? The realtime extent size is the unit of allocation in the realtime subvolume, you still get larger extents than this, they are just always multiples of this. I don't think you will see fragmentation at all. Steve From owner-linux-xfs Mon Apr 4 23:16:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Apr 2005 23:16:34 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j356GOY6002914 for ; Mon, 4 Apr 2005 23:16:25 -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 QAA01635; Tue, 5 Apr 2005 16:16:16 +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 j356GDkt061627; Tue, 5 Apr 2005 16:16:13 +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 j356BEiq009928; Tue, 5 Apr 2005 16:11:14 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j356BC6a009926; Tue, 5 Apr 2005 16:11:12 +1000 Date: Tue, 5 Apr 2005 16:11:12 +1000 From: Nathan Scott To: Robert Buels Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump __alloc_pages failures and (maybe) kernel panics on debian stable/vanilla 2.4.29 Message-ID: <20050405061112.GC9044@frodo> References: <424D93BF.8060003@cornell.edu> <20050404044459.GA1859@frodo> <4251B4E4.6050104@cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4251B4E4.6050104@cornell.edu> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 07:38:58 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5229 X-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: 348 Lines: 14 On Mon, Apr 04, 2005 at 05:43:00PM -0400, Robert Buels wrote: > Nathan, > > Thanks a lot for the info. I see there has been a 2.4.30 release over > at kernel.org. Does that kernel have the patch that you speak of? I doubt it. The patch should still apply cleanly though, and I'll update the CVS tree at some point soon. cheers. -- Nathan From owner-linux-xfs Tue Apr 5 23:31:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Apr 2005 23:31:08 -0700 (PDT) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j366V4Fp029996 for ; Tue, 5 Apr 2005 23:31:05 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j366UufE059508; Wed, 6 Apr 2005 16:30:56 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j366Up3m059616; Wed, 6 Apr 2005 16:30:51 +1000 (AEST) Date: Wed, 6 Apr 2005 16:30:51 +1000 From: Tim Shimmin To: Craig Rodrigues Cc: linux-xfs@oss.sgi.com Subject: Re: How does linux-xfs list extended attributes by namespace? Message-ID: <20050406163051.D52456@boing.melbourne.sgi.com> References: <20050331173543.GA77406@crodrigues.org> <20050401112352.H3561661@wobbly.melbourne.sgi.com> <20050401021956.GA79464@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050401021956.GA79464@crodrigues.org>; from rodrigc@crodrigues.org on Thu, Mar 31, 2005 at 09:19:56PM -0500 X-Virus-Scanned: ClamAV 0.83/808/Tue Apr 5 02:54:46 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5230 X-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: 4892 Lines: 137 Hi Craig, On Thu, Mar 31, 2005 at 09:19:56PM -0500, Craig Rodrigues wrote: > In terms of documentation/code samples, the best source is > the extattr(2) and extattr(9) man pages: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/sys/extattr_get_file.2 > http://www.freebsd.org/cgi/cvsweb.cgi/src/share/man/man9/extattr.9 > > Basically I am trying to implement the following system call: > > ssize_t extattr_list_file(const char *path, int attrnamespace, void *data, > size_t nbytes); > > Currently on FreeBSD, for attrnamespace, > "user" attr namespace == 1 > "system" attr namespace == 2 > > These are the only namespaces implemented so far, but could be > extended for other file systems > > > On Fri, Apr 01, 2005 at 11:35:31AM +1000, Tim Shimmin wrote: > > Hi Craig, > > From xfs_attr.h: > > #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ > > #define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ > > > > #define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ > > #define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ > > #define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) > > > > So back to the question. > > The linux interface of listing attributes will always list _all_ of > > the EAs for all the namespaces. > > The lower level xfs listing code (VOP_ATTR_LIST or xfs_attr_list) > > can handle listing of EAs for a particular namespace (by specifying > > the namespace bit in the passed in xflags). > > > > --Tim > > > Tim, thanks for your detailed response, it was VERY helpful. > So if I understand things correctly, if I take extattr_list_file()'s > attrnamespace flag, and map it to an ATTR_* flag for xfs_attr_list(), > I might be able to get things to work correctly. Any advice how > to do this? Something like: > > attrnamespace = 1 (user) = xfs_attr_list() flag ATTR_KERNORMALS > attrnamespace = 2 (system) = xfs_attr_list() flag ATTR_KERNROOTLS > > Hmmm... > Not quite. I find the changes that were made for linux a little confusing :) Basically they've added flags to stop doing namespace matches between the request and what is on disk. It has also got complicated because on IRIX we only had a ROOT bit which when 0 meant USER but since then we've added another namespace. The code in list says: if (((context->flags & ATTR_SECURE) != 0) != ((sfe->flags & XFS_ATTR_SECURE) != 0) && !(context->flags & ATTR_KERNORMALS)) { sfe = XFS_ATTR_SF_NEXTENTRY(sfe); continue; } if (((context->flags & ATTR_ROOT) != 0) != ((sfe->flags & XFS_ATTR_ROOT) != 0) && !(context->flags & ATTR_KERNROOTLS)) { sfe = XFS_ATTR_SF_NEXTENTRY(sfe); continue; } i.e. if (we do NOT have the same namespace bits matching for secure AND we are not overriding with ATTR_KERNORMALS) then we don't have a match and look at other EAs if (we do NOT have the same namespace bits for root AND we are not overriding with ATTR_KERNROOTLS) then we don't have a match and look at other EAs In linvfs_listxattr() we set: xflags |= capable(CAP_SYS_ADMIN) ? ATTR_KERNFULLS : ATTR_KERNORMALS; > > #define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) So if we have CAP_SYS_ADMIN then we don't do the 1st check or the 2nd check as we have both overrides on and so we list all. If we do _not_ have CAP_SYS_ADMIN then: (1) as the override is on for secure, we don't test the secure bit (2) as the override is off for root and we don't have ATTR_ROOT set, we will never get the ROOT ones => we get all non-root EAs You want user and system for your xfs_attr_list(). You might map like this: (a) user = user system = root (trusted) OR (b) user = user + secure system = root (trusted) If you do the first one (a), then you basically want what we have on IRIX. For that you could just use 0 for user and ATTR_ROOT for system. If you want the second one (b), which maps user+secure to user, then you need to use an overriding macro. (If we had had the USER namespace as a bit in its own right then we could have done ATTR_USER | ATTR_ROOT which would have been much clearer - but we don't - bummer). For this you could use ATTR_KERNORMALS for user (no secure checks and no root namespace) and ATTR_ROOT for system. i.e. (a) > attrnamespace = 1 (user) = xfs_attr_list() flag 0 > attrnamespace = 2 (system) = xfs_attr_list() flag ATTR_ROOT (b) > attrnamespace = 1 (user) = xfs_attr_list() flag ATTR_KERNORMALS > attrnamespace = 2 (system) = xfs_attr_list() flag ATTR_ROOT You need the ATTR_KERN* macros if you want multiple namespaces. And they work by cancelling out one of the namespace checks. If you ever add attrnamespace = 3 (secure) then just use 0 (user), ATTR_SECURE (secure), ATTR_ROOT (system). I think that makes sense :) --Tim From owner-linux-xfs Wed Apr 6 14:33:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Apr 2005 14:33:58 -0700 (PDT) Received: from rain.plan9.de (schmorp@rain.plan9.de [193.108.181.162]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36LXua9002710 for ; Wed, 6 Apr 2005 14:33:56 -0700 Received: from [10.0.0.5] (helo=mailout.schmorp.de ident=schmorp) by rain.plan9.de with esmtp (Exim 4.34) id 1DJI9q-0004o0-3X for linux-xfs@oss.sgi.com; Wed, 06 Apr 2005 23:33:54 +0200 Received: from [10.0.0.1] (helo=cerebro.laendle) by mailout.schmorp.de with esmtp (Exim 4.44) id 1DJI9p-0007x1-KV for linux-xfs@oss.sgi.com; Wed, 06 Apr 2005 23:33:53 +0200 Received: from root by cerebro.laendle with local (Exim 4.34) id 1DJI9p-0000FP-H8 for linux-xfs@oss.sgi.com; Wed, 06 Apr 2005 23:33:53 +0200 Date: Wed, 6 Apr 2005 23:33:53 +0200 From: Marc Lehmann To: linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? Message-ID: <20050406213352.GA886@schmorp.de> References: <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <42500F94.1070603@thebarn.com> <20050403190327.GA13211@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050403190327.GA13211@taniwha.stupidest.org> X-PGP: "1024D/DA743396 1999-01-26 Marc Alexander Lehmann Key fingerprint = 475A FE9B D1D4 039E 01AC C217 A1E8 0270 DA74 3396" X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: schmorp@schmorp.de Precedence: bulk X-list: linux-xfs Content-Length: 3604 Lines: 67 On Sun, Apr 03, 2005 at 12:03:27PM -0700, Chris Wedgwood wrote: > > I think the problem you are running into is that with a slow writing > > app pdflush is pushing pages out to disk to quickly. A way to test > > that is to increase the pdflush interval, don't remember which proc > > value you need to change for that dirty_writback_centisecs I think. > > for really slow writes i found a large biosize helped. i've had this > in my quilt series for a long time now and use it (with appropriate > mount option): applying the patch and mounting with biosize=24 improved it a little bit, typical xfs_bmap -v output for a recording looks like this: 0: [0..383]: 175826800..175827183 8 (19535920..19536303) 384 1: [384..1023]: 175666096..175666735 8 (19375216..19375855) 640 2: [1024..1151]: 175665968..175666095 8 (19375088..19375215) 128 3: [1152..2175]: 175158880..175159903 8 (18868000..18869023) 1024 4: [2176..4351]: 175156704..175158879 8 (18865824..18867999) 2176 5: [4352..5375]: 175155680..175156703 8 (18864800..18865823) 1024 6: [5376..6399]: 175154656..175155679 8 (18863776..18864799) 1024 7: [6400..7423]: 175153632..175154655 8 (18862752..18863775) 1024 8: [7424..8447]: 175152608..175153631 8 (18861728..18862751) 1024 9: [8448..9471]: 175151584..175152607 8 (18860704..18861727) 1024 10: [9472..10495]: 175150552..175151575 8 (18859672..18860695) 1024 11: [10496..11519]: 175149528..175150551 8 (18858648..18859671) 1024 12: [11520..12479]: 175148568..175149527 8 (18857688..18858647) 960 13: [12480..14591]: 175146456..175148567 8 (18855576..18857687) 2112 14: [14592..15615]: 175145432..175146455 8 (18854552..18855575) 1024 15: [15616..16639]: 175144408..175145431 8 (18853528..18854551) 1024 16: [16640..17663]: 175143384..175144407 8 (18852504..18853527) 1024 17: [17664..30463]: 192737976..192750775 9 (16910736..16923535) 12800 18: [30464..233087]: 208000752..208203375 10 (12637152..12839775) 202624 19: [233088..234111]: 204951752..204952775 10 (9588152..9589175) 1024 20: [234112..235135]: 204950728..204951751 10 (9587128..9588151) 1024 21: [235136..236159]: 204949704..204950727 10 (9586104..9587127) 1024 22: [236160..237183]: 204948680..204949703 10 (9585080..9586103) 1024 23: [237184..238207]: 204947656..204948679 10 (9584056..9585079) 1024 24: [238208..239359]: 204946504..204947655 10 (9582904..9584055) 1152 ..etc.. I'd inclined to say that it didn't improve the situation much, but there certainly is improvement (the typical extent size is now 1024, while before it was more like 127..256). I'd say 4mb/extent is enough to make me happy, given the small amount of work required to arrive at that solution. Thanks for the hint&patch! [realtime code] With regards to realtime code, the reason I was a bit reluctant is the help entry for the realtime subvolume switch in the kernel config, which says: This feature is unsupported at this time, is not yet fully functional, and may cause serious problems. But maybe "realtime subvolume" is not the same thing as "using the realtime block allocator?". -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE From owner-linux-xfs Wed Apr 6 14:59:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Apr 2005 14:59:36 -0700 (PDT) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36LxVM1004351 for ; Wed, 6 Apr 2005 14:59:35 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Apr 2005 14:59:25 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Apr 2005 14:59:25 -0700 Message-ID: <42545BBC.1020003@xfs.org> Date: Wed, 06 Apr 2005 16:59:24 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Lehmann CC: linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? References: <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <42500F94.1070603@thebarn.com> <20050403190327.GA13211@taniwha.stupidest.org> <20050406213352.GA886@schmorp.de> In-Reply-To: <20050406213352.GA886@schmorp.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2005 21:59:25.0554 (UTC) FILETIME=[E5B9A520:01C53AF3] X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5232 X-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: 756 Lines: 24 Marc Lehmann wrote: > > [realtime code] > > With regards to realtime code, the reason I was a bit reluctant is the > help entry for the realtime subvolume switch in the kernel config, which > says: > > This feature is unsupported at this time, is not yet fully > functional, and may cause serious problems. > > But maybe "realtime subvolume" is not the same thing as "using the > realtime block allocator?". > It is the same thing, that comment has been there for several years and is not going to go away unless someone tries to use it in earnest. I don't think the actual code is as bad as that comment suggests. Realtime on Irix was used by lots of folks, its the linux specific parts which may be need a little help. Steve From owner-linux-xfs Wed Apr 6 16:33:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Apr 2005 16:33:36 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j36NXPhx013195 for ; Wed, 6 Apr 2005 16:33:25 -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 j371BVBw002647 for ; Wed, 6 Apr 2005 18:11:42 -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 j36NVq0F12718098; Wed, 6 Apr 2005 18:31:53 -0500 (CDT) Message-ID: <42547167.3090409@sgi.com> Date: Wed, 06 Apr 2005 18:31:51 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: Marc Lehmann , linux-xfs@oss.sgi.com Subject: Re: unexpected high fragmentation, any ideas? References: <20050403004653.GA981@schmorp.de> <20050403050542.GB5727@taniwha.stupidest.org> <20050403135805.GC24559@schmorp.de> <42500F94.1070603@thebarn.com> <20050403190327.GA13211@taniwha.stupidest.org> <20050406213352.GA886@schmorp.de> <42545BBC.1020003@xfs.org> In-Reply-To: <42545BBC.1020003@xfs.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5233 X-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: 890 Lines: 21 Steve Lord wrote: >> This feature is unsupported at this time, is not yet fully >> functional, and may cause serious problems. >> > It is the same thing, that comment has been there for several years > and is not going to go away unless someone tries to use it in > earnest. I don't think the actual code is as bad as that comment > suggests. Realtime on Irix was used by lots of folks, its the linux > specific parts which may be need a little help. Hmm I probably wrote that comment ;-) At one point realtime had a bad habit of clobbering your superblock when IO went to the wrong device... but I fixed that a couple years ago. At one point realtime -was- working fine. If you'd like to try it, and have any concerns, just give it a whirl on a disposable filesystem. Anything that goes wrong will be contained to that filesystem, so no real worries. -Eric From owner-linux-xfs Wed Apr 6 18:06:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Apr 2005 18:06:09 -0700 (PDT) Received: from mailhub1.arup.com.au (mailhub1.arup.com.au [202.3.74.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37165Pg016518 for ; Wed, 6 Apr 2005 18:06:07 -0700 Received: from syduxs03.au.arup.com ([10.32.20.3]) by mailhub1.arup.com.au with InterScan Messaging Security Suite; Thu, 07 Apr 2005 11:05:04 +1000 Received: from sydexc02.global.arup.com (sydexc02.global.arup.com [10.32.11.32]) by syduxs03.au.arup.com (8.12.10/8.12.10) with ESMTP id j370eEJL022004 for ; Thu, 7 Apr 2005 10:40:15 +1000 Received: from bneexc01.global.arup.com ([10.33.11.31]) by sydexc02.global.arup.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Apr 2005 11:05:19 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: realtime ( was RE: unexpected high fragmentation, any ideas? ) Date: Thu, 7 Apr 2005 11:05:18 +1000 Message-ID: <2B6FD80A38020542803BA5DC9B3C9754224C7E@bneexc01.global.arup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: realtime ( was RE: unexpected high fragmentation, any ideas? ) thread-index: AcU7AS8HkX4YmI2gQ56FU7Dta+G/gwADJS0g From: "Scott Fagg" To: X-OriginalArrivalTime: 07 Apr 2005 01:05:19.0357 (UTC) FILETIME=[DDE8EAD0:01C53B0D] X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j37168Pg016521 X-archive-position: 5234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com.au Precedence: bulk X-list: linux-xfs Content-Length: 1366 Lines: 39 Would realtime have any use outside of video-streaming ? What sort of benefit might it offer other apps, e.g. db servers ? > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Eric Sandeen > Sent: Thursday, 7 April 2005 9:32 AM > To: Steve Lord > Cc: Marc Lehmann; linux-xfs@oss.sgi.com > Subject: Re: unexpected high fragmentation, any ideas? > > Steve Lord wrote: > >> This feature is unsupported at this time, is not > yet fully > >> functional, and may cause serious problems. > >> > > It is the same thing, that comment has been there for several years > > and is not going to go away unless someone tries to use it in > > earnest. I don't think the actual code is as bad as that comment > > suggests. Realtime on Irix was used by lots of folks, its the linux > > specific parts which may be need a little help. > > Hmm I probably wrote that comment ;-) At one point realtime > had a bad > habit of clobbering your superblock when IO went to the wrong > device... > but I fixed that a couple years ago. At one point realtime -was- > working fine. > > If you'd like to try it, and have any concerns, just give it > a whirl on > a disposable filesystem. Anything that goes wrong will be > contained to > that filesystem, so no real worries. > > -Eric > From owner-linux-xfs Wed Apr 6 18:50:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Apr 2005 18:50:06 -0700 (PDT) Received: from mail00hq.adic.com (mail00hq.adic.com [63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j371o4Mm023856 for ; Wed, 6 Apr 2005 18:50:04 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Apr 2005 18:49:58 -0700 Received: from [127.0.0.1] ([172.16.82.13]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Apr 2005 18:49:58 -0700 Message-ID: <425491C2.50108@xfs.org> Date: Wed, 06 Apr 2005 20:49:54 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Fagg CC: linux-xfs@oss.sgi.com Subject: Re: realtime ( was RE: unexpected high fragmentation, any ideas? ) References: <2B6FD80A38020542803BA5DC9B3C9754224C7E@bneexc01.global.arup.com> In-Reply-To: <2B6FD80A38020542803BA5DC9B3C9754224C7E@bneexc01.global.arup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2005 01:49:58.0761 (UTC) FILETIME=[1AF58590:01C53B14] X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5235 X-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: 1730 Lines: 44 Scott Fagg wrote: > > Would realtime have any use outside of video-streaming ? What sort of > benefit might it offer other apps, e.g. db servers ? > > Originally the realtime subvolume was designed for media streaming applications. It was coupled with another Irix feature called GRIO or guaranteed rate I/O. Basically a scheme for reserving disk bandwidth for specific I/O streams. At this time it only supported O_DIRECT I/O. There is code in there now to do buffered I/O as well, I cannot say I have used it at all. The basic differences are: o The realtime device only gets file data I/O, there is no metadata on the device at all. You need another partition for this. All the inodes, extent information, freespace maps etc live on this partition - known as the data subvolume. o In order to get a file to live on the realtime subvolume, you have to use a special ioctl call on the file descriptor after it is opened and before any space is allocated. o Space is allocated in muliples of the real time extent size, using a different allocator which uses a binary chop algorithm to parcel out disk space. i.e. the first inode gets space starting at the begining of the space, the second starts in the middle, the third goes 25% of the way into the space etc. It tends to do a good job of keeping things contiguous. o The allocator was also intended to be deterministic, so that the time taken to allocate space should always be about the same. So if you want big fat files which get layed out in one chunk, and spindles where no other I/O gets in the way of the data I/O, then it can be handy. It does sound like something a database might like to use. Steve From owner-linux-xfs Wed Apr 6 19:04:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Apr 2005 19:04:08 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j372458Y024547 for ; Wed, 6 Apr 2005 19:04: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 MAA05459; Thu, 7 Apr 2005 12:03:48 +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 j3723jkt114279; Thu, 7 Apr 2005 12:03:46 +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 j371wiMm001302; Thu, 7 Apr 2005 11:58:45 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j371wbDs001300; Thu, 7 Apr 2005 11:58:37 +1000 Date: Thu, 7 Apr 2005 11:58:37 +1000 From: Nathan Scott To: Scott Fagg , Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: realtime ( was RE: unexpected high fragmentation, any ideas? ) Message-ID: <20050407015837.GA777@frodo> References: <2B6FD80A38020542803BA5DC9B3C9754224C7E@bneexc01.global.arup.com> <425491C2.50108@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425491C2.50108@xfs.org> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5236 X-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: 869 Lines: 22 On Wed, Apr 06, 2005 at 08:49:54PM -0500, Steve Lord wrote: > o In order to get a file to live on the realtime subvolume, you have > to use a special ioctl call on the file descriptor after it is > opened and before any space is allocated. Actually, theres an easy way to do this now which doesn't require applications to know about realtime volumes - a directory can have the "realtime-inherit" flag set on it (e.g. via xfs_io) and files subsequently created in that directory will automatically be marked as realtime (at creation time). I would be surprised if there aren't one or two bugs remaining in the realtime port for Linux, as Steve pointed out, but there is a decent foundation with years of testing on IRIX for the core code, so it shouldn't be too hard to knock out any remaining issues (if someone wanted to give it a go..) cheers. -- Nathan From owner-linux-xfs Wed Apr 6 19:17:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Apr 2005 19:17:52 -0700 (PDT) Received: from mailhub1.arup.com.au (mailhub1.arup.com.au [202.3.74.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j372Hodv025270 for ; Wed, 6 Apr 2005 19:17:51 -0700 Received: from syduxs03.au.arup.com ([10.32.20.3]) by mailhub1.arup.com.au with InterScan Messaging Security Suite; Thu, 07 Apr 2005 12:16:50 +1000 Received: from sydexc02.global.arup.com (sydexc02.global.arup.com [10.32.11.32]) by syduxs03.au.arup.com (8.12.10/8.12.10) with ESMTP id j371q0JL023440; Thu, 7 Apr 2005 11:52:00 +1000 Received: from bneexc01.global.arup.com ([10.33.11.31]) by sydexc02.global.arup.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Apr 2005 12:17:23 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: realtime ( was RE: unexpected high fragmentation, any ideas? ) Date: Thu, 7 Apr 2005 12:17:22 +1000 Message-ID: <2B6FD80A38020542803BA5DC9B3C9754224C81@bneexc01.global.arup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: realtime ( was RE: unexpected high fragmentation, any ideas? ) thread-index: AcU7Fh+nF2eYS24nTHqBDFgwpBqZfwAAYtmQ From: "Scott Fagg" To: "Nathan Scott" , "Steve Lord" Cc: X-OriginalArrivalTime: 07 Apr 2005 02:17:23.0438 (UTC) FILETIME=[EF4350E0:01C53B17] X-Virus-Scanned: ClamAV 0.83/809/Tue Apr 5 11:22:26 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j372Hpdv025281 X-archive-position: 5237 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com.au Precedence: bulk X-list: linux-xfs Content-Length: 1203 Lines: 35 I might give this a go... > -----Original Message----- > From: Nathan Scott [mailto:nathans@sgi.com] > Sent: Thursday, 7 April 2005 11:59 AM > To: Scott Fagg; Steve Lord > Cc: linux-xfs@oss.sgi.com > Subject: Re: realtime ( was RE: unexpected high > fragmentation, any ideas? ) > > On Wed, Apr 06, 2005 at 08:49:54PM -0500, Steve Lord wrote: > > o In order to get a file to live on the realtime > subvolume, you have > > to use a special ioctl call on the file descriptor after it is > > opened and before any space is allocated. > > Actually, theres an easy way to do this now which doesn't require > applications to know about realtime volumes - a directory can have > the "realtime-inherit" flag set on it (e.g. via xfs_io) and files > subsequently created in that directory will automatically be marked > as realtime (at creation time). > > I would be surprised if there aren't one or two bugs remaining in > the realtime port for Linux, as Steve pointed out, but there is a > decent foundation with years of testing on IRIX for the core code, > so it shouldn't be too hard to knock out any remaining issues (if > someone wanted to give it a go..) > > cheers. > > -- > Nathan > From owner-linux-xfs Thu Apr 7 05:00:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Apr 2005 05:00:07 -0700 (PDT) Received: from mailgate.mysql.com (mailgate1.mysql.com [213.115.162.47]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37C03hX001889 for ; Thu, 7 Apr 2005 05:00:04 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate.mysql.com (8.13.2/8.13.1) with ESMTP id j37BwD8n027973; Thu, 7 Apr 2005 13:58:13 +0200 Received: from mail.mysql.com ([10.222.1.99]) by localhost (mailgate.mysql.com [10.222.1.98]) (amavisd-new, port 10026) with LMTP id 27470-02; Thu, 7 Apr 2005 13:58:12 +0200 (CEST) Received: from [192.168.1.54] (c211-28-166-127.eburwd2.vic.optusnet.com.au [211.28.166.127]) (authenticated bits=0) by mail.mysql.com (8.12.10/8.12.10) with ESMTP id j37Bxb4c026682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 7 Apr 2005 13:59:42 +0200 Subject: database filesystem (ab)use [Was: Re: realtime ( was RE: unexpected high fragmentation, any ideas? )] From: Stewart Smith To: Steve Lord Cc: Scott Fagg , linux-xfs@oss.sgi.com In-Reply-To: <425491C2.50108@xfs.org> References: <2B6FD80A38020542803BA5DC9B3C9754224C7E@bneexc01.global.arup.com> <425491C2.50108@xfs.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TWmydMmPW5nVGoEmxMl8" Organization: MySQL AB Date: Thu, 07 Apr 2005 21:59:29 +1000 Message-Id: <1112875170.23224.38.camel@kennedy> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at mailgate.mysql.com X-Virus-Status: Clean X-archive-position: 5239 X-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@mysql.com Precedence: bulk X-list: linux-xfs Content-Length: 2334 Lines: 64 --=-TWmydMmPW5nVGoEmxMl8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-04-06 at 20:49 -0500, Steve Lord wrote: > So if you want big fat files which get layed out in one chunk, and=20 > spindles where no other I/O gets in the way of the data I/O, then > it can be handy. It does sound like something a database might > like to use. For MySQL, with InnoDB tables (the on-disk ones with transactions etc) keeps one (or n) big data file(s) that grows dynamically (or you can statically allocate them in chunks) - typical grow size is 5 or 10MB. ideally, the ibdata files (and *especially* the ib_logfiles) would be contiguous on disk (and close to each other on disk). fsync performance is much more important for innodb (for transaction throughput). XFS is slower than ext3 in this regard (from benchmarks i've run*, data less than physical mem size). for myisam tables, which don't grow by so much (handfuls of kilobytes), and have several files per table (MYD data file, MYI index file) - all tables for a database are in the same directory (usually, users can configure this). The story becomes trickier here (many files growing). XFS does as good or better than ext3. MyISAM also doesn't explicitly sync (so with a lot of inserts, you get only one allocation request). NDB (Cluster) keeps all data in memory and checkpoints to disk (keeping several around). currently, i don't think we use direct io (we should) - when i have a spare minute or three i'll add the flag and see what happens. [*] Can post full benchmark results (mysql-bench), instructions on how to duplicate etc --=20 Stewart Smith, Software Engineer MySQL AB, www.mysql.com Office: +14082136540 Ext: 6616 VoIP: 6616@sip.us.mysql.com Mobile: +61 4 3 8844 332 Jumpstart your cluster: http://www.mysql.com/consulting/packaged/cluster.html --=-TWmydMmPW5nVGoEmxMl8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iQCVAwUAQlUgoYwDm44RooHBAQIl1QP8D+ZJCqT3HPpOj3wiHSRmad3/bEKeKyhU lhPdSH9Sy+8fB7OYg5qUTTAj0DWGT73rlt3tO9LRjfdgVIwOXP3nov6n9fcOsp0N XFuIvHh5S70VAmjo4JALVah/RrIKmvqvx1hBVWOwmRTcstXQA6BFLoQqUhvLW3YY 5W2TJwqfA3I= =duSC -----END PGP SIGNATURE----- --=-TWmydMmPW5nVGoEmxMl8-- From owner-linux-xfs Thu Apr 7 10:22:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Apr 2005 10:22:02 -0700 (PDT) Received: from mx2.tippett.com (mx2.tippett.com [64.81.248.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37HM0fn024975 for ; Thu, 7 Apr 2005 10:22:01 -0700 Received: from hermes.tippett.com (hermes.tippett.com [192.168.3.20]) by mx2.tippett.com (8.12.8/8.12.8) with ESMTP id j37H8ZWr026186 for ; Thu, 7 Apr 2005 10:08:36 -0700 Received: from [192.168.3.62] (gangsta.tippett.com [192.168.3.62]) by hermes.tippett.com (SGI-8.12.5/8.12.5) with ESMTP id j37HLvWa936731 for ; Thu, 7 Apr 2005 10:21:58 -0700 (PDT) Message-ID: <42556C08.6090005@tippett.com> Date: Thu, 07 Apr 2005 10:21:12 -0700 From: Christian Rice Reply-To: xian@tippett.com Organization: Tippett Studio User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: best source for xfsdump rpm? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (mx2.tippett.com [192.168.12.2]); Thu, 07 Apr 2005 10:08:36 -0700 (PDT) X-Scanned-By: MIMEDefang 2.48 on 192.168.12.2 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xian@tippett.com Precedence: bulk X-list: linux-xfs Content-Length: 542 Lines: 14 Anyone got a recommendation for the best place to get a recent xfsdump x86_64, preferably compiled on/for FC3? Or a pointer to the FAQ on how to use CVS over SSH to download and compile the project? Yeah, I've been on the list a long time, but I'm a laggard if the code isn't plopped down as an rpm, or with a ready makefile in a tarball. I need to clone a disk, and I'm not finding xfsdump in the FC3 distro. Isn't that a bit odd? Feel free to publicly make fun of me on this one, but please, only if you have a useful answer ;) From owner-linux-xfs Thu Apr 7 11:18:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Apr 2005 11:18:59 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37IIwue027317 for ; Thu, 7 Apr 2005 11:18:58 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.11/8.12.11) with ESMTP id j37IIoU6011200; Thu, 7 Apr 2005 14:18:50 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.11/8.12.11/Submit) with ESMTP id j37IIoNT011196; Thu, 7 Apr 2005 14:18:50 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 7 Apr 2005 14:18:50 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Christian Rice cc: linux-xfs@oss.sgi.com Subject: Re: best source for xfsdump rpm? In-Reply-To: <42556C08.6090005@tippett.com> Message-ID: References: <42556C08.6090005@tippett.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 569 Lines: 19 On Thu, 7 Apr 2005 at 10:21am, Christian Rice wrote > Anyone got a recommendation for the best place to get a recent xfsdump > x86_64, preferably compiled on/for FC3? Grab the SRPMs from ftp://oss.sgi.com/projects/xfs/cmd_rpms/SRPMS and compile 'em yourself. I just did so on centos-4 and it's quick and painless. > need to clone a disk, and I'm not finding xfsdump in the FC3 distro. > Isn't that a bit odd? No. Red Hat (unfortunately) is rather uninterested in supporting XFS. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs Thu Apr 7 12:55:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Apr 2005 12:55:03 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37Jstnw015776 for ; Thu, 7 Apr 2005 12:54:57 -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 j37LX9r4018529 for ; Thu, 7 Apr 2005 14:33:19 -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 j37JsOR05581136 for ; Thu, 7 Apr 2005 14:54:24 -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 j37JsMaV38015523; Thu, 7 Apr 2005 14:54:22 -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 j37Jqigc000505; Thu, 7 Apr 2005 14:52:44 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j37Jqivj000503; Thu, 7 Apr 2005 14:52:44 -0500 Date: Thu, 7 Apr 2005 14:52:44 -0500 From: Eric Sandeen Message-Id: <200504071952.j37Jqivj000503@penguin.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 933362 - X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5242 X-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: 1289 Lines: 28 Enable XFS_VNODE_TRACE Date: Thu Apr 7 12:53:16 PDT 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: cattelan The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:190725a Makefile-linux-2.6 - 1.196 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.6.diff?r1=text&tr1=1.196&r2=text&tr2=1.195&f=h Makefile-linux-2.4 - 1.209 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.4.diff?r1=text&tr1=1.209&r2=text&tr2=1.208&f=h linux-2.6/xfs_vnode.h - 1.101 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.101&r2=text&tr2=1.100&f=h - Move the v_trace entry above the inode; due to the way we allocate the vnode/inode the inode must be last in the struct linux-2.4/Makefile - 1.205 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/Makefile.diff?r1=text&tr1=1.205&r2=text&tr2=1.204&f=h linux-2.4/xfs_vnode.h - 1.95 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vnode.h.diff?r1=text&tr1=1.95&r2=text&tr2=1.94&f=h - Move the v_trace entry above the inode; due to the way we allocate the vnode/inode the inode must be last in the struct From owner-linux-xfs Thu Apr 7 16:47:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Apr 2005 16:47:20 -0700 (PDT) Received: from mailhub1.arup.com.au (mailhub1.arup.com.au [202.3.74.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j37NlGwF013465 for ; Thu, 7 Apr 2005 16:47:17 -0700 Received: from syduxs03.au.arup.com ([10.32.20.3]) by mailhub1.arup.com.au with InterScan Messaging Security Suite; Fri, 08 Apr 2005 09:46:15 +1000 Received: from sydexc02.global.arup.com (sydexc02.global.arup.com [10.32.11.32]) by syduxs03.au.arup.com (8.12.10/8.12.10) with ESMTP id j37NLMJJ009531; Fri, 8 Apr 2005 09:21:22 +1000 Received: from bneexc01.global.arup.com ([10.33.11.31]) by sydexc02.global.arup.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Apr 2005 09:47:09 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: database filesystem (ab)use [Was: Re: realtime ( was RE:unexpected high fragmentation, any ideas? )] Date: Fri, 8 Apr 2005 09:47:09 +1000 Message-ID: <2B6FD80A38020542803BA5DC9B3C9754224C92@bneexc01.global.arup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: database filesystem (ab)use [Was: Re: realtime ( was RE:unexpected high fragmentation, any ideas? )] thread-index: AcU7aWBdFXss4xZeRwKQahWxU62TXAAYgxIg From: "Scott Fagg" To: "Stewart Smith" , "Steve Lord" Cc: X-OriginalArrivalTime: 07 Apr 2005 23:47:09.0995 (UTC) FILETIME=[1D3ECFB0:01C53BCC] X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j37NlIwF013467 X-archive-position: 5243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com.au Precedence: bulk X-list: linux-xfs Content-Length: 1952 Lines: 51 > -----Original Message----- > From: Stewart Smith [mailto:stewart@mysql.com] > Sent: Thursday, 7 April 2005 9:59 PM > To: Steve Lord > Cc: Scott Fagg; linux-xfs@oss.sgi.com > Subject: database filesystem (ab)use [Was: Re: realtime ( was > RE:unexpected high fragmentation, any ideas? )] > > On Wed, 2005-04-06 at 20:49 -0500, Steve Lord wrote: > > So if you want big fat files which get layed out in one chunk, and > > spindles where no other I/O gets in the way of the data I/O, then > > it can be handy. It does sound like something a database might > > like to use. > > For MySQL, with InnoDB tables (the on-disk ones with transactions etc) > keeps one (or n) big data file(s) that grows dynamically (or you can > statically allocate them in chunks) - typical grow size is 5 or 10MB. It's mysql i'm using, and it was a performance problem on a new server that prompted the question. I'm getting 5 times the throughput on a 4 year old desktop than i am with 1 month old server. Using InnoDB and binary logs gets about 1MB/s throughput on the server, but 5MB/s on the desktop. I was wondering if a change of filesystem would help, but it sounds as though it would not. Using MyISAM and turning off binary logs, gets me reasonable performance , so perhaps i have a filesystem problem or a storage array (hardware raid) problem. I've also tried toggling between mysql v3 and v5, the FC3 kernel RPM and a vanilla kernel from kernel.org, but all that has had little impact. Other processes can write to disc at much higher rates than mysql, so perhaps i should take this problem to a different forum .. > > ideally, the ibdata files (and *especially* the ib_logfiles) would be > contiguous on disk (and close to each other on disk). > > fsync performance is much more important for innodb (for transaction > throughput). XFS is slower than ext3 in this regard (from benchmarks > i've run*, data less than physical mem size). regards, From owner-linux-xfs Thu Apr 7 18:35:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Apr 2005 18:35:10 -0700 (PDT) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j381Z7wJ025463 for ; Thu, 7 Apr 2005 18:35:08 -0700 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 j381Yrvi5917715; Fri, 8 Apr 2005 11:34:53 +1000 (EST) Received: (from ianc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j381Ypjx5880029; Fri, 8 Apr 2005 11:34:51 +1000 (EST) Date: Fri, 8 Apr 2005 11:34:51 +1000 (EST) From: Ian Costello Message-Id: <200504080134.j381Ypjx5880029@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.kudzu@engr.sgi.com Subject: TAKE 933458 - X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ianc@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 692 Lines: 19 Date: Thu Apr 7 18:34:38 PDT 2005 Workarea: snort.melbourne.sgi.com:/home/ianc/isms/cxfs3_3 Inspected by: bnaujok lachlan Author: ianc.longdrop.melbourne.sgi.com Merged by: ianc Merged mods: 1.1-melb:cxfs-win:22076a The following file(s) were checked into: bonnie.engr.sgi.com:/proj/cxfs/cxfs3.3/isms Modid: cxfs3.3:cxfs-win:22076a cxfs-win/src/kern/cxfs/driver/vmm.c - 1.84 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cxfs-win/src/kern/cxfs/driver/vmm.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h - Merge of 1.1-melb:cxfs-win:22076a by ianc. This time I explicitly check for the existence of a DataSectionObject prior to calling CcPurgeCacheSection. From owner-linux-xfs Thu Apr 7 18:55:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Apr 2005 18:55:05 -0700 (PDT) Received: from bruce.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j381t3Rb026119 for ; Thu, 7 Apr 2005 18:55:03 -0700 Received: by bruce.melbourne.sgi.com (Postfix, from userid 38403) id 8F0E559A4F; Fri, 8 Apr 2005 11:52:12 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfstests Message-Id: <20050408015212.8F0E559A4F@bruce.melbourne.sgi.com> Date: Fri, 8 Apr 2005 11:52:12 +1000 (EST) From: fsgqa@bruce.melbourne.sgi.com (FSG QA) X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 743 Lines: 18 Abstract out some common quota shell code, add project operation to fsstress. Date: Fri Apr 8 11:53:49 AEST 2005 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22099a xfstests/050 - 1.22 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/050.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h xfstests/common.config - 1.54 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/common.config.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h xfstests/ltp/fsstress.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/ltp/fsstress.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h From owner-linux-xfs Thu Apr 7 19:39:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Apr 2005 19:39:29 -0700 (PDT) Received: from mailgate.mysql.com (mailgate1.mysql.com [213.115.162.47]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j382dQlF028159 for ; Thu, 7 Apr 2005 19:39:27 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate.mysql.com (8.13.2/8.13.1) with ESMTP id j382bcRL014058; Fri, 8 Apr 2005 04:37:38 +0200 Received: from mail.mysql.com ([10.222.1.99]) by localhost (mailgate.mysql.com [10.222.1.98]) (amavisd-new, port 10026) with LMTP id 11675-02; Fri, 8 Apr 2005 04:37:38 +0200 (CEST) Received: from [192.168.1.54] (c211-28-166-127.eburwd2.vic.optusnet.com.au [211.28.166.127]) (authenticated bits=0) by mail.mysql.com (8.12.10/8.12.10) with ESMTP id j382dA4c001430 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 8 Apr 2005 04:39:14 +0200 Subject: RE: database filesystem (ab)use [Was: Re: realtime ( was RE:unexpected high fragmentation, any ideas? )] From: Stewart Smith To: Scott Fagg Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <2B6FD80A38020542803BA5DC9B3C9754224C92@bneexc01.global.arup.com> References: <2B6FD80A38020542803BA5DC9B3C9754224C92@bneexc01.global.arup.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-X6K6oqTpeaGpnYSH3xIV" Organization: MySQL AB Date: Fri, 08 Apr 2005 12:38:54 +1000 Message-Id: <1112927934.23224.53.camel@kennedy> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at mailgate.mysql.com X-Virus-Status: Clean X-archive-position: 5246 X-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@mysql.com Precedence: bulk X-list: linux-xfs Content-Length: 2217 Lines: 69 --=-X6K6oqTpeaGpnYSH3xIV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-04-08 at 09:47 +1000, Scott Fagg wrote: > Using InnoDB and binary logs gets about 1MB/s throughput on the server, > but 5MB/s on the desktop. is dma on? right drivers for the server? sounds like a problem along those lines. > I was wondering if a change of filesystem would help, but it sounds as > though it would not. it *some* areas it does... some others, it doesn't. i hope to analyse the results further sometime soon. one thing is for certain, create+drop is MUCH faster on XFS - but that's not your time critical database operation :) (at least 300% faster than ext3). > Using MyISAM and turning off binary logs, gets me reasonable performance > , so perhaps i have a filesystem problem or a storage array (hardware > raid) problem. could be driver issue - you should be getting higher performance than what you are. > I've also tried toggling between mysql v3 and v5, the FC3 kernel RPM and > a vanilla kernel from kernel.org, but all that has had little impact. performance of mysql 3 through 5 should be about the same or better > Other processes can write to disc at much higher rates than mysql, so > perhaps i should take this problem to a different forum ..=20 this is interesting... maybe try a bonnie++ run on the disk. You may also need to tune mysql parameters - check out the manual or the MySQL Administrator GUI tool (which also does some performance monitoring). --=20 Stewart Smith, Software Engineer MySQL AB, www.mysql.com Office: +14082136540 Ext: 6616 VoIP: 6616@sip.us.mysql.com Mobile: +61 4 3 8844 332 Jumpstart your cluster: http://www.mysql.com/consulting/packaged/cluster.html --=-X6K6oqTpeaGpnYSH3xIV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iQCVAwUAQlXuvowDm44RooHBAQJBXgP9GJlDWizy+BD7Et32qJt0QkirRKYLBnvJ q0l4gvNLUZwz2i4w8NsyVrP4iKlgbkoV7aRKpym7jDEk6Jf9ankcj0uI8v/2z9m+ sDC1pRFpoUF25b42E0u/E/jRvxE3tI1AqsX2NSX2yUeXWt1+Ba57ehWUZIGpoPt2 3mq/wka6btE= =J9ci -----END PGP SIGNATURE----- --=-X6K6oqTpeaGpnYSH3xIV-- From owner-linux-xfs Thu Apr 7 20:45:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Apr 2005 20:45:07 -0700 (PDT) Received: from mailhub1.arup.com.au (mailhub1.arup.com.au [202.3.74.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j383j4ft001950 for ; Thu, 7 Apr 2005 20:45:04 -0700 Received: from syduxs03.au.arup.com ([10.32.20.3]) by mailhub1.arup.com.au with InterScan Messaging Security Suite; Fri, 08 Apr 2005 13:44:03 +1000 Received: from sydexc02.global.arup.com (sydexc02.global.arup.com [10.32.11.32]) by syduxs03.au.arup.com (8.12.10/8.12.10) with ESMTP id j383J9JL014447; Fri, 8 Apr 2005 13:19:09 +1000 Received: from bneexc01.global.arup.com ([10.33.11.31]) by sydexc02.global.arup.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Apr 2005 13:44:20 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: database filesystem (ab)use [Was: Re: realtime ( wasRE:unexpected high fragmentation, any ideas? )] Date: Fri, 8 Apr 2005 13:44:19 +1000 Message-ID: <2B6FD80A38020542803BA5DC9B3C9754224C99@bneexc01.global.arup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: database filesystem (ab)use [Was: Re: realtime ( wasRE:unexpected high fragmentation, any ideas? )] thread-index: AcU75DuuAT+kcEI9SXelq2jUs4sKUAAACLaA From: "Scott Fagg" To: "Stewart Smith" Cc: "Steve Lord" , X-OriginalArrivalTime: 08 Apr 2005 03:44:20.0650 (UTC) FILETIME=[3F6070A0:01C53BED] X-Virus-Scanned: ClamAV 0.83/813/Thu Apr 7 03:20:51 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j383j5ft001956 X-archive-position: 5247 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com.au Precedence: bulk X-list: linux-xfs Content-Length: 3071 Lines: 102 > -----Original Message----- > From: Stewart Smith [mailto:stewart@mysql.com] > Sent: Friday, 8 April 2005 12:39 PM > To: Scott Fagg > Cc: Steve Lord; linux-xfs@oss.sgi.com > Subject: RE: database filesystem (ab)use [Was: Re: realtime ( > wasRE:unexpected high fragmentation, any ideas? )] > > On Fri, 2005-04-08 at 09:47 +1000, Scott Fagg wrote: > > Using InnoDB and binary logs gets about 1MB/s throughput on > the server, > > but 5MB/s on the desktop. > > is dma on? right drivers for the server? sounds like a problem along > those lines. I'll look into that. > > > I've also tried toggling between mysql v3 and v5, the FC3 > kernel RPM and > > a vanilla kernel from kernel.org, but all that has had > little impact. > > performance of mysql 3 through 5 should be about the same or better That's what i've been seeing on the servers that seem to be behaving. > > > Other processes can write to disc at much higher rates than > mysql, so > > perhaps i should take this problem to a different forum .. > > this is interesting... maybe try a bonnie++ run on the disk. I ran bonnie++ with what seemed like reasonable values and did one run each, toggling the '-b' option to run with and without fsync(); Good server using XFS (older hardware): ./bonnie++ -d /tmp/ -s 2000 -m bneuxs11 -r 1000 -x 1 bneuxs11,2000M,10349,97,23391,16,13092,13,10242,87,43113,27,482.7,2,16,( lots of +'s deleted) ./bonnie++ -d /tmp/ -s 2000 -m bneuxs11 -r 1000 -x 1 -b bneuxs11,2000M,10449,97,20486,14,12483,13,11574,98,43418,27,525.5,3,16,( lots of +'s deleted) Mis-behaving Server using ext3fs (new machine): ./bonnie++ -d /tmp/ -s 4000 -m syduxs08 -r 2000 -x 1 syduxs08,4000M,36927,79,43812,14,22258,5,45767,85,61616,5,372.3,0,16,(lo ts of +'s deleted) ./bonnie++ -d /tmp/ -s 4000 -m syduxs08 -r 2000 -x 1 -b syduxs08,4000M,39005,84,37419,12,23580,5,50082,92,61995,5,263.4,0,16,(lo ts of +'s deleted) I think those results are reasonable, the better machine giving slightly better numbers. My insert script produces results like this : On the good server: - myisam, no bin-log = 61 seconds, kb/s varied a lot - myisam, bin-log = 69 seconds, kb/s varied a lot - innodb, no bin-log = 230 seconds, 3000kb/s - innodb, bin-log = 230 seconds, 3000kb/s On the mis-behaving: - myisam, no bin-log = 24 seconds, 5000kb/s - myisam, bin-log = 24 seconds, 5000kb/s - innodb, no bin-log = 24 minutes, 800kb/s - innodb, bin-log = 24 minutes, 800kb/s Dud innodb file ? > > > You may also need to tune mysql parameters - check out the > manual or the The only tuning i've attempted is to take some hints from the my-huge.cnf sample file, but that had no discernable impact, possibly because i'm not really putting much load on the system. > MySQL Administrator GUI tool (which also does some performance > monitoring). > > -- > Stewart Smith, Software Engineer > MySQL AB, www.mysql.com > Office: +14082136540 Ext: 6616 > VoIP: 6616@sip.us.mysql.com > Mobile: +61 4 3 8844 332 > > Jumpstart your cluster: > http://www.mysql.com/consulting/packaged/cluster.html > From owner-linux-xfs Sat Apr 9 09:53:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Apr 2005 09:53:40 -0700 (PDT) Received: from mailhost.rpsplc.co.uk (mailhost.rpsplc.co.uk [194.203.154.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39GrbCS029632 for ; Sat, 9 Apr 2005 09:53:38 -0700 Received: from mailhost.rpsplc.co.uk ([10.1.0.25]) by mailhost.rpsplc.co.uk with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Apr 2005 17:53:39 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Trouble Patching Date: Sat, 9 Apr 2005 17:53:29 +0100 Message-ID: <88ADEB3C5B6059468695ED6E3E0463AD770FB1@exch02.rpsplc.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trouble Patching thread-index: AcU9JKgJVEzgeVbhQROInLAa8EpUYQ== From: "Simon Hodge" To: X-OriginalArrivalTime: 09 Apr 2005 16:53:39.0572 (UTC) FILETIME=[ADE83340:01C53D24] X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j39GrcCS029634 X-archive-position: 5249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Hodges@rpsgroup.com Precedence: bulk X-list: linux-xfs Content-Length: 2505 Lines: 49 Hi, I wondered if some kind soul could offer me some advice! I have spent a lot of time searching the net for a getting started guide to installing xfs support but haven't had much luck - therefore I may not be doing things the best way. If you can point me in the direction of an idiots guide, that would be great! Anyway, the current problem I have is with applying the patch. I'm running RedHat ES3 with kernel 2.4.21-27.0.2 (on a Dell server). I've got the source for the kernel in /usr/src/linux-2.4 (Actually a sym-link to a directory with the full kernel version as its name). I've downloaded the kernel patch from the SGI site ( linux-xfs-1.3.1.patch). I gunziped the patch and copied to to the linux-2.4 directory. Within that directory I then did: patch -p1 < linux-xfs-1.3.1.patch However, on a number of the files I got the following warning: The next patch would create the file Documentation/filesystems/xfs.txt, which already exists! Assume -R? [n] I tried skipping them and I tried assuming the -R flag which told me: 1 out of 1 hunk FAILED -- saving rejects to file This happened to all the files not in the ./fs/xfs directory, ie, ./Documentation/filesystems/xfs.txt, ./fs/quota.c etc. Despite this, I tried a 'make xconfig' but theres no mention of XFS support in the Filesystems menu. Thanks very much for reading, and if you can help, great! If you need to know anything else, just ask. If I've submitted this question to the wrong place, I appologise. Simon This e-mail message and any attached file is the property of the sender and is sent in confidence to the addressee only. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. If you experience difficulty with opening any attachments to this message, or with sending a reply by email, please telephone on + 44-(0)1235 438151 or fax on + 44-(0)1235 438188. Any advice contained in this e-mail or any accompanying file attached hereto is for information purposes only. RPS do not take any responsibility for differences between the original and the transmission copy or any amendments made thereafter. If the addressee requires RPS to be responsible for the contents of this e-mail, RPS will be pleased to issue a signed hard copy of the document upon request. RPS Group Plc web link: From owner-linux-xfs Sat Apr 9 11:58:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Apr 2005 11:58:46 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39Iwj7J000851 for ; Sat, 9 Apr 2005 11:58:45 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j39IwjGd000850 for linux-xfs@oss.sgi.com; Sat, 9 Apr 2005 11:58:45 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39IwiVf000837 for ; Sat, 9 Apr 2005 11:58:44 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j39HwirI031313; Sat, 9 Apr 2005 10:58:44 -0700 Date: Sat, 9 Apr 2005 10:58:44 -0700 Message-Id: <200504091758.j39HwirI031313@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 406] New: gentoo-ppc64 : XFS dies under load X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 996 Lines: 28 http://oss.sgi.com/bugzilla/show_bug.cgi?id=406 Summary: gentoo-ppc64 : XFS dies under load Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: blocker Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: omkhar@rogers.com I'm assisting with the gentoo-ppc64 (testing on IBM POWER5) port. In testing XFS I've found that XFS dies under moderate load. I noticed a number of I/O errors during an rsync operatation. This prompted me to unmount and run xfs_check which reported a journal needed to be commited. I umounted/remounted and got a kernel panic. Other fs's (ext2/3,reiserfs, jfs) seem to work without issue. I'm a little stumped and would like some advice as to how to continue. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sat Apr 9 12:59:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Apr 2005 12:59:33 -0700 (PDT) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39JxWJC006733 for ; Sat, 9 Apr 2005 12:59:32 -0700 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.11/8.12.11) with ESMTP id j39JxQCC019063; Sat, 9 Apr 2005 15:59:26 -0400 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.11/8.12.11/Submit) with ESMTP id j39JxQbJ019059; Sat, 9 Apr 2005 15:59:26 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Sat, 9 Apr 2005 15:59:26 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Simon Hodge cc: linux-xfs@oss.sgi.com Subject: Re: Trouble Patching In-Reply-To: <88ADEB3C5B6059468695ED6E3E0463AD770FB1@exch02.rpsplc.co.uk> Message-ID: References: <88ADEB3C5B6059468695ED6E3E0463AD770FB1@exch02.rpsplc.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 736 Lines: 20 On Sat, 9 Apr 2005 at 5:53pm, Simon Hodge wrote > Anyway, the current problem I have is with applying the patch. I'm > running RedHat ES3 with kernel 2.4.21-27.0.2 (on a Dell server). I've > got the source for the kernel in /usr/src/linux-2.4 (Actually a sym-link > to a directory with the full kernel version as its name). I've > downloaded the kernel patch from the SGI site ( > linux-xfs-1.3.1.patch). I gunziped the patch and copied to to the > linux-2.4 directory. Within that directory I then did: > > patch -p1 < linux-xfs-1.3.1.patch Look in -- there are pre-patched and compiled kernel RPMs. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs Sat Apr 9 13:58:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Apr 2005 13:58:47 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39Kwjiw008689 for ; Sat, 9 Apr 2005 13:58:45 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j39KwjH5008688 for linux-xfs@oss.sgi.com; Sat, 9 Apr 2005 13:58:45 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j39Kwi3j008673 for ; Sat, 9 Apr 2005 13:58:44 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j39KQAXW008240; Sat, 9 Apr 2005 13:26:10 -0700 Date: Sat, 9 Apr 2005 13:26:10 -0700 Message-Id: <200504092026.j39KQAXW008240@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 407] New: log recovery failure on AMD64 X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3137 Lines: 79 http://oss.sgi.com/bugzilla/show_bug.cgi?id=407 Summary: log recovery failure on AMD64 Product: Linux XFS Version: Current Platform: AMD OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: steffen.list.account@gmail.com I have an AMD64 machine with two Linux kernel architectures installed: i386 and x86_64. After mounting my data partition sda2 with i386, I cannot mount it from the x86_84 system any more. The log says: Apr 9 18:43:01 a kernel: XFS mounting filesystem sda2 Apr 9 18:43:01 a kernel: Starting XFS recovery on filesystem: sda2 (dev:sda2) Apr 9 18:43:01 a kernel: attempt to access beyond end of device Apr 9 18:43:01 a kernel: sda2: rw=0, want=68719477760, limit=281073240 Apr 9 18:43:01 a kernel: attempt to access beyond end of device Apr 9 18:43:01 a kernel: sda2: rw=0, want=68719478784, limit=281073240 Apr 9 18:43:01 a kernel: attempt to access beyond end of device Apr 9 18:43:01 a kernel: sda2: rw=0, want=68719479808, limit=281073240 Apr 9 18:43:01 a kernel: attempt to access beyond end of device Apr 9 18:43:01 a kernel: sda2: rw=0, want=68719480832, limit=281073240 Apr 9 18:43:01 a kernel: attempt to access beyond end of device Apr 9 18:43:01 a kernel: sda2: rw=0, want=68719481856, limit=281073240 Apr 9 18:43:01 a kernel: attempt to access beyond end of device Apr 9 18:43:01 a kernel: sda2: rw=0, want=68719482880, limit=281073240 Apr 9 18:43:01 a kernel: attempt to access beyond end of device Apr 9 18:43:01 a kernel: sda2: rw=0, want=68719483392, limit=281073240 Apr 9 18:43:01 a kernel: XFS: log mount/recovery failed: error 5 Apr 9 18:43:01 a kernel: XFS: log mount failed I have to do xfs_repair -L /dev/sda2, but I am afraid that might lead to data loss (although it has not happened so far). The problem did not occure while I was only running the 64bit kernel, but after running the 32bit kernel it happend every time. And just in case it is useful, here is my system configuration. Hardware: AMD64 Winchester 3000+ 939pin CPU Asrock K8 Combo-Z mainboard 1 GB dual channel RAM 200 GB SATA hard disk on SATA channel 2 ATAPI DVD-writer 32bit system: Debian Sarge/testing (a few weeks old) Kernel 2.6.10, custom compiled for K8 CPU installed on /dev/sda2 64bit system unofficial Debian Sarge/testing pure64 port (also a few weeks old) Kernel 2.6.10, custom compiled for AMD64 installed on /dev/sda1 Partitioning: /dev/sda1 1 3648 29302528+ 83 Linux /dev/sda2 3649 21144 140536620 83 Linux /dev/sda3 * 21145 24791 29294527+ 7 HPFS/NTFS If necessary I can provide more information (such as the complete kernel configuration). I can also do a few tests, but I would like to keep my data on sda2 intakt if possible. I hope you can solve this issue, since I really like XFS. Yours, Thomas ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Apr 10 16:58:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Apr 2005 16:58:49 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ANwmYY021771 for ; Sun, 10 Apr 2005 16:58:48 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3ANwm5D021770 for linux-xfs@oss.sgi.com; Sun, 10 Apr 2005 16:58:48 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ANwkrq021755 for ; Sun, 10 Apr 2005 16:58:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3ANIjCU017418; Sun, 10 Apr 2005 16:18:45 -0700 Date: Sun, 10 Apr 2005 16:18:45 -0700 Message-Id: <200504102318.j3ANIjCU017418@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 406] gentoo-ppc64 : XFS dies under load X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 733 Lines: 26 http://oss.sgi.com/bugzilla/show_bug.cgi?id=406 ------- Additional Comments From nathans@sgi.com 2005-10-04 16:18 PDT ------- Whats your kernel version there? And what does "dies" mean in this context - kernel panic? Or just the I/O errors? Can you give more details of these I/O errors too - are they being reported by the kernel or by rsync? | This prompted me to unmount and run xfs_check which reported a journal | needed to be commited That should never happen after a clean unmount... do you see the same issues with a non-patched kernel.org kernel? You using a non-patched gcc there? thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Apr 11 00:54:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Apr 2005 00:54:37 -0700 (PDT) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3B7sTOZ013264 for ; Mon, 11 Apr 2005 00:54:30 -0700 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id B91A6FB485 for ; Mon, 11 Apr 2005 09:54:28 +0200 (CEST) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 09:54:28 +0200 From: Anders Saaby Organization: Cohaesio A/S To: linux-xfs@oss.sgi.com Subject: 2.6.11.6 XFS-LVM Crashes. Date: Mon, 11 Apr 2005 09:54:33 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504110954.33507.as@cohaesio.com> X-OriginalArrivalTime: 11 Apr 2005 07:54:28.0666 (UTC) FILETIME=[B01731A0:01C53E6B] X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Content-Length: 30432 Lines: 1345 Hi List, I recently moved some of our XFS filesystems to LVM2, which have resulted in various errors from XFS. I don't know if this is a result of some incompatibility between LVM2 and XFS, or if it is because the server running the setup is not equipped with ECC RAM. - But the same hardware has been running stable for several months under the same load and configuration (only diff. is LVM). I have seen ERROR1 4 times in 3 days now, and ERROR2 just once. Is the only sane thing here to switch to an ECC setup? - I have a hard time believing thats whats biting me(?) Any ideas? - Thank you in advance. Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ Specific info: Kernel is from kernel.org and unpatched: root # uname -a Linux mirror1 2.6.11.6 #6 SMP Thu Apr 7 19:37:07 CEST 2005 i686 GNU/Linux xfs_force_shutdown(dm-1,0x8) called from line 1091 of file fs/xfs/xfs_trans.c. Return address = 0xc01ffcd1 Filesystem "dm-1": Corruption of in-memory data detected. Shutting down filesystem: dm-1 Please umount the filesystem, and rectify the problem(s) XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller 0xc01aae8b [] xfs_free_ag_extent+0x42a/0x5ca [] xfs_free_extent+0xba/0xe0 [] xfs_free_extent+0xba/0xe0 [] kmem_zone_zalloc+0x21/0x45 [] xfs_trans_get_efd+0x1f/0x27 [] xfs_bmap_finish+0xe1/0x157 [] xfs_itruncate_finish+0x1f5/0x2de [] xfs_inactive+0x1f7/0x3ef [] d_move+0x125/0x1c2 [] vn_rele+0x4d/0x8d [] linvfs_clear_inode+0x10/0x1d [] clear_inode+0x65/0x93 [] generic_delete_inode+0x84/0xd5 [] iput+0x5d/0x60 [] dput+0x158/0x185 [] sys_rename+0x16b/0x1c6 [] sys_lchown+0x33/0x3e [] tcp_retrans_try_collapse+0xab/0x2a6 [] sys_time+0x10/0x45 [] syscall_call+0x7/0xb xfs_force_shutdown(dm-0,0x8) called from line 4073 of file fs/xfs/xfs_bmap.c. Return address = 0xc01ffcd1 Filesystem "dm-0": Corruption of in-memory data detected. Shutting down filesystem: dm-0 Please umount the filesystem, and rectify the problem(s) All filesystems runs on 3ware 9000 controllers: 0000:00:00.0 Host bridge: Intel Corp. 915G/P/GV Processor to I/O Controller (rev 04) 0000:00:01.0 PCI bridge: Intel Corp. 915G/P/GV PCI Express Root Port (rev 04) 0000:00:02.0 VGA compatible controller: Intel Corp. 82915G Express Chipset Family Graphics Controller (rev 04) 0000:00:1c.0 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 0000:00:1c.1 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) 0000:00:1c.2 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03) 0000:00:1c.3 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 03) 0000:00:1d.0 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 0000:00:1d.1 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 0000:00:1d.2 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 0000:00:1d.3 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 0000:00:1d.7 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev d3) 0000:00:1f.0 ISA bridge: Intel Corp. 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 0000:00:1f.1 IDE interface: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 0000:00:1f.2 IDE interface: Intel Corp. 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03) 0000:00:1f.3 SMBus: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 0000:04:00.0 Ethernet controller: Marvell Technology Group Ltd.: Unknown device 4361 (rev 17) 0000:06:00.0 RAID bus controller: 3ware Inc 3ware ATA-RAID 0000:06:01.0 RAID bus controller: 3ware Inc 3ware ATA-RAID 0000:06:02.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02) <.CONFIG> # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11.6 # Thu Apr 7 15:08:07 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y # CONFIG_KOBJECT_UEVENT is not set # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y # CONFIG_X86_MCE is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # # CONFIG_ACPI is not set CONFIG_ACPI_BOOT=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_PCIEPORTBUS is not set CONFIG_PCI_MSI=y # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PC-card bridges # # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play support # # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_INITRAMFS_SOURCE="" CONFIG_LBD=y # CONFIG_CDROM_PKTCDVD is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_ATA_OVER_ETH is not set # # ATA/ATAPI/MFM/RLL support # # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI=y # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_CONSTANTS is not set CONFIG_SCSI_LOGGING=y # # SCSI Transport Attributes # CONFIG_SCSI_SPI_ATTRS=y # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set CONFIG_SCSI_3W_9XXX=y # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_AHCI is not set # CONFIG_SCSI_SATA_SVW is not set CONFIG_SCSI_ATA_PIIX=y # CONFIG_SCSI_SATA_NV is not set # CONFIG_SCSI_SATA_PROMISE is not set # CONFIG_SCSI_SATA_QSTOR is not set # CONFIG_SCSI_SATA_SX4 is not set # CONFIG_SCSI_SATA_SIL is not set # CONFIG_SCSI_SATA_SIS is not set # CONFIG_SCSI_SATA_ULI is not set # CONFIG_SCSI_SATA_VIA is not set # CONFIG_SCSI_SATA_VITESSE is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y # CONFIG_MD_LINEAR is not set CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y # CONFIG_MD_RAID10 is not set CONFIG_MD_RAID5=y # CONFIG_MD_RAID6 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_MD_FAULTY is not set CONFIG_BLK_DEV_DM=y # CONFIG_DM_CRYPT is not set CONFIG_DM_SNAPSHOT=y CONFIG_DM_MIRROR=y # CONFIG_DM_ZERO is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_TUNNEL is not set CONFIG_IP_TCPDIAG=y # CONFIG_IP_TCPDIAG_IPV6 is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m # CONFIG_IP_NF_CT_ACCT is not set # CONFIG_IP_NF_CONNTRACK_MARK is not set # CONFIG_IP_NF_CT_PROTO_SCTP is not set CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m # CONFIG_IP_NF_MATCH_SCTP is not set # CONFIG_IP_NF_MATCH_COMMENT is not set # CONFIG_IP_NF_MATCH_HASHLIMIT is not set CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_TARGET_NOTRACK=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set CONFIG_VLAN_8021Q=y # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set CONFIG_NET_CLS_ROUTE=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_NETDEVICES=y # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # # CONFIG_NET_ETHERNET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=y # CONFIG_E1000_NAPI is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set CONFIG_SK98LIN=y # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set CONFIG_SERIO_PCIPS2=y CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=y # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_WAFER_WDT is not set # CONFIG_I8XX_TCO is not set # CONFIG_SC1200_WDT is not set # CONFIG_SCx200_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_MACHZ_WDT is not set # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set # CONFIG_HW_RANDOM is not set CONFIG_NVRAM=y CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m # CONFIG_AGP_INTEL_MCH is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set CONFIG_HANGCHECK_TIMER=y # # I2C support # CONFIG_I2C=m # CONFIG_I2C_CHARDEV is not set # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set CONFIG_I2C_ISA=m # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # # Hardware Sensors Chip support # # CONFIG_I2C_SENSOR is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83627HF is not set # # Other I2C Chip support # # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_RTC8564 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # # CONFIG_VIDEO_BT848 is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5246A is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_ZR36120 is not set # CONFIG_VIDEO_SAA7134 is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_CX88 is not set # CONFIG_VIDEO_OVCAMCHIP is not set # # Radio Adapters # # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # # CONFIG_FB is not set CONFIG_VIDEO_SELECT=y # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_BANDWIDTH=y # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_RW_DETECT=y # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_SN9C102 is not set # CONFIG_USB_STV680 is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETKIT is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_TEST is not set # # USB ATM/DSL drivers # # # USB Gadget Support # CONFIG_USB_GADGET=m # CONFIG_USB_GADGET_DEBUG_FILES is not set CONFIG_USB_GADGET_NET2280=y CONFIG_USB_NET2280=m # CONFIG_USB_GADGET_PXA2XX is not set # CONFIG_USB_GADGET_GOKU is not set # CONFIG_USB_GADGET_SA1100 is not set # CONFIG_USB_GADGET_LH7A40X is not set # CONFIG_USB_GADGET_DUMMY_HCD is not set # CONFIG_USB_GADGET_OMAP is not set CONFIG_USB_GADGET_DUALSPEED=y CONFIG_USB_ZERO=m CONFIG_USB_ETH=m CONFIG_USB_ETH_RNDIS=y CONFIG_USB_GADGETFS=m CONFIG_USB_FILE_STORAGE=m # CONFIG_USB_FILE_STORAGE_TEST is not set CONFIG_USB_G_SERIAL=m # # MMC/SD Card support # # CONFIG_MMC is not set # # InfiniBand support # # CONFIG_INFINIBAND is not set # # File systems # CONFIG_EXT2_FS=m # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # # XFS support # CONFIG_XFS_FS=y CONFIG_XFS_EXPORT=y # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_SECURITY is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_MINIX_FS is not set CONFIG_ROMFS_FS=y # CONFIG_QUOTA is not set # CONFIG_DNOTIFY is not set CONFIG_AUTOFS_FS=y CONFIG_AUTOFS4_FS=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # # CONFIG_MSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y # CONFIG_PROC_KCORE is not set CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_TMPFS_XATTR is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set # CONFIG_NFSD_TCP is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_SUNRPC=y # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="cp437" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=y # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_BUGVERBOSE is not set # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_FS is not set # CONFIG_FRAME_POINTER is not set # CONFIG_EARLY_PRINTK is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_KPROBES is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # # CONFIG_CRYPTO is not set # # Hardware crypto devices # # # Library routines # # CONFIG_CRC_CCITT is not set # CONFIG_CRC32 is not set # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y From owner-linux-xfs Mon Apr 11 01:03:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Apr 2005 01:03:59 -0700 (PDT) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3B83rkf014060 for ; Mon, 11 Apr 2005 01:03:53 -0700 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 3F90DFB49F for ; Mon, 11 Apr 2005 10:03:52 +0200 (CEST) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 10:03:52 +0200 From: Anders Saaby Organization: Cohaesio A/S To: linux-xfs@oss.sgi.com Subject: Re: 2.6.11.6 XFS-LVM Crashes. Date: Mon, 11 Apr 2005 10:03:56 +0200 User-Agent: KMail/1.8 References: <200504110954.33507.as@cohaesio.com> In-Reply-To: <200504110954.33507.as@cohaesio.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504111003.57176.as@cohaesio.com> X-OriginalArrivalTime: 11 Apr 2005 08:03:52.0117 (UTC) FILETIME=[FFEEFE50:01C53E6C] X-Virus-Scanned: ClamAV 0.83/816/Fri Apr 8 17:46:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Content-Length: 35476 Lines: 1401 Maybe I forgot a few details: root # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 38G 1,7G 36G 5% / tmpfs 502M 0 502M 0% /dev/shm /dev/sda1 89M 16M 69M 19% /boot /dev/md6 1,1T 356G 762G 32% /mnt/backup none 10M 652K 9,4M 7% /dev /dev/mapper/vg--raid1-rsync--mirror1 639G 572G 67G 90% /mnt/rsync_mirror1 /dev/mapper/vg--raid1-rsync--mirror2 200G 179G 22G 90% /mnt/rsync_mirror2 root # grep -i "xfs_force" /var/log/kern.log Apr 8 00:25:00 localhost kernel: xfs_force_shutdown(md6,0x8) called from line 1091 of file fs/xfs/xfs_trans.c. Return address = 0xc01ffcd1 Apr 8 12:21:58 localhost kernel: xfs_force_shutdown(md6,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc01ffcd1 Apr 8 12:27:17 localhost kernel: xfs_force_shutdown(md6,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc01ffcd1 Apr 9 23:39:39 localhost kernel: xfs_force_shutdown(dm-1,0x8) called from line 1091 of file fs/xfs/xfs_trans.c. Return address = 0xc01ffcd1 Apr 10 23:00:31 localhost kernel: xfs_force_shutdown(dm-1,0x8) called from line 1091 of file fs/xfs/xfs_trans.c. Return address = 0xc01ffcd1 Apr 11 01:11:46 localhost kernel: xfs_force_shutdown(dm-1,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc01ffcd1 Apr 11 01:31:03 localhost kernel: xfs_force_shutdown(dm-1,0x8) called from line 1091 of file fs/xfs/xfs_trans.c. Return address = 0xc01ffcd1 Apr 11 07:29:48 localhost kernel: xfs_force_shutdown(dm-0,0x8) called from line 4073 of file fs/xfs/xfs_bmap.c. Return address = 0xc01ffcd1 Apr 11 11:56:36 localhost kernel: xfs_force_shutdown(dm-0,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc01ffcd1 Apr 11 11:56:38 localhost kernel: xfs_force_shutdown(dm-1,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc01ffcd1 As you see, not only the dm devices fail, but also md6 in one case. //Saaby On Monday 11 April 2005 09:54, Anders Saaby wrote: > Hi List, > > I recently moved some of our XFS filesystems to LVM2, which have resulted > in various errors from XFS. > > I don't know if this is a result of some incompatibility between LVM2 and > XFS, or if it is because the server running the setup is not equipped with > ECC RAM. - But the same hardware has been running stable for several months > under the same load and configuration (only diff. is LVM). > > I have seen ERROR1 4 times in 3 days now, and ERROR2 just once. > > Is the only sane thing here to switch to an ECC setup? - I have a hard time > believing thats whats biting me(?) > > Any ideas? > > - Thank you in advance. > > Med venlig hilsen - Best regards - Meilleures salutations > > Anders Saaby > Systems Engineer > ------------------------------------------------ > Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby > Phone: +45 45 880 888 - Fax: +45 45 880 777 > Mail: as@cohaesio.com - http://www.cohaesio.com > ------------------------------------------------ > > Specific info: > > Kernel is from kernel.org and unpatched: > > root # uname -a > Linux mirror1 2.6.11.6 #6 SMP Thu Apr 7 19:37:07 CEST 2005 i686 GNU/Linux > > > xfs_force_shutdown(dm-1,0x8) called from line 1091 of file > fs/xfs/xfs_trans.c. Return address = 0xc01ffcd1 > Filesystem "dm-1": Corruption of in-memory data detected. Shutting down > filesystem: dm-1 > Please umount the filesystem, and rectify the problem(s) > > > > XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1583 of file > fs/xfs/xfs_alloc.c. Caller 0xc01aae8b > [] xfs_free_ag_extent+0x42a/0x5ca > [] xfs_free_extent+0xba/0xe0 > [] xfs_free_extent+0xba/0xe0 > [] kmem_zone_zalloc+0x21/0x45 > [] xfs_trans_get_efd+0x1f/0x27 > [] xfs_bmap_finish+0xe1/0x157 > [] xfs_itruncate_finish+0x1f5/0x2de > [] xfs_inactive+0x1f7/0x3ef > [] d_move+0x125/0x1c2 > [] vn_rele+0x4d/0x8d > [] linvfs_clear_inode+0x10/0x1d > [] clear_inode+0x65/0x93 > [] generic_delete_inode+0x84/0xd5 > [] iput+0x5d/0x60 > [] dput+0x158/0x185 > [] sys_rename+0x16b/0x1c6 > [] sys_lchown+0x33/0x3e > [] tcp_retrans_try_collapse+0xab/0x2a6 > [] sys_time+0x10/0x45 > [] syscall_call+0x7/0xb > xfs_force_shutdown(dm-0,0x8) called from line 4073 of file > fs/xfs/xfs_bmap.c. Return address = 0xc01ffcd1 > Filesystem "dm-0": Corruption of in-memory data detected. Shutting down > filesystem: dm-0 > Please umount the filesystem, and rectify the problem(s) > > > > All filesystems runs on 3ware 9000 controllers: > > 0000:00:00.0 Host bridge: Intel Corp. 915G/P/GV Processor to I/O Controller > (rev 04) > 0000:00:01.0 PCI bridge: Intel Corp. 915G/P/GV PCI Express Root Port (rev > 04) 0000:00:02.0 VGA compatible controller: Intel Corp. 82915G Express > Chipset Family Graphics Controller (rev 04) > 0000:00:1c.0 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 1 (rev 03) > 0000:00:1c.1 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 2 (rev 03) > 0000:00:1c.2 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 3 (rev 03) > 0000:00:1c.3 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 4 (rev 03) > 0000:00:1d.0 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #1 (rev 03) > 0000:00:1d.1 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #2 (rev 03) > 0000:00:1d.2 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #3 (rev 03) > 0000:00:1d.3 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #4 (rev 03) > 0000:00:1d.7 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB2 EHCI Controller (rev 03) > 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev d3) > 0000:00:1f.0 ISA bridge: Intel Corp. 82801FB/FR (ICH6/ICH6R) LPC Interface > Bridge (rev 03) > 0000:00:1f.1 IDE interface: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) > IDE Controller (rev 03) > 0000:00:1f.2 IDE interface: Intel Corp. 82801FB/FW (ICH6/ICH6W) SATA > Controller (rev 03) > 0000:00:1f.3 SMBus: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus > Controller (rev 03) > 0000:04:00.0 Ethernet controller: Marvell Technology Group Ltd.: Unknown > device 4361 (rev 17) > 0000:06:00.0 RAID bus controller: 3ware Inc 3ware ATA-RAID > 0000:06:01.0 RAID bus controller: 3ware Inc 3ware ATA-RAID > 0000:06:02.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet > Controller (rev 02) > > > <.CONFIG> > # > # Automatically generated make config: don't edit > # Linux kernel version: 2.6.11.6 > # Thu Apr 7 15:08:07 2005 > # > CONFIG_X86=y > CONFIG_MMU=y > CONFIG_UID16=y > CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_IOMAP=y > > # > # Code maturity level options > # > CONFIG_EXPERIMENTAL=y > # CONFIG_CLEAN_COMPILE is not set > CONFIG_BROKEN=y > CONFIG_BROKEN_ON_SMP=y > CONFIG_LOCK_KERNEL=y > > # > # General setup > # > CONFIG_LOCALVERSION="" > CONFIG_SWAP=y > CONFIG_SYSVIPC=y > CONFIG_POSIX_MQUEUE=y > # CONFIG_BSD_PROCESS_ACCT is not set > CONFIG_SYSCTL=y > # CONFIG_AUDIT is not set > CONFIG_LOG_BUF_SHIFT=14 > CONFIG_HOTPLUG=y > # CONFIG_KOBJECT_UEVENT is not set > # CONFIG_IKCONFIG is not set > CONFIG_EMBEDDED=y > CONFIG_KALLSYMS=y > # CONFIG_KALLSYMS_ALL is not set > # CONFIG_KALLSYMS_EXTRA_PASS is not set > CONFIG_FUTEX=y > CONFIG_EPOLL=y > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > CONFIG_SHMEM=y > CONFIG_CC_ALIGN_FUNCTIONS=0 > CONFIG_CC_ALIGN_LABELS=0 > CONFIG_CC_ALIGN_LOOPS=0 > CONFIG_CC_ALIGN_JUMPS=0 > # CONFIG_TINY_SHMEM is not set > > # > # Loadable module support > # > CONFIG_MODULES=y > CONFIG_MODULE_UNLOAD=y > # CONFIG_MODULE_FORCE_UNLOAD is not set > CONFIG_OBSOLETE_MODPARM=y > # CONFIG_MODVERSIONS is not set > # CONFIG_MODULE_SRCVERSION_ALL is not set > CONFIG_KMOD=y > CONFIG_STOP_MACHINE=y > > > # > # Processor type and features > # > CONFIG_X86_PC=y > # CONFIG_X86_ELAN is not set > # CONFIG_X86_VOYAGER is not set > # CONFIG_X86_NUMAQ is not set > # CONFIG_X86_SUMMIT is not set > # CONFIG_X86_BIGSMP is not set > # CONFIG_X86_VISWS is not set > # CONFIG_X86_GENERICARCH is not set > # CONFIG_X86_ES7000 is not set > # CONFIG_M386 is not set > # CONFIG_M486 is not set > # CONFIG_M586 is not set > # CONFIG_M586TSC is not set > # CONFIG_M586MMX is not set > # CONFIG_M686 is not set > # CONFIG_MPENTIUMII is not set > # CONFIG_MPENTIUMIII is not set > # CONFIG_MPENTIUMM is not set > CONFIG_MPENTIUM4=y > # CONFIG_MK6 is not set > # CONFIG_MK7 is not set > # CONFIG_MK8 is not set > # CONFIG_MCRUSOE is not set > # CONFIG_MEFFICEON is not set > # CONFIG_MWINCHIPC6 is not set > # CONFIG_MWINCHIP2 is not set > # CONFIG_MWINCHIP3D is not set > # CONFIG_MCYRIXIII is not set > # CONFIG_MVIAC3_2 is not set > # CONFIG_X86_GENERIC is not set > CONFIG_X86_CMPXCHG=y > CONFIG_X86_XADD=y > CONFIG_X86_L1_CACHE_SHIFT=7 > CONFIG_RWSEM_XCHGADD_ALGORITHM=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > CONFIG_X86_WP_WORKS_OK=y > CONFIG_X86_INVLPG=y > CONFIG_X86_BSWAP=y > CONFIG_X86_POPAD_OK=y > CONFIG_X86_GOOD_APIC=y > CONFIG_X86_INTEL_USERCOPY=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_HPET_TIMER=y > # CONFIG_HPET_EMULATE_RTC is not set > CONFIG_SMP=y > CONFIG_NR_CPUS=2 > CONFIG_SCHED_SMT=y > # CONFIG_PREEMPT is not set > CONFIG_X86_LOCAL_APIC=y > CONFIG_X86_IO_APIC=y > CONFIG_X86_TSC=y > # CONFIG_X86_MCE is not set > # CONFIG_TOSHIBA is not set > # CONFIG_I8K is not set > CONFIG_MICROCODE=y > CONFIG_X86_MSR=y > CONFIG_X86_CPUID=y > > # > # Firmware Drivers > # > # CONFIG_EDD is not set > # CONFIG_NOHIGHMEM is not set > CONFIG_HIGHMEM4G=y > # CONFIG_HIGHMEM64G is not set > CONFIG_HIGHMEM=y > # CONFIG_HIGHPTE is not set > # CONFIG_MATH_EMULATION is not set > CONFIG_MTRR=y > CONFIG_IRQBALANCE=y > CONFIG_HAVE_DEC_LOCK=y > # CONFIG_REGPARM is not set > > # > # Power management options (ACPI, APM) > # > CONFIG_PM=y > # CONFIG_PM_DEBUG is not set > # CONFIG_SOFTWARE_SUSPEND is not set > > # > # ACPI (Advanced Configuration and Power Interface) Support > # > # CONFIG_ACPI is not set > CONFIG_ACPI_BOOT=y > > # > # APM (Advanced Power Management) BIOS Support > # > # CONFIG_APM is not set > > # > # CPU Frequency scaling > # > # CONFIG_CPU_FREQ is not set > > # > # Bus options (PCI, PCMCIA, EISA, MCA, ISA) > # > CONFIG_PCI=y > # CONFIG_PCI_GOBIOS is not set > # CONFIG_PCI_GOMMCONFIG is not set > # CONFIG_PCI_GODIRECT is not set > CONFIG_PCI_GOANY=y > CONFIG_PCI_BIOS=y > CONFIG_PCI_DIRECT=y > # CONFIG_PCIEPORTBUS is not set > CONFIG_PCI_MSI=y > # CONFIG_PCI_LEGACY_PROC is not set > CONFIG_PCI_NAMES=y > # CONFIG_ISA is not set > # CONFIG_MCA is not set > # CONFIG_SCx200 is not set > > # > # PCCARD (PCMCIA/CardBus) support > # > # CONFIG_PCCARD is not set > > # > # PC-card bridges > # > > # > # PCI Hotplug Support > # > # CONFIG_HOTPLUG_PCI is not set > > # > # Executable file formats > # > CONFIG_BINFMT_ELF=y > # CONFIG_BINFMT_AOUT is not set > # CONFIG_BINFMT_MISC is not set > > # > # Device Drivers > # > > # > # Generic Driver Options > # > CONFIG_STANDALONE=y > CONFIG_PREVENT_FIRMWARE_BUILD=y > CONFIG_FW_LOADER=m > # CONFIG_DEBUG_DRIVER is not set > > # > # Memory Technology Devices (MTD) > # > # CONFIG_MTD is not set > > # > # Parallel port support > # > # CONFIG_PARPORT is not set > > # > # Plug and Play support > # > > # > # Block devices > # > # CONFIG_BLK_DEV_FD is not set > # CONFIG_BLK_CPQ_DA is not set > # CONFIG_BLK_CPQ_CISS_DA is not set > # CONFIG_BLK_DEV_DAC960 is not set > # CONFIG_BLK_DEV_UMEM is not set > # CONFIG_BLK_DEV_COW_COMMON is not set > CONFIG_BLK_DEV_LOOP=m > # CONFIG_BLK_DEV_CRYPTOLOOP is not set > # CONFIG_BLK_DEV_NBD is not set > # CONFIG_BLK_DEV_SX8 is not set > # CONFIG_BLK_DEV_UB is not set > # CONFIG_BLK_DEV_RAM is not set > CONFIG_BLK_DEV_RAM_COUNT=16 > CONFIG_INITRAMFS_SOURCE="" > CONFIG_LBD=y > # CONFIG_CDROM_PKTCDVD is not set > > # > # IO Schedulers > # > CONFIG_IOSCHED_NOOP=y > CONFIG_IOSCHED_AS=y > CONFIG_IOSCHED_DEADLINE=y > CONFIG_IOSCHED_CFQ=y > # CONFIG_ATA_OVER_ETH is not set > > # > # ATA/ATAPI/MFM/RLL support > # > # CONFIG_IDE is not set > > # > # SCSI device support > # > CONFIG_SCSI=y > # CONFIG_SCSI_PROC_FS is not set > > # > # SCSI support type (disk, tape, CD-ROM) > # > CONFIG_BLK_DEV_SD=y > # CONFIG_CHR_DEV_ST is not set > # CONFIG_CHR_DEV_OSST is not set > # CONFIG_BLK_DEV_SR is not set > CONFIG_CHR_DEV_SG=y > > # > # Some SCSI devices (e.g. CD jukebox) support multiple LUNs > # > CONFIG_SCSI_MULTI_LUN=y > # CONFIG_SCSI_CONSTANTS is not set > CONFIG_SCSI_LOGGING=y > > # > # SCSI Transport Attributes > # > CONFIG_SCSI_SPI_ATTRS=y > # CONFIG_SCSI_FC_ATTRS is not set > # CONFIG_SCSI_ISCSI_ATTRS is not set > > # > # SCSI low-level drivers > # > # CONFIG_BLK_DEV_3W_XXXX_RAID is not set > CONFIG_SCSI_3W_9XXX=y > # CONFIG_SCSI_ACARD is not set > # CONFIG_SCSI_AACRAID is not set > # CONFIG_SCSI_AIC7XXX is not set > # CONFIG_SCSI_AIC7XXX_OLD is not set > # CONFIG_SCSI_AIC79XX is not set > # CONFIG_SCSI_DPT_I2O is not set > # CONFIG_SCSI_ADVANSYS is not set > # CONFIG_MEGARAID_NEWGEN is not set > # CONFIG_MEGARAID_LEGACY is not set > CONFIG_SCSI_SATA=y > # CONFIG_SCSI_SATA_AHCI is not set > # CONFIG_SCSI_SATA_SVW is not set > CONFIG_SCSI_ATA_PIIX=y > # CONFIG_SCSI_SATA_NV is not set > # CONFIG_SCSI_SATA_PROMISE is not set > # CONFIG_SCSI_SATA_QSTOR is not set > # CONFIG_SCSI_SATA_SX4 is not set > # CONFIG_SCSI_SATA_SIL is not set > # CONFIG_SCSI_SATA_SIS is not set > # CONFIG_SCSI_SATA_ULI is not set > # CONFIG_SCSI_SATA_VIA is not set > # CONFIG_SCSI_SATA_VITESSE is not set > # CONFIG_SCSI_BUSLOGIC is not set > # CONFIG_SCSI_CPQFCTS is not set > # CONFIG_SCSI_DMX3191D is not set > # CONFIG_SCSI_EATA is not set > # CONFIG_SCSI_EATA_PIO is not set > # CONFIG_SCSI_FUTURE_DOMAIN is not set > # CONFIG_SCSI_GDTH is not set > # CONFIG_SCSI_IPS is not set > # CONFIG_SCSI_INITIO is not set > # CONFIG_SCSI_INIA100 is not set > # CONFIG_SCSI_SYM53C8XX_2 is not set > # CONFIG_SCSI_IPR is not set > # CONFIG_SCSI_PCI2000 is not set > # CONFIG_SCSI_PCI2220I is not set > # CONFIG_SCSI_QLOGIC_ISP is not set > # CONFIG_SCSI_QLOGIC_FC is not set > # CONFIG_SCSI_QLOGIC_1280 is not set > CONFIG_SCSI_QLA2XXX=y > # CONFIG_SCSI_QLA21XX is not set > # CONFIG_SCSI_QLA22XX is not set > # CONFIG_SCSI_QLA2300 is not set > # CONFIG_SCSI_QLA2322 is not set > # CONFIG_SCSI_QLA6312 is not set > # CONFIG_SCSI_DC395x is not set > # CONFIG_SCSI_DC390T is not set > # CONFIG_SCSI_NSP32 is not set > # CONFIG_SCSI_DEBUG is not set > > # > # Multi-device support (RAID and LVM) > # > CONFIG_MD=y > CONFIG_BLK_DEV_MD=y > # CONFIG_MD_LINEAR is not set > CONFIG_MD_RAID0=y > CONFIG_MD_RAID1=y > # CONFIG_MD_RAID10 is not set > CONFIG_MD_RAID5=y > # CONFIG_MD_RAID6 is not set > # CONFIG_MD_MULTIPATH is not set > # CONFIG_MD_FAULTY is not set > CONFIG_BLK_DEV_DM=y > # CONFIG_DM_CRYPT is not set > CONFIG_DM_SNAPSHOT=y > CONFIG_DM_MIRROR=y > # CONFIG_DM_ZERO is not set > > # > # Fusion MPT device support > # > # CONFIG_FUSION is not set > > # > # IEEE 1394 (FireWire) support > # > # CONFIG_IEEE1394 is not set > > # > # I2O device support > # > # CONFIG_I2O is not set > > # > # Networking support > # > CONFIG_NET=y > > # > # Networking options > # > CONFIG_PACKET=y > CONFIG_PACKET_MMAP=y > CONFIG_NETLINK_DEV=y > CONFIG_UNIX=y > CONFIG_NET_KEY=y > CONFIG_INET=y > # CONFIG_IP_MULTICAST is not set > # CONFIG_IP_ADVANCED_ROUTER is not set > # CONFIG_IP_PNP is not set > # CONFIG_NET_IPIP is not set > # CONFIG_NET_IPGRE is not set > # CONFIG_ARPD is not set > CONFIG_SYN_COOKIES=y > # CONFIG_INET_AH is not set > # CONFIG_INET_ESP is not set > # CONFIG_INET_IPCOMP is not set > # CONFIG_INET_TUNNEL is not set > CONFIG_IP_TCPDIAG=y > # CONFIG_IP_TCPDIAG_IPV6 is not set > > # > # IP: Virtual Server Configuration > # > # CONFIG_IP_VS is not set > # CONFIG_IPV6 is not set > CONFIG_NETFILTER=y > # CONFIG_NETFILTER_DEBUG is not set > > # > # IP: Netfilter Configuration > # > CONFIG_IP_NF_CONNTRACK=m > # CONFIG_IP_NF_CT_ACCT is not set > # CONFIG_IP_NF_CONNTRACK_MARK is not set > # CONFIG_IP_NF_CT_PROTO_SCTP is not set > CONFIG_IP_NF_FTP=m > CONFIG_IP_NF_IRC=m > CONFIG_IP_NF_TFTP=m > CONFIG_IP_NF_AMANDA=m > CONFIG_IP_NF_QUEUE=m > CONFIG_IP_NF_IPTABLES=m > CONFIG_IP_NF_MATCH_LIMIT=m > CONFIG_IP_NF_MATCH_IPRANGE=m > CONFIG_IP_NF_MATCH_MAC=m > CONFIG_IP_NF_MATCH_PKTTYPE=m > CONFIG_IP_NF_MATCH_MARK=m > CONFIG_IP_NF_MATCH_MULTIPORT=m > CONFIG_IP_NF_MATCH_TOS=m > CONFIG_IP_NF_MATCH_RECENT=m > CONFIG_IP_NF_MATCH_ECN=m > CONFIG_IP_NF_MATCH_DSCP=m > CONFIG_IP_NF_MATCH_AH_ESP=m > CONFIG_IP_NF_MATCH_LENGTH=m > CONFIG_IP_NF_MATCH_TTL=m > CONFIG_IP_NF_MATCH_TCPMSS=m > CONFIG_IP_NF_MATCH_HELPER=m > CONFIG_IP_NF_MATCH_STATE=m > CONFIG_IP_NF_MATCH_CONNTRACK=m > CONFIG_IP_NF_MATCH_OWNER=m > CONFIG_IP_NF_MATCH_ADDRTYPE=m > CONFIG_IP_NF_MATCH_REALM=m > # CONFIG_IP_NF_MATCH_SCTP is not set > # CONFIG_IP_NF_MATCH_COMMENT is not set > # CONFIG_IP_NF_MATCH_HASHLIMIT is not set > CONFIG_IP_NF_FILTER=m > CONFIG_IP_NF_TARGET_REJECT=m > CONFIG_IP_NF_TARGET_LOG=m > CONFIG_IP_NF_TARGET_ULOG=m > CONFIG_IP_NF_TARGET_TCPMSS=m > CONFIG_IP_NF_NAT=m > CONFIG_IP_NF_NAT_NEEDED=y > CONFIG_IP_NF_TARGET_MASQUERADE=m > CONFIG_IP_NF_TARGET_REDIRECT=m > CONFIG_IP_NF_TARGET_NETMAP=m > CONFIG_IP_NF_TARGET_SAME=m > CONFIG_IP_NF_NAT_SNMP_BASIC=m > CONFIG_IP_NF_NAT_IRC=m > CONFIG_IP_NF_NAT_FTP=m > CONFIG_IP_NF_NAT_TFTP=m > CONFIG_IP_NF_NAT_AMANDA=m > CONFIG_IP_NF_MANGLE=m > CONFIG_IP_NF_TARGET_TOS=m > CONFIG_IP_NF_TARGET_ECN=m > CONFIG_IP_NF_TARGET_DSCP=m > CONFIG_IP_NF_TARGET_MARK=m > CONFIG_IP_NF_TARGET_CLASSIFY=m > CONFIG_IP_NF_RAW=m > CONFIG_IP_NF_TARGET_NOTRACK=m > CONFIG_IP_NF_ARPTABLES=m > CONFIG_IP_NF_ARPFILTER=m > CONFIG_IP_NF_ARP_MANGLE=m > CONFIG_XFRM=y > # CONFIG_XFRM_USER is not set > > # > # SCTP Configuration (EXPERIMENTAL) > # > # CONFIG_IP_SCTP is not set > # CONFIG_ATM is not set > # CONFIG_BRIDGE is not set > CONFIG_VLAN_8021Q=y > # CONFIG_DECNET is not set > # CONFIG_LLC2 is not set > # CONFIG_IPX is not set > # CONFIG_ATALK is not set > # CONFIG_X25 is not set > # CONFIG_LAPB is not set > # CONFIG_NET_DIVERT is not set > # CONFIG_ECONET is not set > # CONFIG_WAN_ROUTER is not set > > # > # QoS and/or fair queueing > # > # CONFIG_NET_SCHED is not set > CONFIG_NET_CLS_ROUTE=y > > # > # Network testing > # > # CONFIG_NET_PKTGEN is not set > # CONFIG_NETPOLL is not set > # CONFIG_NET_POLL_CONTROLLER is not set > # CONFIG_HAMRADIO is not set > # CONFIG_IRDA is not set > # CONFIG_BT is not set > CONFIG_NETDEVICES=y > # CONFIG_DUMMY is not set > # CONFIG_BONDING is not set > # CONFIG_EQUALIZER is not set > # CONFIG_TUN is not set > # CONFIG_ETHERTAP is not set > > # > # ARCnet devices > # > # CONFIG_ARCNET is not set > > # > # Ethernet (10 or 100Mbit) > # > # CONFIG_NET_ETHERNET is not set > > # > # Ethernet (1000 Mbit) > # > # CONFIG_ACENIC is not set > # CONFIG_DL2K is not set > CONFIG_E1000=y > # CONFIG_E1000_NAPI is not set > # CONFIG_NS83820 is not set > # CONFIG_HAMACHI is not set > # CONFIG_YELLOWFIN is not set > # CONFIG_R8169 is not set > CONFIG_SK98LIN=y > # CONFIG_TIGON3 is not set > > # > # Ethernet (10000 Mbit) > # > # CONFIG_IXGB is not set > # CONFIG_S2IO is not set > > # > # Token Ring devices > # > # CONFIG_TR is not set > > # > # Wireless LAN (non-hamradio) > # > # CONFIG_NET_RADIO is not set > > # > # Wan interfaces > # > # CONFIG_WAN is not set > # CONFIG_FDDI is not set > # CONFIG_HIPPI is not set > # CONFIG_PPP is not set > # CONFIG_SLIP is not set > # CONFIG_NET_FC is not set > # CONFIG_SHAPER is not set > # CONFIG_NETCONSOLE is not set > > # > # ISDN subsystem > # > # CONFIG_ISDN is not set > > # > # Telephony Support > # > # CONFIG_PHONE is not set > > # > # Input device support > # > CONFIG_INPUT=y > > # > # Userland interfaces > # > # CONFIG_INPUT_MOUSEDEV is not set > # CONFIG_INPUT_JOYDEV is not set > # CONFIG_INPUT_TSDEV is not set > # CONFIG_INPUT_EVDEV is not set > # CONFIG_INPUT_EVBUG is not set > > # > # Input I/O drivers > # > # CONFIG_GAMEPORT is not set > CONFIG_SOUND_GAMEPORT=y > CONFIG_SERIO=y > CONFIG_SERIO_I8042=y > # CONFIG_SERIO_SERPORT is not set > # CONFIG_SERIO_CT82C710 is not set > CONFIG_SERIO_PCIPS2=y > CONFIG_SERIO_LIBPS2=y > # CONFIG_SERIO_RAW is not set > > # > # Input Device Drivers > # > CONFIG_INPUT_KEYBOARD=y > CONFIG_KEYBOARD_ATKBD=y > # CONFIG_KEYBOARD_SUNKBD is not set > # CONFIG_KEYBOARD_LKKBD is not set > # CONFIG_KEYBOARD_XTKBD is not set > # CONFIG_KEYBOARD_NEWTON is not set > # CONFIG_INPUT_MOUSE is not set > # CONFIG_INPUT_JOYSTICK is not set > # CONFIG_INPUT_TOUCHSCREEN is not set > # CONFIG_INPUT_MISC is not set > > # > # Character devices > # > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_HW_CONSOLE=y > # CONFIG_SERIAL_NONSTANDARD is not set > > # > # Serial drivers > # > CONFIG_SERIAL_8250=y > # CONFIG_SERIAL_8250_CONSOLE is not set > CONFIG_SERIAL_8250_NR_UARTS=4 > # CONFIG_SERIAL_8250_EXTENDED is not set > > # > # Non-8250 serial port support > # > CONFIG_SERIAL_CORE=y > CONFIG_UNIX98_PTYS=y > # CONFIG_LEGACY_PTYS is not set > > # > # IPMI > # > # CONFIG_IPMI_HANDLER is not set > > # > # Watchdog Cards > # > CONFIG_WATCHDOG=y > # CONFIG_WATCHDOG_NOWAYOUT is not set > > # > # Watchdog Device Drivers > # > CONFIG_SOFT_WATCHDOG=y > # CONFIG_ACQUIRE_WDT is not set > # CONFIG_ADVANTECH_WDT is not set > # CONFIG_ALIM1535_WDT is not set > # CONFIG_ALIM7101_WDT is not set > # CONFIG_SC520_WDT is not set > # CONFIG_EUROTECH_WDT is not set > # CONFIG_IB700_WDT is not set > # CONFIG_WAFER_WDT is not set > # CONFIG_I8XX_TCO is not set > # CONFIG_SC1200_WDT is not set > # CONFIG_SCx200_WDT is not set > # CONFIG_60XX_WDT is not set > # CONFIG_CPU5_WDT is not set > # CONFIG_W83627HF_WDT is not set > # CONFIG_W83877F_WDT is not set > # CONFIG_MACHZ_WDT is not set > > # > # PCI-based Watchdog Cards > # > # CONFIG_PCIPCWATCHDOG is not set > # CONFIG_WDTPCI is not set > > # > # USB-based Watchdog Cards > # > # CONFIG_USBPCWATCHDOG is not set > # CONFIG_HW_RANDOM is not set > CONFIG_NVRAM=y > CONFIG_RTC=y > # CONFIG_DTLK is not set > # CONFIG_R3964 is not set > # CONFIG_APPLICOM is not set > # CONFIG_SONYPI is not set > > # > # Ftape, the floppy tape device driver > # > # CONFIG_FTAPE is not set > CONFIG_AGP=m > # CONFIG_AGP_ALI is not set > # CONFIG_AGP_ATI is not set > # CONFIG_AGP_AMD is not set > # CONFIG_AGP_AMD64 is not set > CONFIG_AGP_INTEL=m > # CONFIG_AGP_INTEL_MCH is not set > # CONFIG_AGP_NVIDIA is not set > # CONFIG_AGP_SIS is not set > # CONFIG_AGP_SWORKS is not set > # CONFIG_AGP_VIA is not set > # CONFIG_AGP_EFFICEON is not set > # CONFIG_DRM is not set > # CONFIG_MWAVE is not set > # CONFIG_RAW_DRIVER is not set > CONFIG_HANGCHECK_TIMER=y > > # > # I2C support > # > CONFIG_I2C=m > # CONFIG_I2C_CHARDEV is not set > > # > # I2C Algorithms > # > CONFIG_I2C_ALGOBIT=m > # CONFIG_I2C_ALGOPCF is not set > # CONFIG_I2C_ALGOPCA is not set > > # > # I2C Hardware Bus support > # > # CONFIG_I2C_ALI1535 is not set > # CONFIG_I2C_ALI1563 is not set > # CONFIG_I2C_ALI15X3 is not set > # CONFIG_I2C_AMD756 is not set > # CONFIG_I2C_AMD8111 is not set > # CONFIG_I2C_I801 is not set > # CONFIG_I2C_I810 is not set > CONFIG_I2C_ISA=m > # CONFIG_I2C_NFORCE2 is not set > # CONFIG_I2C_PARPORT_LIGHT is not set > # CONFIG_I2C_PIIX4 is not set > # CONFIG_I2C_PROSAVAGE is not set > # CONFIG_I2C_SAVAGE4 is not set > # CONFIG_SCx200_ACB is not set > # CONFIG_I2C_SIS5595 is not set > # CONFIG_I2C_SIS630 is not set > # CONFIG_I2C_SIS96X is not set > # CONFIG_I2C_STUB is not set > # CONFIG_I2C_VIA is not set > # CONFIG_I2C_VIAPRO is not set > # CONFIG_I2C_VOODOO3 is not set > # CONFIG_I2C_PCA_ISA is not set > > # > # Hardware Sensors Chip support > # > # CONFIG_I2C_SENSOR is not set > # CONFIG_SENSORS_ADM1021 is not set > # CONFIG_SENSORS_ADM1025 is not set > # CONFIG_SENSORS_ADM1026 is not set > # CONFIG_SENSORS_ADM1031 is not set > # CONFIG_SENSORS_ASB100 is not set > # CONFIG_SENSORS_DS1621 is not set > # CONFIG_SENSORS_FSCHER is not set > # CONFIG_SENSORS_GL518SM is not set > # CONFIG_SENSORS_IT87 is not set > # CONFIG_SENSORS_LM63 is not set > # CONFIG_SENSORS_LM75 is not set > # CONFIG_SENSORS_LM77 is not set > # CONFIG_SENSORS_LM78 is not set > # CONFIG_SENSORS_LM80 is not set > # CONFIG_SENSORS_LM83 is not set > # CONFIG_SENSORS_LM85 is not set > # CONFIG_SENSORS_LM87 is not set > # CONFIG_SENSORS_LM90 is not set > # CONFIG_SENSORS_MAX1619 is not set > # CONFIG_SENSORS_PC87360 is not set > # CONFIG_SENSORS_SMSC47B397 is not set > # CONFIG_SENSORS_SMSC47M1 is not set > # CONFIG_SENSORS_VIA686A is not set > # CONFIG_SENSORS_W83781D is not set > # CONFIG_SENSORS_W83L785TS is not set > # CONFIG_SENSORS_W83627HF is not set > > # > # Other I2C Chip support > # > # CONFIG_SENSORS_EEPROM is not set > # CONFIG_SENSORS_PCF8574 is not set > # CONFIG_SENSORS_PCF8591 is not set > # CONFIG_SENSORS_RTC8564 is not set > # CONFIG_I2C_DEBUG_CORE is not set > # CONFIG_I2C_DEBUG_ALGO is not set > # CONFIG_I2C_DEBUG_BUS is not set > # CONFIG_I2C_DEBUG_CHIP is not set > > # > # Dallas's 1-wire bus > # > # CONFIG_W1 is not set > > # > # Misc devices > # > # CONFIG_IBM_ASM is not set > > # > # Multimedia devices > # > CONFIG_VIDEO_DEV=m > > # > # Video For Linux > # > > # > # Video Adapters > # > # CONFIG_VIDEO_BT848 is not set > # CONFIG_VIDEO_CPIA is not set > # CONFIG_VIDEO_SAA5246A is not set > # CONFIG_VIDEO_SAA5249 is not set > # CONFIG_TUNER_3036 is not set > # CONFIG_VIDEO_STRADIS is not set > # CONFIG_VIDEO_ZORAN is not set > # CONFIG_VIDEO_ZR36120 is not set > # CONFIG_VIDEO_SAA7134 is not set > # CONFIG_VIDEO_MXB is not set > # CONFIG_VIDEO_DPC is not set > # CONFIG_VIDEO_HEXIUM_ORION is not set > # CONFIG_VIDEO_HEXIUM_GEMINI is not set > # CONFIG_VIDEO_CX88 is not set > # CONFIG_VIDEO_OVCAMCHIP is not set > > # > # Radio Adapters > # > # CONFIG_RADIO_GEMTEK_PCI is not set > # CONFIG_RADIO_MAXIRADIO is not set > # CONFIG_RADIO_MAESTRO is not set > > # > # Digital Video Broadcasting Devices > # > # CONFIG_DVB is not set > > # > # Graphics support > # > # CONFIG_FB is not set > CONFIG_VIDEO_SELECT=y > > # > # Console display driver support > # > CONFIG_VGA_CONSOLE=y > CONFIG_DUMMY_CONSOLE=y > > # > # Sound > # > # CONFIG_SOUND is not set > > # > # USB support > # > CONFIG_USB=y > # CONFIG_USB_DEBUG is not set > > # > # Miscellaneous USB options > # > CONFIG_USB_DEVICEFS=y > CONFIG_USB_BANDWIDTH=y > # CONFIG_USB_DYNAMIC_MINORS is not set > # CONFIG_USB_SUSPEND is not set > # CONFIG_USB_OTG is not set > CONFIG_USB_ARCH_HAS_HCD=y > CONFIG_USB_ARCH_HAS_OHCI=y > > # > # USB Host Controller Drivers > # > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_SPLIT_ISO=y > CONFIG_USB_EHCI_ROOT_HUB_TT=y > # CONFIG_USB_OHCI_HCD is not set > CONFIG_USB_UHCI_HCD=y > # CONFIG_USB_SL811_HCD is not set > > # > # USB Device Class drivers > # > # CONFIG_USB_BLUETOOTH_TTY is not set > # CONFIG_USB_ACM is not set > # CONFIG_USB_PRINTER is not set > > # > # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be > needed; see USB_STORAGE Help for more information > # > CONFIG_USB_STORAGE=m > # CONFIG_USB_STORAGE_DEBUG is not set > CONFIG_USB_STORAGE_RW_DETECT=y > # CONFIG_USB_STORAGE_DATAFAB is not set > # CONFIG_USB_STORAGE_FREECOM is not set > # CONFIG_USB_STORAGE_DPCM is not set > # CONFIG_USB_STORAGE_HP8200e is not set > # CONFIG_USB_STORAGE_SDDR09 is not set > # CONFIG_USB_STORAGE_SDDR55 is not set > # CONFIG_USB_STORAGE_JUMPSHOT is not set > > # > # USB Input Devices > # > CONFIG_USB_HID=y > CONFIG_USB_HIDINPUT=y > # CONFIG_HID_FF is not set > # CONFIG_USB_HIDDEV is not set > # CONFIG_USB_AIPTEK is not set > # CONFIG_USB_WACOM is not set > # CONFIG_USB_KBTAB is not set > # CONFIG_USB_POWERMATE is not set > # CONFIG_USB_MTOUCH is not set > # CONFIG_USB_EGALAX is not set > # CONFIG_USB_XPAD is not set > # CONFIG_USB_ATI_REMOTE is not set > > # > # USB Imaging devices > # > # CONFIG_USB_MDC800 is not set > # CONFIG_USB_MICROTEK is not set > # CONFIG_USB_HPUSBSCSI is not set > > # > # USB Multimedia devices > # > # CONFIG_USB_DABUSB is not set > # CONFIG_USB_VICAM is not set > # CONFIG_USB_DSBR is not set > # CONFIG_USB_IBMCAM is not set > # CONFIG_USB_KONICAWC is not set > # CONFIG_USB_OV511 is not set > # CONFIG_USB_SE401 is not set > # CONFIG_USB_SN9C102 is not set > # CONFIG_USB_STV680 is not set > > # > # USB Network Adapters > # > # CONFIG_USB_CATC is not set > # CONFIG_USB_KAWETH is not set > # CONFIG_USB_PEGASUS is not set > # CONFIG_USB_RTL8150 is not set > # CONFIG_USB_USBNET is not set > > # > # USB port drivers > # > > # > # USB Serial Converter support > # > # CONFIG_USB_SERIAL is not set > > # > # USB Miscellaneous drivers > # > # CONFIG_USB_EMI62 is not set > # CONFIG_USB_EMI26 is not set > # CONFIG_USB_AUERSWALD is not set > # CONFIG_USB_RIO500 is not set > # CONFIG_USB_LEGOTOWER is not set > # CONFIG_USB_LCD is not set > # CONFIG_USB_LED is not set > # CONFIG_USB_CYTHERM is not set > # CONFIG_USB_PHIDGETKIT is not set > # CONFIG_USB_PHIDGETSERVO is not set > # CONFIG_USB_IDMOUSE is not set > # CONFIG_USB_TEST is not set > > # > # USB ATM/DSL drivers > # > > # > # USB Gadget Support > # > CONFIG_USB_GADGET=m > # CONFIG_USB_GADGET_DEBUG_FILES is not set > CONFIG_USB_GADGET_NET2280=y > CONFIG_USB_NET2280=m > # CONFIG_USB_GADGET_PXA2XX is not set > # CONFIG_USB_GADGET_GOKU is not set > # CONFIG_USB_GADGET_SA1100 is not set > # CONFIG_USB_GADGET_LH7A40X is not set > # CONFIG_USB_GADGET_DUMMY_HCD is not set > # CONFIG_USB_GADGET_OMAP is not set > CONFIG_USB_GADGET_DUALSPEED=y > CONFIG_USB_ZERO=m > CONFIG_USB_ETH=m > CONFIG_USB_ETH_RNDIS=y > CONFIG_USB_GADGETFS=m > CONFIG_USB_FILE_STORAGE=m > # CONFIG_USB_FILE_STORAGE_TEST is not set > CONFIG_USB_G_SERIAL=m > > # > # MMC/SD Card support > # > # CONFIG_MMC is not set > > # > # InfiniBand support > # > # CONFIG_INFINIBAND is not set > > # > # File systems > # > CONFIG_EXT2_FS=m > # CONFIG_EXT2_FS_XATTR is not set > CONFIG_EXT3_FS=y > # CONFIG_EXT3_FS_XATTR is not set > CONFIG_JBD=y > # CONFIG_JBD_DEBUG is not set > # CONFIG_REISERFS_FS is not set > # CONFIG_JFS_FS is not set > > # > # XFS support > # > CONFIG_XFS_FS=y > CONFIG_XFS_EXPORT=y > # CONFIG_XFS_RT is not set > # CONFIG_XFS_QUOTA is not set > # CONFIG_XFS_SECURITY is not set > # CONFIG_XFS_POSIX_ACL is not set > # CONFIG_MINIX_FS is not set > CONFIG_ROMFS_FS=y > # CONFIG_QUOTA is not set > # CONFIG_DNOTIFY is not set > CONFIG_AUTOFS_FS=y > CONFIG_AUTOFS4_FS=y > > # > # CD-ROM/DVD Filesystems > # > CONFIG_ISO9660_FS=m > CONFIG_JOLIET=y > CONFIG_ZISOFS=y > CONFIG_ZISOFS_FS=m > CONFIG_UDF_FS=m > CONFIG_UDF_NLS=y > > # > # DOS/FAT/NT Filesystems > # > # CONFIG_MSDOS_FS is not set > # CONFIG_VFAT_FS is not set > # CONFIG_NTFS_FS is not set > > # > # Pseudo filesystems > # > CONFIG_PROC_FS=y > # CONFIG_PROC_KCORE is not set > CONFIG_SYSFS=y > # CONFIG_DEVFS_FS is not set > # CONFIG_DEVPTS_FS_XATTR is not set > CONFIG_TMPFS=y > # CONFIG_TMPFS_XATTR is not set > # CONFIG_HUGETLBFS is not set > # CONFIG_HUGETLB_PAGE is not set > CONFIG_RAMFS=y > > # > # Miscellaneous filesystems > # > # CONFIG_ADFS_FS is not set > # CONFIG_AFFS_FS is not set > # CONFIG_HFS_FS is not set > # CONFIG_HFSPLUS_FS is not set > # CONFIG_BEFS_FS is not set > # CONFIG_BFS_FS is not set > # CONFIG_EFS_FS is not set > # CONFIG_CRAMFS is not set > # CONFIG_VXFS_FS is not set > # CONFIG_HPFS_FS is not set > # CONFIG_QNX4FS_FS is not set > # CONFIG_SYSV_FS is not set > # CONFIG_UFS_FS is not set > > # > # Network File Systems > # > CONFIG_NFS_FS=y > CONFIG_NFS_V3=y > # CONFIG_NFS_V4 is not set > # CONFIG_NFS_DIRECTIO is not set > CONFIG_NFSD=y > CONFIG_NFSD_V3=y > # CONFIG_NFSD_V4 is not set > # CONFIG_NFSD_TCP is not set > CONFIG_LOCKD=y > CONFIG_LOCKD_V4=y > CONFIG_EXPORTFS=y > CONFIG_SUNRPC=y > # CONFIG_RPCSEC_GSS_KRB5 is not set > # CONFIG_RPCSEC_GSS_SPKM3 is not set > # CONFIG_SMB_FS is not set > # CONFIG_CIFS is not set > # CONFIG_NCP_FS is not set > # CONFIG_CODA_FS is not set > # CONFIG_AFS_FS is not set > > # > # Partition Types > # > # CONFIG_PARTITION_ADVANCED is not set > CONFIG_MSDOS_PARTITION=y > > # > # Native Language Support > # > CONFIG_NLS=y > CONFIG_NLS_DEFAULT="cp437" > # CONFIG_NLS_CODEPAGE_437 is not set > # CONFIG_NLS_CODEPAGE_737 is not set > # CONFIG_NLS_CODEPAGE_775 is not set > CONFIG_NLS_CODEPAGE_850=y > # CONFIG_NLS_CODEPAGE_852 is not set > # CONFIG_NLS_CODEPAGE_855 is not set > # CONFIG_NLS_CODEPAGE_857 is not set > # CONFIG_NLS_CODEPAGE_860 is not set > # CONFIG_NLS_CODEPAGE_861 is not set > # CONFIG_NLS_CODEPAGE_862 is not set > # CONFIG_NLS_CODEPAGE_863 is not set > # CONFIG_NLS_CODEPAGE_864 is not set > # CONFIG_NLS_CODEPAGE_865 is not set > # CONFIG_NLS_CODEPAGE_866 is not set > # CONFIG_NLS_CODEPAGE_869 is not set > # CONFIG_NLS_CODEPAGE_936 is not set > # CONFIG_NLS_CODEPAGE_950 is not set > # CONFIG_NLS_CODEPAGE_932 is not set > # CONFIG_NLS_CODEPAGE_949 is not set > # CONFIG_NLS_CODEPAGE_874 is not set > # CONFIG_NLS_ISO8859_8 is not set > # CONFIG_NLS_CODEPAGE_1250 is not set > # CONFIG_NLS_CODEPAGE_1251 is not set > CONFIG_NLS_ASCII=y > # CONFIG_NLS_ISO8859_1 is not set > # CONFIG_NLS_ISO8859_2 is not set > # CONFIG_NLS_ISO8859_3 is not set > # CONFIG_NLS_ISO8859_4 is not set > # CONFIG_NLS_ISO8859_5 is not set > # CONFIG_NLS_ISO8859_6 is not set > # CONFIG_NLS_ISO8859_7 is not set > # CONFIG_NLS_ISO8859_9 is not set > # CONFIG_NLS_ISO8859_13 is not set > # CONFIG_NLS_ISO8859_14 is not set > # CONFIG_NLS_ISO8859_15 is not set > # CONFIG_NLS_KOI8_R is not set > # CONFIG_NLS_KOI8_U is not set > # CONFIG_NLS_UTF8 is not set > > # > # Profiling support > # > # CONFIG_PROFILING is not set > > # > # Kernel hacking > # > CONFIG_DEBUG_KERNEL=y > CONFIG_MAGIC_SYSRQ=y > # CONFIG_SCHEDSTATS is not set > # CONFIG_DEBUG_SLAB is not set > # CONFIG_DEBUG_SPINLOCK is not set > # CONFIG_DEBUG_SPINLOCK_SLEEP is not set > # CONFIG_DEBUG_KOBJECT is not set > # CONFIG_DEBUG_HIGHMEM is not set > # CONFIG_DEBUG_BUGVERBOSE is not set > # CONFIG_DEBUG_INFO is not set > # CONFIG_DEBUG_FS is not set > # CONFIG_FRAME_POINTER is not set > # CONFIG_EARLY_PRINTK is not set > # CONFIG_DEBUG_STACKOVERFLOW is not set > # CONFIG_KPROBES is not set > # CONFIG_DEBUG_STACK_USAGE is not set > # CONFIG_DEBUG_PAGEALLOC is not set > # CONFIG_4KSTACKS is not set > CONFIG_X86_FIND_SMP_CONFIG=y > CONFIG_X86_MPPARSE=y > > # > # Security options > # > # CONFIG_KEYS is not set > # CONFIG_SECURITY is not set > > # > # Cryptographic options > # > # CONFIG_CRYPTO is not set > > # > # Hardware crypto devices > # > > # > # Library routines > # > # CONFIG_CRC_CCITT is not set > # CONFIG_CRC32 is not set > # CONFIG_LIBCRC32C is not set > CONFIG_ZLIB_INFLATE=m > CONFIG_GENERIC_HARDIRQS=y > CONFIG_GENERIC_IRQ_PROBE=y > CONFIG_X86_SMP=y > CONFIG_X86_HT=y > CONFIG_X86_BIOS_REBOOT=y > CONFIG_X86_TRAMPOLINE=y > -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Mon Apr 11 10:11:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Apr 2005 10:11:51 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BHBnxk028597 for ; Mon, 11 Apr 2005 10:11:49 -0700 Received: by rproxy.gmail.com with SMTP id r35so1251090rna for ; Mon, 11 Apr 2005 10:11:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=Yb5iAMHqzrr1se/XBic5vXA4ImlCK+3u0UFHtX0o3qi6QnanExvTK+FJyp0bzaxmU1W/Oa/Orupv1U3Geik37DpyRGJYaC4j/tR5DVgulVxB1O56yOJ3U4XVQyzOyr9QE8cBRk71uY7ua/TaS8qa2UVP6C/yhNxz+UrR6DpLvxw= Received: by 10.38.69.34 with SMTP id r34mr51986rna; Mon, 11 Apr 2005 10:11:43 -0700 (PDT) Received: by 10.38.73.70 with HTTP; Mon, 11 Apr 2005 10:11:43 -0700 (PDT) Message-ID: <2ca133d205041110111e3a43d5@mail.gmail.com> Date: Mon, 11 Apr 2005 12:11:43 -0500 From: KrishnaPradeep Tamma Reply-To: KrishnaPradeep Tamma To: linux-xfs@oss.sgi.com Subject: Unable to match the Magic Number Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krishnapradeep@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 881 Lines: 34 Hi, I am not able to read the super block using the following code. Can some one help in reading the super block. read_block is a routine of a driver and debug is just a print statement. XFS created different allocation groups, and when I try to read the first block of each allocation group the number returned is the same but not equal to Magic Number. if ((data = read_block(XFS_SB_DADDR)) != NULL) { xfs_sb_t *xsb = (xfs_sb_t *)data; if( xsb->magicnum == XFS_SB_MAGIC) { debug(1,"SUCCESS ! Found xfs superblock\n"); } else { debug(1,"FAILED Not Found xfs superblock\n"); } } else { debug(1,"NULL Not Found xfs superblock\n"); } Thanks Pradeep From owner-linux-xfs Mon Apr 11 14:04:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Apr 2005 14:04:03 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BL41jV007409 for ; Mon, 11 Apr 2005 14:04:02 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3BL3t5j078180 for ; Mon, 11 Apr 2005 17:03:55 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3BL3s6O217362 for ; Mon, 11 Apr 2005 15:03:54 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3BL3s9Y013993 for ; Mon, 11 Apr 2005 15:03:54 -0600 Received: from dyn95395150.austin.ibm.com (dyn95395150.austin.ibm.com [9.53.95.150]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3BL3r4A013956; Mon, 11 Apr 2005 15:03:54 -0600 Subject: Re: Unable to match the Magic Number From: Luciano Chavez To: KrishnaPradeep Tamma Cc: linux-xfs@oss.sgi.com In-Reply-To: <2ca133d205041110111e3a43d5@mail.gmail.com> References: <2ca133d205041110111e3a43d5@mail.gmail.com> Content-Type: text/plain Organization: IBM Date: Mon, 11 Apr 2005 16:03:07 -0500 Message-Id: <1113253387.7346.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lnx1138@us.ibm.com Precedence: bulk X-list: linux-xfs Content-Length: 1100 Lines: 43 Endianess problem maybe? What arch? On Mon, 2005-04-11 at 12:11 -0500, KrishnaPradeep Tamma wrote: > Hi, > > > I am not able to read the super block using the following code. Can > some one help in reading the super block. > > read_block is a routine of a driver and debug is just a print statement. > > XFS created different allocation groups, and when I try to read the > first block of each allocation group the number returned is the same > but not equal to Magic Number. > > if ((data = read_block(XFS_SB_DADDR)) != NULL) { > > xfs_sb_t *xsb = (xfs_sb_t *)data; > > if( xsb->magicnum == XFS_SB_MAGIC) > { > debug(1,"SUCCESS ! Found xfs superblock\n"); > } > else > { > debug(1,"FAILED Not Found xfs superblock\n"); > } > } > else > { > debug(1,"NULL Not Found xfs superblock\n"); > } > > > Thanks > Pradeep > > > -- Luciano Chavez IBM From owner-linux-xfs Mon Apr 11 16:18:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Apr 2005 16:18:16 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3BNIC2R015407 for ; Mon, 11 Apr 2005 16:18:13 -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 JAA10028; Tue, 12 Apr 2005 09:17:54 +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 j3BNHbkt262321; Tue, 12 Apr 2005 09:17:42 +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 j3BNCRei001057; Tue, 12 Apr 2005 09:12:27 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j3BNCESG001055; Tue, 12 Apr 2005 09:12:14 +1000 Date: Tue, 12 Apr 2005 09:12:14 +1000 From: Nathan Scott To: Pavel Machek Cc: "Barry K. Nathan" , Andrew Morton , linux-kernel@vger.kernel.org, hare@suse.de, linux-xfs@oss.sgi.com Subject: Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1] Message-ID: <20050411231213.GD702@frodo> References: <20050406125958.GA8150@ip68-4-98-123.oc.oc.cox.net> <20050406142749.6065b836.akpm@osdl.org> <20050407030614.GA7583@ip68-4-98-123.oc.oc.cox.net> <20050408103327.GD1392@elf.ucw.cz> <20050410211808.GA12118@ip68-4-98-123.oc.oc.cox.net> <20050410212747.GB26316@elf.ucw.cz> <20050410225708.GB12118@ip68-4-98-123.oc.oc.cox.net> <20050410230053.GD12794@elf.ucw.cz> <20050411043124.GA24626@ip68-4-98-123.oc.oc.cox.net> <20050411105759.GB1373@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411105759.GB1373@elf.ucw.cz> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5261 X-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: 1836 Lines: 51 On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote: > Hi! > > > > > No, XFS is my root filesystem. :( (Now that I think about it, would > > > > modularizing XFS and using an initrd be OK?) > > > > > > Yes, loading xfs from initrd should help. [At least it did during > > > suse9.3 testing.] > > > > Once I modularized xfs and switched to using an initrd, the problem > > disappeared. > > I reproduced it locally. Problem is that xfsbufd goes refrigerated, > but someone still tries to wake it up *very* often. Probably something > else in xfs needs refrigerating, too, but I'm not a XFS wizard... Thanks Pavel - I've been reading the thread from the other side of the fence, not understanding the swsusp side of things. :) There are two ways the xfsbufd thread will wake up - either by its timer going off (for it to flush delayed write metadata buffers) or by being explicitly woken up when we're low on memory (in which case it also flushes out dirty metadata, such that pages can be cleaned and made available to the system). Since the refrigerator() call is in place in the main xfsbufd loop, I suspect we're hitting that second case here, where a low memory situation is resulting in someone attempting to wakeup xfsbufd -- I'm not sure if this is the right way to check if we're in that state, but does this patch help? (it would certainly prevent the spurious wakeups, but only if the caller has PF_FREEZE set - will that be the case here?) cheers. -- Nathan --- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000 +++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 08:59:38.973557728 +1000 @@ -1753,6 +1753,8 @@ pagebuf_daemon_wakeup( int priority, unsigned int mask) { + if (current->flags & PF_FREEZE) + return 0; force_flush = 1; barrier(); wake_up_process(pagebuf_daemon_task); From owner-linux-xfs Mon Apr 11 16:51:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Apr 2005 16:51:26 -0700 (PDT) Received: from amd.ucw.cz (postfix@gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3BNpJc6020470 for ; Mon, 11 Apr 2005 16:51:22 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id 6792C2C137; Tue, 12 Apr 2005 01:51:10 +0200 (CEST) Date: Tue, 12 Apr 2005 01:51:10 +0200 From: Pavel Machek To: Nathan Scott Cc: "Barry K. Nathan" , Andrew Morton , linux-kernel@vger.kernel.org, hare@suse.de, linux-xfs@oss.sgi.com Subject: Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1] Message-ID: <20050411235110.GA2472@elf.ucw.cz> References: <20050406142749.6065b836.akpm@osdl.org> <20050407030614.GA7583@ip68-4-98-123.oc.oc.cox.net> <20050408103327.GD1392@elf.ucw.cz> <20050410211808.GA12118@ip68-4-98-123.oc.oc.cox.net> <20050410212747.GB26316@elf.ucw.cz> <20050410225708.GB12118@ip68-4-98-123.oc.oc.cox.net> <20050410230053.GD12794@elf.ucw.cz> <20050411043124.GA24626@ip68-4-98-123.oc.oc.cox.net> <20050411105759.GB1373@elf.ucw.cz> <20050411231213.GD702@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411231213.GD702@frodo> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: linux-xfs Content-Length: 1682 Lines: 40 Hi! > > > > > No, XFS is my root filesystem. :( (Now that I think about it, would > > > > > modularizing XFS and using an initrd be OK?) > > > > > > > > Yes, loading xfs from initrd should help. [At least it did during > > > > suse9.3 testing.] > > > > > > Once I modularized xfs and switched to using an initrd, the problem > > > disappeared. > > > > I reproduced it locally. Problem is that xfsbufd goes refrigerated, > > but someone still tries to wake it up *very* often. Probably something > > else in xfs needs refrigerating, too, but I'm not a XFS wizard... > > Thanks Pavel - I've been reading the thread from the other side > of the fence, not understanding the swsusp side of things. :) > > There are two ways the xfsbufd thread will wake up - either by its > timer going off (for it to flush delayed write metadata buffers) > or by being explicitly woken up when we're low on memory (in which > case it also flushes out dirty metadata, such that pages can be > cleaned and made available to the system). > > Since the refrigerator() call is in place in the main xfsbufd loop, > I suspect we're hitting that second case here, where a low memory > situation is resulting in someone attempting to wakeup xfsbufd -- > I'm not sure if this is the right way to check if we're in that > state, but does this patch help? (it would certainly prevent the > spurious wakeups, but only if the caller has PF_FREEZE set - will > that be the case here?) I should take some sleep now, so I can't test the patch, but I don't think it will help. If someone has PF_FREEZE set, he should be in refrigerator. Pavel -- Boycott Kodak -- for their patent abuse against Java. From owner-linux-xfs Mon Apr 11 17:31:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Apr 2005 17:31:53 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3C0Vn0A022464 for ; Mon, 11 Apr 2005 17:31:50 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA11144; Tue, 12 Apr 2005 10:31:36 +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 j3C0VSkt264824; Tue, 12 Apr 2005 10:31:32 +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 j3C0QGei001329; Tue, 12 Apr 2005 10:26:16 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j3C0Q33W001327; Tue, 12 Apr 2005 10:26:03 +1000 Date: Tue, 12 Apr 2005 10:26:03 +1000 From: Nathan Scott To: Pavel Machek Cc: "Barry K. Nathan" , Andrew Morton , linux-kernel@vger.kernel.org, hare@suse.de, linux-xfs@oss.sgi.com Subject: Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1] Message-ID: <20050412002603.GA1178@frodo> References: <20050407030614.GA7583@ip68-4-98-123.oc.oc.cox.net> <20050408103327.GD1392@elf.ucw.cz> <20050410211808.GA12118@ip68-4-98-123.oc.oc.cox.net> <20050410212747.GB26316@elf.ucw.cz> <20050410225708.GB12118@ip68-4-98-123.oc.oc.cox.net> <20050410230053.GD12794@elf.ucw.cz> <20050411043124.GA24626@ip68-4-98-123.oc.oc.cox.net> <20050411105759.GB1373@elf.ucw.cz> <20050411231213.GD702@frodo> <20050411235110.GA2472@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050411235110.GA2472@elf.ucw.cz> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5263 X-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: 1292 Lines: 49 On Tue, Apr 12, 2005 at 01:51:10AM +0200, Pavel Machek wrote: > I should take some sleep now, so I can't test the patch, but I don't > think it will help. If someone has PF_FREEZE set, he should be in > refrigerator. OK, so if that doesn't help, here's an alternate approach - this lets xfsbufd track when its entering the refrigerator(), so that other callers know that attempts to wake it are futile. cheers. -- Nathan --- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000 +++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 10:14:27.468202824 +1000 @@ -1746,13 +1746,15 @@ STATIC DECLARE_COMPLETION(pagebuf_daemon STATIC struct task_struct *pagebuf_daemon_task; STATIC int pagebuf_daemon_active; STATIC int force_flush; - +STATIC int force_sleep; STATIC int pagebuf_daemon_wakeup( int priority, unsigned int mask) { + if (force_sleep) + return 0; force_flush = 1; barrier(); wake_up_process(pagebuf_daemon_task); @@ -1778,7 +1780,12 @@ pagebuf_daemon( INIT_LIST_HEAD(&tmp); do { - try_to_freeze(PF_FREEZE); + if (unlikely(current->flags & PF_FREEZE)) { + force_sleep = 1; + refrigerator(PF_FREEZE); + } else { + force_sleep = 0; + } set_current_state(TASK_INTERRUPTIBLE); schedule_timeout((xfs_buf_timer_centisecs * HZ) / 100); From owner-linux-xfs Mon Apr 11 20:58:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Apr 2005 20:58:52 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3C3wotZ000813 for ; Mon, 11 Apr 2005 20:58:50 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3C3wo6H000812 for linux-xfs@oss.sgi.com; Mon, 11 Apr 2005 20:58:50 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3C3wmu1000799 for ; Mon, 11 Apr 2005 20:58:48 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3C3HUfg028805; Mon, 11 Apr 2005 20:17:30 -0700 Date: Mon, 11 Apr 2005 20:17:30 -0700 Message-Id: <200504120317.j3C3HUfg028805@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 406] gentoo-ppc64 : XFS dies under load X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1448 Lines: 40 http://oss.sgi.com/bugzilla/show_bug.cgi?id=406 ------- Additional Comments From omkhar@rogers.com 2005-11-04 20:17 PDT ------- |Whats your kernel version there? I've tried on 2.6.9+Gentoo patches. I will try 2.6.11.6 in a couple of days (more on this below) |And what does "dies" mean in this context - kernel panic? Or just the I/O |errors? Can you give more details of these I/O errors too - are they being |reported by the kernel or by rsync? both the kernel (dmesg) and rsync (stderr) reported I/O errors. No IMMEDIATE kernel panic, but the kernel did panic after I attempted to remount the fs. Each subsequent time the server would reboot it would hang when attempting to mount the xfs filesystem - but no panic || This prompted me to unmount and run xfs_check which reported a journal || needed to be commited |That should never happen after a clean unmount... do you see the same issues |with a non-patched kernel.org kernel? You using a non-patched gcc there? The gcc is patched (I'm not sure that I know of any distro that used vanilla gcc... That said here is my idea: I'm in the middle of spinning up a couple of release discs over the next couple of days - once this is complete I will try reverting the filespace to the xfs system. Are there any special flags I should use with mkfs.xfs ? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Apr 11 21:58:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Apr 2005 21:58:51 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3C4woZU003194 for ; Mon, 11 Apr 2005 21:58:50 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3C4woMq003193 for linux-xfs@oss.sgi.com; Mon, 11 Apr 2005 21:58:50 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3C4wmL7003177 for ; Mon, 11 Apr 2005 21:58:49 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3C48u8D001530; Mon, 11 Apr 2005 21:08:56 -0700 Date: Mon, 11 Apr 2005 21:08:56 -0700 Message-Id: <200504120408.j3C48u8D001530@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 406] gentoo-ppc64 : XFS dies under load X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 431 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=406 ------- Additional Comments From sandeen@sgi.com 2005-11-04 21:08 PDT ------- can you paste in the "I/O" errors you're seeing? Some actual description of how xfs "died" would be a good place to start. dmesg messages would be most useful. Thanks, -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Apr 12 04:04:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Apr 2005 04:04:48 -0700 (PDT) Received: from amd.ucw.cz (postfix@gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CB4fdJ031930 for ; Tue, 12 Apr 2005 04:04:44 -0700 Received: by amd.ucw.cz (Postfix, from userid 8) id 8CB9A2C0F5; Tue, 12 Apr 2005 13:04:25 +0200 (CEST) Date: Tue, 12 Apr 2005 13:04:25 +0200 From: Pavel Machek To: Nathan Scott Cc: "Barry K. Nathan" , Andrew Morton , linux-kernel@vger.kernel.org, hare@suse.de, linux-xfs@oss.sgi.com Subject: Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1] Message-ID: <20050412110425.GA3063@elf.ucw.cz> References: <20050408103327.GD1392@elf.ucw.cz> <20050410211808.GA12118@ip68-4-98-123.oc.oc.cox.net> <20050410212747.GB26316@elf.ucw.cz> <20050410225708.GB12118@ip68-4-98-123.oc.oc.cox.net> <20050410230053.GD12794@elf.ucw.cz> <20050411043124.GA24626@ip68-4-98-123.oc.oc.cox.net> <20050411105759.GB1373@elf.ucw.cz> <20050411231213.GD702@frodo> <20050411235110.GA2472@elf.ucw.cz> <20050412002603.GA1178@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050412002603.GA1178@frodo> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/819/Sun Apr 10 17:01:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: linux-xfs Content-Length: 463 Lines: 16 Hi! > > I should take some sleep now, so I can't test the patch, but I don't > > think it will help. If someone has PF_FREEZE set, he should be in > > refrigerator. > > OK, so if that doesn't help, here's an alternate approach - this > lets xfsbufd track when its entering the refrigerator(), so that > other callers know that attempts to wake it are futile. Thanks, this patch helped. Pavel -- Boycott Kodak -- for their patent abuse against Java. From owner-linux-xfs Tue Apr 12 04:50:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Apr 2005 04:50:52 -0700 (PDT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CBooxR006091 for ; Tue, 12 Apr 2005 04:50:50 -0700 Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 8510F890; Tue, 12 Apr 2005 07:50:47 -0400 (EDT) Received: from ip68-4-98-123.oc.oc.cox.net (ip68-4-98-123.oc.oc.cox.net [68.4.98.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id F3C888B; Tue, 12 Apr 2005 07:50:40 -0400 (EDT) Received: by ip68-4-98-123.oc.oc.cox.net (Postfix, from userid 500) id 3B5AE58DA9AA; Tue, 12 Apr 2005 04:50:41 -0700 (PDT) Date: Tue, 12 Apr 2005 04:50:41 -0700 From: "Barry K. Nathan" To: Pavel Machek Cc: Nathan Scott , "Barry K. Nathan" , Andrew Morton , linux-kernel@vger.kernel.org, hare@suse.de, linux-xfs@oss.sgi.com Subject: Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1] Message-ID: <20050412115040.GA14008@ip68-4-98-123.oc.oc.cox.net> References: <20050410211808.GA12118@ip68-4-98-123.oc.oc.cox.net> <20050410212747.GB26316@elf.ucw.cz> <20050410225708.GB12118@ip68-4-98-123.oc.oc.cox.net> <20050410230053.GD12794@elf.ucw.cz> <20050411043124.GA24626@ip68-4-98-123.oc.oc.cox.net> <20050411105759.GB1373@elf.ucw.cz> <20050411231213.GD702@frodo> <20050411235110.GA2472@elf.ucw.cz> <20050412002603.GA1178@frodo> <20050412110425.GA3063@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050412110425.GA3063@elf.ucw.cz> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: barryn@pobox.com Precedence: bulk X-list: linux-xfs Content-Length: 488 Lines: 13 On Tue, Apr 12, 2005 at 01:04:25PM +0200, Pavel Machek wrote: > > OK, so if that doesn't help, here's an alternate approach - this > > lets xfsbufd track when its entering the refrigerator(), so that > > other callers know that attempts to wake it are futile. > > Thanks, this patch helped. I can confirm, the 2nd patch worked and the 1st one didn't. (This is against 2.6.12-rc2-mm1 with sched-x86-patch-name-is-way-too-long.patch backed out. ;) ) -Barry K. Nathan From owner-linux-xfs Tue Apr 12 05:22:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Apr 2005 05:22:54 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CCMpB8008073 for ; Tue, 12 Apr 2005 05:22:51 -0700 Received: by wproxy.gmail.com with SMTP id 68so2923254wra for ; Tue, 12 Apr 2005 05:22:46 -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; b=LEwNCuyWAUbpsF7dqsEVE96dRKl93LYJ16EF9iLVDfJkWNyIjBbE8cnCCRkLutQLxZzz1SFXdpM0MmsSuxPFImWj8gPEAvH9pHEVNyCkDW/t0nHKzXzPd2yaDAOx7tuYu/5Bmrz3Z1ZMm4dg5kChvJ69Mip0/CX/Ekj/g3HnfKE= Received: by 10.54.39.34 with SMTP id m34mr978679wrm; Tue, 12 Apr 2005 05:22:45 -0700 (PDT) Received: by 10.54.53.27 with HTTP; Tue, 12 Apr 2005 05:22:45 -0700 (PDT) Message-ID: <22ebd2af05041205226ab44bd@mail.gmail.com> Date: Tue, 12 Apr 2005 22:22:45 +1000 From: Paul Neilson Reply-To: Paul Neilson To: linux-xfs@oss.sgi.com Subject: Problem running xfs_repair - it crashes. Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: neilson.paul@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 11259 Lines: 304 I am trying to recover from a failed IDE controller. I have installed a new motherboard and all seems to be well except for some residual disc problems. I am running FC3 with xfsprogs-2.6.13-2 from atrpms.net When I run xfs_repair on my lvm logical volume (450GB over 3 discs), I get "xfs_repair: pwrite64 failed: Illegal seek" as follows: [root@moose src]# xfs_repair /dev/VG0/myth Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... block (8,898667) already used, state 2 block (8,898668) already used, state 2 block (8,898669) already used, state 2 block (8,898670) already used, state 2 block (8,898671) already used, state 2 block (8,898672) already used, state 2 block (8,898673) already used, state 2 block (8,898674) already used, state 2 block (8,898675) already used, state 2 block (8,898676) already used, state 2 block (8,898677) already used, state 2 block (8,898678) already used, state 2 block (8,898679) already used, state 2 block (8,898680) already used, state 2 block (8,898681) already used, state 2 block (8,898682) already used, state 2 block (8,898683) already used, state 2 block (8,898684) already used, state 2 block (8,898685) already used, state 2 block (8,898686) already used, state 2 block (8,898687) already used, state 2 block (8,898688) already used, state 2 block (8,898689) already used, state 2 block (8,898690) already used, state 2 block (8,898691) already used, state 2 block (8,898692) already used, state 2 block (8,898693) already used, state 2 block (8,898694) already used, state 2 block (8,898695) already used, state 2 block (8,898696) already used, state 2 - 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 corrupt block 0 in directory inode 544785218 will junk block no . entry for directory 544785218 no .. entry for directory 544785218 - 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 - 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 - deleting existing "lost+found" entry xfs_repair: pwrite64 failed: Illegal seek *** glibc detected *** free(): invalid pointer: 0x08696f70 *** Aborted There are clearly big problems with the disc as can be seen as follows: [root@moose src]# xfs_repair -n /dev/VG0/myth Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... block (8,898667) already used, state 2 block (8,898668) already used, state 2 block (8,898669) already used, state 2 block (8,898670) already used, state 2 block (8,898671) already used, state 2 block (8,898672) already used, state 2 block (8,898673) already used, state 2 block (8,898674) already used, state 2 block (8,898675) already used, state 2 block (8,898676) already used, state 2 block (8,898677) already used, state 2 block (8,898678) already used, state 2 block (8,898679) already used, state 2 block (8,898680) already used, state 2 block (8,898681) already used, state 2 block (8,898682) already used, state 2 block (8,898683) already used, state 2 block (8,898684) already used, state 2 block (8,898685) already used, state 2 block (8,898686) already used, state 2 block (8,898687) already used, state 2 block (8,898688) already used, state 2 block (8,898689) already used, state 2 block (8,898690) already used, state 2 block (8,898691) already used, state 2 block (8,898692) already used, state 2 block (8,898693) already used, state 2 block (8,898694) already used, state 2 block (8,898695) already used, state 2 block (8,898696) 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 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 corrupt block 0 in directory inode 544785218 would junk block no . entry for directory 544785218 no .. entry for directory 544785218 - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 corrupt block 0 in directory inode 544785218 would junk block no . entry for directory 544785218 no .. entry for directory 544785218 - 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 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... entry "video" in directory inode 128 not consistent with .. value (18446744073709551615) in inode 544785218, would junk entry "video" - traversal finished ... - traversing all unattached subtrees ... corrupt block 0 in directory inode 544785218: would junk block bad hash table for directory inode 544785218 (no data entry): would rebuild would create missing "." entry in dir ino 544785218 - traversals finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 544785218, would move to lost+found disconnected inode 544785219, would move to lost+found disconnected inode 544785220, would move to lost+found disconnected inode 544785221, would move to lost+found disconnected inode 544785222, would move to lost+found disconnected inode 544785223, would move to lost+found disconnected inode 544785224, would move to lost+found disconnected inode 544785225, would move to lost+found disconnected inode 544785226, would move to lost+found disconnected inode 544785227, would move to lost+found disconnected inode 544785228, would move to lost+found disconnected inode 544785229, would move to lost+found disconnected inode 544785230, would move to lost+found disconnected inode 544785231, would move to lost+found disconnected inode 544785232, would move to lost+found disconnected inode 544785233, would move to lost+found disconnected inode 544785234, would move to lost+found disconnected inode 544785235, would move to lost+found disconnected inode 544785236, would move to lost+found disconnected inode 544785237, would move to lost+found disconnected inode 544785238, would move to lost+found disconnected inode 544785239, would move to lost+found disconnected inode 544785240, would move to lost+found disconnected inode 544785241, would move to lost+found disconnected inode 544785242, would move to lost+found disconnected inode 544785243, would move to lost+found disconnected inode 544785244, would move to lost+found disconnected inode 544785245, would move to lost+found disconnected inode 544785246, would move to lost+found disconnected inode 544785247, would move to lost+found disconnected inode 545299776, would move to lost+found disconnected inode 545299777, would move to lost+found disconnected inode 545299778, would move to lost+found disconnected inode 545299779, would move to lost+found disconnected inode 545299780, would move to lost+found disconnected inode 545299781, would move to lost+found disconnected inode 545299782, would move to lost+found disconnected inode 545299783, would move to lost+found disconnected inode 545299784, would move to lost+found disconnected inode 545299785, would move to lost+found disconnected inode 545299786, would move to lost+found disconnected inode 545299787, would move to lost+found disconnected inode 545299788, would move to lost+found disconnected inode 545299789, would move to lost+found disconnected inode 545299790, would move to lost+found disconnected inode 545299791, would move to lost+found disconnected inode 545299792, would move to lost+found disconnected inode 545299793, would move to lost+found disconnected inode 545299794, would move to lost+found disconnected inode 545299795, would move to lost+found disconnected inode 545299796, would move to lost+found disconnected inode 545299797, would move to lost+found disconnected inode 545299798, would move to lost+found disconnected inode 545299799, would move to lost+found disconnected inode 545299800, would move to lost+found disconnected inode 545299801, would move to lost+found disconnected inode 545299802, would move to lost+found disconnected inode 545299803, would move to lost+found disconnected inode 545299804, would move to lost+found disconnected inode 545299806, would move to lost+found disconnected inode 545299807, would move to lost+found disconnected inode 545299809, would move to lost+found disconnected inode 545299816, would move to lost+found disconnected inode 545299818, would move to lost+found disconnected inode 545299826, would move to lost+found disconnected inode 545299834, would move to lost+found disconnected inode 545299839, would move to lost+found disconnected inode 585614500, would move to lost+found disconnected inode 585614501, would move to lost+found disconnected inode 585614504, would move to lost+found disconnected inode 585614507, would move to lost+found disconnected inode 585614509, would move to lost+found disconnected inode 585614511, would move to lost+found disconnected inode 585614512, would move to lost+found disconnected inode 585614513, would move to lost+found disconnected inode 585614522, would move to lost+found disconnected inode 585614523, would move to lost+found Phase 7 - verify link counts... would have reset inode 128 nlinks from 9 to 8 No modify flag set, skipping filesystem flush and exiting. Thanks in advance Paul From owner-linux-xfs Tue Apr 12 05:45:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Apr 2005 05:45:37 -0700 (PDT) Received: from oban.houtzager.net (oban.houtzager.net [217.77.130.26]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CCjZ9N009546 for ; Tue, 12 Apr 2005 05:45:35 -0700 Received: from localhost (oban [127.0.0.1]) by oban.houtzager.net (Postfix) with ESMTP id E54E0584BA for ; Tue, 12 Apr 2005 14:45:33 +0200 (CEST) Received: from oban.houtzager.net ([127.0.0.1]) by localhost (oban [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32483-05-2 for ; Tue, 12 Apr 2005 14:45:31 +0200 (CEST) Received: from bowmore.ipv6.houtzager.net (bowmore.ipv6.houtzager.net [IPv6:2001:9c0:2005:2:230:1bff:feac:42d]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by oban.houtzager.net (Postfix) with ESMTP id D6BEC583C2 for ; Tue, 12 Apr 2005 14:45:30 +0200 (CEST) Subject: Corrupt files From: Guus Houtzager To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Tue, 12 Apr 2005 14:45:29 +0200 Message-Id: <1113309929.3468.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at houtzager.net X-Virus-Status: Clean X-archive-position: 5270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: guus@houtzager.net Precedence: bulk X-list: linux-xfs Content-Length: 2035 Lines: 42 Hi, I'm having some trouble with my xfs filesystem. I thought it somewhat similar to the problem James Foris reported last month, but I think it's something different. What happens is, that if several programs are writing data at the same time on the same filesystem, some of the written files, but not all, get corrupted. For example: I'm downloading some files with bittorrent (using the bittornado client) while at the same time downloading some files with lftp from another box. Bittornado says every now and then someting like this: piece 5739 failed hash check, re-downloading it. The files I downloaded at the same time with lftp are rar files. When I try to unrar them, several (last time 3 out of 90) files report: packed data CRC failed in volume . If I redownload those files they are ok. I tried using a different ftp client and scp but that made no difference, some files still get corrupted. Using cmp -b on the corrupt and the correct file show that the files differ in 1 byte. Output from those 3 files: correct1 corrupt1 byte 43330599, line 227755 is 7 ^G 47 ' correct2 corrupt2 byte 21769255, line 113448 is 302 M-B 342 M-b correct3 corrupt3 byte 39713823, line 206079 is 10 ^H 30 ^X No messages in logfiles whatsoever. At the moment I'm running a vanilla 2.6.12-rc2, but I had the same problems running several 2.6.11 flavors. I have only recently started using XFS, so I don't know if the problem exists with older kernels. I'm using LVM2 with 1 logical volume that spans 3 disks. I tried using the noalign mount option as suggested earlier, but that isn't making a difference. The filesystem was created with mkfs.xfs /dev/mapper/storage-new I hope someone can help me debug this. If more information is required, just let me know. TIA! Regards, -- Guus Houtzager Email: guus@houtzager.net PGP fingerprint = 5E E6 96 35 F0 64 34 14 CC 03 2B 36 71 FB 4B 5D Early to rise, early to bed, makes a man healthy, wealthy and dead. --Rincewind, The Light Fantastic From owner-linux-xfs Tue Apr 12 05:47:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Apr 2005 05:47:33 -0700 (PDT) Received: from mail.digitalservice.pl (IDENT:qDoP1FnD6uUoCQN5GpVA8/sV01Ej7PvX@grendel.digitalservice.pl [217.67.200.140]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3CClUtP009995 for ; Tue, 12 Apr 2005 05:47:31 -0700 Received: (qmail 12568 invoked from network); 12 Apr 2005 12:50:52 -0000 Received: from localhost (?DAAka3KRp6J6clQDBsbMEbIhuqlgKj6d?@127.0.0.1) by localhost with SMTP; 12 Apr 2005 12:50:52 -0000 Received: from mail.digitalservice.pl ([127.0.0.1]) by localhost (grendel [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 12358-06 for ; Tue, 12 Apr 2005 14:50:51 +0200 (CEST) Received: (qmail 12516 invoked from network); 12 Apr 2005 12:50:45 -0000 Received: from localhost (HELO albercik.fuw.edu.pl) (?WsUpTERx4dGyL7xUaSIZmTEn1UcPTvZT?@127.0.0.1) by localhost with SMTP; 12 Apr 2005 12:50:45 -0000 From: "Rafael J. Wysocki" To: Pavel Machek Subject: Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1] Date: Tue, 12 Apr 2005 14:47:20 +0200 User-Agent: KMail/1.7.1 Cc: Nathan Scott , "Barry K. Nathan" , Andrew Morton , linux-kernel@vger.kernel.org, hare@suse.de, linux-xfs@oss.sgi.com References: <20050406142749.6065b836.akpm@osdl.org> <20050411231213.GD702@frodo> <20050411235110.GA2472@elf.ucw.cz> In-Reply-To: <20050411235110.GA2472@elf.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504121447.21774.rjw@sisk.pl> X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at grendel.digitalservice.pl using MkS_Vir for Linux (beta) X-Virus-Status: Clean X-archive-position: 5271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rjw@sisk.pl Precedence: bulk X-list: linux-xfs Content-Length: 950 Lines: 27 Hi, On Tuesday, 12 of April 2005 01:51, Pavel Machek wrote: ]--snip--[ > > Since the refrigerator() call is in place in the main xfsbufd loop, > > I suspect we're hitting that second case here, where a low memory > > situation is resulting in someone attempting to wakeup xfsbufd -- > > I'm not sure if this is the right way to check if we're in that > > state, but does this patch help? (it would certainly prevent the > > spurious wakeups, but only if the caller has PF_FREEZE set - will > > that be the case here?) > > I should take some sleep now, so I can't test the patch, but I don't > think it will help. If someone has PF_FREEZE set, he should be in > refrigerator. Or he was in TASK_UNINTERRUPTIBLE while processes were being frozen. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" From owner-linux-xfs Tue Apr 12 07:37:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Apr 2005 07:37:35 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CEbXFr016112 for ; Tue, 12 Apr 2005 07:37:33 -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 j3CEbXxT002064 for ; Tue, 12 Apr 2005 09:37:33 -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 j3CEbWR05894921; Tue, 12 Apr 2005 09:37:32 -0500 (CDT) Message-ID: <425BDD2C.1070800@sgi.com> Date: Tue, 12 Apr 2005 09:37:32 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guus Houtzager CC: linux-xfs@oss.sgi.com Subject: Re: Corrupt files References: <1113309929.3468.23.camel@localhost> In-Reply-To: <1113309929.3468.23.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5272 X-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: 842 Lines: 20 Guus Houtzager wrote: > If I redownload those files they > are ok. I tried using a different ftp client and scp but that made no > difference, some files still get corrupted. Using cmp -b on the corrupt > and the correct file show that the files differ in 1 byte. Output from > those 3 files: > correct1 corrupt1 byte 43330599, line 227755 is 7 ^G 47 ' > correct2 corrupt2 byte 21769255, line 113448 is 302 M-B 342 M-b > correct3 corrupt3 byte 39713823, line 206079 is 10 ^H 30 ^X > No messages in logfiles whatsoever. These are single-bit errors... I think it's unlikely that xfs is at fault. Maybe run some memory checking, or try a different underlying fileystem, volume mgr (or plain partition) or a different download tool? (I guess you've already done that last one) Some other tests might narrow down the problem. -Eric From owner-linux-xfs Tue Apr 12 08:27:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Apr 2005 08:27:23 -0700 (PDT) Received: from mail00hq.adic.com (mail00hq.adic.com [63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CFRLD4028674 for ; Tue, 12 Apr 2005 08:27:22 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Apr 2005 08:27:16 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Apr 2005 08:27:15 -0700 Message-ID: <425BE8D1.2070804@xfs.org> Date: Tue, 12 Apr 2005 10:27:13 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Guus Houtzager , linux-xfs@oss.sgi.com Subject: Re: Corrupt files References: <1113309929.3468.23.camel@localhost> <425BDD2C.1070800@sgi.com> In-Reply-To: <425BDD2C.1070800@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2005 15:27:15.0680 (UTC) FILETIME=[1B4E4E00:01C53F74] X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5273 X-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: 970 Lines: 30 Eric Sandeen wrote: > Guus Houtzager wrote: > >> If I redownload those files they >> are ok. I tried using a different ftp client and scp but that made no >> difference, some files still get corrupted. Using cmp -b on the corrupt >> and the correct file show that the files differ in 1 byte. Output from >> those 3 files: >> correct1 corrupt1 byte 43330599, line 227755 is 7 ^G 47 ' >> correct2 corrupt2 byte 21769255, line 113448 is 302 M-B 342 M-b >> correct3 corrupt3 byte 39713823, line 206079 is 10 ^H 30 ^X >> No messages in logfiles whatsoever. > > > These are single-bit errors... I think it's unlikely that xfs is at > fault. Maybe run some memory checking, or try a different underlying > fileystem, volume mgr (or plain partition) or a different download tool? > (I guess you've already done that last one) > > Some other tests might narrow down the problem. > > -Eric > IDE cable problems? That has been the cause of these before. Steve From owner-linux-xfs Tue Apr 12 12:58:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Apr 2005 12:58:52 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CJwpq4011899 for ; Tue, 12 Apr 2005 12:58:51 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3CJwpaV011898 for linux-xfs@oss.sgi.com; Tue, 12 Apr 2005 12:58:51 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3CJwn7O011885 for ; Tue, 12 Apr 2005 12:58:49 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3CJioDb009179; Tue, 12 Apr 2005 12:44:50 -0700 Date: Tue, 12 Apr 2005 12:44:50 -0700 Message-Id: <200504121944.j3CJioDb009179@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 406] gentoo-ppc64 : XFS dies under load X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 499 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=406 ------- Additional Comments From omkhar@rogers.com 2005-12-04 12:44 PDT ------- I began testing again today, I started by zeroing the partition and using 2.6.11.6 (instead of the 2.6.9-gentoo kernel). Things seem to be working well thus far - will keep the bug open while I test with a couple of more kernels - thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Apr 12 18:31:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Apr 2005 18:31:32 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D1VThT031300 for ; Tue, 12 Apr 2005 18:31:30 -0700 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j3D1VNnA009529 for ; Wed, 13 Apr 2005 11:31:23 +1000 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j3D1VMva009527 for linux-xfs@oss.sgi.com; Wed, 13 Apr 2005 11:31:22 +1000 Date: Wed, 13 Apr 2005 11:31:22 +1000 From: Nathan Scott Message-Id: <200504130131.j3D1VMva009527@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - update 2.4 dmapi-enable kernel patch X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 602 Lines: 16 Update DMAPI split patches for open_exec hook. Date: Wed Apr 13 11:30:46 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.4.x-xfs-melb Modid: 2.4.x-xfs-melb:linux:22155a split-patches/series - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/series.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h split-patches/dmapi-enable - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/dmapi-enable.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h From owner-linux-xfs Tue Apr 12 18:58:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Apr 2005 18:58:53 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D1wq1l032014 for ; Tue, 12 Apr 2005 18:58:52 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3D1wqra032013 for linux-xfs@oss.sgi.com; Tue, 12 Apr 2005 18:58:52 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3D1woaS032000 for ; Tue, 12 Apr 2005 18:58:50 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3D1kEL3031846; Tue, 12 Apr 2005 18:46:14 -0700 Date: Tue, 12 Apr 2005 18:46:14 -0700 Message-Id: <200504130146.j3D1kEL3031846@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 406] gentoo-ppc64 : XFS dies under load X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/822/Mon Apr 11 21:55:55 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 651 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=406 omkhar@rogers.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From omkhar@rogers.com 2005-12-04 18:46 PDT ------- Latest Gentoo versioned kernel works perfectly after some intense testing - closing out (that was an easy one eh ?) ;-) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Apr 13 08:07:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Apr 2005 08:07:07 -0700 (PDT) Received: from mailhost.intellivid.com (mailhost.intellivid.com [64.32.200.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3DF762E017714 for ; Wed, 13 Apr 2005 08:07:06 -0700 Received: from [192.168.2.68] (spectre.intellivid.com [192.168.2.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by newmail.intellivid.com (Postfix) with ESMTP id CB6A9F1806A for ; Wed, 13 Apr 2005 11:07:05 -0400 (EDT) Subject: linux software RAID, 2.6.6, XFS, Postgres: corrupt files From: Ian Westmacott To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1113404825.2054.89.camel@spectre.intellivid.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 13 Apr 2005 11:07:05 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ianw@intellivid.com Precedence: bulk X-list: linux-xfs Content-Length: 1694 Lines: 52 We have experienced a file corruption problem (that may be similar to those reported by Guus Houtzager & James Foris recently). Here are the details: - 2.6.6 kernel.org kernel - Software RAID 0 on two SATA drives - XFS (versionnum [0x3184] = V4,ALIGN,DALIGN,DIRV2,EXTFLG) % xfs_info /dev/md0 meta-data=/data isize=256 agcount=16, agsize=6942328 blks = sectsz=512 data = bsize=4096 blocks=111077248, imaxpct=25 = sunit=8 swidth=16 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 % - problem occurs both with and without noalign mount option - Postgres 7.4.2 (only) on /dev/md0 - approx. 250 transactions per second - problem occurs both with and without Postgres fsync option The problem: with nearly 100% reproducibility, after a reboot one or more (usually more) Postgres files (tables, indexes, log files) are corrupt and/or missing. Errors are of the form: invalid page header in table or index, page uninitialized, transaction log file does not exist, corrupt table entries, OID invalid. What we have tried: - xfs_check reports no problems - Neither ext3 nor JFS exhibit this problem (all else being equal) - adding sync/sleep in shutdown scripts do not help the problem What we have yet to try: - explicit sunit=0 & swidth=0 - check whether simple umount/mount is sufficient to produce problem Does anyone have any other ideas? Thanks, --Ian From owner-linux-xfs Wed Apr 13 21:24:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Apr 2005 21:24:49 -0700 (PDT) Received: from ms-smtp-03.rdc-kc.rr.com (ms-smtp-03.rdc-kc.rr.com [24.94.166.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3E4OlMT003878 for ; Wed, 13 Apr 2005 21:24:48 -0700 Received: from [192.168.2.2] (rrcs-67-52-12-36.west.biz.rr.com [67.52.12.36]) by ms-smtp-03.rdc-kc.rr.com (8.12.10/8.12.7) with ESMTP id j3E4OfHB027840; Wed, 13 Apr 2005 23:24:41 -0500 (CDT) Message-ID: <425DD4CD.1090108@wi.rr.com> Date: Wed, 13 Apr 2005 21:26:21 -0500 From: James Foris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.3.2.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: ianw@intellivid.com Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Status: Clean X-archive-position: 5279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jforis@wi.rr.com Precedence: bulk X-list: linux-xfs Content-Length: 518 Lines: 17 Yes, this does sound like it might be the problem we are working on. The definitive test is to do a unmount/mount cycle instead of a reboot; if data corruption is found, then we are looking at the same thing. BTW, we have now duplicated this problem on the current Ubuntu Linux release, and on SUSE 9.2 (we will be checking 9.3 as soon as we get a copy... but I think we can recreate it there, too). Fortunately, it seems to be very hard to hit; it seems to be very hardware configuration dependent. Jim Foris From owner-linux-xfs Wed Apr 13 22:11:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Apr 2005 22:11:04 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3E5B2Pq005025 for ; Wed, 13 Apr 2005 22:11:02 -0700 Received: from spectre (c-66-30-216-118.hsd1.ma.comcast.net[66.30.216.118]) by comcast.net (sccrmhc13) with SMTP id <2005041405105601600aocske>; Thu, 14 Apr 2005 05:10:56 +0000 From: "Ian Westmacott" To: "James Foris" , Cc: Subject: RE: linux software RAID, 2.6.6, XFS, Postgres: corrupt files Date: Thu, 14 Apr 2005 00:53:05 -0400 Message-ID: <000401c540ad$d865d780$76d81e42@hsd1.ma.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <425DD4CD.1090108@wi.rr.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ianw@intellivid.com Precedence: bulk X-list: linux-xfs Content-Length: 1864 Lines: 53 Well, I can provide a bit more information. -- We have a number of these hardware systems. As I said, it is very easy to reproduce, at some of them. As it goes, it is at our Beta sites where it is easy to reproduce, and in our lab where it is tough to reproduce. We are looking into why. -- I was unable to try the sunit=0 & swidth=0 experiment: no matter what parameters I give to mkfs.xfs (sunit, swidth, su, sw, various args), or what options I use in mount, the filesystem is always created/mounted with the geometry read from the RAID. (perhaps this is a known issue) -- we are currently verifying a workaround: we added a pseudo-service during shutdown that does dd if=/dev/zero of=/xfs_filesystem/junk bs=64k count=8k (and removes junk on startup). On a system where this was nearly 100% repeatable, we have now gone though 10 reboot cycles without a problem (tests continue -- tough at a beta site). -- The problem remains unchanged if Linux Software RAID is removed from the equation. I stopped the RAID, formatted one of the disks as XFS (installed Postgres, etc.), and got the corruption on the first reboot. Is there any definitive information known about what hardware configurations are susceptible? Thanks, --Ian > -----Original Message----- > Yes, this does sound like it might be the problem we are working on. > > The definitive test is to do a unmount/mount cycle instead of a reboot; if > data corruption is found, then we are looking at the same thing. > > BTW, we have now duplicated this problem on the current Ubuntu Linux > release, > and on SUSE 9.2 (we will be checking 9.3 as soon as we get a copy... but > I think > we can recreate it there, too). > > Fortunately, it seems to be very hard to hit; it seems to be very > hardware configuration > dependent. > > Jim Foris From owner-linux-xfs Wed Apr 13 22:30:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Apr 2005 22:30:20 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3E5UHRZ005726 for ; Wed, 13 Apr 2005 22:30:18 -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 PAA21907; Thu, 14 Apr 2005 15:30:08 +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 j3E5U3kt330519; Thu, 14 Apr 2005 15:30:03 +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 j3E5OnBi002144; Thu, 14 Apr 2005 15:24:49 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j3E5OlNo002142; Thu, 14 Apr 2005 15:24:47 +1000 Date: Thu, 14 Apr 2005 15:24:47 +1000 From: Nathan Scott To: Ian Westmacott Cc: James Foris , linux-xfs@oss.sgi.com Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files Message-ID: <20050414052447.GB1855@frodo> References: <425DD4CD.1090108@wi.rr.com> <000401c540ad$d865d780$76d81e42@hsd1.ma.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401c540ad$d865d780$76d81e42@hsd1.ma.comcast.net> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5281 X-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: 1558 Lines: 41 On Thu, Apr 14, 2005 at 12:53:05AM -0400, Ian Westmacott wrote: > Well, I can provide a bit more information. > > -- We have a number of these hardware systems. As I said, it is very > easy to reproduce, at some of them. As it goes, it is at our Beta > sites where it is easy to reproduce, and in our lab where it is > tough to reproduce. We are looking into why. Sounds familiar. :( > -- I was unable to try the sunit=0 & swidth=0 experiment: no matter > what parameters I give to mkfs.xfs (sunit, swidth, su, sw, various > args), or what options I use in mount, the filesystem is always > created/mounted with the geometry read from the RAID. (perhaps this > is a known issue) You need a very recent mkfs (cvs), which has a noalign (-d suboption) command line argument now. > -- we are currently verifying a workaround: we added a pseudo-service > during shutdown that does > > dd if=/dev/zero of=/xfs_filesystem/junk bs=64k count=8k > > (and removes junk on startup). On a system where this was > nearly 100% repeatable, we have now gone though 10 reboot cycles > without a problem (tests continue -- tough at a beta site). > > -- The problem remains unchanged if Linux Software RAID is removed > from the equation. I stopped the RAID, formatted one of the disks > as XFS (installed Postgres, etc.), and got the corruption on the > first reboot. If you can, try to come up with a step-by-step test case so that we can reproduce your situation locally - thats a huge help. thanks! -- Nathan From owner-linux-xfs Thu Apr 14 04:20:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Apr 2005 04:20:46 -0700 (PDT) Received: from mta208-rme.xtra.co.nz (mta208-rme.xtra.co.nz [210.86.15.119]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EBKgFt026203 for ; Thu, 14 Apr 2005 04:20:43 -0700 Received: from mta6-rme.xtra.co.nz ([210.86.15.240]) by mta208-rme.xtra.co.nz with ESMTP id <20050414112033.JOBQ5260.mta208-rme.xtra.co.nz@mta6-rme.xtra.co.nz> for ; Thu, 14 Apr 2005 23:20:33 +1200 Received: from twintech.co.nz ([222.152.143.54]) by mta6-rme.xtra.co.nz with ESMTP id <20050414112033.HEZC1394.mta6-rme.xtra.co.nz@twintech.co.nz> for ; Thu, 14 Apr 2005 23:20:33 +1200 Message-ID: <425E51FC.ED27455F@twintech.co.nz> Date: Thu, 14 Apr 2005 23:20:29 +1200 From: Richard Cooper Organization: Twin Technology Ltd X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Converting IRIX XFS file system to Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/825/Tue Apr 12 15:53:21 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dcooper@twintech.co.nz Precedence: bulk X-list: linux-xfs Content-Length: 1112 Lines: 26 I apologise if I am going over old ground here, but I urgently need some help. I have a hard disk with an XFS file system on it created under IRIX. I think it has version 1 directories (superblock versionnum =0x1094). Having changed over to (Debian) Linux, the intention is to bring this drive over, along with its contents, but so far, without success. 1. A dump was taken of the fs under IRIX using xfsdump. However, when we try to rebuild that (using xfsrestore under Linux) there are many errors and no directory structure is built. Details can be provided. The -J flag was used and improved things but it still failed. 2. When the drive is mounted (kernel 2.4.27), the mount point appears empty but a df shows the drive as being 50% full. If you use a current version of xfsdump(2.2.27), it appears to recognise a lot (if not all) of the files on the fs . However, it again fails when an attempt is made to restore it to another XFS fs. Is there a "proper" way of converting/copying this drive so that I can use it under Linux, or do the version 1 directories prohibit conversion? . Thanks, Richard From owner-linux-xfs Thu Apr 14 11:50:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Apr 2005 11:50:15 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EIoDE2008643 for ; Thu, 14 Apr 2005 11:50:13 -0700 Received: by rproxy.gmail.com with SMTP id r35so474148rna for ; Thu, 14 Apr 2005 11:50:10 -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=Jtgs7sBtpV4nahgeZ05QlfiQzn2p2ZlaoRmzwHWt3CPKA8UxVBad9CUSaDjrorm6B7aQY1R5EXgJ3llqCdXHo+dCmteiM97g/wDqWWKR7lBvCVAyIjAYaBiZkl6AMo66wJu3PXbgmOBTg5gPkxN4nkGGj6CRFVpaUO40jqjU4a8= Received: by 10.38.67.66 with SMTP id p66mr31598rna; Thu, 14 Apr 2005 11:50:09 -0700 (PDT) Received: by 10.38.73.70 with HTTP; Thu, 14 Apr 2005 11:50:06 -0700 (PDT) Message-ID: <2ca133d20504141150512db1ac@mail.gmail.com> Date: Thu, 14 Apr 2005 13:50:06 -0500 From: KrishnaPradeep Tamma Reply-To: KrishnaPradeep Tamma To: linux-xfs@oss.sgi.com Subject: Architecture specific headers Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3EIoEE2008653 X-archive-position: 5285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krishnapradeep@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 439 Lines: 15 We are experimenting with XFS on Linux X86. We found that super block has endian problems and need to use xsf_xlatesb to convert to X86. Now we got similar problem with log header. We tried to read the first log block and match with XLOG_HEADER_MAGIC_NUM. But we are getting a different number. Does the log structure also need some endian conversion? Could some tell which function should we use to convert the same? Thanks Pradeep From owner-linux-xfs Thu Apr 14 11:58:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Apr 2005 11:58:33 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EIwVKh009227 for ; Thu, 14 Apr 2005 11:58:32 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DM9Xq-0001pQ-Ri; Thu, 14 Apr 2005 19:58:30 +0100 Date: Thu, 14 Apr 2005 19:58:30 +0100 From: Christoph Hellwig To: KrishnaPradeep Tamma Cc: linux-xfs@oss.sgi.com Subject: Re: Architecture specific headers Message-ID: <20050414185830.GA7006@infradead.org> References: <2ca133d20504141150512db1ac@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ca133d20504141150512db1ac@mail.gmail.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 556 Lines: 14 On Thu, Apr 14, 2005 at 01:50:06PM -0500, KrishnaPradeep Tamma wrote: > We are experimenting with XFS on Linux X86. We found that super block > has endian problems and need to use xsf_xlatesb to convert to X86. It's not an endian problem, it's per design. > Now we got similar problem with log header. We tried to read the first > log block and match with XLOG_HEADER_MAGIC_NUM. But we are getting a > different number. > > Does the log structure also need some endian conversion? Most of it doesn't, some does. I'd suggest you read the source code. From owner-linux-xfs Thu Apr 14 12:58:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Apr 2005 12:58:56 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EJwspH016706 for ; Thu, 14 Apr 2005 12:58:54 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3EJwsUC016705 for linux-xfs@oss.sgi.com; Thu, 14 Apr 2005 12:58:54 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EJwrwu016690 for ; Thu, 14 Apr 2005 12:58:53 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id j3EJExaU010346; Thu, 14 Apr 2005 12:14:59 -0700 Date: Thu, 14 Apr 2005 12:14:59 -0700 Message-Id: <200504141914.j3EJExaU010346@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 408] New: XFS internal error xfs_da_do_buf(2) at line 2284 of file xfs_da_btree.c. X-Bugzilla-Reason: AssignedTo X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4411 Lines: 84 http://oss.sgi.com/bugzilla/show_bug.cgi?id=408 Summary: XFS internal error xfs_da_do_buf(2) at line 2284 of file xfs_da_btree.c. Product: Linux XFS Version: 1.3.x Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: jae@amnh.org Our file server running 2.4.20-20.9.XFS1.3.1smp had the following error: ------------------- Apr 7 12:31:32 radon kernel: 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Apr 7 12:31:32 radon kernel: Filesystem "sd(8,1)": XFS internal error xfs_da_do_buf(2) at line 2284 of file xfs_da_btree.c. Caller 0xf8a42067 Apr 7 12:31:32 radon kernel: c836dbec f8a5238f 00000008 00000000 00000001 f740d400 f8aa7980 f8aa619b Apr 7 12:31:32 radon kernel: 000008ec f8aa60a2 f8a42067 00000001 00000001 00000038 f8a52503 f8aa619b Apr 7 12:31:32 radon kernel: 00000001 f740d400 f8aa60a2 000008ec f8a42067 d1b5dd30 f8a41be9 f8aa619b Apr 7 12:31:32 radon kernel: Call Trace: [] xfs_error_report [xfs] 0x6f (0xc836dbf0)) Apr 7 12:31:32 radon kernel: [] .rodata.str1.32 [xfs] 0x240 (0xc836dc04)) Apr 7 12:31:32 radon kernel: [] .rodata.str1.1 [xfs] 0x3d7 (0xc836dc08)) Apr 7 12:31:32 radon kernel: [] .rodata.str1.1 [xfs] 0x2de (0xc836dc10)) Apr 7 12:31:32 radon kernel: [] xfs_da_read_buf [xfs] 0x57 (0xc836dc14)) Apr 7 12:31:32 radon kernel: [] xfs_corruption_error [xfs] 0x43 (0xc836dc24)) Apr 7 12:31:32 radon kernel: [] .rodata.str1.1 [xfs] 0x3d7 (0xc836dc28)) Apr 7 12:31:32 radon kernel: [] .rodata.str1.1 [xfs] 0x2de (0xc836dc34)) Apr 7 12:31:32 radon kernel: [] xfs_da_read_buf [xfs] 0x57 (0xc836dc3c)) Apr 7 12:31:32 radon kernel: [] xfs_da_do_buf [xfs] 0x509 (0xc836dc44)) Apr 7 12:31:32 radon kernel: [] .rodata.str1.1 [xfs] 0x3d7 (0xc836dc48)) Apr 7 12:31:32 radon kernel: [] .rodata.str1.1 [xfs] 0x2de (0xc836dc58)) Apr 7 12:31:32 radon kernel: [] xfs_da_read_buf [xfs] 0x57 (0xc836dc60)) Apr 7 12:31:32 radon kernel: [] _pagebuf_lookup_pages [xfs] 0x2c4 (0xc836dc70)) Apr 7 12:31:32 radon kernel: [] xfs_trans_brelse [xfs] 0xc5 (0xc836dce0)) Apr 7 12:31:32 radon kernel: [] xfs_da_read_buf [xfs] 0x57 (0xc836dcf4)) Apr 7 12:31:32 radon kernel: [] xfs_dir2_block_lookup_int [xfs] 0x52 (0xc836dd14)) Apr 7 12:31:32 radon kernel: [] xfs_dir2_block_lookup_int [xfs] 0x52 (0xc836dd20)) Apr 7 12:31:32 radon kernel: [] ext3_getblk [ext3] 0xa8 (0xc836dd40)) Apr 7 12:31:32 radon kernel: [] xfs_dir2_block_lookup [xfs] 0x2f (0xc836dd70)) Apr 7 12:31:32 radon kernel: [] xfs_dir2_lookup [xfs] 0xc1 (0xc836dd98)) Apr 7 12:31:32 radon kernel: [] ext3_find_entry [ext3] 0x2fb (0xc836ddfc)) Apr 7 12:31:32 radon kernel: [] .rodata.str1.1 [ext3] 0x55e (0xc836de00)) Apr 7 12:31:32 radon kernel: [] xfs_dir_lookup_int [xfs] 0x4c (0xc836de1c)) Apr 7 12:31:32 radon kernel: [] xfs_lookup [xfs] 0x65 (0xc836de50)) Apr 7 12:31:32 radon kernel: [] linvfs_lookup [xfs] 0x67 (0xc836de80)) Apr 7 12:31:32 radon kernel: [] real_lookup [kernel] 0xec (0xc836dea8)) Apr 7 12:31:32 radon kernel: [] link_path_walk [kernel] 0x164 (0xc836dec8)) Apr 7 12:31:32 radon kernel: [] path_walk [kernel] 0x16 (0xc836df08)) Apr 7 12:31:32 radon kernel: [] path_lookup [kernel] 0x39 (0xc836df0c)) Apr 7 12:31:32 radon kernel: [] __user_walk [kernel] 0x49 (0xc836df1c)) Apr 7 12:31:32 radon kernel: [] vfs_stat [kernel] 0x1f (0xc836df38)) Apr 7 12:31:32 radon kernel: [] sys_stat64 [kernel] 0x1b (0xc836df70)) Apr 7 12:31:32 radon kernel: [] do_page_fault [kernel] 0x0 (0xc836dfb0)) Apr 7 12:31:32 radon kernel: [] error_code [kernel] 0x34 (0xc836dfb8)) Apr 7 12:31:32 radon kernel: [] system_call [kernel] 0x33 (0xc836dfc0)) Apr 7 12:31:32 radon kernel: ------------------- Any help in resolving this problem will be greatly appreciated. Thanks, Jae ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Apr 14 13:31:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Apr 2005 13:31:43 -0700 (PDT) Received: from mailhost.intellivid.com (mailhost.intellivid.com [64.32.200.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3EKVgC7018409 for ; Thu, 14 Apr 2005 13:31:42 -0700 Received: from [192.168.2.68] (spectre.intellivid.com [192.168.2.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by newmail.intellivid.com (Postfix) with ESMTP id B180AF1806A; Thu, 14 Apr 2005 16:31:41 -0400 (EDT) Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files From: Ian Westmacott To: Nathan Scott Cc: James Foris , linux-xfs@oss.sgi.com In-Reply-To: <20050414052447.GB1855@frodo> References: <425DD4CD.1090108@wi.rr.com> <000401c540ad$d865d780$76d81e42@hsd1.ma.comcast.net> <20050414052447.GB1855@frodo> Content-Type: text/plain Message-Id: <1113510701.5148.506.camel@spectre.intellivid.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 14 Apr 2005 16:31:41 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5288 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ianw@intellivid.com Precedence: bulk X-list: linux-xfs Content-Length: 1252 Lines: 34 > > -- we are currently verifying a workaround: we added a pseudo-service > > during shutdown that does > > > > dd if=/dev/zero of=/xfs_filesystem/junk bs=64k count=8k > > > > (and removes junk on startup). On a system where this was > > nearly 100% repeatable, we have now gone though 10 reboot cycles > > without a problem (tests continue -- tough at a beta site). verification of this workaround failed. It is still possible to get corruption. > If you can, try to come up with a step-by-step test case so that > we can reproduce your situation locally - thats a huge help. I'm working on simple reproduction steps (without luck so far). Our procedure involves creating a database and rebooting while it is under load. If I find something simple, I'll send it. One difference in our experience from Jim's is that corruption can occur when the filesystem is 5% full. We have not been able to produce a failure with his script (though we have not gotten the filesystem up to 70% yet with that procedure). We have noticed that some calls to xfs_unmount_wait were added to xfs_unmount in modid xfs-linux:xfs-kern:182694a, commenting on async buffers. Any chance that is related (we don't have that patch)? Thanks, --Ian From owner-linux-xfs Thu Apr 14 16:34:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Apr 2005 16:34:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3ENYjOq028928 for ; Thu, 14 Apr 2005 16:34:46 -0700 Received: from mumble.melbourne.sgi.com (mumble.melbourne.sgi.com [134.14.55.227]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04794; Fri, 15 Apr 2005 09:34:34 +1000 Received: from mumble.melbourne.sgi.com (localhost [127.0.0.1]) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j3ENYQXf028720; Fri, 15 Apr 2005 09:34:29 +1000 (EST) Received: (from dgc@localhost) by mumble.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j3ENYKui029373; Fri, 15 Apr 2005 09:34:20 +1000 (EST) Date: Fri, 15 Apr 2005 09:34:20 +1000 From: Dave Chinner To: Ian Westmacott Cc: Nathan Scott , James Foris , linux-xfs@oss.sgi.com Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files Message-ID: <20050415093420.Q19332@melbourne.sgi.com> References: <425DD4CD.1090108@wi.rr.com> <000401c540ad$d865d780$76d81e42@hsd1.ma.comcast.net> <20050414052447.GB1855@frodo> <1113510701.5148.506.camel@spectre.intellivid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1113510701.5148.506.camel@spectre.intellivid.com>; from ianw@intellivid.com on Thu, Apr 14, 2005 at 04:31:41PM -0400 X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5289 X-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: 760 Lines: 24 On Thu, Apr 14, 2005 at 04:31:41PM -0400, Ian Westmacott wrote: > > > If you can, try to come up with a step-by-step test case so that > > we can reproduce your situation locally - thats a huge help. > > I'm working on simple reproduction steps (without luck so far). > Our procedure involves creating a database and rebooting while > it is under load. If I find something simple, I'll send it. Hmmm. Is the database using asynchronous buffered I/O? If it is, then what you are doing here is guaranteed to produce data corruption because you are rebooting before (all) the data has been flushed to disk. Can you confirm what type of I/O the database is actually doing? Cheers, Dave. -- Dave Chinner R&D Software Engineer SGI Australian Software Group From owner-linux-xfs Thu Apr 14 17:30:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Apr 2005 17:30:03 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3F0U1G3030409 for ; Thu, 14 Apr 2005 17:30:02 -0700 Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j3F0U0l8002693 for ; Thu, 14 Apr 2005 20:30:02 -0400 X-ORBL: [63.202.174.40] Received: from taniwha.stupidest.org (adsl-63-202-174-40.dsl.snfc21.pacbell.net [63.202.174.40]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j3F0TsxG137746; Thu, 14 Apr 2005 20:29:58 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id C30DC11FF6BA; Thu, 14 Apr 2005 17:29:53 -0700 (PDT) Date: Thu, 14 Apr 2005 17:29:53 -0700 From: Chris Wedgwood To: Dave Chinner Cc: Ian Westmacott , Nathan Scott , James Foris , linux-xfs@oss.sgi.com Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files Message-ID: <20050415002953.GA8709@taniwha.stupidest.org> References: <425DD4CD.1090108@wi.rr.com> <000401c540ad$d865d780$76d81e42@hsd1.ma.comcast.net> <20050414052447.GB1855@frodo> <1113510701.5148.506.camel@spectre.intellivid.com> <20050415093420.Q19332@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415093420.Q19332@melbourne.sgi.com> X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 199 Lines: 7 On Fri, Apr 15, 2005 at 09:34:20AM +1000, Dave Chinner wrote: > Hmmm. Is the database using asynchronous buffered I/O? It can't be. Buffered AIO under linux doesn't work (well, not in mainline). From owner-linux-xfs Thu Apr 14 17:33:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Apr 2005 17:33:35 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3F0XXbL031095 for ; Thu, 14 Apr 2005 17:33: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 KAA05806; Fri, 15 Apr 2005 10:33: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 j3F0XKkt353123; Fri, 15 Apr 2005 10:33:20 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j3F0XHGa352209; Fri, 15 Apr 2005 10:33:17 +1000 (EST) Date: Fri, 15 Apr 2005 10:33:17 +1000 From: Nathan Scott To: Chris Wedgwood Cc: Dave Chinner , Ian Westmacott , James Foris , linux-xfs@oss.sgi.com Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files Message-ID: <20050415103317.G350217@wobbly.melbourne.sgi.com> References: <425DD4CD.1090108@wi.rr.com> <000401c540ad$d865d780$76d81e42@hsd1.ma.comcast.net> <20050414052447.GB1855@frodo> <1113510701.5148.506.camel@spectre.intellivid.com> <20050415093420.Q19332@melbourne.sgi.com> <20050415002953.GA8709@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050415002953.GA8709@taniwha.stupidest.org>; from cw@f00f.org on Thu, Apr 14, 2005 at 05:29:53PM -0700 X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5291 X-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: 362 Lines: 15 On Thu, Apr 14, 2005 at 05:29:53PM -0700, Chris Wedgwood wrote: > On Fri, Apr 15, 2005 at 09:34:20AM +1000, Dave Chinner wrote: > > > Hmmm. Is the database using asynchronous buffered I/O? > > It can't be. Buffered AIO under linux doesn't work (well, not in > mainline). By "asynchronous" Dave meant non-O_SYNC buffered IO, not AIO. :) cheers. -- Nathan From owner-linux-xfs Thu Apr 14 18:00:24 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Apr 2005 18:00:25 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3F10MeU000884 for ; Thu, 14 Apr 2005 18:00: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 LAA06199; Fri, 15 Apr 2005 11:00:01 +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 j3F0xukt353735; Fri, 15 Apr 2005 10:59:57 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j3F0xq75354268; Fri, 15 Apr 2005 10:59:52 +1000 (EST) Date: Fri, 15 Apr 2005 10:59:52 +1000 From: Nathan Scott To: Ian Westmacott Cc: James Foris , linux-xfs@oss.sgi.com Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files Message-ID: <20050415105952.H350217@wobbly.melbourne.sgi.com> References: <425DD4CD.1090108@wi.rr.com> <000401c540ad$d865d780$76d81e42@hsd1.ma.comcast.net> <20050414052447.GB1855@frodo> <1113510701.5148.506.camel@spectre.intellivid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1113510701.5148.506.camel@spectre.intellivid.com>; from ianw@intellivid.com on Thu, Apr 14, 2005 at 04:31:41PM -0400 X-Virus-Scanned: ClamAV 0.83/828/Wed Apr 13 16:18:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5292 X-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: 16 On Thu, Apr 14, 2005 at 04:31:41PM -0400, Ian Westmacott wrote: > ... > We have noticed that some calls to xfs_unmount_wait were added to > xfs_unmount in modid xfs-linux:xfs-kern:182694a, commenting on > async buffers. Any chance that is related (we don't have that > patch)? That was a change to guarantee that all metadata buffers were flushed by the time we unmounted, or remounted readonly, and would not have affected regular file data. cheers. -- Nathan From owner-linux-xfs Fri Apr 15 05:21:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Apr 2005 05:21:48 -0700 (PDT) Received: from mailhost.intellivid.com (mailhost.intellivid.com [64.32.200.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FCLkoj001800 for ; Fri, 15 Apr 2005 05:21:46 -0700 Received: from [192.168.2.68] (spectre.intellivid.com [192.168.2.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by newmail.intellivid.com (Postfix) with ESMTP id A9A0CF1806A for ; Fri, 15 Apr 2005 08:21:43 -0400 (EDT) Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files From: Ian Westmacott To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1113567703.8214.1.camel@spectre.intellivid.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 15 Apr 2005 08:21:43 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ianw@intellivid.com Precedence: bulk X-list: linux-xfs Content-Length: 1082 Lines: 27 On Thu, 2005-04-14 at 19:34, Dave Chinner wrote: > On Thu, Apr 14, 2005 at 04:31:41PM -0400, Ian Westmacott wrote: > > > > > If you can, try to come up with a step-by-step test case so that > > > we can reproduce your situation locally - thats a huge help. > > > > I'm working on simple reproduction steps (without luck so far). > > Our procedure involves creating a database and rebooting while > > it is under load. If I find something simple, I'll send it. > > Hmmm. Is the database using asynchronous buffered I/O? If it is, > then what you are doing here is guaranteed to produce data > corruption because you are rebooting before (all) the data has > been flushed to disk. > > Can you confirm what type of I/O the database is actually doing? Near as we can tell from source, it is either doing O_SYNC, fsync or fdatasync, depending on configuration. In any case, we have tried explicit syncs, 30 second waits, and dumping 1GB of junk bits to the disk before shutdown -- none of which helps. (BTW, by 'reboot' I do mean orderly shutdown and startup). Thanks, --Ian From owner-linux-xfs Fri Apr 15 08:11:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Apr 2005 08:11:41 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FFBa7A012163 for ; Fri, 15 Apr 2005 08:11:37 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j3FFBVDB010884 for ; Fri, 15 Apr 2005 17:11:31 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 15 Apr 2005 17:11:30 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j3FFAWYw025444 for ; Fri, 15 Apr 2005 17:10:34 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j3FFBRZa011922 for ; Fri, 15 Apr 2005 17:11:27 +0200 (MEST) Message-ID: <425FD99F.1080600@ocre.cea.fr> Date: Fri, 15 Apr 2005 17:11:27 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: fsys_vector and dmapiops Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 692 Lines: 17 Hello, I'm trying to figure out the architecture and behaviour of the kernel part of DMAPI. Presently, I've got problems to understand the interface between DMAPI and the file systems. I notice that 2 functions vectors are used : *fsys_vector* and *dmapiops*. To get the fsys_vector structure, we need to use a function available in dmapiops. Except few differences, they work as the same manner and they do the same job. They're filesystem's interface into the DMAPI code. In fact, I even don't understand why they got those differences. It must why I do not understand why two structures exist to do the same job. ;) Could anybody explain to me how that stuff works ? :) Aurelien From owner-linux-xfs Fri Apr 15 08:33:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Apr 2005 08:33:55 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FFXq8S017293 for ; Fri, 15 Apr 2005 08:33: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 j3FFXpxT009860 for ; Fri, 15 Apr 2005 10:33:51 -0500 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3FFXpR06116096; Fri, 15 Apr 2005 10:33:51 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 1CC314FE57; Fri, 15 Apr 2005 10:33:51 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: fsys_vector and dmapiops Date: Fri, 15 Apr 2005 10:33:50 -0500 From: Dean Roehrich Message-Id: <20050415153351.1CC314FE57@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1351 Lines: 28 >From: Aurelien Degremont - Stagiaire >Hello, > >I'm trying to figure out the architecture and behaviour of the kernel >part of DMAPI. Presently, I've got problems to understand the interface >between DMAPI and the file systems. >I notice that 2 functions vectors are used : *fsys_vector* and *dmapiops*. >To get the fsys_vector structure, we need to use a function available in >dmapiops. >Except few differences, they work as the same manner and they do the >same job. They're filesystem's interface into the DMAPI code. In fact, I >even don't understand why they got those differences. It must why I do >not understand why two structures exist to do the same job. ;) It's very likely that we'll migrate everything to the dmapi_operations structure someday. I've never liked that fsys_vector thing, and after the port to linux it starts to look even more silly. The dmapi_operations structure was created because the dmapi code no longer knew about XFS vfs_t and vnode_t types and it couldn't, for example, call VFS_DMAPIOPS and VFS_VGET/VFS_ROOT and VOP_FID2 on its own anymore. Because it couldn't call VFS_DMAPIOPS, it couldn't get the fsys_vector... On the other hand, the dmapi_operations needs to be handled better in dmapi_mountinfo.c. It needs to be changed to use linux-style lists for starters. Dean From owner-linux-xfs Fri Apr 15 09:35:07 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Apr 2005 09:35:08 -0700 (PDT) Received: from mailhost.intellivid.com (mailhost.intellivid.com [64.32.200.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FGZ7Zk019484 for ; Fri, 15 Apr 2005 09:35:07 -0700 Received: from [192.168.2.64] (vishambu.intellivid.com [192.168.2.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by newmail.intellivid.com (Postfix) with ESMTP id CA285F1806A for ; Fri, 15 Apr 2005 12:35:06 -0400 (EDT) Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files From: "Thomas J. Teixeira" To: linux-xfs In-Reply-To: <1113576995.9697.76.camel@vishambu.intellivid.com> References: <1113576995.9697.76.camel@vishambu.intellivid.com> Content-Type: text/plain Message-Id: <1113582906.9697.97.camel@vishambu.intellivid.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 15 Apr 2005 12:35:06 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tjt@intellivid.com Precedence: bulk X-list: linux-xfs Content-Length: 1584 Lines: 35 On Fri, 2005-04-15 at 10:56, Thomas J. Teixeira wrote: > From the symptoms we are seeing -- no corruption as long as the file > system stays mounted -- I would expect to find some data buffer in a > strange state -- something like dirty but locked in a way that > prevents it from being written, but keeps it around so reads will find > the data. If XFS were simply dropping a dirty bit, I would expect to > see corruption even while the file system stays continuously mounted. Okay, I've been reading through more of the code and am very suspicious of this code in xfs_unmountfs: /* * Flush out the log synchronously so that we know for sure * that nothing is pinned. This is important because bflush() * will skip pinned buffers. */ xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE | XFS_LOG_SYNC); xfs_binval(mp->m_ddev_targp); xfs_binval seems to be the same as bflush(), and actually invokes xfs_flush_buftarg which helpfully returns a count of how many buffers it found pinned. It seems as though unmount should at least make sure xfs_binval returned 0, although I haven't read enough code to have a clue about what it should do if it isn't zero: if nothing else, print a message and maybe try xfs_log_force yet again. This is where I need to read a bunch more code, but at first guess if a pagebuf got pinned early in its lifetime, and the pagebuf pin count was never decremented properly, wouldn't this result in an always-cached-but-never-written page? For what it's worth, we are running on a Pentium 4 with hyper-threading enabled. From owner-linux-xfs Fri Apr 15 09:58:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Apr 2005 09:58:48 -0700 (PDT) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.182.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FGwkWR020967 for ; Fri, 15 Apr 2005 09:58:47 -0700 Received: from filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.183.68]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id 3E9C9364D87; Fri, 15 Apr 2005 16:58:46 +0000 (UTC) Received: from relay01.roc.ny.frontiernet.net ([66.133.182.164]) by filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.183.68]) (amavisd-new, port 10024) with LMTP id 12883-04-25; Fri, 15 Apr 2005 16:58:46 +0000 (UTC) Received: from [192.168.1.65] (67-137-96-87.dsl2.brv.mn.frontiernet.net [67.137.96.87]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id A8DFA365A86; Fri, 15 Apr 2005 16:58:41 +0000 (UTC) Message-ID: <425FF2CE.9010007@xfs.org> Date: Fri, 15 Apr 2005 11:58:54 -0500 From: Stephen Lord User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomas J. Teixeira" Cc: linux-xfs Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files References: <1113576995.9697.76.camel@vishambu.intellivid.com> <1113582906.9697.97.camel@vishambu.intellivid.com> In-Reply-To: <1113582906.9697.97.camel@vishambu.intellivid.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter01.roc.ny.frontiernet.net X-Virus-Status: Clean X-archive-position: 5297 X-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: 2176 Lines: 53 Thomas J. Teixeira wrote: > On Fri, 2005-04-15 at 10:56, Thomas J. Teixeira wrote: > > >> From the symptoms we are seeing -- no corruption as long as the file >>system stays mounted -- I would expect to find some data buffer in a >>strange state -- something like dirty but locked in a way that >>prevents it from being written, but keeps it around so reads will find >>the data. If XFS were simply dropping a dirty bit, I would expect to >>see corruption even while the file system stays continuously mounted. > > > Okay, I've been reading through more of the code and am very suspicious > of this code in xfs_unmountfs: > > /* > * Flush out the log synchronously so that we know for sure > * that nothing is pinned. This is important because bflush() > * will skip pinned buffers. > */ > xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE | XFS_LOG_SYNC); > > xfs_binval(mp->m_ddev_targp); > > xfs_binval seems to be the same as bflush(), and actually invokes > xfs_flush_buftarg which helpfully returns a count of how many buffers it > found pinned. It seems as though unmount should at least make sure > xfs_binval returned 0, although I haven't read enough code to have a > clue about what it should do if it isn't zero: if nothing else, print a > message and maybe try xfs_log_force yet again. This is where I need to > read a bunch more code, but at first guess if a pagebuf got pinned early > in its lifetime, and the pagebuf pin count was never decremented > properly, wouldn't this result in an always-cached-but-never-written > page? > > For what it's worth, we are running on a Pentium 4 with hyper-threading > enabled. > The code is very funky here. A metadata structure gets pinned when a transaction is copied into the in core log buffers. It gets unpinned when the incore log buffer's write completes. The xfs_log_force call with LOG_SYNC set it intended to wait for that to happen. We are in unmount here, so no new transactions are possible. Now, if there are indeed still pinned items after the log_force call then yes, things are broken, and it would be educational to learn that. Steve From owner-linux-xfs Fri Apr 15 12:44:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Apr 2005 12:44:45 -0700 (PDT) Received: from mailhost.intellivid.com (mailhost.intellivid.com [64.32.200.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3FJiiDc030558 for ; Fri, 15 Apr 2005 12:44:44 -0700 Received: from [192.168.2.64] (vishambu.intellivid.com [192.168.2.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by newmail.intellivid.com (Postfix) with ESMTP id 74F0EF18179 for ; Fri, 15 Apr 2005 15:44:41 -0400 (EDT) Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files From: "Thomas J. Teixeira" To: linux-xfs Content-Type: text/plain Message-Id: <1113594280.9697.103.camel@vishambu.intellivid.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 15 Apr 2005 15:44:41 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tjt@intellivid.com Precedence: bulk X-list: linux-xfs Content-Length: 1270 Lines: 30 Resending this since it didn't seem to go through the first time -- I'm looking for kernel diagnostic tools. - Tom -- RESEND STARTS HERE -- I'm working with Ian Westmacott on this corruption problem and was wondering if there are any tools for examining the state of kernel XFS buffers of a running system. I didn't see anything obvious in the source RPM for xfsprogs from SuSE 9.1, but I was looking for something that would open something like /dev/kmem (I'm a reformed unix kernel hacker, but don't have experience with linux at this level). The reasoning is that although we haven't been able to construct a reproducible test case in our lab, we can go to a beta site and stop our application and postgres at which point there should be no open files on the XFS file system which is used exclusively by postgres. From the symptoms we are seeing -- no corruption as long as the file system stays mounted -- I would expect to find some data buffer in a strange state -- something like dirty but locked in a way that prevents it from being written, but keeps it around so reads will find the data. If XFS were simply dropping a dirty bit, I would expect to see corruption even while the file system stays continuously mounted. Thanks in advance, - Tom Teixeira From owner-linux-xfs Sat Apr 16 02:35:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Apr 2005 02:35:53 -0700 (PDT) Received: from satan.blackhosts (cnq137.neoplus.adsl.tpnet.pl [83.31.170.137]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3G9Zmo1001978 for ; Sat, 16 Apr 2005 02:35:49 -0700 Received: from satan.blackhosts (localhost [127.0.0.1]) by satan.blackhosts (8.13.3/8.13.3) with ESMTP id j3G9gJfA004720 for ; Sat, 16 Apr 2005 11:42:20 +0200 Received: (from qboosh@localhost) by satan.blackhosts (8.13.3/8.13.3/Submit) id j3G9gJRN004717 for linux-xfs@oss.sgi.com; Sat, 16 Apr 2005 11:42:19 +0200 Date: Sat, 16 Apr 2005 11:42:19 +0200 From: Jakub Bogusz To: linux-xfs@oss.sgi.com Subject: Polish translation update for attr 2.4.20 Message-ID: <20050416094219.GB3971@fngna.oyu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline Content-Transfer-Encoding: 8bit Organization: Black Hosts X-Disclaimer: speaking only for myself User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/830/Thu Apr 14 13:44:31 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: qboosh@pld-linux.org Precedence: bulk X-list: linux-xfs Content-Length: 5406 Lines: 167 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I've updated pl.po for attr 2.4.20. Patch included. Or, alternatively, whole updated pl.po is available at http://cyber.cs.net.pl/~qboosh/pl.po/attr-2.4.20.pl.po BTW, attr.pot included in attr 2.4.20 tarball requires update ("make attr.pot" is enough). -- Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename="attr-po.patch" Content-Transfer-Encoding: 8bit --- attr-2.4.20/po/pl.po.orig 2004-10-15 17:05:18.000000000 +0200 +++ attr-2.4.20/po/pl.po 2005-04-16 01:31:14.311162152 +0200 @@ -1,13 +1,13 @@ # Polish translation for attr. # Copyright (C) 2004 Free Software Foundation, Inc. # This file is distributed under the same license as the attr package. -# Jakub Bogusz , 2004. +# Jakub Bogusz , 2004-2005. # msgid "" msgstr "" -"Project-Id-Version: attr-2.4.14\n" +"Project-Id-Version: attr-2.4.20\n" "POT-Creation-Date: 2004-01-28 21:04+0100\n" -"PO-Revision-Date: 2004-01-28 21:09+0100\n" +"PO-Revision-Date: 2005-04-16 01:30+0200\n" "Last-Translator: Jakub Bogusz \n" "Language-Team: Polish \n" "MIME-Version: 1.0\n" @@ -78,26 +78,26 @@ msgid "At least one of -s, -g, or -r is required\n" msgstr "Wymagane jest jedno z -s, -g lub -r\n" -#: ../getfattr/getfattr.c:97 ../setfattr/setfattr.c:69 +#: ../getfattr/getfattr.c:98 ../setfattr/setfattr.c:71 msgid "No such attribute" msgstr "Nie ma takiego atrybutu" -#: ../getfattr/getfattr.c:253 +#: ../getfattr/getfattr.c:254 #, c-format msgid "%s: Removing leading '/' from absolute path names\n" msgstr "%s: Usuniêcie wiod±cego '/' ze ¶cie¿ek bezwzglêdnych\n" -#: ../getfattr/getfattr.c:391 +#: ../getfattr/getfattr.c:392 #, c-format msgid "%s %s -- get extended attributes\n" msgstr "%s %s -- odczyt rozszerzonych atrybutów\n" -#: ../getfattr/getfattr.c:393 ../setfattr/setfattr.c:167 +#: ../getfattr/getfattr.c:394 ../setfattr/setfattr.c:169 #, c-format msgid "Usage: %s %s\n" msgstr "Sk³adnia: %s %s\n" -#: ../getfattr/getfattr.c:396 +#: ../getfattr/getfattr.c:397 #, c-format msgid "" " -n, --name=name get the named extended attribute value\n" @@ -128,12 +128,12 @@ " --version wy¶wietlenie informacji o wersji i zakoñczenie\n" " --help ten tekst pomocy\n" -#: ../getfattr/getfattr.c:493 +#: ../getfattr/getfattr.c:494 #, c-format msgid "%s: invalid regular expression \"%s\"\n" msgstr "%s: b³êdne wyra¿enie regularne \"%s\"\n" -#: ../getfattr/getfattr.c:511 ../setfattr/setfattr.c:259 +#: ../getfattr/getfattr.c:512 #, c-format msgid "" "Usage: %s %s\n" @@ -142,22 +142,27 @@ "Sk³adnia: %s %s\n" "`%s --help' wy¶wietli wiêcej informacji.\n" -#: ../setfattr/setfattr.c:122 +#: ../setfattr/setfattr.c:124 #, c-format msgid "%s: %s: No filename found in line %d, aborting\n" msgstr "%s: %s: Nie znaleziono nazwy pliku w linii %d, przerwanie pracy\n" -#: ../setfattr/setfattr.c:126 +#: ../setfattr/setfattr.c:128 #, c-format -msgid "%s: No filename found inline %d of standard input, aborting\n" +msgid "%s: No filename found in line %d of standard input, aborting\n" msgstr "%s: Nie znaleziono nazwy pliku w linii %d standardowego wej¶cia, przerwanie pracy\n" -#: ../setfattr/setfattr.c:166 +#: ../setfattr/setfattr.c:168 #, c-format msgid "%s %s -- set extended attributes\n" msgstr "%s %s -- ustawianie rozszerzonych atrybutów\n" -#: ../setfattr/setfattr.c:169 +#: ../setfattr/setfattr.c:170 +#, c-format +msgid " %s %s\n" +msgstr " %s %s\n" + +#: ../setfattr/setfattr.c:172 #, c-format msgid "" " -n, --name=name set the value of the named extended attribute\n" @@ -176,24 +181,35 @@ " --version wy¶wietlenie informacji o wersji i zakoñczenie\n" " --help ten tekst pomocy\n" -#: ../libattr/attr_copy_fd.c:80 ../libattr/attr_copy_fd.c:95 -#: ../libattr/attr_copy_file.c:78 ../libattr/attr_copy_file.c:93 +#: ../setfattr/setfattr.c:262 +#, c-format +msgid "" +"Usage: %s %s\n" +" %s %s\n" +"Try `%s --help' for more information.\n" +msgstr "" +"Sk³adnia: %s %s\n" +" %s %s\n" +"`%s --help' wy¶wietli wiêcej informacji.\n" + +#: ../libattr/attr_copy_fd.c:81 ../libattr/attr_copy_fd.c:96 +#: ../libattr/attr_copy_file.c:79 ../libattr/attr_copy_file.c:94 #, c-format msgid "listing attributes of %s" msgstr "wypisywanie atrybutów %s" -#: ../libattr/attr_copy_fd.c:116 ../libattr/attr_copy_fd.c:133 -#: ../libattr/attr_copy_file.c:114 ../libattr/attr_copy_file.c:131 +#: ../libattr/attr_copy_fd.c:117 ../libattr/attr_copy_fd.c:134 +#: ../libattr/attr_copy_file.c:115 ../libattr/attr_copy_file.c:132 #, c-format msgid "getting attribute %s of %s" msgstr "odczyt atrybutu %s dla %s" -#: ../libattr/attr_copy_fd.c:143 ../libattr/attr_copy_file.c:141 +#: ../libattr/attr_copy_fd.c:144 ../libattr/attr_copy_file.c:142 #, c-format msgid "setting attributes for %s" msgstr "ustawianie atrybutów dla %s" -#: ../libattr/attr_copy_fd.c:149 ../libattr/attr_copy_file.c:147 +#: ../libattr/attr_copy_fd.c:150 ../libattr/attr_copy_file.c:148 #, c-format msgid "setting attribute %s for %s" msgstr "ustawianie atrybutu %s dla %s" --u3/rZRmxL6MmkK24-- From owner-linux-xfs Sat Apr 16 05:06:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Apr 2005 05:06:24 -0700 (PDT) Received: from saturn.hfp.fr (saturn.hfp.fr [62.23.99.135]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3GC6KDn014356 for ; Sat, 16 Apr 2005 05:06:23 -0700 Received: from saturn.hfp.fr (root@localhost) by saturn.hfp.fr (8.12.5-20030924/8.12.5) with ESMTP id j3GCqLjP010058 for ; Sat, 16 Apr 2005 14:52:21 +0200 (CEST) Message-Id: <200504161252.j3GCqLjP010058@saturn.hfp.fr> From: "Service de messagerie" To: linux-xfs@oss.sgi.com Subject: =?iso-8859-1?Q?Message_incompatible_avec_le_syst=E8me_de_messagerie?= Mime-version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Sat, 16 Apr 2005 14:01:02 +0200 X-Virus-Scanned: ClamAV 0.83/833/Fri Apr 15 19:31:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3GC6NDn014360 X-archive-position: 5300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: neti@hfp.fr Precedence: bulk X-list: linux-xfs Content-Length: 274 Lines: 6 Le message émis par linux-xfs@oss.sgi.com est incompatible avec le système de messagerie, il a été supprimé. Certains éléments contenus dans ce message ayant pour objet :" Re: Your document " sont susceptibles d'être dangereux pour le destinataire : 9110fea9@hfp.fr . From owner-linux-xfs Sat Apr 16 05:35:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Apr 2005 05:35:43 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3GCZeYB015361 for ; Sat, 16 Apr 2005 05:35:41 -0700 Received: by rproxy.gmail.com with SMTP id c51so798651rne for ; Sat, 16 Apr 2005 05:35:38 -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=IabTnAAp+9fiK1e1Ygz0Lfu6QNgfvzjbGINKCSXT+vVxuJaIf1xm+VDPnv+4Nh4JF8+a3eYFyaH4UhUKRgiSajTBjFjO1gqGPEF0GfaLAYGjlCFgyKigPItZ/2VwIWeP69b4/4BMjWreFLOisbPo3J4Pf+wjgQruhcsP7zL9rJk= Received: by 10.38.96.65 with SMTP id t65mr4113137rnb; Sat, 16 Apr 2005 05:35:38 -0700 (PDT) Received: by 10.38.89.57 with HTTP; Sat, 16 Apr 2005 05:35:38 -0700 (PDT) Message-ID: <8e53136c050416053512438f04@mail.gmail.com> Date: Sat, 16 Apr 2005 07:35:38 -0500 From: Rich Coe Reply-To: Rich Coe To: linux-xfs@oss.sgi.com Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/833/Fri Apr 15 19:31:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3GCZfYB015363 X-archive-position: 5301 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: codedr@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 5896 Lines: 228 I have been working on this problem for the last several weeks. Below is a test case that will reproduce the problem every time. I don't think this is an unmount problem, as I have this code in xfs_flush_buftarg() { [ ... ] printk(KERN_WARNING "xfs: xfs_flush_buftarg pincount %d\n", pincount); return pincount; } I always get a pincount of zero, and I can get corruption to always occur. My configuration and failing test cases follows. ctest will fill the disk and show the corruption. ctest.size shows that if the writes are slowed down or limited, that the corruption can be avoided. Some results of experiments on friday: 10 images 1 sec no corruption 20 images 1 sec no corruption 50 images 1 sec no corruption 100 images 1 sec corruption 20 images .5 sec 1 corruption 20 images .75 sec no corruption There seems to be a problem with the amount of data or the state of busy-ness in the disks. Nathan Scott attempted to reproduce this with IDE drives, but couldn't either because the size of the data partitions was too small or the drives too slow. #### mkfs.xfs -f -l logdev=/dev/sda5,sunit=8 /dev/md0 #### xfs_info #### meta-data=/export isize=256 agcount=16, agsize=263104 blks = sectsz=512 data = bsize=4096 blocks=4208896, imaxpct=25 = sunit=64 swidth=128 blks, unwritten=1 naming =version 2 bsize=4096 log =external bsize=4096 blocks=18065, version=2 = sectsz=512 sunit=1 blks realtime =none extsz=524288 blocks=0, rtextents=0 #### /etc/fstab #### /dev/md0 /bigdir xfs defaults,noatime,noalign,logbufs=8,logdev=/dev/sda5 1 2 #### /dev/sdb #### Disk /dev/sdb: 73.4 GB, 73407865856 bytes 255 heads, 63 sectors/track, 8924 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 1048 8418028+ fd Linux raid autodetect #### /dev/sdc #### Disk /dev/sdc: 73.4 GB, 73407865856 bytes 255 heads, 63 sectors/track, 8924 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdc1 1 1048 8418028+ fd Linux raid autodetect #### raidtab #### raiddev /dev/md0 raid-level 0 nr-raid-disks 2 nr-spare-disks 0 persistent-superblock 1 chunk-size 256 device /dev/sdb1 raid-disk 0 device /dev/sdc1 raid-disk 1 #### ctest ##### #!/bin/bash function elapsed { tot=`expr $2 - $1` mins=`expr $tot \/ 60` tsec=`expr $mins \* 60` rsec=`expr $tot - $tsec` echo "$mins minutes $rsec secs" } numberOfSmallFiles=1000000 directory=/bigdir/home/pool/test # rm -rf $directory mkdir -p $directory 2> /dev/null #find $directory -type f | egrep -v 'orimularge_[0-9][0-9]+' | xargs rm find $directory -type f | xargs rm start=`date +'%s'` device=`df -k $directory | tail -1 | awk '{ print $1 }'` # --- fragment the disk --- echo "create lots of small files" i=0 while ((i < numberOfSmallFiles)); do echo "*" > $directory/small_$i let i=$i+1 done echo "fill disk with big files" i=0 while : ; do if [ ! -e "$directory/orimularge_$i" ]; then if ( dd if=/dev/zero of=$directory/orimularge_$i bs=1M count=256 2>/dev/null) ; then echo -n "." else break; fi; fi let i=$i+1 done echo "rm the small files" i=0 while ((i < numberOfSmallFiles )); do echo $directory/small_$i let i=$i+2 done | xargs rm echo " --- create several copies of the same file ---" dd if=/dev/urandom of=$directory/data_reference bs=1K count=513 i=0 while ( cp $directory/data_reference $directory/data_$i ); do let i=$i+1 done echo " --- mount/umount ---" umount $device mount $device echo " --- check that the copies are equal --- " find $directory -name "data_*[0-9]" -exec cmp $directory/data_reference {} \; end=`date +'%s'` elapsed $start $end #### ctest.size #### #!/bin/bash if [ -z "$1" -o -z "$2" ]; then echo "ctest files interval" exit 1 fi SZ=$1 ITER=$2 echo "ctest: copying $SZ files at $ITER intervals" function elapsed { tot=`expr $2 - $1` mins=`expr $tot \/ 60` tsec=`expr $mins \* 60` rsec=`expr $tot - $tsec` echo "$mins minutes $rsec secs" } numberOfSmallFiles=1000000 directory=/bigdir/home/pool/test # rm -rf $directory mkdir -p $directory 2> /dev/null find $directory -type f | egrep -v 'orimularge_[0-9][0-9]+' | xargs rm #find $directory -type f | xargs rm start=`date +'%s'` device=`df -k $directory | tail -1 | awk '{ print $1 }'` # --- fragment the disk --- echo "create lots of small files" i=0 while ((i < numberOfSmallFiles)); do echo "*" > $directory/small_$i let i=$i+1 done echo "fill disk with big files" i=0 while : ; do if [ ! -e "$directory/orimularge_$i" ]; then if ( dd if=/dev/zero of=$directory/orimularge_$i bs=1M count=256 2>/dev/null) ; then echo -n "." else break; fi; fi let i=$i+1 done echo "rm the small files" i=0 while ((i < numberOfSmallFiles )); do echo $directory/small_$i let i=$i+2 done | xargs rm echo " --- create several copies of the same file ---" dd if=/dev/urandom of=$directory/data_reference bs=1K count=513 i=0 while ( cp $directory/data_reference $directory/data_$i ); do if (( 0 == i % $SZ )); then usleep $ITER fi let i=$i+1 done echo " --- mount/umount ---" umount $device mount $device echo " --- check that the copies are equal --- " find $directory -name "data_*[0-9]" -exec cmp $directory/data_reference {} \; > log wc log end=`date +'%s'` elapsed $start $end From owner-linux-xfs Sat Apr 16 22:11:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Apr 2005 22:11:06 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3H5B4B2027729 for ; Sat, 16 Apr 2005 22:11:05 -0700 Received: by zproxy.gmail.com with SMTP id 8so172958nzo for ; Sat, 16 Apr 2005 22:10:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nuPRCTyvqO0SeCltn+VASmTu41uJpbnRCkCz/jiWwiuS2x9AKCoY8ZHz9BKK8Kq2k/uKkO6VyW3H4GsjZvrj+Yuae2fe63HrGIZ/UTvOglkwYBKemQ82EQqdynY4YyOK2/t5gnu+JZPd2IdX1ffwIOpeG6/QHam9HnTK5lJWD4s= Received: by 10.36.25.2 with SMTP id 2mr284385nzy; Sat, 16 Apr 2005 22:10:57 -0700 (PDT) Received: by 10.36.12.18 with HTTP; Sat, 16 Apr 2005 22:10:57 -0700 (PDT) Message-ID: <2ca133d205041622106b61c016@mail.gmail.com> Date: Sun, 17 Apr 2005 00:10:57 -0500 From: KrishnaPradeep Tamma Reply-To: KrishnaPradeep Tamma To: linux-xfs@oss.sgi.com Subject: XFS journaling modes Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/833/Fri Apr 15 19:31:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3H5B5B2027732 X-archive-position: 5304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krishnapradeep@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 142 Lines: 14 Hi, Could some one tell, what type of journaling modes XFS support.? Some thing like data Ordered writeback Thanks for any help Pradeep From owner-linux-xfs Sat Apr 16 23:19:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Apr 2005 23:19:37 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3H6JXN2029988 for ; Sat, 16 Apr 2005 23:19:34 -0700 Received: from mail.ocs.com.au (pc-kao2.melbourne.sgi.com [134.14.52.228]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA28477 for ; Sun, 17 Apr 2005 16:19:25 +1000 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id 01FA21800AA; Sun, 17 Apr 2005 16:19:17 +1000 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 9ADC570010B; Sun, 17 Apr 2005 16:19:12 +1000 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 8DC2C1000CB; Sun, 17 Apr 2005 16:19:12 +1000 (EST) X-Mailer: exmh version 2.6.3_20040314 03/14/2004 with nmh-1.0.4 From: Keith Owens To: KrishnaPradeep Tamma Cc: linux-xfs@oss.sgi.com Subject: Re: XFS journaling modes In-reply-to: Your message of "Sun, 17 Apr 2005 00:10:57 EST." <2ca133d205041622106b61c016@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Apr 2005 16:19:12 +1000 Message-ID: <31874.1113718752@ocs3.ocs.com.au> X-Virus-Scanned: ClamAV 0.83/833/Fri Apr 15 19:31:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 679 Lines: 21 On Sun, 17 Apr 2005 00:10:57 -0500, KrishnaPradeep Tamma wrote: >Hi, > >Could some one tell, what type of journaling modes XFS support.? > >Some thing like > >data >Ordered >writeback XFS journals metadata updates, not data updates. IOW, it keeps the filesystem metadata in a consistent state (no fsck on restart), but there are no guarantees about the contents of data files. Data integrity is left to the application level, it is up to the application to issue msync or fdatasync when the application needs a checkpoint. Opening a file with O_SYNC will have the same effect as flushing after every update, but that can be significantly slower. From owner-linux-xfs Sun Apr 17 09:02:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Apr 2005 09:02:22 -0700 (PDT) Received: from webmail2.sd.dreamhost.com (webmail2.sd.dreamhost.com [66.33.201.157]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HG2K5T000936 for ; Sun, 17 Apr 2005 09:02:21 -0700 Received: from webmail.delusion.com (localhost [127.0.0.1]) by webmail2.sd.dreamhost.com (Postfix) with SMTP id 89400DC9F8 for ; Sun, 17 Apr 2005 09:02:20 -0700 (PDT) Received: from 67.49.24.45 (SquirrelMail authenticated user delusion@delusion.com) by webmail.delusion.com with HTTP; Sun, 17 Apr 2005 09:02:20 -0700 (PDT) Message-ID: <2254.67.49.24.45.1113753740.spork@webmail.delusion.com> In-Reply-To: <31874.1113718752@ocs3.ocs.com.au> References: Your message of "Sun, 17 Apr 2005 00:10:57 EST." <2ca133d205041622106b61c016@mail.gmail.com> <31874.1113718752@ocs3.ocs.com.au> Date: Sun, 17 Apr 2005 09:02:20 -0700 (PDT) Subject: Linux XFS write performance From: delusion@delusion.com To: linux-xfs@oss.sgi.com User-Agent: DreamHost Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: delusion@delusion.com Precedence: bulk X-list: linux-xfs Content-Length: 305 Lines: 11 Hi, Has anyone had experience/success getting 600MB/s or more (seq writes) off XFS via a raid card like the Areca 16port sata? The card does a 128k stripe and has 1GB of ram but I can't seem to get the right xfs setup and write patterns. Any tips getting the best sequenial write performance? Thanks! From owner-linux-xfs Sun Apr 17 11:19:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Apr 2005 11:19:24 -0700 (PDT) Received: from oban.houtzager.net (oban.houtzager.net [217.77.130.26]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HIJLiF006442 for ; Sun, 17 Apr 2005 11:19:22 -0700 Received: from localhost (oban [127.0.0.1]) by oban.houtzager.net (Postfix) with ESMTP id A66FB58349; Sun, 17 Apr 2005 20:19:16 +0200 (CEST) Received: from oban.houtzager.net ([127.0.0.1]) by localhost (oban [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14133-02; Sun, 17 Apr 2005 20:19:12 +0200 (CEST) Received: from bowmore.ipv6.houtzager.net (bowmore.ipv6.houtzager.net [IPv6:2001:9c0:2005:2:230:1bff:feac:42d]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by oban.houtzager.net (Postfix) with ESMTP id 23109580D3; Sun, 17 Apr 2005 20:19:12 +0200 (CEST) Subject: Re: Corrupt files From: Guus Houtzager To: sandeen@sgi.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <1113318624.3468.44.camel@localhost> References: <1113309929.3468.23.camel@localhost> <425BDD2C.1070800@sgi.com> <1113318624.3468.44.camel@localhost> Content-Type: text/plain Date: Sun, 17 Apr 2005 20:19:11 +0200 Message-Id: <1113761951.3224.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at houtzager.net X-Virus-Status: Clean X-archive-position: 5307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: guus@houtzager.net Precedence: bulk X-list: linux-xfs Content-Length: 1633 Lines: 41 Hi, On Tue, 2005-04-12 at 17:10 +0200, Guus Houtzager wrote: > Hi, > > On Tue, 2005-04-12 at 09:37 -0500, Eric Sandeen wrote: > > Guus Houtzager wrote: > > > If I redownload those files they > > > are ok. I tried using a different ftp client and scp but that made no > > > difference, some files still get corrupted. Using cmp -b on the corrupt > > > and the correct file show that the files differ in 1 byte. Output from > > > those 3 files: > > > correct1 corrupt1 byte 43330599, line 227755 is 7 ^G 47 ' > > > correct2 corrupt2 byte 21769255, line 113448 is 302 M-B 342 M-b > > > correct3 corrupt3 byte 39713823, line 206079 is 10 ^H 30 ^X > > > No messages in logfiles whatsoever. > > > > These are single-bit errors... I think it's unlikely that xfs is at > > fault. Maybe run some memory checking, or try a different underlying > > fileystem, volume mgr (or plain partition) or a different download tool? > > (I guess you've already done that last one) > > Thanks for your reaction. > The memory in this system is about a month old. I did a memtest86+ test > run on it at that time and was ok. Could ofcourse have gone bad in the > mean time, so I'll check that. I finally had time to do some memorytesting and it gave errors. I'll replace the memory next week and that will hopefully fix the problem. If not, I'll let you know. Thanks for the help! Regards, -- Guus Houtzager Email: guus@houtzager.net PGP fingerprint = 5E E6 96 35 F0 64 34 14 CC 03 2B 36 71 FB 4B 5D Early to rise, early to bed, makes a man healthy, wealthy and dead. --Rincewind, The Light Fantastic From owner-linux-xfs Sun Apr 17 12:10:53 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Apr 2005 12:10:54 -0700 (PDT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HJAr55008222 for ; Sun, 17 Apr 2005 12:10:53 -0700 Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j3HJAHO2008132 for ; Sun, 17 Apr 2005 15:10:17 -0400 X-ORBL: [67.124.119.21] Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j3HJAhm1075782; Sun, 17 Apr 2005 15:10:47 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 5F5F5115C859; Sun, 17 Apr 2005 12:10:42 -0700 (PDT) Date: Sun, 17 Apr 2005 12:10:42 -0700 From: Chris Wedgwood To: delusion@delusion.com Cc: linux-xfs@oss.sgi.com Subject: Re: Linux XFS write performance Message-ID: <20050417191042.GA9070@taniwha.stupidest.org> References: <2ca133d205041622106b61c016@mail.gmail.com> <31874.1113718752@ocs3.ocs.com.au> <2254.67.49.24.45.1113753740.spork@webmail.delusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2254.67.49.24.45.1113753740.spork@webmail.delusion.com> X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5308 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 872 Lines: 24 On Sun, Apr 17, 2005 at 09:02:20AM -0700, delusion@delusion.com wrote: > Has anyone had experience/success getting 600MB/s or more (seq > writes) off XFS via a raid card like the Areca 16port sata? Are you sure the card can do that IO rate? > The card does a 128k stripe and has 1GB of ram but I can't seem to > get the right xfs setup and write patterns. Could you explain in more details what you have and what you are doing? > Any tips getting the best sequenial write performance? It depends, large streeam O_DIRECT writes to preallocated space is probably worth experiementing with. I would also let mkfs.xfs know about the underlying RAID topology and see if that helps. 600MB/s is a fair amount of bandwidth, you probably need 2x or 3x this in the system to achieve this and depending on what you are doing that might not even be enough --- more details? From owner-linux-xfs Sun Apr 17 12:32:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Apr 2005 12:32:13 -0700 (PDT) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HJWBcW012698 for ; Sun, 17 Apr 2005 12:32:11 -0700 Received: from [10.1.2.230] (localhost [127.0.0.1]) by shell.wgops.com (Postfix) with ESMTP id 0C16225463; Sun, 17 Apr 2005 13:31:46 -0600 (MDT) Date: Sun, 17 Apr 2005 13:31:44 -0600 From: Michael Loftis To: delusion@delusion.com, linux-xfs@oss.sgi.com Subject: Re: Linux XFS write performance Message-ID: In-Reply-To: <2254.67.49.24.45.1113753740.spork@webmail.delusion.com> References: Your message of "Sun, 17 Apr 2005 00:10:57 EST." <2ca133d205041622106b61c016@mail.gmail.com> <31874.1113718752@ocs3.ocs.com.au> <2254.67.49.24.45.1113753740.spork@webmail.delusion.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-Information: Please contact support@wgops.com X-MailScanner: WGOPS clean X-MailScanner-From: mloftis@wgops.com X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 1527 Lines: 42 --On Sunday, April 17, 2005 9:02 AM -0700 delusion@delusion.com wrote: > > Hi, > > Has anyone had experience/success getting 600MB/s or more (seq writes) > off XFS via a raid card like the Areca 16port sata? > The card does a 128k stripe and has 1GB of ram but I can't > seem to get the right xfs setup and write patterns. > Any tips getting the best sequenial write performance? Which card specifically? Without PCI-X or PCI-Express (and you'd hav to be an x2 or x4 slot to approach this) (don't confuse the two, they're different) you're not going to achieve it. PCI has a hard limit around 133MB/sec. for 32b, 33mhz. 32b,66mhz gets you to around 533MB/sec. PCI-X is good to about 1033MB/sec, with 2.0 variants doubling that. PCI-Expres x1 gets you to around 250MB/sec. These are only theoretical maximums based on the signalling bandwidth. Reality eats away at those numbers considerably. Not to mention most CPUs would have a hard time reliably moving that much peripheral data around too. You're in I/O territory only touched by dedicated systems, and by real servers, not PC hardware...although...if one were VERY careful about the design, it could be achieved (and we're talking figured in bytes, not bits here...if we're talking bits, then it's definitely doable) > Thanks! > > > -- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat From owner-linux-xfs Sun Apr 17 16:05:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Apr 2005 16:05:25 -0700 (PDT) Received: from webmail3.sd.dreamhost.com (webmail3.sd.dreamhost.com [64.111.100.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HN5NNs020251 for ; Sun, 17 Apr 2005 16:05:23 -0700 Received: from webmail.delusion.com (localhost [127.0.0.1]) by webmail3.sd.dreamhost.com (Postfix) with SMTP id 2340F143A2; Sun, 17 Apr 2005 16:05:21 -0700 (PDT) Received: from 67.49.24.45 (SquirrelMail authenticated user delusion@delusion.com) by webmail.delusion.com with HTTP; Sun, 17 Apr 2005 16:05:21 -0700 (PDT) Message-ID: <4958.67.49.24.45.1113779121.spork@webmail.delusion.com> Date: Sun, 17 Apr 2005 16:05:21 -0700 (PDT) Subject: Re: Linux XFS write performance From: delusion@delusion.com To: "Michael Loftis" Cc: delusion@delusion.com, linux-xfs@oss.sgi.com User-Agent: DreamHost Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit References: Your message of "Sun, 17 Apr 2005 00:10:57 EST." <2ca133d205041622106b61c016@mail.gmail.com> <31874.1113718752@ocs3.ocs.com.au><2254.67.49.24.45.1113753740.spork@webmail.delusion.com> In-Reply-To: X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: delusion@delusion.com Precedence: bulk X-list: linux-xfs Content-Length: 1505 Lines: 37 The card is a PCI-X 133 although there is also a PCI-E 8x card. The PCI-E card uses a PCI-X 133 bus on the card so there shouldn't be much of a difference. The card supposedly can do the speeds but I haven't been able to get >Could you explain in more details what you have and what you are doing? 14 x WD raptors (73GB), 3.2GHz dual EMT64, 2GB, Supermicro motherboard. This is essentially a box that needs to backup data coming in over infiniband. The data will be written in 16mb files. >It depends, large streeam O_DIRECT writes to preallocated space is >probably worth experiementing with. I would also let mkfs.xfs know >about the underlying RAID topology and see if that helps. Thanks. Is opening files on the fly till a bit slow as it used to be on IRIX? Sounds like preallocating and opening is the best way to go then? Is there a fast way to preallocate in XFS (my xfs experience dates back a few years on irix and I need to catch up on what's been done since then). I did try sunit=256 and swidth=256*14 (I'm not testing raid 5/6 yet) but it didn't seem to help much. I also tried setting both to zero but it still didn't help. >600MB/s is a fair amount of bandwidth, you probably need 2x or 3x this >in the system to achieve this and depending on what you are doing that >might not even be enough --- more details? It's a fairly straightforward case... 16MB files all written sequentially. In this case, would it be better to use one thread for writing or multiple threads? Thanks. From owner-linux-xfs Sun Apr 17 16:29:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Apr 2005 16:29:52 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3HNToVH024547 for ; Sun, 17 Apr 2005 16:29:50 -0700 Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j3HNTplA004688 for ; Sun, 17 Apr 2005 19:29:51 -0400 X-ORBL: [67.124.119.21] Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j3HNTdxG068252; Sun, 17 Apr 2005 19:29:43 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 490FD115C859; Sun, 17 Apr 2005 16:29:39 -0700 (PDT) Date: Sun, 17 Apr 2005 16:29:39 -0700 From: Chris Wedgwood To: delusion@delusion.com Cc: Michael Loftis , linux-xfs@oss.sgi.com Subject: Re: Linux XFS write performance Message-ID: <20050417232939.GB12606@taniwha.stupidest.org> References: <2ca133d205041622106b61c016@mail.gmail.com> <4958.67.49.24.45.1113779121.spork@webmail.delusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4958.67.49.24.45.1113779121.spork@webmail.delusion.com> X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 2690 Lines: 69 On Sun, Apr 17, 2005 at 04:05:21PM -0700, delusion@delusion.com wrote: > The card is a PCI-X 133 although there is also a PCI-E 8x card. The > PCI-E card uses a PCI-X 133 bus on the card so there shouldn't be > much of a difference. The card supposedly can do the speeds but I > haven't been able to get I'm dubious that you can get 600MB/s on a single inexpensive card right now. I would try it on a raw partition and see how it performs for you to get some idea of the upper limit. This is hardware RAID right? What level? RAID-5 is going to be quit a bit slower. > 14 x WD raptors (73GB), 3.2GHz dual EMT64, 2GB, Supermicro > motherboard. FWIW on lesser hardware I can write 400MB/s across two controllers (each doing RAID-5, I assuming RAID-0 would be faster). > This is essentially a box that needs to backup data coming in over > infiniband. The data will be written in 16mb files. Can you actually sink 600MB/s over IB and also push that out over the bus to the controller? > Thanks. Is opening files on the fly till a bit slow as it used to be > on IRIX? It's not been overly slow or problematic for me. What problems are you seeing? > Sounds like preallocating and opening is the best way to go then? Is > there a fast way to preallocate in XFS (my xfs experience dates back > a few years on irix and I need to catch up on what's been done since > then). 'man xfsctl' for details on preallocation. AFAIK it's the same basic interface as what IRIX has used for many years. > I did try sunit=256 and swidth=256*14 (I'm not testing raid 5/6 yet) > but it didn't seem to help much. I also tried setting both to zero > but it still didn't help. I assume this is RAID-0 then? Are you sure 128K RAID chunks are optimal? When I was testing I was suprised to find that values over 32K actually were slower than smaller values. RAID-5 & 6 are going to be a *lot* slower for you I suspect (I doubt the card you are using has enough bandwidth or CPU to deal with the speed you are after with RAID 5 or 6 --- what doe the specs claim?) > It's a fairly straightforward case... 16MB files all written > sequentially. 16MB files are pretty small for this sort of IO rate. In fact, if they are all 16MBis in size --- why use a filesystem at all? > In this case, would it be better to use one thread for writing or > multiple threads? Some experimentation would probably be needed. I've found a small number of writing threads is faster than one but a larger number has no gain or is slower. It would be nice to try AIO + DIO but presently that doesn't work and I've not really had a chance to revisit fixing that (since apparently it will ge done eventually anyhow). From owner-linux-xfs Sun Apr 17 17:20:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Apr 2005 17:20:09 -0700 (PDT) Received: from webmail1.sd.dreamhost.com (webmail1.sd.dreamhost.com [66.33.201.159]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I0K8TO026992 for ; Sun, 17 Apr 2005 17:20:08 -0700 Received: from webmail.delusion.com (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with SMTP id C8A952C536; Sun, 17 Apr 2005 17:20:05 -0700 (PDT) Received: from 67.49.24.45 (SquirrelMail authenticated user delusion@delusion.com) by webmail.delusion.com with HTTP; Sun, 17 Apr 2005 17:20:05 -0700 (PDT) Message-ID: <1308.67.49.24.45.1113783605.spork@webmail.delusion.com> In-Reply-To: <20050417232939.GB12606@taniwha.stupidest.org> References: <2ca133d205041622106b61c016@mail.gmail.com> <4958.67.49.24.45.1113779121.spork@webmail.delusion.com> <20050417232939.GB12606@taniwha.stupidest.org> Date: Sun, 17 Apr 2005 17:20:05 -0700 (PDT) Subject: Re: Linux XFS write performance From: delusion@delusion.com To: "Chris Wedgwood" Cc: delusion@delusion.com, "Michael Loftis" , linux-xfs@oss.sgi.com User-Agent: DreamHost Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: delusion@delusion.com Precedence: bulk X-list: linux-xfs Content-Length: 2424 Lines: 66 > I'm dubious that you can get 600MB/s on a single inexpensive card > right now. I would try it on a raw partition and see how it performs > for you to get some idea of the upper limit. The 8port card seems to do fairly well but itremains to be seen if the 16port card can perform. The claim it can but not many people have used the card yet. > This is hardware RAID right? What level? RAID-5 is going to be quit > a bit slower. Raid 0 at first and then hopefully raid 5 or 6 (dual parity) at some point with more drives/cards. > FWIW on lesser hardware I can write 400MB/s across two controllers > (each doing RAID-5, I assuming RAID-0 would be faster). Which cards are you using? > Can you actually sink 600MB/s over IB and also push that out over the > bus to the controller? Mellanox claims they can get over 500MB/s with their SRP driver. 500MB/s if fine for me but I'd like to have the additional disk bandwidth. > It's not been overly slow or problematic for me. What problems are > you seeing? I hven't tested that fuly to know for sure yet. > 'man xfsctl' for details on preallocation. AFAIK it's the same basic > interface as what IRIX has used for many years. Thanks. > I assume this is RAID-0 then? Are you sure 128K RAID chunks are > optimal? When I was testing I was suprised to find that values over > 32K actually were slower than smaller values. I assumed 128 would be better but I'll try 32 and 64k next. > RAID-5 & 6 are going to be a *lot* slower for you I suspect (I doubt > the card you are using has enough bandwidth or CPU to deal with the > speed you are after with RAID 5 or 6 --- what doe the specs claim?) The specs are vague but the bandwidth tests on areca.us for the 8port card seems to do ok. I might actually be better off with two of the 8 port cards instead. > 16MB files are pretty small for this sort of IO rate. In fact, if > they are all 16MBis in size --- why use a filesystem at all? Agreed, although I need a filesystem for a number of other applications to access the data easily. > > Some experimentation would probably be needed. I've found a small > number of writing threads is faster than one but a larger number has > no gain or is slower. > > It would be nice to try AIO + DIO but presently that doesn't work and > I've not really had a chance to revisit fixing that (since apparently > it will ge done eventually anyhow). Thanks for the advice! From owner-linux-xfs Sun Apr 17 19:17:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Apr 2005 19:17:56 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I2HtY7030680 for ; Sun, 17 Apr 2005 19:17:55 -0700 Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j3I2Hi5K108200; Sun, 17 Apr 2005 22:17:48 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 616F5115C85B; Sun, 17 Apr 2005 19:17:43 -0700 (PDT) Date: Sun, 17 Apr 2005 19:17:43 -0700 From: Chris Wedgwood To: delusion@delusion.com Cc: Michael Loftis , linux-xfs@oss.sgi.com Subject: Re: Linux XFS write performance Message-ID: <20050418021743.GA29890@taniwha.stupidest.org> References: <2ca133d205041622106b61c016@mail.gmail.com> <4958.67.49.24.45.1113779121.spork@webmail.delusion.com> <20050417232939.GB12606@taniwha.stupidest.org> <1308.67.49.24.45.1113783605.spork@webmail.delusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1308.67.49.24.45.1113783605.spork@webmail.delusion.com> X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1732 Lines: 48 On Sun, Apr 17, 2005 at 05:20:05PM -0700, delusion@delusion.com wrote: > The 8port card seems to do fairly well but it remains to be seen if > the 16port card can perform. How did you test the 8-port card? What results did you get? > The claim it can but not many people have used the card yet. I couldn't find details on what the manufacturer claims the card can do. Do you have the URL? > Raid 0 at first and then hopefully raid 5 or 6 (dual parity) at some > point with more drives/cards. You realize RAID-5 is going to be slower for writes in many cases? (Large writes won't be so bad, but small writes can hurt). RAID-6 slower still. > Which cards are you using? I'm loathed to make recommendations on this hardware at present. But I think to get 200MB/s per card you can find several options. > Mellanox claims they can get over 500MB/s with their SRP driver. Sure. But to do something with that data you need to move it about twice or more usually. > 500MB/s if fine for me but I'd like to have the additional disk > bandwidth. So you suck in 500MB/s into main memory --- and write that out. That's 1GB/s of IO without any overhead. Can you realiably do that on your system? > I assumed 128 would be better but I'll try 32 and 64k next. For large writes it doesn't make much difference, but for smaller writes larger chunk sizes hurt more. You usually don't actually have that much control over the size of the writes that will be sent to the card from userspace (clearly you can influence this, but generally speaking writes will be fragmented and even at times reordered underneath you, and there is also the filesystem metadata updates to consider which are going to be small even for large writes). From owner-linux-xfs Sun Apr 17 19:58:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Apr 2005 19:58:05 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I2w4WO031675 for ; Sun, 17 Apr 2005 19:58:04 -0700 Received: by zproxy.gmail.com with SMTP id 8so313236nzo for ; Sun, 17 Apr 2005 19:57:58 -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=GJttDobuZdvmcgWJGmUCf22hI3MTRdEkcFji2mom8DWeVWM4rl8y37GpeMn4p0aeWH0vS3t8u2vovgsoU0vuktJDx7qVg+bByk2LrI3CSSB8v0oSv23wqJ+NMt5PgQq4KA/gLAY6+iwIhk3rayR7YIUN7HNXsF/7owr5VfXfGMo= Received: by 10.36.12.3 with SMTP id 3mr331431nzl; Sun, 17 Apr 2005 19:57:58 -0700 (PDT) Received: by 10.36.12.18 with HTTP; Sun, 17 Apr 2005 19:57:58 -0700 (PDT) Message-ID: <2ca133d2050417195766346604@mail.gmail.com> Date: Sun, 17 Apr 2005 21:57:58 -0500 From: KrishnaPradeep Tamma Reply-To: KrishnaPradeep Tamma To: linux-xfs@oss.sgi.com Subject: Check point block in log Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3I2w5WO031678 X-archive-position: 5314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krishnapradeep@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 127 Lines: 8 Hi, Does XFS write an explicit CHECK_POINT block in log or does it go through the whole log during recovery? Thanks Pradeep From owner-linux-xfs Sun Apr 17 22:05:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Apr 2005 22:05:59 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3I55uti005813 for ; Sun, 17 Apr 2005 22:05:57 -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 PAA07148; Mon, 18 Apr 2005 15:05:48 +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 j3I55ikt448857; Mon, 18 Apr 2005 15:05:45 +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 j3I50R5J001816; Mon, 18 Apr 2005 15:00:27 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j3I50N0q001813; Mon, 18 Apr 2005 15:00:23 +1000 Date: Mon, 18 Apr 2005 15:00:23 +1000 From: Nathan Scott To: Ian Westmacott , "Thomas J. Teixeira" Cc: linux-xfs Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files Message-ID: <20050418050023.GD721@frodo> References: <1113594280.9697.103.camel@vishambu.intellivid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1113594280.9697.103.camel@vishambu.intellivid.com> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5315 X-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: 1220 Lines: 33 Hi there, On Fri, Apr 15, 2005 at 03:44:41PM -0400, Thomas J. Teixeira wrote: > Resending this since it didn't seem to go through the first time -- I'm > looking for kernel diagnostic tools. KDB is the tool we use for this sort of work. Get it from XFS CVS, where there is also XFS extensions for interpreting and dumping out XFS specific data structures. The current CVS revision is unlikely to work on 2.6.6 though, since its moved on from then, but you may be able to coerce CVS into extracting the right version if you must use 2.6.6. Your post reminded me of another fix - if you are on 2.6.6 you will likely not have this... (see xfs_aops.c CVS revision history) date: 2004/09/30 01:37:19; author: nathans; state: Exp; lines: +19 -12 modid: xfs-linux-melb:xfs-kern:19622a Fix sync issues - use correct writepage page re-dirty interface, and do not clear dirty flag if page only partially written. IIRC, that was merged in 2.6.9 (but don't quote me on that, it was awhile ago). This may well resolve the issue you're seeing, it resolved all the known data sync problems at the time, although there now seems to be a harder-to-hit issue that I'm working through with Rich and James. cheers. -- Nathan From owner-linux-xfs Mon Apr 18 00:33:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Apr 2005 00:33:23 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j3I7XKER023686 for ; Mon, 18 Apr 2005 00:33:21 -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 RAA08949; Mon, 18 Apr 2005 17:33:10 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j3I7X6kt452366; Mon, 18 Apr 2005 17:33: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 j3I7Rp5J002232; Mon, 18 Apr 2005 17:27:51 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id j3I7RohK002230; Mon, 18 Apr 2005 17:27:50 +1000 Date: Mon, 18 Apr 2005 17:27:50 +1000 From: Nathan Scott To: KrishnaPradeep Tamma Cc: linux-xfs@oss.sgi.com Subject: Re: Check point block in log Message-ID: <20050418072750.GC2090@frodo> References: <2ca133d2050417195766346604@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ca133d2050417195766346604@mail.gmail.com> User-Agent: Mutt/1.5.3i X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5316 X-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: 351 Lines: 14 On Sun, Apr 17, 2005 at 09:57:58PM -0500, KrishnaPradeep Tamma wrote: > Hi, > > Does XFS write an explicit CHECK_POINT block in log or does it go > through the whole log during recovery? Hmm, neither of those really - it uses a binary chop type of algorithm to find the head and tail, and replays just that section of the log. cheers. -- Nathan From owner-linux-xfs Mon Apr 18 01:36:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Apr 2005 01:36:56 -0700 (PDT) Received: from boing.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3I8arjC032291 for ; Mon, 18 Apr 2005 01:36:54 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j3I8ahfE436525; Mon, 18 Apr 2005 18:36:43 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id j3I8agV2436615; Mon, 18 Apr 2005 18:36:42 +1000 (AEST) Date: Mon, 18 Apr 2005 18:36:42 +1000 From: Tim Shimmin To: KrishnaPradeep Tamma Cc: linux-xfs@oss.sgi.com Subject: Re: Check point block in log Message-ID: <20050418183642.U114500@boing.melbourne.sgi.com> References: <2ca133d2050417195766346604@mail.gmail.com> <20050418072750.GC2090@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050418072750.GC2090@frodo>; from nathans@sgi.com on Mon, Apr 18, 2005 at 05:27:50PM +1000 X-Virus-Scanned: ClamAV 0.83/836/Sun Apr 17 03:38:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5317 X-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: 2291 Lines: 49 Hi, On Mon, Apr 18, 2005 at 05:27:50PM +1000, Nathan Scott wrote: > On Sun, Apr 17, 2005 at 09:57:58PM -0500, KrishnaPradeep Tamma wrote: > > Hi, > > > > Does XFS write an explicit CHECK_POINT block in log or does it go > > through the whole log during recovery? > > Hmm, neither of those really - it uses a binary chop type of algorithm > to find the head and tail, and replays just that section of the log. > Elaborating a little more as I understand it... Every 512 byte block of the ondisk log has a cycle# stored in either the first word or the 2nd word (for the log record headers). Each time the log wraps with records written to it, the current cycle# is incremented. Log records are added/written to the head of the ondisk log each time internal log buffers get full (or are forced out) which happens as we initiate more metadata operations. As metadata is actually written to disk (the non-log part), the tail of the log can move forward. On recovery we then want to go thru all the outstanding metadata ops which never made it to disk and so we need to recover from the tail to the head. To find the head of the ondisk log it looks at the cycle#s of each block. For instance if we had cycle#s of 4,4,4,4,4,3,3,3,3,3 we would probably have a good idea of where it last finished writing to the ondisk log (just before the first 3 cycle # as we assume this is old data). However, it can get a bit more complicated than this. One such complication is that the log records are written out from a ring of log buffers and each of the log buffers can complete out of order compared with the order in which the writes were issued. i.e. we ask to be written bufA-cyc4 bufB-cyc4 bufC-cyc4 bufD-cyc4 but is is possible that bufB and bufD say finish just prior to the power being turned off. So we will see 3,4,3,4 on the disk during recovery. The binary search part comes in when we go searching for blocks with particular cycle#s. Look at xlog_find_head() for details. Finding the tail is done after finding the head. Every log record header contains the tail ptr as of the time the log record was issued to be written to disk. So to find the tail we scan back from the head to find the log record header and then use the h_tail_lsn field. I think that's the basic idea. --Tim From owner-linux-xfs Mon Apr 18 05:00:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Apr 2005 05:00:05 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IBxxR2021333 for ; Mon, 18 Apr 2005 05:00:02 -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 j3IBxuxT001504 for ; Mon, 18 Apr 2005 06:59:59 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3IBxtR06296165; Mon, 18 Apr 2005 06:59:55 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DNUuw-0004r7-00; Mon, 18 Apr 2005 06:59:54 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 907752 - xfsqa changes for gcc4 Message-Id: From: Christoph Hellwig Date: Mon, 18 Apr 2005 06:59:54 -0500 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1106 Lines: 27 Date: Mon Apr 18 04:58:42 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:191209a xfstests/src/bstat.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/bstat.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h - inode number passed to bulkstat should be unsigned xfstests/src/t_immutable.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/t_immutable.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - fix getuid() calls, we shouldn't check it's address for beeing non-zero xfstests/src/godown.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/godown.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - rename progname to something else, clashes with libxfs headers xfstests/src/writemod.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/writemod.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - include to get a prototype for strlen() From owner-linux-xfs Mon Apr 18 12:40:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Apr 2005 12:40:52 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3IJej9U032481 for ; Mon, 18 Apr 2005 12:40:46 -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 j3ILKbwV020896 for ; Mon, 18 Apr 2005 14:20:47 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3IJeD0F13439202; Mon, 18 Apr 2005 14:40:13 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DNc6J-0006xH-00; Mon, 18 Apr 2005 14:40:07 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 907752 - check whether we actually have an rpm binary before lookin at its version Message-Id: From: Christoph Hellwig Date: Mon, 18 Apr 2005 14:40:07 -0500 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1831 Lines: 32 Date: Mon Apr 18 12:39:36 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-cmds Inspected by: hch@engr The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:191248a acl/aclocal.m4 - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/aclocal.m4.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h attr/m4/package_utilies.m4 - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/m4/package_utilies.m4.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h acl/m4/package_utilies.m4 - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/m4/package_utilies.m4.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h attr/aclocal.m4 - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/aclocal.m4.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h dmapi/m4/package_utilies.m4 - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/m4/package_utilies.m4.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h dmapi/aclocal.m4 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/aclocal.m4.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/m4/package_utilies.m4 - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/m4/package_utilies.m4.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsprogs/aclocal.m4 - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/aclocal.m4.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsdump/aclocal.m4 - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/aclocal.m4.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsdump/m4/package_utilies.m4 - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/package_utilies.m4.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h - check whether we actually have an rpm binary before lookin at its version From owner-linux-xfs Mon Apr 18 14:48:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Apr 2005 14:48:28 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3ILmQYZ007108 for ; Mon, 18 Apr 2005 14:48:27 -0700 Received: by rproxy.gmail.com with SMTP id r35so1221121rna for ; Mon, 18 Apr 2005 14:48:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FOkr1oGZtt8HPLb5354+pl4p/2MzNjSgqqaaenLrLi0FYapo1tH7N6zFVjWlt4K0XndIHFsDjgY0mqVMH6MhG1K5qQiE88BbpNHS6Ek5jgK00Kg0Q1W+wgZhfHOJ4H/1PglZ2ABrRaCg/pSpEwvCeF4ZVWDhqz0gERKmqAf84xY= Received: by 10.38.160.51 with SMTP id i51mr5583324rne; Mon, 18 Apr 2005 14:48:26 -0700 (PDT) Received: by 10.38.98.42 with HTTP; Mon, 18 Apr 2005 14:48:26 -0700 (PDT) Message-ID: Date: Mon, 18 Apr 2005 17:48:26 -0400 From: Leo Qiu Reply-To: Leo Qiu To: linux-xfs@oss.sgi.com Subject: xfs_check out of memory Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3ILmRYZ007110 X-archive-position: 5320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: leo.qiu@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 512 Lines: 16 Hi, I am using xfs_check (version 2.6.25) for my 760MB xfs file system and get an out of memory error. I looked through the source code and found that in init() function in the check.c, it tries to allocate many big buffers for inomap and dbmap for each allocation group. In my case, it tries to allocate about about 6MB for dbmap and 24MB for inomap for each of my 32 allocation groups. After 30 rounds of that, the program complains the memory problem. Has anyone seen the simliar issue? Thank you. Leo From owner-linux-xfs Mon Apr 18 16:23:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Apr 2005 16:23:50 -0700 (PDT) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3INNmrU016123 for ; Mon, 18 Apr 2005 16:23:48 -0700 Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j3INNkcm021004 for ; Mon, 18 Apr 2005 19:23:46 -0400 X-ORBL: [67.124.119.21] Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j3INNlxG097468; Mon, 18 Apr 2005 19:23:47 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id B2F24115C869; Mon, 18 Apr 2005 16:23:46 -0700 (PDT) Date: Mon, 18 Apr 2005 16:23:46 -0700 From: Chris Wedgwood To: Leo Qiu Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_check out of memory Message-ID: <20050418232346.GA11798@taniwha.stupidest.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 279 Lines: 8 On Mon, Apr 18, 2005 at 05:48:26PM -0400, Leo Qiu wrote: > Hi, I am using xfs_check (version 2.6.25) for my 760MB xfs file > system and get an out of memory error. How much memory/swap do you have? For large filesystems xfs_check and xfs_repair need a good amount of memory. From owner-linux-xfs Mon Apr 18 17:33:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Apr 2005 17:33:45 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J0XgcT019003 for ; Mon, 18 Apr 2005 17:33:43 -0700 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j3J0XamZ002845 for ; Tue, 19 Apr 2005 10:33:36 +1000 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j3J0XaAk002843 for linux-xfs@oss.sgi.com; Tue, 19 Apr 2005 10:33:36 +1000 Date: Tue, 19 Apr 2005 10:33:36 +1000 From: Nathan Scott Message-Id: <200504190033.j3J0XaAk002843@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 932952 - xfsprogs X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 11862 Lines: 164 Merge back kernel changes into libxfs, mainly endian stuff. Date: Tue Apr 19 10:32:48 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: hch@engr.sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22256a xfsprogs/db/bmap.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/bmap.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/db/dir2.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/dir2.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/db/sb.c - 1.15 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/sb.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/db/inode.c - 1.15 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/inode.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/db/init.c - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/init.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/db/frag.c - 1.15 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/frag.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/db/check.c - 1.26 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/check.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h xfsprogs/mkfs/xfs_mkfs.c - 1.63 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h xfsprogs/logprint/logprint.c - 1.15 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/logprint/logprint.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/logprint/log_misc.c - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/logprint/log_misc.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/libxlog/xfs_log_recover.c - 1.28 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxlog/xfs_log_recover.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfsprogs/libxlog/util.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxlog/util.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/xfs_log.h - 1.19 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_log.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsprogs/include/xfs_ialloc.h - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_ialloc.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/xfs_ag.h - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_ag.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/include/xfs_buf_item.h - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_buf_item.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/include/xfs_log_priv.h - 1.19 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_log_priv.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsprogs/include/xfs_sb.h - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_sb.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/include/xfs_dir2_block.h - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2_block.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/xfs_arch.h - 1.15 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_arch.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/include/libxfs.h - 1.37 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h xfsprogs/include/xfs_ialloc_btree.h - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_ialloc_btree.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/libxlog.h - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxlog.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/include/xfs_bmap_btree.h - 1.14 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_bmap_btree.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/include/xfs_dir2_sf.h - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2_sf.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/include/xfs_dir_leaf.h - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir_leaf.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/xfs_mount.h - 1.45 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_mount.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h xfsprogs/include/xfs_dir2_data.h - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2_data.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/include/xfs_inode.h - 1.39 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_inode.h.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h xfsprogs/include/xfs_dir2_leaf.h - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2_leaf.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/include/xfs_attr_leaf.h - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_attr_leaf.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/xfs_types.h - 1.25 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_types.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h xfsprogs/include/xfs_trans.h - 1.18 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_trans.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/include/xfs_dir_sf.h - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir_sf.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/include/xfs_alloc.h - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_alloc.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/xfs_quota.h - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_quota.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/include/xfs_dir2.h - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/include/xfs_dinode.h - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dinode.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/repair/phase6.c - 1.19 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase6.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsprogs/repair/phase7.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase7.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/repair/dir2.c - 1.16 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/dir2.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/repair/sb.c - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/sb.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/repair/dir.c - 1.15 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/dir.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/repair/phase4.c - 1.14 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase4.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/repair/dinode.c - 1.19 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/dinode.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsprogs/repair/phase5.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase5.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/repair/agheader.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/agheader.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/repair/versions.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/versions.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/repair/xfs_repair.c - 1.18 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/xfs_repair.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/repair/incore.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/incore.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsprogs/repair/scan.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/scan.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/repair/attr_repair.c - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/attr_repair.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/libxfs/xfs_ialloc.c - 1.21 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_ialloc.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h xfsprogs/libxfs/rdwr.c - 1.23 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/rdwr.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h xfsprogs/libxfs/xfs_da_btree.c - 1.26 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_da_btree.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h xfsprogs/libxfs/xfs.h - 1.42 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs.h.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h xfsprogs/libxfs/trans.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/trans.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/libxfs/xfs_dir2_block.c - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir2_block.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/libxfs/xfs_dir.c - 1.16 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/libxfs/xfs_rtalloc.c - 1.15 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_rtalloc.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/libxfs/xfs_ialloc_btree.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_ialloc_btree.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/libxfs/xfs_dir2_sf.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir2_sf.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/libxfs/xfs_dir_leaf.c - 1.16 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir_leaf.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/libxfs/xfs_mount.c - 1.20 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_mount.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsprogs/libxfs/xfs_btree.c - 1.14 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_btree.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/libxfs/xfs_dir2_data.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir2_data.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/libxfs/xfs_inode.c - 1.28 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_inode.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfsprogs/libxfs/xfs_dir2_leaf.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir2_leaf.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/libxfs/xfs_attr_leaf.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_attr_leaf.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/libxfs/util.c - 1.14 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/util.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/libxfs/xfs_alloc.c - 1.23 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_alloc.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h xfsprogs/libxfs/xfs_bmap.c - 1.25 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_bmap.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h xfsprogs/libxfs/xfs_alloc_btree.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_alloc_btree.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/libxfs/xfs_dir2_node.c - 1.18 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir2_node.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/copy/xfs_copy.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/copy/xfs_copy.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/logprint/log_dump.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/logprint/log_dump.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs Mon Apr 18 20:44:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Apr 2005 20:44:39 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J3iadL005208 for ; Mon, 18 Apr 2005 20:44:37 -0700 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j3J3iRPg018188; Tue, 19 Apr 2005 13:44:27 +1000 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j3J3iR2S018186; Tue, 19 Apr 2005 13:44:27 +1000 Date: Tue, 19 Apr 2005 13:44:27 +1000 From: Nathan Scott Message-Id: <200504190344.j3J3iR2S018186@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: TAKE 934516 - allocsize mount option X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 596 Lines: 17 Allow initial XFS delayed allocation size to be increased beyond 64KB. Date: Tue Apr 19 13:43:45 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: gwehrman@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22261a xfs_vfsops.c - 1.465 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.465&r2=text&tr2=1.464&f=h xfs_mount.h - 1.196 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.196&r2=text&tr2=1.195&f=h From owner-linux-xfs Mon Apr 18 22:54:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Apr 2005 22:54:52 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J5snBw009267 for ; Mon, 18 Apr 2005 22:54:50 -0700 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j3J5scOf019919; Tue, 19 Apr 2005 15:54:38 +1000 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j3J5sbEd019917; Tue, 19 Apr 2005 15:54:37 +1000 Date: Tue, 19 Apr 2005 15:54:37 +1000 From: Nathan Scott Message-Id: <200504190554.j3J5sbEd019917@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: PARTIAL TAKE 932952 - libxcmd.a X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4605 Lines: 80 Move common utility code into a libxcmd.a to ease sharing amongst multiple (current and future) tools that don't need the relatively heavyweight libxfs.a. Date: Tue Apr 19 15:50:38 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22271a xfsprogs/libxcmd/quit.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxquit.c xfsprogs/libxcmd/projects.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxprojects.c xfsprogs/libxcmd/paths.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxpaths.c xfsprogs/libxcmd/input.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxinput.c xfsprogs/libxcmd/help.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxhelp.c xfsprogs/libxcmd/command.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxcommand.c xfsprogs/libxcmd/Makefile - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxMakefile xfsprogs/include/project.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/project.h xfsprogs/include/path.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/path.h xfsprogs/include/input.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/input.h xfsprogs/include/command.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/command.h xfsprogs/Makefile - 1.23 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/Makefile.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h xfsprogs/doc/README.LVM - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/README.LVM.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsprogs/doc/Makefile - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/Makefile.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/doc/README.quota - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/README.quota.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/growfs/xfs_growfs.c - 1.20 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/growfs/xfs_growfs.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsprogs/growfs/Makefile - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/growfs/Makefile.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/include/Makefile - 1.23 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/Makefile.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h xfsprogs/include/builddefs.in - 1.42 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/builddefs.in.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h xfsprogs/growfs/explore.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/growfs/explore.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsprogs/growfs/explore.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/growfs/explore.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h xfsprogs/io/command.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/command.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/io/command.h - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/command.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/io/input.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/input.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsprogs/io/Makefile - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/Makefile.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/io/quit.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/quit.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsprogs/io/help.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/help.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsprogs/io/input.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/input.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/io/init.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/init.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsprogs/io/open.c - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/open.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/io/init.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/init.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/io/io.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/io.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsprogs/io/attr.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/attr.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h From owner-linux-xfs Mon Apr 18 23:14:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Apr 2005 23:14:30 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J6ERin011365 for ; Mon, 18 Apr 2005 23:14:28 -0700 Received: from chook.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by chook.melbourne.sgi.com (8.12.11/8.12.11) with ESMTP id j3J6EFr1020588; Tue, 19 Apr 2005 16:14:15 +1000 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.12.11/8.12.11/Submit) id j3J6EEoZ020586; Tue, 19 Apr 2005 16:14:14 +1000 Date: Tue, 19 Apr 2005 16:14:14 +1000 From: Nathan Scott Message-Id: <200504190614.j3J6EEoZ020586@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: PARTIAL TAKE 932952 - xfs_quota X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2429 Lines: 53 Initial version of xfs quota utility. Knows how to do user/group/project quota, provides missing freespace reporting for realtime on Linux, and for project quotas. Allows all current and future XFS quota functionality to be exposed without complicating the standard quota tools. Not yet enabled in the build, some further QA work to be done before then, but its functional now. We'll bump the xfsprogs version when its enabled, there's a few other odds and ends to come before that. Date: Tue Apr 19 16:07:45 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:22274a xfsprogs/quota/Makefile - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/Makefile xfsprogs/quota/darwin.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/darwin.c xfsprogs/quota/edit.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/edit.c xfsprogs/quota/free.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/free.c xfsprogs/quota/freebsd.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/freebsd.c xfsprogs/quota/init.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/init.c xfsprogs/quota/init.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/init.h xfsprogs/quota/irix.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/irix.c xfsprogs/quota/linux.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/linux.c xfsprogs/quota/path.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/path.c xfsprogs/quota/project.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/project.c xfsprogs/quota/quot.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/quot.c xfsprogs/quota/quota.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/quota.c xfsprogs/quota/quota.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/quota.h xfsprogs/quota/report.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/report.c xfsprogs/quota/state.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/state.c xfsprogs/quota/util.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/util.c From owner-linux-xfs Tue Apr 19 00:34:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Apr 2005 00:34:09 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J7Y1bW017484 for ; Tue, 19 Apr 2005 00:34:01 -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 j3J9DwAY001724 for ; Tue, 19 Apr 2005 02:14:08 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3J7XT0F13472230; Tue, 19 Apr 2005 02:33:29 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DNnEe-0001pF-00; Tue, 19 Apr 2005 02:33:28 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 934520 - fix obj_to_handle on 64bit, Big Endian systems Message-Id: From: Christoph Hellwig Date: Tue, 19 Apr 2005 02:33:28 -0500 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 869 Lines: 23 Date: Tue Apr 19 00:33:02 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-cmds Inspected by: wkendall The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:191270a xfsprogs/VERSION - 1.123 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h - bump to 2.6.29 xfsprogs/doc/CHANGES - 1.167 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.167&r2=text&tr2=1.166&f=h - document recent changes xfsprogs/libhandle/handle.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libhandle/handle.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h - use a temporary 32bit variable in obj_to_handle to avoid scambling over the wrong half of a size_t pointer From owner-linux-xfs Tue Apr 19 00:53:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Apr 2005 00:53:22 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3J7rF6c018954 for ; Tue, 19 Apr 2005 00:53:16 -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 j3J9XCWS007215 for ; Tue, 19 Apr 2005 02:33:23 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3J7phR06354418; Tue, 19 Apr 2005 02:51:44 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1DNnWI-00021b-00; Tue, 19 Apr 2005 02:51:42 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 934523 - extract major number directly from struct stat in xfsdump Message-Id: From: Christoph Hellwig Date: Tue, 19 Apr 2005 02:51:42 -0500 X-Virus-Scanned: ClamAV 0.83/837/Sun Apr 17 08:25:32 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 566 Lines: 16 Date: Tue Apr 19 00:50:46 PDT 2005 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-cmds Inspected by: felixb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:191271a xfsdump/common/drive_scsitape.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/drive_scsitape.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h - avoid converting a struct stat to an xfs_bstat_t and doing macro magic to get the Linux major number again, just call major on the statbuf. From owner-linux-xfs Tue Apr 19 08:05:38 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Apr 2005 08:05:39 -0700 (PDT) Received: from cirse.extra.cea.fr (cirse.extra.cea.fr [132.166.172.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JF5YdE021519 for ; Tue, 19 Apr 2005 08:05:37 -0700 Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by cirse.extra.cea.fr (8.12.10/8.12.10/CEAnet-Internet.4.0) with ESMTP id j3JF5Sep011122 for ; Tue, 19 Apr 2005 17:05:29 +0200 (MEST) Received: from pisaure.intra.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Tue, 19 Apr 2005 17:05:28 +0200 Received: from nenuphar.saclay.cea.fr (nenuphar.saclay.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.12.11/8.12.11) with ESMTP id j3JF4O3D001108 for ; Tue, 19 Apr 2005 17:04:24 +0200 (envelope-from degremont@ocre.cea.fr) Received: from ocre.cea.fr ([132.165.65.70]) by nenuphar.saclay.cea.fr (8.12.10/8.12.10/CEAnet-internes.4.0) with ESMTP id j3JF5RZa027143 for ; Tue, 19 Apr 2005 17:05:27 +0200 (MEST) Message-ID: <42651E37.309@ocre.cea.fr> Date: Tue, 19 Apr 2005 17:05:27 +0200 From: Aurelien Degremont - Stagiaire User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: vfs_altfsid & dm_fsid Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: degremont@ocre.cea.fr Precedence: bulk X-list: linux-xfs Content-Length: 925 Lines: 27 Hello, Still trying to figure out the dmapi/xfs code, here is my new problem :). I wonder what should be set in dmfsid (dm_inode_to_fh/dm_fh_to_inode in dmapiops) field. This is my guess : In XFS, this value is filled with the vfs_altfsid which seems to be an unique ID (for the XFS file system on this machine) set up at filesystem creation. The other filesystems (especially ext3) do not seem to own an equivalent value. (If right, in your opinion, what could be used instead ? ) What are the precise constrains of this field, for DMAPI ? Apparently, it is used to identify each filesystem registered on DMAPI, whatever its filesystem type is. So how find a unique ID if sereval filesystems (not partitions) are used ? More explanation about dmapi_kern.h stuff would be greatly appreciated :) (I've understood the global system but the details, especially the constrains aren't explained) TIA. Aurélien From owner-linux-xfs Tue Apr 19 08:14:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Apr 2005 08:14:07 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JFDutH031432 for ; Tue, 19 Apr 2005 08:13:56 -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 j3JGrt8k001035 for ; Tue, 19 Apr 2005 09:54:06 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3JFCOR06375648; Tue, 19 Apr 2005 10:12:25 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id AD23C4FE57; Tue, 19 Apr 2005 10:12:24 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: vfs_altfsid & dm_fsid Date: Tue, 19 Apr 2005 10:12:24 -0500 From: Dean Roehrich Message-Id: <20050419151224.AD23C4FE57@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 831 Lines: 25 >From: Aurelien Degremont - Stagiaire >Hello, > >Still trying to figure out the dmapi/xfs code, here is my new problem :). > >I wonder what should be set in dmfsid (dm_inode_to_fh/dm_fh_to_inode in >dmapiops) field. >This is my guess : >In XFS, this value is filled with the vfs_altfsid which seems to be an >unique ID (for the XFS file system on this machine) set up at filesystem >creation. The other filesystems (especially ext3) do not seem to own an >equivalent value. (If right, in your opinion, what could be used instead ? ) You need a unique ID for each filesystem. Things like JFS and ReiserFS also havee this unique ID, if I remember correct. >More explanation about dmapi_kern.h stuff would be greatly appreciated Just ask. To which filesystem are you porting the DMAPI code? Dean From owner-linux-xfs Tue Apr 19 12:43:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Apr 2005 12:43:42 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JJhccT018625 for ; Tue, 19 Apr 2005 12:43:41 -0700 Received: by rproxy.gmail.com with SMTP id r35so37792rna for ; Tue, 19 Apr 2005 12:43:38 -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=MhcXBhi3uZpIrgZovDzf40kZPbdJdXOFdycuMEctBecB7OfzgY0Oss4VM5wasjX2SLr1v/2AmtAdGz4fb+Vtyyliw1GqNRhazpK6QCeiUHhw8N68icNkOWqEGBjcGNKzyJARF1yU+n76nwyi2cF4c/vrf2Vn6BXtx9/bdXjxK/8= Received: by 10.38.125.45 with SMTP id x45mr149259rnc; Tue, 19 Apr 2005 12:43:38 -0700 (PDT) Received: by 10.38.98.42 with HTTP; Tue, 19 Apr 2005 12:43:38 -0700 (PDT) Message-ID: Date: Tue, 19 Apr 2005 15:43:38 -0400 From: Leo Qiu Reply-To: Leo Qiu To: Chris Wedgwood Subject: Re: xfs_check out of memory Cc: linux-xfs@oss.sgi.com In-Reply-To: <20050418232346.GA11798@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050418232346.GA11798@taniwha.stupidest.org> X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3JJhfcT018631 X-archive-position: 5332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: leo.qiu@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 692 Lines: 22 I have 16GB of memory and only 200MB of swap. At the time I am doing xfs_check, there is 15966488K memory free. I think the problem is probably that my kernel has 3GB reserved for kernel space and 1GB for process space, and xfs_check tries to exceed this limit. Does xfs_check have to allocate all that much memory at the initialization? Leo On 4/18/05, Chris Wedgwood wrote: > On Mon, Apr 18, 2005 at 05:48:26PM -0400, Leo Qiu wrote: > > > Hi, I am using xfs_check (version 2.6.25) for my 760MB xfs file > > system and get an out of memory error. > > How much memory/swap do you have? For large filesystems xfs_check and > xfs_repair need a good amount of memory. > From owner-linux-xfs Tue Apr 19 12:57:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Apr 2005 12:57:20 -0700 (PDT) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JJv8Pi019317 for ; Tue, 19 Apr 2005 12:57:19 -0700 Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j3JJv5cm016116 for ; Tue, 19 Apr 2005 15:57:06 -0400 X-ORBL: [67.124.119.21] Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j3JJv6xG059374; Tue, 19 Apr 2005 15:57:06 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 08F8C115C85A; Tue, 19 Apr 2005 12:57:06 -0700 (PDT) Date: Tue, 19 Apr 2005 12:57:05 -0700 From: Chris Wedgwood To: Leo Qiu Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_check out of memory Message-ID: <20050419195705.GB32032@taniwha.stupidest.org> References: <20050418232346.GA11798@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 734 Lines: 21 On Tue, Apr 19, 2005 at 03:43:38PM -0400, Leo Qiu wrote: > I think the problem is probably that my kernel has 3GB reserved for > kernel space and 1GB for process space, and xfs_check tries to > exceed this limit. unless your kernel is weird your process can allocate nearly 3GB of RAM w/o problems --- which should be plenty > Does xfs_check have to allocate all that much memory at the > initialization? probably not, but it would require some hacking and i'm not sure it's worth it i'm a bit lost, if you have plenty of memory free why you are getting out of memory with such a small filesystem when you get the out of memory error, where does it come from and what does it say? also, how much memory is it xfs_check using? From owner-linux-xfs Tue Apr 19 14:01:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Apr 2005 14:01:21 -0700 (PDT) Received: from smtp1.ActiveState.com (gw.activestate.com [209.17.183.249]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JL1KIC022265 for ; Tue, 19 Apr 2005 14:01:20 -0700 Received: from rock.activestate.com (rock.ActiveState.com [192.168.3.223]) by smtp1.ActiveState.com (8.12.10/8.12.10) with ESMTP id j3JL1End003672 for ; Tue, 19 Apr 2005 14:01:14 -0700 (envelope-from daves@activestate.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by rock.activestate.com (8.13.1/8.13.1) with ESMTP id j3JL1EGN011434 for ; Tue, 19 Apr 2005 14:01:14 -0700 Message-ID: <42657199.30808@activestate.com> Date: Tue, 19 Apr 2005 14:01:13 -0700 From: David Sparks Reply-To: daves@activestate.com User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfs_check out of memory References: <20050418232346.GA11798@taniwha.stupidest.org> In-Reply-To: <20050418232346.GA11798@taniwha.stupidest.org> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daves@activestate.com Precedence: bulk X-list: linux-xfs Content-Length: 302 Lines: 12 > How much memory/swap do you have? For large filesystems xfs_check and > xfs_repair need a good amount of memory. Not related to this issue, but it there a correlation between FS size and RAM needed to do a xfs_check / xfs_repair? ie What are the RAM requirements to check a 2TB fs? Thanks, ds From owner-linux-xfs Tue Apr 19 14:25:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Apr 2005 14:25:36 -0700 (PDT) Received: from mx2.tippett.com (mx2.tippett.com [64.81.248.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j3JLPYD2023759 for ; Tue, 19 Apr 2005 14:25:34 -0700 Received: from hermes.tippett.com (hermes.tippett.com [192.168.3.20]) by mx2.tippett.com (8.12.8/8.12.8) with ESMTP id j3JL90LX013431 for ; Tue, 19 Apr 2005 14:09:00 -0700 Received: from [192.168.3.62] (gangsta.tippett.com [192.168.3.62]) by hermes.tippett.com (SGI-8.12.5/8.12.5) with ESMTP id j3JLPUWa1561009 for ; Tue, 19 Apr 2005 14:25:30 -0700 (PDT) Message-ID: <42657615.9090404@tippett.com> Date: Tue, 19 Apr 2005 14:20:21 -0700 From: Christian Rice Reply-To: xian@tippett.com Organization: Tippett Studio User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsdump/restore on FC3 wacky Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (mx2.tippett.com [192.168.12.2]); Tue, 19 Apr 2005 14:09:00 -0700 (PDT) X-Scanned-By: MIMEDefang 2.48 on 192.168.12.2 X-Virus-Scanned: ClamAV 0.83/840/Mon Apr 18 18:42:09 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xian@tippett.com Precedence: bulk X-list: linux-xfs Content-Length: 4556 Lines: 111 I built my own xfsdump on a FC3 machine (xfsdump-2.2.25-1.x86_64.rpm), including the requisite parts, so that my system, which is otherwise a stock FC3 from the ISO images, has these rpms: acl-2.2.27-1.x86_64.rpm attr-2.4.19-1.x86_64.rpm dmapi-2.2.1-1.x86_64.rpm dmapi-devel-2.2.1-1.x86_64.rpm libacl-2.2.27-1.x86_64.rpm libacl-devel-2.2.27-1.x86_64.rpm libattr-2.4.19-1.x86_64.rpm libattr-devel-2.4.19-1.x86_64.rpm xfsdump-2.2.25-1.x86_64.rpm xfsprogs-2.6.25-1.x86_64.rpm xfsprogs-devel-2.6.25-1.x86_64.rpm When I dump, I use this commandline (given that an xfs filesystem has been made and mounted at /sdb3): cd /sdb3; xfsdump -J - /dev/sda3 | xfsrestore - . To begin, I get this: [root@oss1 sdb3]# xfsdump -J - /dev/sda3 | xfsrestore - . xfsdump: using file dump (drive_simple) strategy xfsdump: version 2.2.25 (dump format 3.0) - Running single-threaded xfsdump: level 0 dump of oss1:/ xfsdump: dump date: Tue Apr 19 05:20:09 2005 xfsdump: session id: 75451ada-227a-42ae-bd38-bc35e622d8cb xfsdump: session label: "" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 2.2.25 (dump format 3.0) - Running single-threaded xfsrestore: searching media for dump xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 4983425216 bytes xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: dumping directories xfsrestore: examining media file 0 xfsrestore: dump description: xfsrestore: hostname: oss1 xfsrestore: mount point: / xfsrestore: volume: /dev/sda3 xfsrestore: session time: Tue Apr 19 05:20:09 2005 xfsrestore: level: 0 xfsrestore: session label: "" xfsrestore: media label: "" xfsrestore: file system id: 75ff8216-52f3-4b49-89c9-a507416d800b xfsrestore: session id: 75451ada-227a-42ae-bd38-bc35e622d8cb xfsrestore: media id: 8448d841-6aa7-47bc-833b-e2adb0471859 xfsrestore: searching media for directory dump xfsrestore: reading directories xfsdump: dumping non-directory files xfsrestore: 14878 directories and 166918 entries processed xfsrestore: directory post-processing xfsrestore: WARNING: unable to set secure extended attribute for : No such file or directory (2) xfsrestore: restoring non-directory files xfsrestore: NOTE: ino 228 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 307774 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 307777 gen 1 not referenced: placing in orphanage xfsdump: WARNING: could not open regular file ino 307781 mode 0x000081ed: No such file or directory: not dum ped xfsdump: WARNING: could not get list of non-root attributes for nondir ino 307781: No such file or directory (2) xfsdump: WARNING: could not get list of root attributes for nondir ino 307781: No such file or directory (2) xfsdump: WARNING: could not get list of secure attributes for nondir ino 307781: No such file or directory ( 2) xfsdump: WARNING: could not open regular file ino 311097 mode 0x000081ed: No such file or directory: not dum ped xfsdump: WARNING: could not get list of non-root attributes for nondir ino 311097: No such file or directory (2) xfsdump: WARNING: could not get list of root attributes for nondir ino 311097: No such file or directory (2) xfsdump: WARNING: could not get list of secure attributes for nondir ino 311097: No such file or directory ( 2) xfsrestore: NOTE: ino 311100 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 359853 gen 2 not referenced: placing in orphanage xfsdump: WARNING: could not open regular file ino 379734 mode 0x0000816d: No such file or directory: not dum ped xfsdump: WARNING: could not get list of non-root attributes for nondir ino 379734: No such file or directory (2) xfsdump: WARNING: could not get list of root attributes for nondir ino 379734: No such file or directory (2) xfsdump: WARNING: could not get list of secure attributes for nondir ino 379734: No such file or directory ( 2) xfsrestore: NOTE: ino 381411 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 381443 gen 1 not referenced: placing in orphanage xfsrestore: NOTE: ino 381454 gen 1 not referenced: placing in orphanage and the list of orphanage files goes on for a total of 877 files, pretty much all executables. Anyone seen this before? From owner-linux-xfs@oss.sgi.com Wed Apr 27 06:57:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Apr 2005 06:58:03 -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 j3RDvs1O011917 for ; Wed, 27 Apr 2005 06:57:54 -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 j3RDvqxT027526 for ; Wed, 27 Apr 2005 08:57: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 j3RDvqR06913777 for ; Wed, 27 Apr 2005 08:57: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 j3RDvnaV41104083; Wed, 27 Apr 2005 08:57:49 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id j3RDvngc016813; Wed, 27 Apr 2005 08:57:49 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id j3RDvnWk016811; Wed, 27 Apr 2005 08:57:49 -0500 Date: Wed, 27 Apr 2005 08:57:49 -0500 From: Eric Sandeen Message-Id: <200504271357.j3RDvnWk016811@penguin.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 933362 - Fix up vnode tracing with quota enabled X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5087 X-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: 1013 Lines: 25 Fix up vnode tracing with quota enabled Date: Wed Apr 27 06:57:43 PDT 2005 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-clean Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:191669a linux-2.6/xfs_ksyms.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h linux-2.4/xfs_ksyms.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h - export vnode tracing f'ns for quota quota/Makefile-linux-2.4 - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/Makefile-linux-2.4.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h quota/Makefile-linux-2.6 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/Makefile-linux-2.6.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - define XFS_VNODE_TRACE for quota when tracing is enabled From owner-linux-xfs@oss.sgi.com Wed Apr 27 08:54:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Apr 2005 08:54:58 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RFsi1O020912 for ; Wed, 27 Apr 2005 08:54:44 -0700 Received: by rproxy.gmail.com with SMTP id r35so197283rna for ; Wed, 27 Apr 2005 08:54:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:reply-to:organization:to:subject:date:user-agent:mime-version:content-disposition:content-type:content-transfer-encoding:message-id; b=qFgEoDQaP8fZp1oVb0szuFT5Of8qc9hDh04A2b8FFxnHGylCEeVM/XFl6ianGIe4H2XFxXCmNBPnfSDLsJ9+uZW/1yqGJPB6KrSEVoHoLVhouXVsaXegBcUcv4U5eFRhXoyN985PQY0i39KkGuL/rVut1oZCbtqMYOUFKuTiEB0= Received: by 10.38.72.30 with SMTP id u30mr1131719rna; Wed, 27 Apr 2005 08:54:39 -0700 (PDT) Received: from ttrmsyedshabir.comodo.net ([203.101.41.151]) by mx.gmail.com with ESMTP id g2sm936789rne.2005.04.27.08.54.38; Wed, 27 Apr 2005 08:54:39 -0700 (PDT) From: Syed Shabir Zakiullah Reply-To: syed.shabir@gmail.com Organization: C.O.M.O.D.O To: linux-xfs@oss.sgi.com Subject: make error when xfsprogs-2.6.25 compiled on gcc-4.0 Date: Wed, 27 Apr 2005 21:24:29 +0530 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200504272124.29960.syed.shabir@gmail.com> X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5088 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: syed.shabir@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 589 Lines: 20 Hi, I faced some problems while compiling xfsprogs-2.6.25, I solved most of them by applying patch from fedora, But after changing db/sb.h with: extern const struct field *sb_flds; extern const struct field *sb_hfld; I am stuck with following error: field.c:290: error: initializer element is not constant field.c:290: error: (near initialization for 'ftattrtab[111].fmtstr') field.c:291: error: initializer element is not constant field.c:291: error: (near initialization for 'ftattrtab[111].subfld') can anyone help me in solving this compilation.. Thanks in Advance, Syed Shabir From owner-linux-xfs@oss.sgi.com Wed Apr 27 16:02:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Apr 2005 16:02:37 -0700 (PDT) Received: from smtp2.activestate.com (gw.activestate.com [209.17.183.249]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RN2T1O014064 for ; Wed, 27 Apr 2005 16:02:30 -0700 Received: from rock.activestate.com (rock.ActiveState.com [192.168.3.223]) by smtp2.activestate.com (8.12.11/8.12.11) with ESMTP id j3RN2R9p004370 for ; Wed, 27 Apr 2005 16:02:27 -0700 (envelope-from daves@activestate.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by rock.activestate.com (8.13.1/8.13.1) with ESMTP id j3RN2ROH030378 for ; Wed, 27 Apr 2005 16:02:27 -0700 Message-ID: <42701A02.1010604@activestate.com> Date: Wed, 27 Apr 2005 16:02:26 -0700 From: David Sparks Reply-To: daves@activestate.com User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: SAN resizing disk, no LVM X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5093 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daves@activestate.com Precedence: bulk X-list: linux-xfs Content-Length: 762 Lines: 24 I have a SAN that allows resizing of the logical disks it exports. Basically you can increase the size of a logical disk, refresh the linux driver and linux sees a bigger disk. I put a XFS fs directly on one of these logical disks (ie /dev/sdb, not /dev/sdb1). When I change the size of /dev/sdb I can use xfs_growfs to gain usage of the extra space without LVM. I have two questions: Is using /dev/sdb instead of /dev/sdb1 for a fs safe to do? (I've never read anything authoritative on this subject) Are there any known problems using any of the XFS tools (xfs_check, xfs_repair, xfs_fsr, xfs_growfs) on a fs that lives directly on a disk (ie /dev/sdb)? Are there and gotchas or other things I should be aware of by using a setup like this? TIA! ds From owner-linux-xfs@oss.sgi.com Wed Apr 27 16:16:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Apr 2005 16:16: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 j3RNGS1O015379 for ; Wed, 27 Apr 2005 16:16:29 -0700 Received: from mail.ocs.com.au (kao1.melbourne.sgi.com [134.14.55.179]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27913 for ; Thu, 28 Apr 2005 09:16:22 +1000 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id 6A772180092; Thu, 28 Apr 2005 09:16:12 +1000 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 47402707F8A; Thu, 28 Apr 2005 09:16:12 +1000 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 43DAE1000D8; Thu, 28 Apr 2005 09:16:12 +1000 (EST) X-Mailer: exmh version 2.6.3_20040314 03/14/2004 with nmh-1.0.4 From: Keith Owens To: daves@activestate.com Cc: linux-xfs@oss.sgi.com Subject: Re: SAN resizing disk, no LVM In-reply-to: Your message of "Wed, 27 Apr 2005 16:02:26 MST." <42701A02.1010604@activestate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Apr 2005 09:16:12 +1000 Message-ID: <21114.1114643772@ocs3.ocs.com.au> X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5095 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 991 Lines: 22 On Wed, 27 Apr 2005 16:02:26 -0700, David Sparks wrote: >I have a SAN that allows resizing of the logical disks it exports. >Basically you can increase the size of a logical disk, refresh the linux >driver and linux sees a bigger disk. > >I put a XFS fs directly on one of these logical disks (ie /dev/sdb, not >/dev/sdb1). When I change the size of /dev/sdb I can use xfs_growfs to >gain usage of the extra space without LVM. > >I have two questions: > >Is using /dev/sdb instead of /dev/sdb1 for a fs safe to do? (I've never >read anything authoritative on this subject) A block device is a block device is a ... It is safe, as long as no other tool tries to access /dev/sdb. In particular, if anything tries to partition /dev/sdb or to install a boot loader on /dev/sdb then it will overwrite the first superblock of the XFS partition. You are gaining a little extra space, at the risk that some other disk tool will accidentally destroy your filesystem. From owner-linux-xfs@oss.sgi.com Wed Apr 27 16:34:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Apr 2005 16:34:50 -0700 (PDT) Received: from smtp1.ActiveState.com (gw.activestate.com [209.17.183.249]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RNYf1O021229 for ; Wed, 27 Apr 2005 16:34:41 -0700 Received: from rock.activestate.com (rock.ActiveState.com [192.168.3.223]) by smtp1.ActiveState.com (8.12.10/8.12.10) with ESMTP id j3RNYcEw019230 for ; Wed, 27 Apr 2005 16:34:39 -0700 (envelope-from daves@activestate.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by rock.activestate.com (8.13.1/8.13.1) with ESMTP id j3RNYcVE030583 for ; Wed, 27 Apr 2005 16:34:38 -0700 Message-ID: <4270218E.80708@activestate.com> Date: Wed, 27 Apr 2005 16:34:38 -0700 From: David Sparks Reply-To: daves@activestate.com User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: SAN resizing disk, no LVM References: <21114.1114643772@ocs3.ocs.com.au> In-Reply-To: <21114.1114643772@ocs3.ocs.com.au> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5096 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daves@activestate.com Precedence: bulk X-list: linux-xfs Content-Length: 1118 Lines: 32 >>Is using /dev/sdb instead of /dev/sdb1 for a fs safe to do? (I've never >>read anything authoritative on this subject) > > > A block device is a block device is a ... It is safe, as long as no > other tool tries to access /dev/sdb. In particular, if anything tries > to partition /dev/sdb or to install a boot loader on /dev/sdb then it > will overwrite the first superblock of the XFS partition. You are > gaining a little extra space, at the risk that some other disk tool > will accidentally destroy your filesystem. The main idea is that LVM isn't required to resize the disk. A `xfs_growfs /mnt/sdb` is sufficient Is there a simple way to resize a partition with a fs inside it? I do appreciate the warning, I see this every time I load fdisk: Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) I tried to "correct" the invalid flag once and the fs was unmountable. It did get fixed from a xfs_repair but I don't know if there was any actual damage to the fs? It is only a test fs at the moment and mostly empty so there was no indication of data loss. Cheers, ds From owner-linux-xfs@oss.sgi.com Wed Apr 27 16:47:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Apr 2005 16:48:00 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3RNlo1O022986 for ; Wed, 27 Apr 2005 16:47:51 -0700 Received: from mail.ocs.com.au (kao1.melbourne.sgi.com [134.14.55.179]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA28921 for ; Thu, 28 Apr 2005 09:47:46 +1000 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id 7DF921800AA; Thu, 28 Apr 2005 09:47:33 +1000 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id E74E6707F8A; Thu, 28 Apr 2005 09:47:19 +1000 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id E3E521000D8; Thu, 28 Apr 2005 09:47:19 +1000 (EST) X-Mailer: exmh version 2.6.3_20040314 03/14/2004 with nmh-1.0.4 From: Keith Owens To: daves@activestate.com Cc: linux-xfs@oss.sgi.com Subject: Re: SAN resizing disk, no LVM In-reply-to: Your message of "Wed, 27 Apr 2005 16:34:38 MST." <4270218E.80708@activestate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Apr 2005 09:47:19 +1000 Message-ID: <22029.1114645639@ocs3.ocs.com.au> X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5097 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1667 Lines: 38 On Wed, 27 Apr 2005 16:34:38 -0700, David Sparks wrote: >>>Is using /dev/sdb instead of /dev/sdb1 for a fs safe to do? (I've never >>>read anything authoritative on this subject) >> >> >> A block device is a block device is a ... It is safe, as long as no >> other tool tries to access /dev/sdb. In particular, if anything tries >> to partition /dev/sdb or to install a boot loader on /dev/sdb then it >> will overwrite the first superblock of the XFS partition. You are >> gaining a little extra space, at the risk that some other disk tool >> will accidentally destroy your filesystem. > >The main idea is that LVM isn't required to resize the disk. A >`xfs_growfs /mnt/sdb` is sufficient > >Is there a simple way to resize a partition with a fs inside it? Resizing any partitition by increasing the end address is easy, as long as there is free space after the parttion being grown. Both parted and fdisk can change the end address, then you run xfs_growfs. Resizing by changing the start address is hard, all the data has to be moved. >I do appreciate the warning, I see this every time I load fdisk: > > Warning: invalid flag 0x0000 of partition table 4 will be corrected by >w(rite) > > >I tried to "correct" the invalid flag once and the fs was unmountable. >It did get fixed from a xfs_repair but I don't know if there was any >actual damage to the fs? It is only a test fs at the moment and mostly >empty so there was no indication of data loss. Your partition "correction" overwrote the first 512 bytes of the first XFS superblock. Fortunately xfs_repair can recover from that condition by using a backup superblock. From owner-linux-xfs@oss.sgi.com Wed Apr 27 16:50:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Apr 2005 16:50:17 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RNo11O023401 for ; Wed, 27 Apr 2005 16:50:04 -0700 Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j3RNmqqi132562; Wed, 27 Apr 2005 19:48:56 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id A4B4B115C85C; Wed, 27 Apr 2005 16:48:51 -0700 (PDT) Date: Wed, 27 Apr 2005 16:48:51 -0700 From: Chris Wedgwood To: David Sparks Cc: linux-xfs@oss.sgi.com Subject: Re: SAN resizing disk, no LVM Message-ID: <20050427234851.GA21340@taniwha.stupidest.org> References: <21114.1114643772@ocs3.ocs.com.au> <4270218E.80708@activestate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4270218E.80708@activestate.com> X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5098 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 243 Lines: 7 On Wed, Apr 27, 2005 at 04:34:38PM -0700, David Sparks wrote: > Is there a simple way to resize a partition with a fs inside it? not with the current linux partition code, it's not really desirable anyhow if you are using LVM i would argue From owner-linux-xfs@oss.sgi.com Wed Apr 27 16:52:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Apr 2005 16:52:49 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3RNqf1O024359 for ; Wed, 27 Apr 2005 16:52:41 -0700 Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j3RNpaqi156300; Wed, 27 Apr 2005 19:51:36 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 6888E115C85C; Wed, 27 Apr 2005 16:51:36 -0700 (PDT) Date: Wed, 27 Apr 2005 16:51:36 -0700 From: Chris Wedgwood To: Keith Owens Cc: daves@activestate.com, linux-xfs@oss.sgi.com Subject: Re: SAN resizing disk, no LVM Message-ID: <20050427235136.GC21340@taniwha.stupidest.org> References: <4270218E.80708@activestate.com> <22029.1114645639@ocs3.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22029.1114645639@ocs3.ocs.com.au> X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5099 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 458 Lines: 11 On Thu, Apr 28, 2005 at 09:47:19AM +1000, Keith Owens wrote: > Resizing any partitition by increasing the end address is easy, as > long as there is free space after the parttion being grown. Both > parted and fdisk can change the end address, then you run > xfs_growfs. Resizing by changing the start address is hard, all the > data has to be moved. the kernel won't notice partitions increasing in size if *any* parition on that disk in is use though From owner-linux-xfs@oss.sgi.com Wed Apr 27 19:12:41 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Apr 2005 19:12:50 -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 j3S2Cb1O032753 for ; Wed, 27 Apr 2005 19:12:38 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j3S3sAX9010955 for ; Wed, 27 Apr 2005 20:54:10 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3S2BYR06952981; Wed, 27 Apr 2005 21:11:34 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id A885C4FE57; Wed, 27 Apr 2005 21:11:33 -0500 (CDT) To: Aurelien Degremont - Stagiaire Cc: linux-xfs@oss.sgi.com Subject: Re: vfs_altfsid & dm_fsid Date: Wed, 27 Apr 2005 21:11:33 -0500 From: Dean Roehrich Message-Id: <20050428021133.A885C4FE57@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 00:00:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5101 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3074 Lines: 76 >From: Aurelien Degremont - Stagiaire >Dean Roehrich a écrit: >> We already know know that it's a mistake to rely on the fsid, and file >> handles, being persistent across remounts--the mkfs/restore thing. > >Ok, If you think so... In practice, they're basically consistent--until someone does a mkfs/restore. If your filesystem of choice doesn't have an fsid, then you could just generate one that is valid while the filesystem is mounted and is not written to the filesystem, or you could come up with something else. Whatever you choose for an fsid should fit into a 64-bit type. >> It's starting to get away from us now, isn't it? >> >> Maybe we could come back to vector thing later, but we could send the fsid a >s >> a parameter to dm_send_mount_event(), I think, and get rid of ->get_fsid(). > >No, I totally agree for removing the vector stuff and get_fsid. I think I was referring to the idea of having the vector passed as an argument to dm_send_mount_event(). I think maybe this would have to be done anyway, if the two ops vectors (struct filesystem_dmapi_operations and dm_fsys_vector_t) are unified. It's the only way I can see right now to get some of the necessary ops available early enough for an HSM to process the MOUNT event, given that there would be just one ops vector instead of two. So forget what I said about putting it off :) >I'd just wonder it whatever >will be left from the vector_map clean up could integrated in the fsreg >stuff... Maybe not, I haven't check. In thinking about this one again, the fsid is still the preferred key to what we know as the dm_fsreg_t list. That idea about switching to using the sb pointer value as the key won't fly in a distributed environment. >Could you try to sum up how and what improvements you see for all of >this ? How this will be done :) ? Okay, let's try any of these and see what falls out: 1) The fsid should be a parameter to dm_send_mount_event() and dm_send_namesp_event() and dm_send_unmount_event(). The get_fsid op in struct filesystem_dmapi_operations should be dropped. 2) The dm_fsys_vector_t should be folded into struct filesystem_dmapi_operations. The new ops vector should be a parameter to dm_send_mount_event(). The part where today we copy the ops vector from fsys_function_vector_t to dm_fsys_vector_t seems cumbersome and just makes things hard to understand, so maybe that copy should be skipped and some of these datatypes could be removed. The get_fsys_vector op in struct filesystem_dmapi_operations should be dropped. 3) It would be nice to keep in mind distributed filesystems and stackable filesystems; try to make it easier, not harder, to move in those directions. Unfortunately, I have no experience with the Linux view of stackable filesystems and I don't quite know how to approach that problem. 4) The new, unified, ops vector should be kept on a per-filesystem-instance basis, rather than one ops vector to be shared by all filesystems. Does that sum up the things that interest you? Dean From owner-linux-xfs@oss.sgi.com Thu Apr 28 08:32:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Apr 2005 08:32:26 -0700 (PDT) Received: from mailhost.intellivid.com (mailhost.intellivid.com [64.32.200.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SFWC1O021896 for ; Thu, 28 Apr 2005 08:32:12 -0700 Received: from [192.168.2.64] (vishambu.intellivid.com [192.168.2.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by newmail.intellivid.com (Postfix) with ESMTP id 82F5AF1817F for ; Thu, 28 Apr 2005 11:32:04 -0400 (EDT) Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files From: "Thomas J. Teixeira" Cc: linux-xfs In-Reply-To: <20050418050023.GD721@frodo> References: <1113594280.9697.103.camel@vishambu.intellivid.com> <20050418050023.GD721@frodo> Content-Type: text/plain Message-Id: <1114702323.4055.493.camel@vishambu.intellivid.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 28 Apr 2005 11:32:04 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/857/Wed Apr 27 23:30:10 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5104 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tjt@intellivid.com Precedence: bulk X-list: linux-xfs Content-Length: 2191 Lines: 47 On Mon, 2005-04-18 at 01:00, Nathan Scott wrote: > Your post reminded me of another fix - if you are on 2.6.6 you will > likely not have this... (see xfs_aops.c CVS revision history) > > date: 2004/09/30 01:37:19; author: nathans; state: Exp; lines: +19 -12 > modid: xfs-linux-melb:xfs-kern:19622a > Fix sync issues - use correct writepage page re-dirty interface, and do > not clear dirty flag if page only partially written. > > IIRC, that was merged in 2.6.9 (but don't quote me on that, it was > awhile ago). > > This may well resolve the issue you're seeing, it resolved all the > known data sync problems at the time, although there now seems to be > a harder-to-hit issue that I'm working through with Rich and James. Thanks for the pointer. We have installed a SuSE 9.1 update kernel version 2.6.5-7.147 that includes this patch and which works with the rest of our software. Preliminary testing shows this seems to resolve the lost data on reboot. We're seeing a different problem which we at first thought was unrelated, but just be a different symptom of the underlying problem. We are getting system hangs after several days of operation, typically 5 to 6 days. We don't have any information on most of these: the systems seemed to be responding to local network traffic, but not writing to disk, including syslog on the root file system which is ext3, not xfs. We did happen to be connected to one of our test systems and noticed it stopped writing to disk, and the syslogd was in disk wait (according to ps output). According to /proc/meminfo, there were lots of dirty pages (about 400M out of 1G, or ~ 40%), and running sync did not clean out these dirty pages. Looking at the kernel code, I can see where all writes will cease if the dirty pages exceeds /proc/sys/vm/dirty_ratio -- 40%, and this would prevent writes to _all_ filesystems regardless of which file system owns the dirty pages. My question is whether anyone recalls that a symptom of the bug fixed back in the 2.6.9 kernel was this growth in dirty pages. The checkin comment looks more as if the symptom was losing a dirty page bit rather than marking a page as dirty forever. Thanks again, - Tom From owner-linux-xfs@oss.sgi.com Thu Apr 28 08:58:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Apr 2005 08:58:56 -0700 (PDT) Received: from smtp805.mail.sc5.yahoo.com (smtp805.mail.sc5.yahoo.com [66.163.168.184]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3SFwl1O030946 for ; Thu, 28 Apr 2005 08:58:47 -0700 Received: from unknown (HELO ?127.0.0.1?) (scstafford@sbcglobal.net@67.64.68.158 with plain) by smtp805.mail.sc5.yahoo.com with SMTP; 28 Apr 2005 15:58:42 -0000 Message-ID: <4271082D.2050400@sbcglobal.net> Date: Thu, 28 Apr 2005 10:58:37 -0500 From: Stewart Stafford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: cvs server Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scstafford@sbcglobal.net Precedence: bulk X-list: linux-xfs Content-Length: 489 Lines: 16 Is the cvs server up? I am unable to update xfs-cmds. cvs [update aborted]: connect to oss.sgi.com(192.48.159.27):2401 failed: Connection refused I have also been having periodic problems with this mailing list. On or around April 19 I stopped receiving emails. I queried the mailing list to see if I was subscribed and apparently I dropped. I re-subscribed again, yet I am still not getting any emails. I am also posting this to see if it will help my problem. Thanks, Stew From owner-linux-xfs@oss.sgi.com Thu Apr 28 12:54:20 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Apr 2005 12:54:23 -0700 (PDT) Received: from smtp1.ActiveState.com (gw.activestate.com [209.17.183.249]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SJsK7J030531 for ; Thu, 28 Apr 2005 12:54:20 -0700 Received: from rock.activestate.com (rock.ActiveState.com [192.168.3.223]) by smtp1.ActiveState.com (8.12.10/8.12.10) with ESMTP id j3SJsGEb019595 for ; Thu, 28 Apr 2005 12:54:16 -0700 (envelope-from daves@activestate.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by rock.activestate.com (8.13.1/8.13.1) with ESMTP id j3SJsFk6011998 for ; Thu, 28 Apr 2005 12:54:15 -0700 Message-ID: <42713F67.6010905@activestate.com> Date: Thu, 28 Apr 2005 12:54:15 -0700 From: David Sparks Reply-To: daves@activestate.com User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: SAN resizing disk, no LVM References: <22029.1114645639@ocs3.ocs.com.au> In-Reply-To: <22029.1114645639@ocs3.ocs.com.au> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5106 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daves@activestate.com Precedence: bulk X-list: linux-xfs Content-Length: 601 Lines: 16 > Your partition "correction" overwrote the first 512 bytes of the first > XFS superblock. Fortunately xfs_repair can recover from that condition > by using a backup superblock. How big is the superblock? Was only the superblock damaged by "fixing" the partition table with fdisk? One could just rename fdisk on machines directly attached to the storage to prevent accidental damage. (very cheesy) The reason that I'm asking these questions is that LVM does not seem to work well with resizing of the physical disks -- you need to create a new physical volume and then add that in. Thanks, ds From owner-linux-xfs@oss.sgi.com Thu Apr 28 13:04:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Apr 2005 13:04:23 -0700 (PDT) Received: from mbe0.msomt.modwest.com (mbe0.msomt.modwest.com [216.220.25.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SK4I7J031110 for ; Thu, 28 Apr 2005 13:04:19 -0700 Received: from d216-220-25-60.dynip.modwest.com (d216-220-25-60.dynip.modwest.com [216.220.25.60]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mbe0.msomt.modwest.com (Postfix) with ESMTP id 280C766E60E; Thu, 28 Apr 2005 14:04:14 -0600 (MDT) Date: Thu, 28 Apr 2005 14:04:37 -0600 From: Michael Loftis To: daves@activestate.com, linux-xfs@oss.sgi.com Subject: Re: SAN resizing disk, no LVM Message-ID: <462FAD118A05AEC6D75F85F6@d216-220-25-60.dynip.modwest.com> In-Reply-To: <42713F67.6010905@activestate.com> References: <22029.1114645639@ocs3.ocs.com.au> <42713F67.6010905@activestate.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Modwest-MailScanner: Found to be clean X-MailScanner-From: mloftis@wgops.com X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5107 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 590 Lines: 27 --On Thursday, April 28, 2005 12:54 -0700 David Sparks wrote: > The reason that I'm asking these questions is that LVM does not seem to > work well with resizing of the physical disks -- you need to create a > new physical volume and then add that in. to be fair it's not LVM that's the problem, it's other kernel layers that are. Specifically the bits that deal with artitions and the in-kernel memory of partitions. they're not built for dynamic. > > Thanks, > > ds > > > -- GPG/PGP --> 0xE736BD7E 5144 6A2D 977A 6651 DFBE 1462 E351 88B9 E736 BD7E From owner-linux-xfs@oss.sgi.com Thu Apr 28 14:49:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Apr 2005 14:49:15 -0700 (PDT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3SLn97J006262 for ; Thu, 28 Apr 2005 14:49:10 -0700 Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j3SLn8YL007022 for ; Thu, 28 Apr 2005 17:49:08 -0400 X-ORBL: [67.124.119.21] Received: from taniwha.stupidest.org (adsl-67-124-119-21.dsl.snfc21.pacbell.net [67.124.119.21]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j3SLmx5Y151246; Thu, 28 Apr 2005 17:49:04 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id D9EF4115C869; Thu, 28 Apr 2005 14:48:58 -0700 (PDT) Date: Thu, 28 Apr 2005 14:48:58 -0700 From: Chris Wedgwood To: David Sparks Cc: linux-xfs@oss.sgi.com Subject: Re: SAN resizing disk, no LVM Message-ID: <20050428214858.GA5734@taniwha.stupidest.org> References: <22029.1114645639@ocs3.ocs.com.au> <42713F67.6010905@activestate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42713F67.6010905@activestate.com> X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5109 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 756 Lines: 22 On Thu, Apr 28, 2005 at 12:54:15PM -0700, David Sparks wrote: > How big is the superblock? 512 bytes usually (I guess with larger sector size it's sorta larger) > Was only the superblock damaged by "fixing" the partition table with > fdisk? I didn't read the original message, but if you use XFS on the device (not a partition) then fdisk and friends will break SB0. This is because XFS places the first super block right at the start of the disk (all other common Linux filesystems leave some space so this doesn't bite them). > One could just rename fdisk on machines directly attached to the > storage to prevent accidental damage. (very cheesy) Sounds like a better idea is to educate the sysadmins and failing that whip them with salty reeds. From owner-linux-xfs@oss.sgi.com Fri Apr 29 00:04:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Apr 2005 00:04:58 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3T74r7J025445 for ; Fri, 29 Apr 2005 00:04:54 -0700 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id CB73749A40A5; Fri, 29 Apr 2005 17:05:06 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 934923 - data corruption fix Message-Id: <20050429070506.CB73749A40A5@chook.melbourne.sgi.com> Date: Fri, 29 Apr 2005 17:05:06 +1000 (EST) From: nathans@chook.melbourne.sgi.com (Nathan Scott) X-Virus-Scanned: ClamAV 0.83/858/Thu Apr 28 07:02:38 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5111 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2921 Lines: 75 The combination of these mods gets us to the point that Rich Coe's and James Forris' test case now passes. The second mod is the most critical one, but anyone who has seen or suspects they've seen data corruption should use CVS (once it gets its refresh from the internal tree). BTW, I'll be away for four weeks, starting yesterday ;-), so I wont be able to followup on any questions on this (or anything else) until I'm back in the office. cheers. Do not do delalloc conversion on pages beyond EOF ever, not just sometimes. Date: Fri Apr 29 16:47:37 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22376a linux-2.6/xfs_aops.c - 1.85 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h linux-2.4/xfs_aops.c - 1.88 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.88&r2=text&tr2=1.87&f=h Use the right offset when ensuring a delayed allocate conversion has covered the offset originally requested. Can cause data corruption when multiple processes are performing writeout on different areas of the same file. Quite difficult to hit though. Date: Fri Apr 29 16:55:28 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: felixb@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22377a xfs_mount.h - 1.197 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.197&r2=text&tr2=1.196&f=h xfs_iomap.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfs_iomap.c - 1.32 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h linux-2.6/xfs_aops.c - 1.86 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.86&r2=text&tr2=1.85&f=h Cleanup use of loff_t vs xfs_off_t in the core code. Date: Fri Apr 29 16:56:50 AEST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:22378a xfs_dfrag.c - 1.46 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dfrag.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h xfs_mount.h - 1.198 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.198&r2=text&tr2=1.197&f=h xfs_iomap.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfs_iomap.c - 1.33 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h From owner-linux-xfs@oss.sgi.com Fri Apr 29 10:41:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Apr 2005 10:41:47 -0700 (PDT) Received: from listless.cs.ualberta.ca (listless.cs.ualberta.ca [129.128.29.250]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j3THff7J002581 for ; Fri, 29 Apr 2005 10:41:41 -0700 Received: (qmail 21836 invoked by uid 15017); 29 Apr 2005 17:41:36 -0000 Date: Fri, 29 Apr 2005 11:41:36 -0600 From: John Bartoszewski To: linux-xfs@oss.sgi.com Subject: Old XFS_GEOMETRY change Message-ID: <20050429174136.GA21813@ugrad.cs.ualberta.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.83/860/Fri Apr 29 06:45:14 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5117 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: johnb@ugrad.cs.ualberta.ca Precedence: bulk X-list: linux-xfs Content-Length: 433 Lines: 17 I think I've run into the problem listed here: http://oss.sgi.com/archives/linux-xfs/2002-09/msg00010.html Which is that the xfs file system was created with the old XFS_GEOMETRY ioctl and all the tools I have use the new XFS_GEOMETRY ioctl. Has someone written a conversion tool? Where do I find the old headers to rebuild the tools? Would something like 'old_xfsdump -l0 - /dev/hda2 | new_xfrestore - .' work? Thanks, John From owner-linux-xfs@oss.sgi.com Fri Apr 29 19:02:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Apr 2005 19:02:33 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3U22T7J000389 for ; Fri, 29 Apr 2005 19:02:30 -0700 Received: by wproxy.gmail.com with SMTP id 68so1275896wra for ; Fri, 29 Apr 2005 19:02:21 -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=GLkCLN3KD5m3YSdD7nOhCIGUL+kjrxRTJsWDKW7Ssw+ItGUBDekZ91sV69YydBXuE6clWDWZ9iSkzPYCUNxxW52vOypoK9hlfmAMxfQmQqT3rmF1In1PJiTc7/bp/gl67/H4G58lMpbjevx//faSdTSrr/jgKTd1l/otyk/I/DI= Received: by 10.54.83.1 with SMTP id g1mr2017337wrb; Fri, 29 Apr 2005 19:02:21 -0700 (PDT) Received: by 10.54.8.27 with HTTP; Fri, 29 Apr 2005 19:02:21 -0700 (PDT) Message-ID: Date: Sat, 30 Apr 2005 11:02:21 +0900 From: nova shin Reply-To: nova shin To: linux-xfs@oss.sgi.com Subject: How to know that file was closed in dmapi? Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/860/Fri Apr 29 06:45:14 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j3U22U7J000391 X-archive-position: 5118 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: novashine@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 501 Lines: 22 Does anybody here know how to detect that file was closed? I am a novice to DMAPI in Linux-XFS. I am trying to develop an application for HSM. Dmapi version is a dmapi-2.2.1-1. I read a docmunet for Dmapi. It said that dmapi have a file 'close' event. But I could not get any 'close' event from dmapi, especially when the 'create' operation was finished. Is it a my mistake? Or it is not supported? How should i know? Please let me know how to do that. Thanks a lot in advance. Regards, Nova From owner-linux-xfs@oss.sgi.com Fri Apr 29 19:13:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Apr 2005 19:13:13 -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 j3U2DA7J000890 for ; Fri, 29 Apr 2005 19:13:10 -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 j3U3svKb015026 for ; Fri, 29 Apr 2005 20:54:57 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3U2D3R07092722; Fri, 29 Apr 2005 21:13:03 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 54F2C4FE57; Fri, 29 Apr 2005 21:13:03 -0500 (CDT) To: nova shin Cc: linux-xfs@oss.sgi.com Subject: Re: How to know that file was closed in dmapi? Date: Fri, 29 Apr 2005 21:13:03 -0500 From: Dean Roehrich Message-Id: <20050430021303.54F2C4FE57@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV 0.83/860/Fri Apr 29 06:45:14 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5119 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 627 Lines: 31 We currently don't support the CLOSE event for XFS. Dean >From: nova shin >Does anybody here know how to detect that file was closed? > >I am a novice to DMAPI in Linux-XFS. >I am trying to develop an application for HSM. > >Dmapi version is a dmapi-2.2.1-1. > >I read a docmunet for Dmapi. >It said that dmapi have a file 'close' event. > >But I could not get any 'close' event from dmapi, especially when the >'create' operation was finished. > >Is it a my mistake? Or it is not supported? > >How should i know? >Please let me know how to do that. > >Thanks a lot in advance. >Regards, >Nova > > From owner-linux-xfs@oss.sgi.com Fri Apr 29 20:12:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Apr 2005 20:12:14 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3U3C87J003503 for ; Fri, 29 Apr 2005 20:12:08 -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 j3U4ruMT022478 for ; Fri, 29 Apr 2005 21:53:56 -0700 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j3U3B1R07096369; Fri, 29 Apr 2005 22:11:02 -0500 (CDT) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id B58B54FE57; Fri, 29 Apr 2005 22:11:01 -0500 (CDT) To: nova shin Cc: linux-xfs@oss.sgi.com Subject: Re: How to know that file was closed in dmapi? Date: Fri, 29 Apr 2005 22:11:01 -0500 From: Dean Roehrich Message-Id: <20050430031101.B58B54FE57@chewtoy.americas.sgi.com> X-Virus-Scanned: ClamAV 0.83/860/Fri Apr 29 06:45:14 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5120 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2023 Lines: 68 >From: nova shin >> We currently don't support the CLOSE event for XFS. > >Does it mean that there is no way to know when the 'create' was finished? The definition of the CLOSE event is unclear: http://www.opengroup.org/onlinepubs/9657099/chap3.htm#tagcjh_04_05_03 I don't see how it could have anything to do with the CREATE event or with the creation of a file. If the file is created with open(O_CREAT) then you might expect a CLOSE event when close() is called--but the spec doesn't say it has to be implemented that way. If 5 applications open() the file at the same time, and then one-by-one they close() the file, the CLOSE event could come on the last close() by the last application. Or, you could get a CLOSE event from each application as it closes the file. If one application opens the file 5 times and then does 5 closes you could get one CLOSE event on the last close or you could get 5 CLOSE events. The DMAPI spec really leaves this wide open. In my mind, the create is "finished" after the inode has been allocated and hooked up to the directory--so have you looked at the POSTCREATE event? http://www.opengroup.org/onlinepubs/9657099/chap3.htm#tagcjh_04_03_02 Dean >At all? >I'm not sure. > >On 4/30/05, Dean Roehrich wrote: >>=20 >> We currently don't support the CLOSE event for XFS. >>=20 >> Dean >>=20 >> >From: nova shin >> >Does anybody here know how to detect that file was closed? >> > >> >I am a novice to DMAPI in Linux-XFS. >> >I am trying to develop an application for HSM. >> > >> >Dmapi version is a dmapi-2.2.1-1. >> > >> >I read a docmunet for Dmapi. >> >It said that dmapi have a file 'close' event. >> > >> >But I could not get any 'close' event from dmapi, especially when the >> >'create' operation was finished. >> > >> >Is it a my mistake? Or it is not supported? >> > >> >How should i know? >> >Please let me know how to do that. >> > >> >Thanks a lot in advance. >> >Regards, >> >Nova >> > >> > >> >