From owner-linux-xfs@oss.sgi.com Wed Jan 1 04:23:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jan 2003 04:23:50 -0800 (PST) Received: from mail01.agrinet.ch (biene.agri.ch [212.28.134.110]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h01CNf3v006593 for ; Wed, 1 Jan 2003 04:23:42 -0800 Received: from wassern.consult-meyers.com (212.28.158.133) by mail01.agrinet.ch (NPlex 5.5.060) id 3E01D789000C3ABC for linux-xfs@oss.sgi.com; Wed, 1 Jan 2003 13:28:50 +0100 Received: from localhost (localhost [127.0.0.1]) by wassern.consult-meyers.com (Postfix) with ESMTP id 66D4021D8E1C for ; Wed, 1 Jan 2003 11:17:39 +0100 (CET) Received: by wassern.consult-meyers.com (Postfix, from userid 500) id 0454421D8E18; Wed, 1 Jan 2003 11:17:37 +0100 (CET) To: linux-xfs@oss.sgi.com Newsgroups: gmane.linux.debian.user.testing Subject: kernel panic with Debian sarge 2.4.18 SMP and xfs From: spamnjet@yahoo.de (A. L. Meyers) Reply-To: almeyers@freesurf.ch Organization: Meyers Consulting http://www.consult-meyers.com Date: 01 Jan 2003 11:17:37 +0100 Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Posted-To: gmane.linux.debian.user.testing X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id h01CNh3v006594 X-archive-position: 2181 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: spamnjet@yahoo.de Precedence: bulk X-list: linux-xfs The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.user.testing as well. Happy New Year! Using the Debian patch, compiled a monolithic, no-modules kernel including xfs support. Have been able to successfully convert and use all partitions to xfs except /. Can also mount and access the xfs partitions including / from another Linux distib installed on another HD. Was able to format the / partition /dev/hda2 as xfs and successfully tar back all of the files. That xfs / partition was mountable etc. as well from the 2nd HD, /dev/sda2. Was able to configure and run lilo. Tarring back all of the same files to the same partition formatted as ext3 makes the system bootable again. When booting into the xfs / partition /dev/hda2, the system successfully begins and boot but ends in a kernel panic which kills init and freezes the system. On 30 September 2002 Mr. Federico Sevilla III posted a detailed description of a very similar problem ¨Kernel panic killing interrupt handler¨ with a similar system. However, cannot see that anyone posted a solution. Help greatly appreciated. :-) Lucien -- If you receive this by error, please delete it and inform the sender. PGP key fingerprint=F1C0 D9AE 1B18 1405 4DFA B4CC 6DC7 FF78 C76E FB15 To Big Brother Echelon from "spook": supercomputer terrorist DES FSF North Korea FBI Clinton opus dei bomb From owner-linux-xfs@oss.sgi.com Wed Jan 1 07:31:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jan 2003 07:31:58 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h01FVo3v008113 for ; Wed, 1 Jan 2003 07:31:52 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h01FargG089065; Wed, 1 Jan 2003 16:36:53 +0100 (CET) Message-Id: <4.3.2.7.2.20030101163332.042137b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Jan 2003 16:36:48 +0100 To: almeyers@freesurf.ch, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: kernel panic with Debian sarge 2.4.18 SMP and xfs In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2182 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 11:17 1-1-2003 +0100, A. L. Meyers wrote: >The following message is a courtesy copy of an article >that has been posted to gmane.linux.debian.user.testing as well. > >Happy New Year! Same to you! >Was able to format the / partition /dev/hda2 as xfs and successfully tar >back all of the files. That xfs / partition was mountable etc. as well >from the 2nd HD, /dev/sda2. Was able to configure and run lilo. Did you per chance install lilo in the partition instead of the MBR? If you do, lilo will overwrite the XFS superblock which lives at block 0 and thus making it impossible to mount the filesystem. running xfs_repair will fix your filesystem by using one of the secondary super blocks. But though shall not install lilo on a xfs_partition. Afaik you can install lilo on your swap partition. People have reported this to work. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jan 1 13:44:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jan 2003 13:44:40 -0800 (PST) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h01LiV3v010469 for ; Wed, 1 Jan 2003 13:44:34 -0800 Received: from flint.arm.linux.org.uk ([3ffe:8260:2002:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 18Tqk2-0004SJ-00; Wed, 01 Jan 2003 21:49:34 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.04) id 18Tqk1-0002BU-00; Wed, 01 Jan 2003 21:49:33 +0000 Date: Wed, 1 Jan 2003 21:49:33 +0000 From: Russell King To: linux-kernel@vger.kernel.org Cc: linux-xfs@oss.sgi.com, parisc-linux@parisc-linux.org Subject: "vmalloc", friends and GFP flags Message-ID: <20030101214933.A26434@flint.arm.linux.org.uk> Mail-Followup-To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, parisc-linux@parisc-linux.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 2183 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: linux-xfs Hi, This mail is being copied to the XFS and PARISC mailing lists. You should probably trim the reply list as appropriate. I've just been looking over the state of the ARM {dma,pci}_alloc_consistent wrt interrupts etc in 2.5.53, and decided to have a look around this area for other users. I stumbled across the following unsafe areas. a) parisc. Looking at pa11_dma_alloc_consistent: pa11_dma_alloc_consistent -> map_uncached_pages -> (eventually) map_pmd_uncached -> pte_alloc_kernel -> pte_alloc_one_kernel static inline pte_t * pte_alloc_one_kernel(struct mm_struct *mm, unsigned long addr) { pte_t *pte = (pte_t *) __get_free_page(GFP_KERNEL); if (likely(pte != NULL)) clear_page(pte); return pte; } End result is that if pa11_dma_alloc_consistent() is called from IRQ context, parisc calls __get_free_page using GFP_KERNEL. Calling __get_free_page with GFP_KERNEL from IRQ context appears to be unsafe (always has been.) b) xfs. XFS contains this bit of code: static __inline unsigned int flag_convert(int flags) { ... if (flags & KM_NOSLEEP) return GFP_ATOMIC; /* If we're in a transaction, FS activity is not ok */ else if ((current->flags & PF_FSTRANS) || (flags & KM_NOFS)) return GFP_NOFS; else return GFP_KERNEL; } void *kmem_alloc(size_t size, int flags) { ... rval = __vmalloc(size, flag_convert(flags), PAGE_KERNEL); ... } Ok, so xfs can pass GFP_ATOMIC, GFP_NOFS and GFP_KERNEL to __vmalloc. However, do these flags actually ensure what they suggest they do? Lets look at __vmalloc: void *__vmalloc(unsigned long size, int gfp_mask, pgprot_t prot) { ... area = get_vm_area(size, VM_ALLOC); ... } and get_vm_area: struct vm_struct *get_vm_area(unsigned long size, unsigned long flags) { ... area = kmalloc(sizeof(*area), GFP_KERNEL); ... } Also, look at the PMD and PTE allocation functions, which also use GFP_KERNEL. Answer to the above question: no. Is this unsafe? Probably. Now, what does this all have to do with ARM and pci_alloc_consistent. It's the same problem, only I have a BUG_ON() in there to catch uses from IRQ context, which needs to disappear eventually. (This is mainly a requirement for USB to work.) However, before this can happen, I believe I'd need the following: 1. allocation of vm areas (via get_vm_area and friends) needs to become IRQ-safe. - vmlist_lock needs to become IRQ safe (but its held during vread/vwrite) - kmalloc of vm_structs needs to have gfp flags passed in 2. allocation of page tables (via pmd_alloc_kernel / pte_alloc_kernel) needs to become IRQ-safe. - pmd_alloc_kernel / pte_alloc_kernel needs to have gfp flags passed in - map_vm_area would also need gfp flags The same solution also fixes the two instances described above. I suspect, however, that the vmlist_lock change will be unacceptable to many people however. This doesn't affect XFS nor parisc, but would mean that I'd need to completely rewrite the ARM consistent memory allocation to use none of the above (which I think is the right approach, but means _all_ of the above becomes S.E.P. 8)) -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From owner-linux-xfs@oss.sgi.com Wed Jan 1 17:40:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jan 2003 17:40:44 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h021ee3v012794 for ; Wed, 1 Jan 2003 17:40:40 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h021qUkq007530 for ; Wed, 1 Jan 2003 19:52:31 -0600 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 h021iT3s800041 for ; Thu, 2 Jan 2003 12:44:29 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h021iSH7800393 for linux-xfs@oss.sgi.com; Thu, 2 Jan 2003 12:44:28 +1100 (EST) Date: Thu, 2 Jan 2003 12:44:28 +1100 (EST) From: Nathan Scott Message-Id: <200301020144.h021iSH7800393@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor tidyups X-archive-position: 2184 X-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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix up some comments, tidy up some macros - no functional changes. Date: Wed Jan 1 17:40:40 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:135917a linux/fs/xfs/xfs_utils.c - 1.57 linux/fs/xfs/linux/xfs_vnode.h - 1.74 - Add a vname to vnode macro, finishing off the dentry/core XFS code abstraction from a little while ago. linux/fs/xfs/pagebuf/page_buf.c - 1.90 - Fix some comments related to IO completion callbacks. From owner-linux-xfs@oss.sgi.com Wed Jan 1 21:31:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jan 2003 21:31:55 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h025Vk3v014462 for ; Wed, 1 Jan 2003 21:31:47 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h025atlx027671 for ; Wed, 1 Jan 2003 21:36:55 -0800 From: "LA Walsh" To: Subject: building xfsdump... Date: Wed, 1 Jan 2003 21:36:55 -0800 Message-ID: <000f01c2b220$f5efdb70$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h025Vl3v014463 X-archive-position: 2185 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs minor problem with likely a real dumb error on my part in system configuration, but in trying to rebuild the rpm for xfsdump on my SuSE system, I got an error I don't understand (w/o, perhaps an extended period of examination) and was hoping someone might short-circuit my debugging of this issue: I got: ... checking for uuid_generate in -luuid... yes checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking for initscr in -lcurses... no FATAL ERROR: could not find a valid curses library. make: *** [include/builddefs] Error 1 Bad exit status from /var/tmp/rpm-tmp.20760 (%build) checking for curses... ishtar:/usr/src/packages> rpm -qa|grep curs ncurses-5.2-386 ncurses-devel-5.2-386 locating curses... ishtar:/usr/src/packages> locate curses|grep lib' ... /usr/i486-linux-libc5/lib/libcurses.so.1 /usr/i486-linux-libc5/lib/libcurses.so.1.0.0 ... /usr/lib/curses /usr/lib/curses/libcurses.a /usr/lib/curses/libcurses.so /usr/lib/libcurses.so.1 /usr/lib/libcurses.so.1.0.0 exploring curses libs... ishtar:/usr/src/packages> nm /usr/lib/curses/libcurses.so|grep initscr 00004b70 T initscr ishtar:/usr/src/packages> nm /usr/lib/curses/libcurses.a|grep initscr initscr.o: 00000000 T initscr ...... So what am I missing here? Looks like I have something that appears to be a curses lib, and both the shared and static libs appear to have a symbol resembling initscr, so, um, what's missing? Am I just cursed? :-| TIA... -linda From owner-linux-xfs@oss.sgi.com Wed Jan 1 21:36:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Jan 2003 21:36:37 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h025aX3v014910 for ; Wed, 1 Jan 2003 21:36:34 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 2DFF5142D6; Thu, 2 Jan 2003 06:41:41 +0100 (MET) Date: Thu, 2 Jan 2003 06:41:40 +0100 From: Andi Kleen To: LA Walsh , linux-xfs@oss.sgi.com Subject: Re: building xfsdump... Message-ID: <20030102054140.GA18962@wotan.suse.de> References: <000f01c2b220$f5efdb70$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000f01c2b220$f5efdb70$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.4i X-archive-position: 2186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Wed, Jan 01, 2003 at 09:36:55PM -0800, LA Walsh wrote: > > minor problem with likely a real dumb error on my part in system configuration, but in trying to rebuild the rpm for xfsdump on my SuSE system, I got an error I don't understand (w/o, perhaps an extended period of examination) and was hoping someone might short-circuit my debugging of this issue: Take a look at config.log in the build directory where it failed. It usually shows you what went wrong in more detail (compiled source + error messages from the toolkit) -Andi From owner-linux-xfs@oss.sgi.com Thu Jan 2 01:35:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 01:35:57 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h029Zk3v018270 for ; Thu, 2 Jan 2003 01:35:48 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18U1pd-0005jI-00 for ; Thu, 02 Jan 2003 10:40:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18TqMW-0002iB-00 for ; Wed, 01 Jan 2003 22:25:16 +0100 Path: wassern.consult-meyers.com!news From: "A. Lucien Meyers" Subject: Re: kernel panic with Debian sarge 2.4.18 SMP and xfs Date: Wed, 1 Jan 2003 22:24:12 +0100 Lines: 55 Message-ID: References: <4.3.2.7.2.20030101163332.042137b0@pop.xs4all.nl> Reply-To: almeyers@freesurf.ch X-Complaints-To: usenet@main.gmane.org User-Agent: slrn/0.9.7.3 (Linux) X-archive-position: 2187 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nospam.look@replyto.please.because.this.is.invalid.sgi.com Precedence: bulk X-list: linux-xfs * Seth Mos : > At 11:17 1-1-2003 +0100, A. L. Meyers wrote: > >The following message is a courtesy copy of an article > >that has been posted to gmane.linux.debian.user.testing as well. > >Happy New Year! > > Same to you! > > >Was able to format the / partition /dev/hda2 as xfs and > >successfully tar back all of the files. That xfs / partition was > >mountable etc. as well from the 2nd HD, /dev/sda2. Was able to > >configure and run lilo. > > Did you per chance install lilo in the partition instead of the > MBR? If you do, lilo will overwrite the XFS superblock which lives > at block 0 and thus making it impossible to mount the filesystem. > > running xfs_repair will fix your filesystem by using one of the > secondary super blocks. But though shall not install lilo on a > xfs_partition. > > Afaik you can install lilo on your swap partition. People have > reported this to work. > > Cheers Thanks for the advice, Seth. lilo is on the MBR of /dev/hda. lilo does seem to allow installation on the swap partition /dev/hda3 but gives me an error message saying that /dev/hda3 would not be the right place. Followed all your suggestions but, alas, exactly the same result. Here is some of the relevant output during the boot process which results in having to press the reset button: FAT: bogus logical sector size 0 FAT: bogus logical sector size 0 invalid operand: 0000 CPU: EIP: EFLAGS: Process swapper Call trace: Code: <0> Kernel panic: Attempted to kill init! Have left out the details from CPU to Code. Suggestions welcome. Lucien -- If you receive this by error, please delete it and inform the sender. http://www.consult-meyers.com recommends email encryption using GnuPG. From owner-linux-xfs@oss.sgi.com Thu Jan 2 01:45:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 01:45:59 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h029jp3v018791 for ; Thu, 2 Jan 2003 01:45:52 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h029p4up082152; Thu, 2 Jan 2003 10:51:04 +0100 (CET) Message-Id: <4.3.2.7.2.20030102104717.03fe6e90@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Jan 2003 10:50:57 +0100 To: almeyers@freesurf.ch, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: kernel panic with Debian sarge 2.4.18 SMP and xfs In-Reply-To: References: <4.3.2.7.2.20030101163332.042137b0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2188 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 22:24 1-1-2003 +0100, A. Lucien Meyers wrote: >Followed all your suggestions but, alas, exactly the same result. >Here is some of the relevant output during the boot process which >results in having to press the reset button: > >FAT: bogus logical sector size 0 >FAT: bogus logical sector size 0 >invalid operand: 0000 >CPU: >EIP: >EFLAGS: >Process swapper >Call trace: >Code: ><0> Kernel panic: Attempted to kill init! Did you try to use high optimizations for the compile? Or did you compile a i586 kernel on a AMD K6 machine (which often fails). I suspect that either the following might be a problem: - Buggy compiler (what are you using) - Compiling for the wrong architecture (what are you compiling for) - Hardware problem (Failing fan, memory). Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jan 2 03:27:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 03:27:28 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h02BRI3v024498 for ; Thu, 2 Jan 2003 03:27:18 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h02BWRlx032652; Thu, 2 Jan 2003 03:32:27 -0800 From: "LA Walsh" To: "'Andi Kleen'" , Subject: RE: building xfsdump... Date: Thu, 2 Jan 2003 03:32:26 -0800 Message-ID: <000501c2b252$a01617a0$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20030102054140.GA18962@wotan.suse.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h02BRJ3v024499 X-archive-position: 2189 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs Nep...seems to show less detail, last bit of lines: define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_STDINT_H 1 #define HAVE_UNISTD_H 1 #define HAVE_LIBUUID 1 configure: exit 1 --- exit 1: ... I think the error message I'm getting seems to be pointing the to the problem though the problem isn't verifiable via other methods, though I had problems with the curses lib back in SuSE 8.0 -- same symptom when doing a make menuconfig (in kernel) -- curses couldn't be found. But with 8.1 it went away. (Checking...well kernel make menuconfig works with curses linkage). Hmmm...but menuconfig has a define 'CURSES_LOC="" Perhaps xfsdump needs to know to use ncurses rather than curses? Maybe I shouldn't be using suse...:-)...nah...must be a redhat bug that it works :-). > -----Original Message----- > From: Andi Kleen [mailto:ak@suse.de] > Sent: January 01, 2003 09:42p > To: LA Walsh; linux-xfs@oss.sgi.com > Subject: Re: building xfsdump... > > > On Wed, Jan 01, 2003 at 09:36:55PM -0800, LA Walsh wrote: > > > > minor problem with likely a real dumb error on my part in system > > configuration, but in trying to rebuild the rpm for xfsdump > on my SuSE > > system, I got an error I don't understand (w/o, perhaps an extended > > period of examination) and was hoping someone might > short-circuit my > > debugging of this issue: > > Take a look at config.log in the build directory where it > failed. It usually shows you what went wrong in more detail > (compiled source + > error messages from the toolkit) > > -Andi > From owner-linux-xfs@oss.sgi.com Thu Jan 2 03:38:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 03:38:30 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h02BcQ3v024977 for ; Thu, 2 Jan 2003 03:38:26 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h02BhZlx006938; Thu, 2 Jan 2003 03:43:35 -0800 From: "LA Walsh" To: "'Andi Kleen'" , Subject: RE: building xfsdump... Date: Thu, 2 Jan 2003 03:43:35 -0800 Message-ID: <000601c2b254$2ee8c940$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20030102054140.GA18962@wotan.suse.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h02BcQ3v024978 X-archive-position: 2190 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs I changed the 'curses' check to check 'ncurses' instead and everything seemed to make. Is curses/ncurses actually used in xfsdump/restore? Should the configure.in file auto-adapt to either? Guess now the test....*...er, maybe tomorrow morning...er, *later* this morning, more precisely... -l > -----Original Message----- > From: Andi Kleen [mailto:ak@suse.de] > Sent: January 01, 2003 09:42p > To: LA Walsh; linux-xfs@oss.sgi.com > Subject: Re: building xfsdump... > > > On Wed, Jan 01, 2003 at 09:36:55PM -0800, LA Walsh wrote: > > > > minor problem with likely a real dumb error on my part in system > > configuration, but in trying to rebuild the rpm for xfsdump > on my SuSE > > system, I got an error I don't understand (w/o, perhaps an extended > > period of examination) and was hoping someone might > short-circuit my > > debugging of this issue: > > Take a look at config.log in the build directory where it > failed. It usually shows you what went wrong in more detail > (compiled source + > error messages from the toolkit) > > -Andi > From owner-linux-xfs@oss.sgi.com Thu Jan 2 05:17:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 05:17:58 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h02DHt3v028121 for ; Thu, 2 Jan 2003 05:17:55 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h02DTokq012545 for ; Thu, 2 Jan 2003 07:29:50 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA83987 for ; Thu, 2 Jan 2003 07:23:04 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA00891 for ; Thu, 2 Jan 2003 07:23:03 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h02Kbfg02634 for linux-xfs@oss.sgi.com; Thu, 2 Jan 2003 15:37:41 -0500 Resent-Message-Id: <200301022037.h02Kbfg02634@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id GAA63403 for ; Thu, 2 Jan 2003 06:50:12 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h02CoAQb46173181 for ; Thu, 2 Jan 2003 04:50:11 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h02Cm42V020830 for ; Thu, 2 Jan 2003 13:48:04 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h02Cm4ST020829 for hch@sgi.com; Thu, 2 Jan 2003 13:48:04 +0100 Date: Thu, 2 Jan 2003 13:48:04 +0100 From: Christoph Hellwig Message-Id: <200301021248.h02Cm4ST020829@lab343.munich.sgi.com> Subject: TAKE - some more rename cleanups To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 2 Jan 2003 15:37:40 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2191 X-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 Date: Thu Jan 2 04:49:13 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:135919a linux/fs/xfs/xfs_rename.c - 1.46 - xfs_lock_for_rename can't return EAGAIN anymore, no need to handle it; use vname terminology more consistantly From owner-linux-xfs@oss.sgi.com Thu Jan 2 05:18:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 05:18:08 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h02DI43v028152 for ; Thu, 2 Jan 2003 05:18:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h02DU0kq012548 for ; Thu, 2 Jan 2003 07:30:00 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA15712 for ; Thu, 2 Jan 2003 07:23:13 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA97759 for ; Thu, 2 Jan 2003 07:23:12 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h02KboB02639 for linux-xfs@oss.sgi.com; Thu, 2 Jan 2003 15:37:50 -0500 Resent-Message-Id: <200301022037.h02KboB02639@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA53768 for ; Thu, 2 Jan 2003 07:07:05 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h02D73Qb45322242 for ; Thu, 2 Jan 2003 05:07:04 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h02D4v2V021881 for ; Thu, 2 Jan 2003 14:04:57 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h02D4vea021880 for hch@sgi.com; Thu, 2 Jan 2003 14:04:57 +0100 Date: Thu, 2 Jan 2003 14:04:57 +0100 From: Christoph Hellwig Message-Id: <200301021304.h02D4vea021880@lab343.munich.sgi.com> Subject: TAKE - xfs_getattr should be static To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 2 Jan 2003 15:37:50 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2192 X-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 Date: Thu Jan 2 05:06:03 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:135920a linux/fs/xfs/xfs_vnodeops.c - 1.579 From owner-linux-xfs@oss.sgi.com Thu Jan 2 11:14:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 11:14:09 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h02JE73v008755 for ; Thu, 2 Jan 2003 11:14:07 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h02JE7Rg008754 for linux-xfs@oss.sgi.com; Thu, 2 Jan 2003 11:14:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h02JE53x008740 for ; Thu, 2 Jan 2003 11:14:05 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h02J7xeO008252; Thu, 2 Jan 2003 11:07:59 -0800 Date: Thu, 2 Jan 2003 11:07:59 -0800 Message-Id: <200301021907.h02J7xeO008252@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 204] New: directory /var/run got corrupted, got error -990 when trying to add a file X-Bugzilla-Reason: AssignedTo X-archive-position: 2193 X-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=204 Summary: directory /var/run got corrupted, got error -990 when trying to add a file Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: t13_e@yahoo.com If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.20 Where did the XFS code come from? (CVS, Linus, your distribution, etc): CVS patch on XFS website Description of Problem: Suddenly, /var/run got corrupted and nothing was able to write to this directory. Nor was I able to remove it. xfs_repair fixed it. How Reproducible: I don't know. Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: Is 1.2 supposed to be stable enough to use? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jan 2 11:44:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 11:44:12 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h02Ji73v009481 for ; Thu, 2 Jan 2003 11:44:07 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h02Ji7Fm009480 for linux-xfs@oss.sgi.com; Thu, 2 Jan 2003 11:44:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h02Ji53x009466 for ; Thu, 2 Jan 2003 11:44:05 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h02JSjKI009393; Thu, 2 Jan 2003 11:28:45 -0800 Date: Thu, 2 Jan 2003 11:28:45 -0800 Message-Id: <200301021928.h02JSjKI009393@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 204] directory /var/run got corrupted, got error -990 when trying to add a file X-Bugzilla-Reason: AssignedTo X-archive-position: 2194 X-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=204 ------- Additional Comments From lord@sgi.com 2003-01-02 11:28 ------- Can you be a lot more specific about exactly which code you were running here, you say CVS patch from website, but what was the date on the patch, you also list the code you are running as 1.2 based. We have seen the same problem in house, but it is proving difficult to track down. XFS reports version info at startup, for instance: SGI XFS CVS-2002-11-30_06:00_UTC with ACLs, no debug enabled ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jan 2 11:59:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 11:59:06 -0800 (PST) Received: from mail.blazebox.homeip.net (postfix@pool-141-155-136-242.ny5030.east.verizon.net [141.155.136.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h02Jx23v010036 for ; Thu, 2 Jan 2003 11:59:03 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 78BAAA1BD; Thu, 2 Jan 2003 15:03:34 -0500 (EST) Received: from mail.blazebox.homeip.net (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.5) id 56658-760DAC55; Thu, 02 Jan 2003 15:03:34 -0500 Received: from blaze.homeip.net (blaze [192.168.0.43]) by mail.blazebox.homeip.net (Postfix) with ESMTP id A13D79F5C; Thu, 2 Jan 2003 15:03:33 -0500 (EST) Subject: Re: 2.4.21pre2 + preempt + xfs BUG? From: Paul Blazejowski To: joergprante@netcologne.de Cc: linux-xfs@oss.sgi.com In-Reply-To: <200212260149.11718.joergprante@netcologne.de> References: <200212260149.11718.joergprante@netcologne.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AcUBlZPaD8RCK+PQeFue" Organization: Message-Id: <1041537857.8608.4.camel@blaze.homeip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 02 Jan 2003 15:04:17 -0500 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.5; AVE: 6.17.0.2; VDF: 6.17.0.11; host: blazebox.homeip.net) X-archive-position: 2195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: paulb@blazebox.homeip.net Precedence: bulk X-list: linux-xfs --=-AcUBlZPaD8RCK+PQeFue Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, 2002-12-25 at 19:49, J=F6rg Prante wrote: > Hello, >=20 > in my 2.4.21-pre2 based -jp15 kernel patch set I can't boot with XFS and= =20 > preemptive kernel enabled. >=20 > I use: > - 2.4.21pre2 > - preempt 2.4.20-ac1=20 > - XFS snapshot 2.4.20-2002-11-29_01:21_UTC > - and a lot of other patches, see http://infolinux.de/jp15 >=20 > The kernel boots ok for a long time, but when it enters the init process = run=20 > level 5, it throws a kernel BUG in the O(1) scheduler code in schedule() = at=20 > the first statement when it checks for interrupt code.=20 >=20 > I guess it performs a sync on the XFS root file system for the first time= . You=20 > can find a ksymoops message below.=20 >=20 > Here are my observations after several changes in the configuration: >=20 > - if preemptive kernel is disabled, XFS can boot successfully. So, the bu= g is=20 > triggered by the preemptive kernel patch. >=20 > - with preemptive kernel enabled and reiserfs, booting is no problem. So,= the=20 > bug is specific to the combination XFS and preempt. >=20 > Is it just me with this BUG or can it be reproduced?=20 >=20 > A release of the patch set is available at > http://infolinux.de/jp15/patchset-2.4.21-pre2-jp15.tar.bz2 >=20 > Best regards, >=20 > J=F6rg >=20 Hi again, Last time i forgot to CC the list...just to follow up on the previous email. I've created a diff with XFS (cvs version) and preempt against 2.4.21-pre2 which boots and seems to work ok (have run it for ~2 days). The diff+details are on http://www.blazebox.homeip.net:81/~paul/linux . Regards, Paul B. P.S. Happy New Year to all on the list! --=-AcUBlZPaD8RCK+PQeFue Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+FJtBIymMQsXoRDARAsEDAKCZ8NS7j1FqFZaNN+PCjpDiEO9MzACgkeHT gHy/YY41j9SZMzF7mRje9NU= =84Fl -----END PGP SIGNATURE----- --=-AcUBlZPaD8RCK+PQeFue-- From owner-linux-xfs@oss.sgi.com Thu Jan 2 12:14:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 12:14:14 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h02KE73v010571 for ; Thu, 2 Jan 2003 12:14:07 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h02KE7pV010570 for linux-xfs@oss.sgi.com; Thu, 2 Jan 2003 12:14:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h02KE53x010556 for ; Thu, 2 Jan 2003 12:14:05 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h02K7rU5010532; Thu, 2 Jan 2003 12:07:53 -0800 Date: Thu, 2 Jan 2003 12:07:53 -0800 Message-Id: <200301022007.h02K7rU5010532@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 204] directory /var/run got corrupted, got error -990 when trying to add a file X-Bugzilla-Reason: AssignedTo X-archive-position: 2196 X-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=204 ------- Additional Comments From t13_e@yahoo.com 2003-01-02 12:07 ------- OS is debian 3.0 XFS version is: SGI XFS snapshot 2.4.20-2002-11-29_01:21_UTC with DMAPI, quota, no debug enabled compiler version is: tim@sol:~$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) hardware is Dell Insprion 8200: tim@sol:/usr/local/j2eetutorial/examples$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping : 4 cpu MHz : 1595.327 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips : 3185.04 Harddrive is: Travelstar 40GN Model No: IC25N040ATCS04-0 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jan 2 14:42:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 14:42:13 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h02Mg73v012887 for ; Thu, 2 Jan 2003 14:42:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h02KlQG8028002 for ; Thu, 2 Jan 2003 12:47:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA77332 for ; Thu, 2 Jan 2003 16:47:16 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA22484 for ; Thu, 2 Jan 2003 16:47:17 -0600 (CST) Received: from rose.americas.sgi.com (localhost [127.0.0.1]) by rose.americas.sgi.com (8.12.6/8.12.5) with ESMTP id h02MnNkx001557 for ; Thu, 2 Jan 2003 16:49:23 -0600 Received: (from cattelan@localhost) by rose.americas.sgi.com (8.12.6/8.12.6/Submit) id h02MnNII001555 for linux-xfs@oss.sgi.com; Thu, 2 Jan 2003 16:49:23 -0600 Date: Thu, 2 Jan 2003 16:49:23 -0600 From: Rusell Cattelan Message-Id: <200301022249.h02MnNII001555@rose.americas.sgi.com> Subject: TAKE - very small db fix X-archive-position: 2197 X-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@rose.americas.sgi.com Precedence: bulk X-list: linux-xfs use valloc instead of malloc; allow xfs_db/check to run on raw devices Date: Thu Jan 2 14:46:28 PST 2003 Workarea: rose.americas.sgi.com:/usr/src/2.4.x-xfs/find The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:135964a cmd/xfsprogs/db/malloc.c - 1.5 From owner-linux-xfs@oss.sgi.com Thu Jan 2 20:41:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 20:41:45 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h034fb3v015541 for ; Thu, 2 Jan 2003 20:41:37 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h034rakq024513 for ; Thu, 2 Jan 2003 22:53:37 -0600 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 h034jV3s856322 for ; Fri, 3 Jan 2003 15:45:31 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h034jU0d855981 for linux-xfs@oss.sgi.com; Fri, 3 Jan 2003 15:45:30 +1100 (EST) Date: Fri, 3 Jan 2003 15:45:30 +1100 (EST) From: Nathan Scott Message-Id: <200301030445.h034jU0d855981@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - libxfs.a X-archive-position: 2198 X-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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Sync up user/kernel sources and headers (native extents). Date: Thu Jan 2 20:44:31 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:135987a cmd/xfsprogs/db/bmap.c - 1.7 cmd/xfsprogs/repair/dinode.c - 1.11 - Use libxfs_bmbt_disk_get_all which replaces libxfs_bmbt_get_all. cmd/xfsprogs/include/xfs_log_priv.h - 1.11 cmd/xfsprogs/include/libxfs.h - 1.21 cmd/xfsprogs/include/xfs_inode_item.h - 1.7 cmd/xfsprogs/include/xfs_bmap_btree.h - 1.8 cmd/xfsprogs/include/xfs_mount.h - 1.32 cmd/xfsprogs/include/xfs_inode.h - 1.27 cmd/xfsprogs/libxfs/xfs.h - 1.28 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.13 cmd/xfsprogs/libxfs/xfs_btree.c - 1.11 cmd/xfsprogs/libxfs/xfs_inode.c - 1.15 cmd/xfsprogs/libxfs/xfs_alloc.c - 1.17 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.17 cmd/xfsprogs/libxfs/xfs_alloc_btree.c - 1.9 - Sync up user/kernel sources and headers (native extents). From owner-linux-xfs@oss.sgi.com Thu Jan 2 22:14:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 22:14:11 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h036E73v016472 for ; Thu, 2 Jan 2003 22:14:07 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h036E7Tq016471 for linux-xfs@oss.sgi.com; Thu, 2 Jan 2003 22:14:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h036E53x016457 for ; Thu, 2 Jan 2003 22:14:05 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0362M0u016392; Thu, 2 Jan 2003 22:02:22 -0800 Date: Thu, 2 Jan 2003 22:02:22 -0800 Message-Id: <200301030602.h0362M0u016392@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 205] New: make install fails to properly symlink and copy the libraries X-Bugzilla-Reason: AssignedTo X-archive-position: 2199 X-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=205 Summary: make install fails to properly symlink and copy the libraries Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: major Priority: Medium Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: bootsy52@gmx.net Actually this applies to the whole cmd_tar's packages, especially to acl,attr. The Problem: running make install on acl-2.1.1 and attr-2.1.1 fails to properly create the symlinks and to copy the libraries from .libs. The Problem is present in every version so far I've installed. As a given examply I refer to acl-2.1.1 (earlier version have the same problem) I installed acl-2.1.1 with: ./configure --prefix=/usr --localstatedir=/var --mandir=/usr/share/man && \ make && \ make install && \ make install-dev After this a ls -la /usr/lib/libacl.* gives: bash-2.05a# ls -la /usr/lib/libacl.* lrwxr-xr-x 1 root root 21 Jan 3 06:29 /usr/lib/libacl.a -> /usr/libexec/libacl.a lrwxr-xr-x 1 root root 22 Jan 3 06:29 /usr/lib/libacl.la -> /usr/libexec/libacl.la lrwxr-xr-x 1 root root 11 Jan 3 06:29 /usr/lib/libacl.so -> libacl.so.1 As you can see libacl.so is linked to libacl.so.1 but libacl.so.1 is missing, as well as libacl.so.1.0.3 the final destination is missing as well. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jan 2 23:14:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Jan 2003 23:14:13 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h037E73v017348 for ; Thu, 2 Jan 2003 23:14:07 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h037E7P8017347 for linux-xfs@oss.sgi.com; Thu, 2 Jan 2003 23:14:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h037E53x017333 for ; Thu, 2 Jan 2003 23:14:05 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0378U1G017279; Thu, 2 Jan 2003 23:08:30 -0800 Date: Thu, 2 Jan 2003 23:08:30 -0800 Message-Id: <200301030708.h0378U1G017279@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 205] make install fails to properly symlink and copy the libraries X-Bugzilla-Reason: AssignedTo X-archive-position: 2200 X-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=205 ------- Additional Comments From bootsy52@gmx.net 2003-01-02 23:08 ------- Even worse is that if xfsprogs-2.3.6 is build with: ./configure --prefix=/usr --exec-prefix=/ --bindir=/usr/sbin \ --localstatedir=/var --mandir=/usr/share/man && \ make && \ make install && \ make install-dev not even copies anything of libxfs[a,so] and afterwards the build of xfsdump-2.2.4 complains about not finding libxfs. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Jan 3 01:31:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 01:31:59 -0800 (PST) Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h039Vo3v020264 for ; Fri, 3 Jan 2003 01:31:52 -0800 Received: from ids.org.au (localhost [127.0.0.1]) by ids.org.au (Postfix) with SMTP id A2F91C8B1F1 for ; Fri, 3 Jan 2003 20:37:02 +1100 (EST) Received: from 144.137.30.141 (SquirrelMail authenticated user ian) by www.ids.org.au with HTTP; Fri, 3 Jan 2003 20:37:02 +1100 (EST) Message-ID: <4817.144.137.30.141.1041586622.squirrel@www.ids.org.au> Date: Fri, 3 Jan 2003 20:37:02 +1100 (EST) Subject: uptime From: "Ian Cumming" To: linux-xfs@oss.sgi.com Reply-To: ian@ids.org.au X-Mailer: SquirrelMail (version 1.3.2) MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-archive-position: 2201 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ian@semisphere.org Precedence: bulk X-list: linux-xfs Hi people, just a quick note to thank all those who have been developing xfs on Linux over the past year. I could write all I want to praise the development team, but I think that 154 days uptime and 100Gb of XFS filesystems (not to mention 250 users) speaks for itself. Thanks to everyone and SGI for this impressive product, and keep up the good work! Ian. -- ids:/# uname --all Linux ids 2.4.18-xfs-1.1 #1 SMP Fri Jul 5 17:26:25 EST 2002 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux ids:/# uptime 20:32:09 up 154 days, 3:08, 9 users, load average: 0.00, 0.07, 0.04 ids:/# df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda5 975100 39440 935660 5% / /dev/hda7 4878928 1527208 3351720 32% /usr /dev/hda8 9762688 1056524 8706164 11% /var /dev/hda9 1947064 5776 1941288 1% /tmp /dev/hda10 19538240 1891920 17646320 10% /pub /dev/hdc5 58608488 23794496 34813992 41% /home ids:/# From owner-linux-xfs@oss.sgi.com Fri Jan 3 09:12:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 09:12:27 -0800 (PST) Received: from dfw-gate1.raytheon.com (dfw-gate1.raytheon.com [199.46.199.230]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03HCI3v012090 for ; Fri, 3 Jan 2003 09:12:18 -0800 Received: from ds02e00.directory.ray.com (ds02e00.directory.ray.com [147.25.130.245]) by dfw-gate1.raytheon.com (8.12.5/8.12.5) with ESMTP id h03HHbcp003696 for ; Fri, 3 Jan 2003 11:17:37 -0600 (CST) Received: from ds02e00.directory.ray.com (localhost [127.0.0.1]) by ds02e00.directory.ray.com (8.12.6/8.12.1) with ESMTP id h03HHY8X015558 for ; Fri, 3 Jan 2003 17:17:35 GMT Received: from rtslan-ds01.lme.us.ray.com (rtslan-ds01.lme.us.ray.com [155.157.19.10]) by ds02e00.directory.ray.com (8.12.6/8.12.1) with ESMTP id h03HHWSH015524 for ; Fri, 3 Jan 2003 17:17:32 GMT Subject: linux To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Patrick_Coleman@raytheon.com Date: Fri, 3 Jan 2003 12:15:38 -0500 X-MIMETrack: Serialize by Router on RTSLAN-DS01/RTS/Raytheon/US(Release 5.0.9a |January 7, 2002) at 01/03/2003 12:15:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 2202 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Patrick_Coleman@raytheon.com Precedence: bulk X-list: linux-xfs Hi, Can you run Linux on an SGI O2 machine? Thanks. Pat. Patrick Coleman Patrick_Coleman@raytheon.com 301-794-5478 From owner-linux-xfs@oss.sgi.com Fri Jan 3 11:02:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 11:02:21 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03J2G3v014028 for ; Fri, 3 Jan 2003 11:02:17 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h03J7Z8s014050; Fri, 3 Jan 2003 20:07:36 +0100 (CET) Message-Id: <4.3.2.7.2.20030103200552.041510c0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Jan 2003 20:07:31 +0100 To: Patrick_Coleman@raytheon.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: linux In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 12:15 3-1-2003 -0500, Patrick_Coleman@raytheon.com wrote: >Hi, > >Can you run Linux on an SGI O2 machine? AFAIK, there have been some tries in the past. Graphics is out of the question though, serial console is the only option. I also believe only the R5K series were a possibility. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Jan 3 11:19:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 11:19:59 -0800 (PST) Received: from poptart.bithose.com (ip-204-97-176-41.modem.logical.net [204.97.176.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03JJr3v014593 for ; Fri, 3 Jan 2003 11:19:54 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.2/8.12.2) with ESMTP id h03JPDN1044239 for ; Fri, 3 Jan 2003 14:25:13 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.2/8.12.2/Submit) with ESMTP id h03JPDAp044241 for ; Fri, 3 Jan 2003 14:25:13 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Fri, 3 Jan 2003 14:25:13 -0500 (EST) From: Jameel Akari To: Subject: Re: linux In-Reply-To: <4.3.2.7.2.20030103200552.041510c0@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2204 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: linux-xfs On Fri, 3 Jan 2003, Seth Mos wrote: > At 12:15 3-1-2003 -0500, Patrick_Coleman@raytheon.com wrote: > >Hi, > > > >Can you run Linux on an SGI O2 machine? No. > AFAIK, there have been some tries in the past. Graphics is out of the > question though, serial console is the only option. I also believe only the > R5K series were a possibility. Yeah, last time I looked, there was a partially working Linux for Indys (R4K/R5K) that ran in serial console. No graphics. Might have been multiuser, maybe not. Even though I have a working Indy, I stuck with Irix. I also thought I had seen dmesg from where some brave soul had booted a Linux SMP kernel on a Origin or something with like 32 processors.. no idea if that was a hoax, or what became of it. Given the published SGI strategy of Linux on x86 and IRIX on MIPS, something tells me any Linux on SGI MIPS machines is going to be a total hack anyway. #!/jameel/akari sleep 4800; make clean && make breakfast From owner-linux-xfs@oss.sgi.com Fri Jan 3 12:04:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 12:04:12 -0800 (PST) Received: from vracs001.vrac.iastate.edu (vracs001.vrac.iastate.edu [129.186.232.215]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03K493v015492 for ; Fri, 3 Jan 2003 12:04:09 -0800 Received: from regatta.vrac.iastate.edu (regatta.vrac.iastate.edu [129.186.232.185]) by vracs001.vrac.iastate.edu (SGI-8.9.3/8.9.3) with ESMTP id OAA59530 for ; Fri, 3 Jan 2003 14:09:29 -0600 (CST) Subject: XFS and tg3 driver From: "Daniel E. Shipton" To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Jan 2003 14:09:18 -0600 Message-Id: <1041624558.19560.6.camel@regatta.vrac.iastate.edu> Mime-Version: 1.0 X-archive-position: 2205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dshipton@vrac.iastate.edu Precedence: bulk X-list: linux-xfs Is anyone using a Broadcom card with the tg3 driver on a smp system. We have a dell 4600 that locks every other day. There is a redhat errata about this at https://rhn.redhat.com/errata/RHBA-2002-292.html . I can't find a patch for that kernel to fix our problem......any suggestions? thanks Daniel E. Shipton Virtual Reality Application Center From owner-linux-xfs@oss.sgi.com Fri Jan 3 12:08:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 12:09:00 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03K8s3v015978 for ; Fri, 3 Jan 2003 12:08:56 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18UYBx-0006Vr-00 for ; Fri, 03 Jan 2003 21:13:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18UYBw-0006Vh-00 for ; Fri, 03 Jan 2003 21:13:16 +0100 Path: wassern.consult-meyers.com!news From: "A. L. Meyers" Subject: Re: kernel panic with Debian sarge 2.4.18 SMP and xfs Date: 03 Jan 2003 21:13:42 +0100 Organization: Meyers Consulting http://www.consult-meyers.com Lines: 46 Message-ID: References: <4.3.2.7.2.20030101163332.042137b0@pop.xs4all.nl> <4.3.2.7.2.20030102104717.03fe6e90@pop.xs4all.nl> Reply-To: "A. L. Meyers" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-archive-position: 2206 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nospam.look@replyto.because.this.is.invalid.sgi.com Precedence: bulk X-list: linux-xfs Seth Mos writes: > At 22:24 1-1-2003 +0100, A. Lucien Meyers wrote: > >Followed all your suggestions but, alas, exactly the same result. > >Here is some of the relevant output during the boot process which > >results in having to press the reset button: > > > >FAT: bogus logical sector size 0 > >FAT: bogus logical sector size 0 > >invalid operand: 0000 > >CPU: > >EIP: > >EFLAGS: > >Process swapper > >Call trace: > >Code: > ><0> Kernel panic: Attempted to kill init! > > Did you try to use high optimizations for the compile? Just standard setting, O2. Do you suggest reducing this to 1 or 0? > Or did you compile a i586 kernel on a AMD K6 machine (which often fails). No. Compiled a 686 smp kernel. Have 2 Pentium Pro processors. > I suspect that either the following might be a problem: > - Buggy compiler (what are you using) Used gcc 2.95. Is 3.2 required? > - Compiling for the wrong architecture (what are you compiling for) What would you suggest? i386? > - Hardware problem (Failing fan, memory). Probably not, as the SuSE distrib boots from an xfs partition perfectly on another disk in the same system. Lucien -- If you receive this by error, please delete it and inform the sender. PGP key fingerprint=F1C0 D9AE 1B18 1405 4DFA B4CC 6DC7 FF78 C76E FB15 To Big Brother Echelon from "spook": Sudan colonel Rule Psix Kandahar Peking quiche counter-intelligence FBI From owner-linux-xfs@oss.sgi.com Fri Jan 3 12:39:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 12:39:53 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03Kdn3v016828 for ; Fri, 3 Jan 2003 12:39:50 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18UYgk-0002VI-00; Fri, 03 Jan 2003 20:45:06 +0000 Date: Fri, 3 Jan 2003 20:45:06 +0000 From: Christoph Hellwig To: Seth Mos Cc: Patrick_Coleman@raytheon.com, linux-xfs@oss.sgi.com Subject: Re: linux Message-ID: <20030103204506.A9477@infradead.org> References: <4.3.2.7.2.20030103200552.041510c0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4.3.2.7.2.20030103200552.041510c0@pop.xs4all.nl>; from knuffie@xs4all.nl on Fri, Jan 03, 2003 at 08:07:31PM +0100 X-archive-position: 2208 X-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 On Fri, Jan 03, 2003 at 08:07:31PM +0100, Seth Mos wrote: > >Can you run Linux on an SGI O2 machine? > > AFAIK, there have been some tries in the past. Graphics is out of the > question though, serial console is the only option. I also believe only the > R5K series were a possibility. O2 framebuffer and video drivers in early stages were posted on linux-mips recently. There's no out of the box distribution for the O2 that I know of yet. From owner-linux-xfs@oss.sgi.com Fri Jan 3 12:39:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 12:39:22 -0800 (PST) Received: from borg-cube.no-ip.com (30.57-136-217.adsl.skynet.be [217.136.57.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03KdF3v016681 for ; Fri, 3 Jan 2003 12:39:17 -0800 Received: from skynet.be (borg-cube.no-ip.com [127.0.0.1]) by borg-cube.no-ip.com (8.11.6/8.11.6) with ESMTP id h03KWq305473; Fri, 3 Jan 2003 21:32:52 +0100 Message-ID: <3E15F374.8C3F2222@skynet.be> Date: Fri, 03 Jan 2003 21:32:52 +0100 From: kris buggenhout X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.19-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jameel Akari , "linux-xfs@oss.sgi.com" Subject: Re: linux References: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1861 X-archive-position: 2207 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kris.buggenhout@skynet.be Precedence: bulk X-list: linux-xfs Jameel Akari wrote: > On Fri, 3 Jan 2003, Seth Mos wrote: > > > At 12:15 3-1-2003 -0500, Patrick_Coleman@raytheon.com wrote: > > >Hi, > > > > > >Can you run Linux on an SGI O2 machine? > > No. > > > AFAIK, there have been some tries in the past. Graphics is out of the > > question though, serial console is the only option. I also believe only the > > R5K series were a possibility. > > Yeah, last time I looked, there was a partially working Linux for > Indys (R4K/R5K) that ran in serial console. No graphics. Might have been > multiuser, maybe not. Even though I have a working Indy, I stuck with > Irix. > wrong, indy's have full support for linux, even the gfx. R4/R5K There is an indigo 2 linux which is serial console only and the O2 is being worked on, but serial at the moment ... see here : http://www.debian.org/ports/mips/ http://www.rocklinux.org/projects/mips/ and also more comprehensible: http://web.inter.nl.net/users/schnecke/mips/mips-howto.html Where there is stated support for R10K on O2 and Indigo2 > > I also thought I had seen dmesg from where some brave soul had > booted a Linux SMP kernel on a Origin or something with like 32 > processors.. no idea if that was a hoax, or what became of it. there i one from sgi themselves, linux scalability project, Origin 2000 with 128 cpus even... ftp://oss.sgi.com/projects/linux-scalability/download/ but i guess this project has been set on hold... > > > Given the published SGI strategy of Linux on x86 and IRIX on MIPS, > something tells me any Linux on SGI MIPS machines is going to be a total > hack anyway. Actually a few years ago, they anounced the end of IRIX and MIPS , but lately these eol's have been postponed. !!! wonder why... might it be that itanium does not deliver its promises ? -- [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Jan 3 12:44:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 12:44:55 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03Kip3v017598 for ; Fri, 3 Jan 2003 12:44:52 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18UYlc-0002Wi-00; Fri, 03 Jan 2003 20:50:08 +0000 Date: Fri, 3 Jan 2003 20:50:08 +0000 From: Christoph Hellwig To: Jameel Akari Cc: linux-xfs@oss.sgi.com Subject: Re: linux Message-ID: <20030103205008.B9477@infradead.org> References: <4.3.2.7.2.20030103200552.041510c0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jakari@bithose.com on Fri, Jan 03, 2003 at 02:25:13PM -0500 X-archive-position: 2209 X-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 On Fri, Jan 03, 2003 at 02:25:13PM -0500, Jameel Akari wrote: > > >Can you run Linux on an SGI O2 machine? > > No. You might not be able to get it working yet, maby other people not either. But there is an early port and some people at least claim it boots :) > Yeah, last time I looked, there was a partially working Linux for > Indys (R4K/R5K) that ran in serial console. No graphics. Might have been > multiuser, maybe not. Even though I have a working Indy, I stuck with > Irix. The indy in my cubicle (running debian woody) runs nicely under X. You don't really want to use gnome or kde on it it's pretty useable for occasional testing on big-endian linux boxens. > I also thought I had seen dmesg from where some brave soul had > booted a Linux SMP kernel on a Origin or something with like 32 > processors.. no idea if that was a hoax, or what became of it. http://www.uwsg.iu.edu/hypermail/linux/kernel/0103.0/0239.html From owner-linux-xfs@oss.sgi.com Fri Jan 3 12:50:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 12:50:38 -0800 (PST) Received: from woody.fsl.noaa.gov (woody.fsl.noaa.gov [137.75.132.225]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03KoZ3v018208 for ; Fri, 3 Jan 2003 12:50:36 -0800 Received: from woody.fsl.noaa.gov (woody.fsl.noaa.gov [127.0.0.1]) by woody.fsl.noaa.gov (8.12.5/8.12.5) with ESMTP id h03Kttbl013354; Fri, 3 Jan 2003 13:55:55 -0700 Received: (from tierney@localhost) by woody.fsl.noaa.gov (8.12.5/8.12.5/Submit) id h03KttK1013352; Fri, 3 Jan 2003 13:55:55 -0700 Date: Fri, 3 Jan 2003 13:55:55 -0700 From: Craig Tierney To: "Daniel E. Shipton" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and tg3 driver Message-ID: <20030103205554.GB13321@hpti.com> References: <1041624558.19560.6.camel@regatta.vrac.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1041624558.19560.6.camel@regatta.vrac.iastate.edu> User-Agent: Mutt/1.4i X-archive-position: 2210 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@hpti.com Precedence: bulk X-list: linux-xfs On Fri, Jan 03, 2003 at 02:09:18PM -0600, Daniel E. Shipton wrote: > Is anyone using a Broadcom card with the tg3 driver on a smp system. We > have a dell 4600 that locks every other day. There is a redhat errata > about this at https://rhn.redhat.com/errata/RHBA-2002-292.html . I > can't find a patch for that kernel to fix our problem......any > suggestions? I am currently testing a P3 smp (Dell 4500) system with using the tg3 driver over XFS. Disks are Fibre Channel pushing 100 MB/s for reads and writes. It is holding up very well. It holds up under extreme load (64 nodes writing multiple GB files over NFS), It was running 10 nodes writing files continuously for 12 weeks. Heavy load tests on the disk directly showed stable performance, but I wasn't running the load on the disks directly for more than an hour at a time. I am going to upgrade our 6 other NFS servers to this setup. All filesystems are going to be converted from ext3 to xfs. Redhat 8.0 Stock 2.4.20 kernel, added Trond's NFS patches Qla2200 v6.01.00 driver Craig > > thanks > Daniel E. Shipton > > Virtual Reality Application Center > > > > > > -- Craig Tierney (ctierney@hpti.com) From owner-linux-xfs@oss.sgi.com Fri Jan 3 12:50:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 12:50:51 -0800 (PST) Received: from poptart.bithose.com (ip-204-97-176-41.modem.logical.net [204.97.176.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03Koj3v018294 for ; Fri, 3 Jan 2003 12:50:46 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.2/8.12.2) with ESMTP id h03Ku5N1044377; Fri, 3 Jan 2003 15:56:05 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.2/8.12.2/Submit) with ESMTP id h03Ku53O044382; Fri, 3 Jan 2003 15:56:05 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Fri, 3 Jan 2003 15:56:05 -0500 (EST) From: Jameel Akari To: kris buggenhout cc: "linux-xfs@oss.sgi.com" Subject: Re: linux In-Reply-To: <3E15F374.8C3F2222@skynet.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: linux-xfs On Fri, 3 Jan 2003, kris buggenhout wrote: > Jameel Akari wrote: > > Yeah, last time I looked, there was a partially working Linux for > wrong, indy's have full support for linux, even the gfx. R4/R5K Well, I guess I stand corrected. Sorry. Emphasis on "last time I checked" which I think was June or July? I was going to follow up withe the NetBSD sgi-mips port, which I know mostly works, but the question was about Linux. All the Linux links are good to know about seeing as its gets increasingly difficult to get patches for IRIX (the maint. releases aren't a free download anymore as far as I can tell) I'm not going to pay for a SGI contract just to get my Indy or Octane up to 6.5.14. Sorry, can't afford a shiny new Octane2 with a new contract... ;) #!/jameel/akari sleep 4800; make clean && make breakfast From owner-linux-xfs@oss.sgi.com Fri Jan 3 13:36:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 13:36:29 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03LaN3v019704 for ; Fri, 3 Jan 2003 13:36:24 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h03HgGG8015435 for ; Fri, 3 Jan 2003 09:42:16 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA12108; Fri, 3 Jan 2003 13:42:07 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA12699; Fri, 3 Jan 2003 13:42:07 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h03Jg7D10981; Fri, 3 Jan 2003 13:42:07 -0600 Subject: Re: linux From: Steve Lord To: Jameel Akari Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1041622927.3079.129.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 03 Jan 2003 13:42:07 -0600 X-archive-position: 2212 X-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@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2003-01-03 at 13:25, Jameel Akari wrote: > > I also thought I had seen dmesg from where some brave soul had > booted a Linux SMP kernel on a Origin or something with like 32 > processors.. no idea if that was a hoax, or what became of it. Look in the linux kernel source for sn0 support, that's the hardware that was running linux. We do run linux on 64 cpus internally, but that is on intel processors, not sure what the highest mips cpu count linux has run on, we have Irix running on 512 cpus at customer sites though. > > Given the published SGI strategy of Linux on x86 and IRIX on MIPS, > something tells me any Linux on SGI MIPS machines is going to be a total > hack anyway. > Well, not a total hack, but graphics on old hardware is a lot of work for someone to make xfree support it, and I do not think the company is willing or able to release the specs of the chips to let someone else do it. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jan 3 13:49:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 13:49:51 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03Lnl3v020676 for ; Fri, 3 Jan 2003 13:49:48 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h03Lt6Qp045145; Fri, 3 Jan 2003 22:55:06 +0100 (CET) Message-Id: <4.3.2.7.2.20030103224859.04155420@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Jan 2003 22:55:02 +0100 To: "Daniel E. Shipton" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS and tg3 driver In-Reply-To: <1041624558.19560.6.camel@regatta.vrac.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 14:09 3-1-2003 -0600, Daniel E. Shipton wrote: >Is anyone using a Broadcom card with the tg3 driver on a smp system. We >have a dell 4600 that locks every other day. There is a redhat errata >about this at https://rhn.redhat.com/errata/RHBA-2002-292.html . I >can't find a patch for that kernel to fix our problem......any >suggestions? Install the kernel-source rpm. Download the tg3 1.2 driver from http://people.redhat.com/garzik/ and patch the driver. Recompile this kernel and the lockups should go away. As noted on linux-poweredge@dell.com the actual speed may be of influence as well. Most people that see the crashes are using the card in 100Mbit mode. I myself and a few others have not seen this problem yet on with the card connected at gigabit speeds. The 2.4.18-19 kernel still did not fix the lockups reading comments from the other list. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Jan 3 13:51:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 13:51:07 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h03Lp23v021110 for ; Fri, 3 Jan 2003 13:51:03 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h03LuLka004392; Fri, 3 Jan 2003 22:56:22 +0100 (CET) Message-Id: <4.3.2.7.2.20030103225549.0415d568@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Jan 2003 22:56:17 +0100 To: "Daniel E. Shipton" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS and tg3 driver Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2214 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 14:09 3-1-2003 -0600, Daniel E. Shipton wrote: >Is anyone using a Broadcom card with the tg3 driver on a smp system. We >have a dell 4600 that locks every other day. There is a redhat errata >about this at https://rhn.redhat.com/errata/RHBA-2002-292.html . I >can't find a patch for that kernel to fix our problem......any >suggestions? That should have been http://people.redhat.com/jgarzik/ Gomen -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Jan 3 15:20:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Jan 2003 15:20:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h03NKC3v024921 for ; Fri, 3 Jan 2003 15:20:12 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h03NKCL7024920 for linux-xfs@oss.sgi.com; Fri, 3 Jan 2003 15:20:12 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h03NKA3x024903 for ; Fri, 3 Jan 2003 15:20:10 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h03NFGBu024885; Fri, 3 Jan 2003 15:15:16 -0800 Date: Fri, 3 Jan 2003 15:15:16 -0800 Message-Id: <200301032315.h03NFGBu024885@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 205] make install fails to properly symlink and copy the libraries X-Bugzilla-Reason: AssignedTo X-archive-position: 2215 X-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=205 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From nathans@sgi.com 2003-01-03 15:15 ------- > > ./configure --prefix=/usr --localstatedir=/var --mandir=/usr/share/man && \ > make && \ > make install && \ > make install-dev > You are overriding some of the places where the build will later be installing things, and leaving the rest as the defaults - no surpise that nothing works this way. A working set of configure options are included in the top level Makefiles (eg. cmd/acl/Makefile). If you omit the ./configure step in your example above, you will find that everything works as you would expect. You may also want to try the ./Makepkgs script, it can automate some steps for you (rpms, tars, debs can be auto-generated). cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Jan 4 03:46:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 04 Jan 2003 03:46:31 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h04BkM3v003228 for ; Sat, 4 Jan 2003 03:46:24 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18Umow-0007ZX-00 for ; Sat, 04 Jan 2003 12:50:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18UNnJ-0007mH-00 for ; Fri, 03 Jan 2003 10:07:09 +0100 Path: wassern.consult-meyers.com!news From: "A. L. Meyers" Subject: Re: kernel panic with Debian sarge 2.4.18 SMP and xfs Date: 03 Jan 2003 10:06:48 +0100 Organization: Meyers Consulting http://www.consult-meyers.com Lines: 46 Message-ID: References: <4.3.2.7.2.20030101163332.042137b0@pop.xs4all.nl> <4.3.2.7.2.20030102104717.03fe6e90@pop.xs4all.nl> Reply-To: "A. L. Meyers" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-archive-position: 2216 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nospam.look@replyto.because.this.is.invalid.sgi.com Precedence: bulk X-list: linux-xfs Seth Mos writes: > At 22:24 1-1-2003 +0100, A. Lucien Meyers wrote: > >Followed all your suggestions but, alas, exactly the same result. > >Here is some of the relevant output during the boot process which > >results in having to press the reset button: > > > >FAT: bogus logical sector size 0 > >FAT: bogus logical sector size 0 > >invalid operand: 0000 > >CPU: > >EIP: > >EFLAGS: > >Process swapper > >Call trace: > >Code: > ><0> Kernel panic: Attempted to kill init! > > Did you try to use high optimizations for the compile? Just standard setting, O2. Do you suggest reducing this to 1 or 0? > Or did you compile a i586 kernel on a AMD K6 machine (which often fails). No. Compiled a 686 smp kernel. Have 2 Pentium Pro processors. > I suspect that either the following might be a problem: > - Buggy compiler (what are you using) Used gcc 2.95. Is 3.2 required? > - Compiling for the wrong architecture (what are you compiling for) What would you suggest? i386? > - Hardware problem (Failing fan, memory). Probably not, as the SuSE distrib boots from an xfs partition perfectly on another disk in the same system. Lucien -- If you receive this by error, please delete it and inform the sender. PGP key fingerprint=F1C0 D9AE 1B18 1405 4DFA B4CC 6DC7 FF78 C76E FB15 To Big Brother Echelon from "spook": Delta Force Sharon heroine FSF Serbian plutonium arrangements NORAD Nazi From owner-linux-xfs@oss.sgi.com Sun Jan 5 01:25:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jan 2003 01:26:02 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h059Po3v017749 for ; Sun, 5 Jan 2003 01:25:52 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18V76m-0008Rg-00 for ; Sun, 05 Jan 2003 10:30:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18V6we-00086F-00 for ; Sun, 05 Jan 2003 10:19:48 +0100 Path: not-for-mail From: "Stig Are M. Botterli" Subject: execute bit on new files Date: Sun, 5 Jan 2003 09:19:48 +0000 (UTC) Lines: 3 Message-ID: X-Complaints-To: usenet@main.gmane.org User-Agent: slrn/0.9.7.4 (Linux) X-archive-position: 2217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: samb@mo.himolde.no Precedence: bulk X-list: linux-xfs Using ACLs, is it possible to make it so that all new files below a particular dir are created with the execute bit set? While the umask can be overridden by setting the default ACL, it seems the execute bit won't take. From owner-linux-xfs@oss.sgi.com Sun Jan 5 15:06:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jan 2003 15:06:43 -0800 (PST) Received: from zork.zork.net (mail@zork.zork.net [66.92.188.166]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h05N6X3v008890 for ; Sun, 5 Jan 2003 15:06:34 -0800 Received: from sneakums by zork.zork.net with local (Exim 3.35 #1 (Debian)) id 18VJvy-0004bR-00; Sun, 05 Jan 2003 15:11:58 -0800 To: linux-xfs@oss.sgi.com Subject: Re: execute bit on new files References: From: Sean Neakums X-Worst-Pick-Up-Line-Ever: "Hey baby, wanna peer with my leafnode instance?" X-Message-Flag: Message text advisory: DENIAL OF THE ANTECEDENT, AMPHIBOLY X-Mailer: Norman X-Groin-Mounted-Steering-Wheel: "Arrrr... it's driving me nuts!" X-Alameda: WHY DOESN'T ANYONE KNOW ABOUT ALAMEDA? IT'S RIGHT NEXT TO OAKLAND!!! Organization: The Emadonics Institute Mail-Followup-To: linux-xfs@oss.sgi.com Date: Sun, 05 Jan 2003 15:11:57 -0800 In-Reply-To: ("Stig Are M. Botterli"'s message of "Sun, 5 Jan 2003 09:19:48 +0000 (UTC)") Message-ID: <6u3co76vk2.fsf@zork.zork.net> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2218 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sneakums@zork.net Precedence: bulk X-list: linux-xfs commence Stig Are M. Botterli quotation: > Using ACLs, is it possible to make it so that all new files below a > particular dir are created with the execute bit set? While the umask > can be overridden by setting the default ACL, it seems the execute > bit won't take. The umask does not give but take away; the mode passed by the application has all of the set bits in the umask turned off. If the application does not have the execute bit set in the mode it passes to open/creat, then I do not believe there is a way to use ACLs to force execute on for all cases. -- / | [|] Sean Neakums | Questions are a burden to others; [|] | answers a prison for oneself. \ | From owner-linux-xfs@oss.sgi.com Sun Jan 5 17:20:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jan 2003 17:20:14 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h061KC3v010445 for ; Sun, 5 Jan 2003 17:20:12 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h061KCqo010444 for linux-xfs@oss.sgi.com; Sun, 5 Jan 2003 17:20:12 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h061KA3x010430 for ; Sun, 5 Jan 2003 17:20:10 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h061K9v3010427; Sun, 5 Jan 2003 17:20:09 -0800 Date: Sun, 5 Jan 2003 17:20:09 -0800 Message-Id: <200301060120.h061K9v3010427@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 205] make install fails to properly symlink and copy the libraries X-Bugzilla-Reason: AssignedTo X-archive-position: 2219 X-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=205 ------- Additional Comments From bootsy52@gmx.net 2003-01-05 17:20 ------- 1. It's new to me that you couldn't use configure options, because for what are they there otherwise. 2. A complete Gnome Build with --prefix=/opt/gnome2 --sysconfdir=/etc/gnome2 --localstatedir=/var installs everything the way expected, despite of that some defaults are overidden and some are not. XFS Progs are the first packages that do not. Every other program I build so far, behaves (in my eyes) correctly. 3. Even if I just run ./configure make make install install-lib the installation procedure fails to copy (example taken from attr-2.1.1) libattr.so to /usr/local/lib, so the installation procedure is buggy, this is also true for the provided rpm's as you can see here: http://rpmfind.net//linux/RPM/SGI/xfs/cmd_rpms/i386/libattr-2.1.1-0.i386.html 4. If only some of the configure parameters could be used then this should in my eyes at least documented in doc/INSTALL where currently is no info about that you can only use a specific combination of configure Arguments. Please correct me if I'm wrong ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Jan 5 17:44:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jan 2003 17:44:08 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h061i73v011001 for ; Sun, 5 Jan 2003 17:44:07 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h061i7xx011000 for linux-xfs@oss.sgi.com; Sun, 5 Jan 2003 17:44:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h061i53x010986 for ; Sun, 5 Jan 2003 17:44:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h061PqbS010909; Sun, 5 Jan 2003 17:25:52 -0800 Date: Sun, 5 Jan 2003 17:25:52 -0800 Message-Id: <200301060125.h061PqbS010909@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 205] make install fails to properly symlink and copy the libraries X-Bugzilla-Reason: AssignedTo X-archive-position: 2220 X-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=205 ------- Additional Comments From bootsy52@gmx.net 2003-01-05 17:25 ------- Even a better example is: http://rpmfind.net//linux/RPM/SGI/xfs/cmd_rpms/contributed-OpenLinux/RPMS/libxfs-2.0.4-1.i386.html ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Jan 5 18:26:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jan 2003 18:26:49 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h062Qi3v011694 for ; Sun, 5 Jan 2003 18:26:45 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h061bnKp016344 for ; Sun, 5 Jan 2003 17:37:51 -0800 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA08384; Mon, 6 Jan 2003 13:30:49 +1100 (AEDT) Date: Mon, 6 Jan 2003 13:30:49 +1100 From: Tim Shimmin To: LA Walsh Cc: linux-xfs@oss.sgi.com Subject: Re: building xfsdump... Message-ID: <20030106133049.B2704933@boing.melbourne.sgi.com> References: <20030102054140.GA18962@wotan.suse.de> <000601c2b254$2ee8c940$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <000601c2b254$2ee8c940$1403a8c0@sc.tlinx.org>; from law@tlinx.org on Thu, Jan 02, 2003 at 03:43:35AM -0800 X-archive-position: 2221 X-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 Hi there, On Thu, Jan 02, 2003 at 03:43:35AM -0800, LA Walsh wrote: > I changed the 'curses' check to check 'ncurses' instead and everything > seemed to make. Is curses/ncurses actually used in xfsdump/restore? > It is not used by xfsdump or xfsrestore but by xfsinvutil(8) for interactively modifying the dump inventory. Looking at xfsdump/configure.in logs: ---------------------------- revision 1.25 date: 2002/11/07 15:19:20; author: hch; state: Exp; lines: +7 -7 modid: xfs-cmds:slinx:132304a check for ncurses instead of curses check for ncurses.h instead of curses.h and libncurses instead of libcurses ---------------------------- it appears that the switch to ncurses was made on Nov 7 last year. --Tim From owner-linux-xfs@oss.sgi.com Sun Jan 5 20:14:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Jan 2003 20:14:14 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h064E73v012713 for ; Sun, 5 Jan 2003 20:14:07 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h064E70K012712 for linux-xfs@oss.sgi.com; Sun, 5 Jan 2003 20:14:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h064E53x012698 for ; Sun, 5 Jan 2003 20:14:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h063pgLg012561; Sun, 5 Jan 2003 19:51:42 -0800 Date: Sun, 5 Jan 2003 19:51:42 -0800 Message-Id: <200301060351.h063pgLg012561@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 205] make install fails to properly symlink and copy the libraries X-Bugzilla-Reason: AssignedTo X-archive-position: 2222 X-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=205 ------- Additional Comments From sandeen@sgi.com 2003-01-05 19:51 ------- Please try a later version, your configure parameters in version 2.2.1 seem to do the right thing. However, some parts of the configure script may well be broken and the build system could probably use some maintenance. If anyone is good at this stuff, please submit a patch. This kind of work is going to be fairly low on the TODO list for a while. However, it's a great candidate for community involvement... Thanks, -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 01:44:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 01:44:29 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h069iA3v015728 for ; Mon, 6 Jan 2003 01:44:10 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h069iA3J015721 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 01:44:10 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h069i647015667 for ; Mon, 6 Jan 2003 01:44:07 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h069XdHl015573; Mon, 6 Jan 2003 01:33:39 -0800 Date: Mon, 6 Jan 2003 01:33:39 -0800 Message-Id: <200301060933.h069XdHl015573@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 2225 X-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=197 ------- Additional Comments From knutjbj@online.no 2003-01-06 01:33 ------- Created an attachment (id=57) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=57&action=view) output of strace ls /var/lock/subsys ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 01:44:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 01:44:19 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h069iA3v015725 for ; Mon, 6 Jan 2003 01:44:10 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h069iAuc015724 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 01:44:10 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h069i645015667 for ; Mon, 6 Jan 2003 01:44:07 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h069WHGP015552; Mon, 6 Jan 2003 01:32:17 -0800 Date: Mon, 6 Jan 2003 01:32:17 -0800 Message-Id: <200301060932.h069WHGP015552@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 2223 X-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=197 ------- Additional Comments From knutjbj@online.no 2003-01-06 01:32 ------- This bug is harder to hit in 1.2pre4. I' amd send along output off strace ls /var/lock/subsys and xfs_repair /dev/hdb2. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 01:44:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 01:44:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h069iA3v015727 for ; Mon, 6 Jan 2003 01:44:10 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h069iA4H015722 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 01:44:10 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h069i649015667 for ; Mon, 6 Jan 2003 01:44:07 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h069YWHT015601; Mon, 6 Jan 2003 01:34:32 -0800 Date: Mon, 6 Jan 2003 01:34:32 -0800 Message-Id: <200301060934.h069YWHT015601@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 2224 X-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=197 knutjbj@online.no changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #57 mime|application/octet-stream |text/plain type| | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 01:44:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 01:44:37 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h069iA3v015726 for ; Mon, 6 Jan 2003 01:44:10 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h069iAcm015723 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 01:44:10 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h069i64B015667 for ; Mon, 6 Jan 2003 01:44:07 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h069Za1x015617; Mon, 6 Jan 2003 01:35:36 -0800 Date: Mon, 6 Jan 2003 01:35:36 -0800 Message-Id: <200301060935.h069Za1x015617@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 2226 X-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=197 ------- Additional Comments From knutjbj@online.no 2003-01-06 01:35 ------- Created an attachment (id=58) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=58&action=view) output from xfs_repair /dev/hdb2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 01:50:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 01:50:14 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h069oB3v017536 for ; Mon, 6 Jan 2003 01:50:11 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h069oBGS017535 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 01:50:11 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h069oA3x017520 for ; Mon, 6 Jan 2003 01:50:10 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h069iPS9015822; Mon, 6 Jan 2003 01:44:25 -0800 Date: Mon, 6 Jan 2003 01:44:25 -0800 Message-Id: <200301060944.h069iPS9015822@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 2227 X-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=197 ------- Additional Comments From knutjbj@online.no 2003-01-06 01:44 ------- This bug might be similar to bug 204, since I alsa get error -990 when trying to do touch /var/lock/subsys/kuduzu, rm /var/lock/subsys/* and ls /var/lock/subsys/*. XFS 1.2pre4 kernel 2.4.18-18SGI_1.2pre4, gcc 3.2.1-2. Harddisk IC35L060AVER07-0 IBM 60XP 60 mb. Corrputer from bug 198 cause no corrpution with 1.2pre4. distrubution Redhat 8.0. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 06:51:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 06:51:33 -0800 (PST) Received: from mail-gw.farmexim.ro (mail-gw.farmexim.ro [217.156.6.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h06Ep63v023943 for ; Mon, 6 Jan 2003 06:51:07 -0800 Received: from 127.0.0.1 (localhost [127.0.0.1]) by email.farmexim.ro (Postfix) with SMTP id 181AB17ACE for ; Mon, 6 Jan 2003 16:33:18 +0200 (EET) Received: from localhost.localdomain (busybox.farmexim.intern [192.168.1.60]) by mail-gw.farmexim.ro (Postfix) with ESMTP id C445517ACC for ; Mon, 6 Jan 2003 16:33:17 +0200 (EET) Subject: xfs questions From: Dragos Delcea To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jan 2003 16:33:17 +0200 Message-Id: <1041863597.1699.80.camel@busybox> Mime-Version: 1.0 X-archive-position: 2228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dragos.delcea@farmexim.ro Precedence: bulk X-list: linux-xfs Happy new year to you all xfs developers & users! I'm evaluating xfs for use with the next incarnation of file server (samba/linux) for my company, and while getting used to it (great design, great implamentation - thanks SGI and xfs developers-) I came across a few little problems: -how does one recreate the log (external log, that is) after a device (hdd) crash? the xfs partition resides on an raid5 device, but the log itself resides on a simple disk; I browsed through man pages, but found no clue of how to do it; does it work like that to just mount as usually with "logdevice=/.." and automatically the log is recreated? sorry, I haven't tried that, I'm two disks short now and a little away from the server; fortunately, it's just a test setup (no data is lost). -also, on an earlier test run, I created an xfs partition with an internal log, (log) version 2; mkfs.xfs created it, but I could not mount it, it complained something about "invalid sb" (not quite sure, citing from memory); I'm on SuSE 8.1 with an updated kernel (still from SuSE, ready compiled (from SLES8, used for oracle certification I think), xfsutils and xfsdump from distribution). I know I should ask them, but I have a feeling that I'm doing something wrong. as a side note, when toying with xfsdump and xfsinvutil, I observed that the UUID of the partition got set to 0000...; when doing a dump, xfsdump gave me the message: xfsdump: getting UUID of the device: operation (ioctl?) not supported (again from memory); yes, I shoud ask SuSE about that, but does that impact restoring from back-up in any way? thanks for your time, dragos delcea From owner-linux-xfs@oss.sgi.com Mon Jan 6 07:24:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 07:24:47 -0800 (PST) Received: from mail-gw.farmexim.ro (mail-gw.farmexim.ro [217.156.6.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h06FOe3v025391 for ; Mon, 6 Jan 2003 07:24:41 -0800 Received: from 127.0.0.1 (localhost [127.0.0.1]) by email.farmexim.ro (Postfix) with SMTP id B1FBE17ACB; Mon, 6 Jan 2003 17:28:01 +0200 (EET) Received: from localhost.localdomain (busybox.farmexim.intern [192.168.1.60]) by mail-gw.farmexim.ro (Postfix) with ESMTP id 6D87B17AC5; Mon, 6 Jan 2003 17:27:57 +0200 (EET) Subject: Re: xfs questions From: Dragos Delcea To: Mihai RUSU Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jan 2003 17:27:57 +0200 Message-Id: <1041866877.1699.91.camel@busybox> Mime-Version: 1.0 X-archive-position: 2229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dragos.delcea@farmexim.ro Precedence: bulk X-list: linux-xfs On Mon, 2003-01-06 at 17:29, Mihai RUSU wrote: > Hi Dragos > > On 6 Jan 2003, Dragos Delcea wrote: > > > -how does one recreate the log (external log, that is) after a device > > (hdd) crash? the xfs partition resides on an raid5 device, but the log > > itself resides on a simple disk; I browsed through man pages, but found > > no clue of how to do it; does it work like that to just mount as usually > > with "logdevice=/.." and automatically the log is recreated? sorry, I > > haven't tried that, I'm two disks short now and a little away from the > > server; fortunately, it's just a test setup (no data is lost). > > I think the best thing to do is to backup your log partition. This is what > I do on every server with XFS external log: > cp /dev/logpartition xfs-log you mean dd if=/dev/logpartition of=./xfs_log, right? > anyway, you made your point. > Keep that backup somewhere safe and after you loose your XFS log should be > enough to cp xfs-log /dev/logpartition (while the XFS volume is not > mounted). Notice that you will need a xfs_repair tho. > > > -also, on an earlier test run, I created an xfs partition with an > > internal log, (log) version 2; mkfs.xfs created it, but I could not > > mount it, it complained something about "invalid sb" (not quite sure, > > citing from memory); I'm on SuSE 8.1 with an updated kernel (still from > > SuSE, ready compiled (from SLES8, used for oracle certification I > > think), xfsutils and xfsdump from distribution). I know I should ask > > them, but I have a feeling that I'm doing something wrong. > > The XFS version 2 log works with latest XFS code (1.2pre or late CVS). > Are you sure the XFS bits you are using do support version 2 log ? I'm pretty sure it's at least 1.2preX; while compiling a kernel from SuSE sources the xfs suboptions were: [*] include realtime support [*] enable DMAPI support, so I assume that is at least 1.2pre; as for userland, if mkfs.xfs din't barf at logversion=2 I think it should support it. thanks, dragos PS I'm delighted to see romanian users here! (besides me, that is) > > ---------------------------- > Mihai RUSU From owner-linux-xfs@oss.sgi.com Mon Jan 6 08:23:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 08:23:20 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h06GN93v026340 for ; Mon, 6 Jan 2003 08:23:10 -0800 Received: (qmail 9510 invoked by uid 1000); 6 Jan 2003 16:47:58 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Jan 2003 16:47:58 -0000 Date: Mon, 6 Jan 2003 18:47:58 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Dragos Delcea cc: Linux XFS List Subject: Re: xfs questions In-Reply-To: <1041866877.1699.91.camel@busybox> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs On 6 Jan 2003, Dragos Delcea wrote: > > cp /dev/logpartition xfs-log > you mean dd if=/dev/logpartition of=./xfs_log, right? :) I see many people used to dd but cp works very well too (dd has some other cool features tho). I forgot to mention, that log backup should be done between mkfs.xfs and the first mount (but probably should work after any other clean umount). > I'm pretty sure it's at least 1.2preX; while compiling a kernel from > SuSE sources the xfs suboptions were: [*] include realtime support [*] > enable DMAPI support, so I assume that is at least 1.2pre; as for > userland, if mkfs.xfs din't barf at logversion=2 I think it should > support it. Heh, realtime and DMAPI are in XFS for linux for some time now (since I first got into XFS, arround 1.0.1 release). mkfs.xfs clearly is a new version that knows about log version 2 but Im not sure your XFS part of kernel does know that. For example, try to compile latest CVS or a 1.2 prerelease and boot it and see if it still complains. ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Mon Jan 6 09:14:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 09:14:15 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06HE83v027320 for ; Mon, 6 Jan 2003 09:14:08 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06HE8v8027319 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 09:14:08 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06HE63x027305 for ; Mon, 6 Jan 2003 09:14:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06GpIKK026977; Mon, 6 Jan 2003 08:51:18 -0800 Date: Mon, 6 Jan 2003 08:51:18 -0800 Message-Id: <200301061651.h06GpIKK026977@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 206] New: XFS filesysem corruption while umounting sw raid 1 X-Bugzilla-Reason: AssignedTo X-archive-position: 2231 X-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=206 Summary: XFS filesysem corruption while umounting sw raid 1 Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: daniel.stanek@mius.cz If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.20 with thirdparty patches Where did the XFS code come from? (CVS, Linus, your distribution, etc): SGI Description of Problem: redhat-7.2 kernel-2.4.20 with patches: freeswan-1.99, netfilter patch-o-matic 20021227, imq, i2c 2.7.0 and lm_sensors 2.7.0, lvm-1.0.6 and ext3_fixes from official web site (maybe the source of problems because of fixes in umount code in 2.4.20) xfs patch version: SGI XFS snapshot 2.4.20-2002-11-29_01:21_UTC with ACLs, DMAPI, quota, no debug enabled running on PIII/1200, xfs on sw raid md1 (system /) and xfs on md2 (data /mnt/vol2) mount options: quota quota utils: quota-3.06 symptoms: - could not run quotas on root filesystem Enabling group quota on root filesystem (reboot to take effect) quotaon: quotactl on /dev/md1: Invalid argument Enabling user quota on root filesystem (reboot to take effect) quotaon: quotactl on /dev/md1: Invalid argument - when shutting down system after quotaon / on root filesystem: Shutting down system logger: xfs_force_shutdown(md(9,1),0x8) called from line 4044 of file xfs_bmap.c. Return address = 0xc0174b06 Filesystem "md(9,1)": Corruption of in-memory data detected. Shutting down filesystem: md(9,1) Please umount the filesystem, and rectify the problem(s). - after booting there are duplicate and bad files in /var/lock/subsys/ (I think this is one of the last modified dirs) How Reproducible: Steps to Reproduce: 1. xfs_restore from rescue disks 2. boot and quotaon / (error messages) 3. shutting down system Actual Results: Expected Results: Additional Information: I can send you all the patches or utils. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 13:50:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 13:50:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06LoE3v010707 for ; Mon, 6 Jan 2003 13:50:14 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06LoEgk010700 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 13:50:14 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06LoA4F010619 for ; Mon, 6 Jan 2003 13:50:12 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06Ljq2L010547; Mon, 6 Jan 2003 13:45:52 -0800 Date: Mon, 6 Jan 2003 13:45:52 -0800 Message-Id: <200301062145.h06Ljq2L010547@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 2232 X-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=197 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 13:50:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 13:50:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06LoE3v010708 for ; Mon, 6 Jan 2003 13:50:14 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06LoEmV010703 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 13:50:14 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06LoA4H010619 for ; Mon, 6 Jan 2003 13:50:12 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06LnRN2010603; Mon, 6 Jan 2003 13:49:27 -0800 Date: Mon, 6 Jan 2003 13:49:27 -0800 Message-Id: <200301062149.h06LnRN2010603@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 2236 X-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=197 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |t13_e@yahoo.com ------- Additional Comments From cattelan@thebarn.com 2003-01-06 13:49 ------- *** Bug 204 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 13:50:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 13:50:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06LoE3v010689 for ; Mon, 6 Jan 2003 13:50:14 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06LoE7v010688 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 13:50:14 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06LoA4B010619 for ; Mon, 6 Jan 2003 13:50:12 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06Lk0Sx010554; Mon, 6 Jan 2003 13:46:00 -0800 Date: Mon, 6 Jan 2003 13:46:00 -0800 Message-Id: <200301062146.h06Lk0Sx010554@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 204] directory /var/run got corrupted, got error -990 when trying to add a file X-Bugzilla-Reason: AssignedTo X-archive-position: 2235 X-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=204 ------- Additional Comments From be@berdmann.de 2003-01-06 13:45 ------- I've observed this behaviour on a Dell Latitude C610 as well. Using 2.4.19pre3-xfs, shutdown -r now and power off when BIOS screen appears. It even ate /etc/fstab. Seems to be related to "IDE disk does not flush write cache before power off". I inserted hdparm -f /dev/hda into /etc/init.d/halt. As well, I switched to 2.4.19pre4-xfs and got into the habit of shutdown -h now before power off. Haven't observed it in the mean time again. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 13:50:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 13:50:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06LoD3v010684 for ; Mon, 6 Jan 2003 13:50:13 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06LoD7v010683 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 13:50:13 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06LoA3v010619 for ; Mon, 6 Jan 2003 13:50:10 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06LlPAG010581; Mon, 6 Jan 2003 13:47:25 -0800 Date: Mon, 6 Jan 2003 13:47:25 -0800 Message-Id: <200301062147.h06LlPAG010581@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 202] XFS data corruption X-Bugzilla-Reason: AssignedTo X-archive-position: 2233 X-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=202 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |LATER ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 13:50:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 13:50:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06LoE3v010696 for ; Mon, 6 Jan 2003 13:50:14 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06LoEV4010694 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 13:50:14 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06LoA4D010619 for ; Mon, 6 Jan 2003 13:50:12 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06LnQku010599; Mon, 6 Jan 2003 13:49:26 -0800 Date: Mon, 6 Jan 2003 13:49:26 -0800 Message-Id: <200301062149.h06LnQku010599@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 204] directory /var/run got corrupted, got error -990 when trying to add a file X-Bugzilla-Reason: AssignedTo X-archive-position: 2234 X-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=204 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From cattelan@thebarn.com 2003-01-06 13:49 ------- *** This bug has been marked as a duplicate of 197 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 14:14:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 14:14:10 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06ME73v013059 for ; Mon, 6 Jan 2003 14:14:07 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06ME7qn013058 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 14:14:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h06ME641013042 for ; Mon, 6 Jan 2003 14:14:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h06Lri9q012716; Mon, 6 Jan 2003 13:53:44 -0800 Date: Mon, 6 Jan 2003 13:53:44 -0800 Message-Id: <200301062153.h06Lri9q012716@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 2237 X-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=197 ------- Additional Comments From be@berdmann.de 2003-01-06 13:53 ------- I've observed this behaviour on a Dell Latitude C610. The directory /var/lock was empty, really empty: It did not even contain . and ..! After xfs_repair from the installer CD (linux rescue) it worked again, but /etc/fstab was empty. ls -l showed approx. 250 chars for /etc/fstab, but cat did not show any line. I had to recreate /etc/fstab. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 6 14:29:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Jan 2003 14:30:19 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h06MT63v013659 for ; Mon, 6 Jan 2003 14:29:37 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h06IXTG8005952 for ; Mon, 6 Jan 2003 10:33:29 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA51066 for ; Mon, 6 Jan 2003 14:33:20 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:8FTsJsLyxiYljweHBiMqryNdvjp/0NJq@chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA15649 for ; Mon, 6 Jan 2003 14:33:20 -0600 (CST) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by chuckle.americas.sgi.com (8.12.5/8.12.5) with ESMTP id h06KXKx1010436 for ; Mon, 6 Jan 2003 14:33:20 -0600 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.5/8.12.5/Submit) id h06KXKdJ010434 for linux-xfs@oss.sgi.com; Mon, 6 Jan 2003 14:33:20 -0600 Date: Mon, 6 Jan 2003 14:33:20 -0600 From: Russell Cattelan Message-Id: <200301062033.h06KXKdJ010434@chuckle.americas.sgi.com> Subject: TAKE - debug.c One more time :-) X-archive-position: 2238 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs make *cmn_err interrupt safe Date: Mon Jan 6 12:32:53 PST 2003 Workarea: chuckle.americas.sgi.com:/misc/xfs2/XFS/x2.4-xfs-devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136126a linux/fs/xfs/support/debug.c - 1.15 From owner-linux-xfs@oss.sgi.com Tue Jan 7 03:28:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jan 2003 03:28:36 -0800 (PST) Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h07BQ83v030747 for ; Tue, 7 Jan 2003 03:28:02 -0800 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id h07BVhM10853 for linux-xfs@oss.sgi.com.KAV; Tue, 7 Jan 2003 12:31:43 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id h07BVcP10771 for ; Tue, 7 Jan 2003 12:31:42 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id h07BV0305116 for ; Tue, 7 Jan 2003 12:31:00 +0100 Subject: xfsdump build problem - current CVS From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 07 Jan 2003 12:31:00 +0100 Message-Id: <1041939060.5075.4.camel@venus> Mime-Version: 1.0 X-archive-position: 2239 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Hi, CVS from yesterday. I use Makepkgs for creating rpms. The configure script for xfsdump wants dmapi.h. It tries to find it in /usr/include/xfs but the dmapi-devel package puts it in /usr/include/attr so it fails. Please correct. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Tue Jan 7 04:41:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jan 2003 04:41:55 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h07Cdm3v032421 for ; Tue, 7 Jan 2003 04:41:17 -0800 Received: (qmail 5970 invoked by uid 1000); 7 Jan 2003 13:04:43 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Jan 2003 13:04:43 -0000 Date: Tue, 7 Jan 2003 15:04:43 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: XFS mem leak ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Hi I have compiled and I am running late CVS version (SGI XFS CVS-2002-11-30_06:00_UTC with no debug enabled). I have noticed messages in the kernel log about "Out of memory: killing process...", but before upgrading the kernel I have never seen any such messages. The machine is over 2GB of memory and usually free reports 500mb used (the rest beeing cached). This is cat /proc/slabinfo | grep xfs xfs_chashlist 60926 79588 16 394 394 1 : 252 126 xfs_ili 25897 36596 140 1307 1307 1 : 252 126 xfs_ifork 0 0 56 0 0 1 : 252 126 xfs_efi_item 60 60 260 4 4 1 : 124 62 xfs_efd_item 60 60 260 4 4 1 : 124 62 xfs_buf_item 557 598 148 23 23 1 : 252 126 xfs_dabuf 202 202 16 1 1 1 : 252 126 xfs_da_state 22 22 336 2 2 1 : 124 62 xfs_trans 143 143 592 11 11 2 : 124 62 xfs_inode 141896 175850 400 17585 17585 1 : 124 62 xfs_btree_cur 58 58 132 2 2 1 : 252 126 xfs_bmap_free_item 252 253 12 1 1 1 : 252 126 If I remember well before upgrade the xfs_inode usage was arround 50000. This is xfs_info on the XFS filesystems mounted on that machine: # xfs_info /mnt/s1 meta-data=/mnt/s1 isize=256 agcount=35, agsize=1048576 blks data = bsize=4096 blocks=35830966, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =external bsize=4096 blocks=32768 realtime =none extsz=65536 blocks=0, rtextents=0 # xfs_info /mnt/s2 meta-data=/mnt/s2 isize=256 agcount=35, agsize=1048576 blks data = bsize=4096 blocks=35830966, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =external bsize=4096 blocks=32768 realtime =none extsz=65536 blocks=0, rtextents=0 Is that usage reported by slabinfo ok ? Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Tue Jan 7 08:44:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jan 2003 08:44:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h07Gi83v015574 for ; Tue, 7 Jan 2003 08:44:08 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h07Gi88O015572 for linux-xfs@oss.sgi.com; Tue, 7 Jan 2003 08:44:08 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h07Gi63x015555 for ; Tue, 7 Jan 2003 08:44:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h07GMj5M015407; Tue, 7 Jan 2003 08:22:45 -0800 Date: Tue, 7 Jan 2003 08:22:45 -0800 Message-Id: <200301071622.h07GMj5M015407@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 207] New: Filesystem corruption at boot, with data loss X-Bugzilla-Reason: AssignedTo X-archive-position: 2241 X-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=207 Summary: Filesystem corruption at boot, with data loss Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: dgborin@libero.it Kernel 2.4.20 with XFS patch 2002-11-29 and Kernel 2.4.19 with XFS patch 1.2pre4 Debian 3.0r0 with security patches, XFree 4.2.1, Gnome 2 e KDE 3. Both the patches from oss.sgi.com. At reboot, I randomly get a filesystem corruption: the first time the system wasn't able to mount /, the other times it wasn't able to read getty, so I coudn't read the other messages. Trying to fix with xfs_repair from xfsutils 2.3.6 wasn't possible because of an internal error. With the older version shipped with Debian 3.0r0 I was able to repair it. After the repairs, there was random data loss (entire files with 0 length). The problem never happened before, with kernel 2.4.19 with XFS patch 2002-09-27 and previous versions. Hardware configuration: AMD K6 1.3GHz ASUS A7V motherboard (VIA KT133) NVidia GeForce 2 MX 400 Creative SB Live! Adaptech SCSI controller 2940U DEC 10/100 ethernet controller (tulip driver) IBM 40GB hard disk (checked, it works OK) Additional kernel modules: ALSA 0.9pre6 NVidia driver 1.0-3123 Packet writing 2.4.19-2 (only with 2.4.19) All software compiled with gcc 2.95.4 (the version shipped with Debian 3.0). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Jan 7 13:28:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jan 2003 13:29:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h07LSk3v032391 for ; Tue, 7 Jan 2003 13:28:46 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h07LSki9032390 for linux-xfs@oss.sgi.com; Tue, 7 Jan 2003 13:28:46 -0800 Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h07LQp3v032359; Tue, 7 Jan 2003 13:28:44 -0800 Received: from localhost (localhost [127.0.0.1]) by tapu.f00f.org (Postfix) with ESMTP id 98C752014EF; Tue, 7 Jan 2003 13:32:29 -0800 (PST) Received: by tapu.f00f.org (Postfix, from userid 1000) id 1CAA32014F2; Tue, 7 Jan 2003 13:32:29 -0800 (PST) Date: Tue, 7 Jan 2003 13:32:29 -0800 From: Chris Wedgwood To: dgborin@libero.it, bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com Subject: Re: [Bug 207] New: Filesystem corruption at boot, with data loss Message-ID: <20030107213229.GB2671@tapu.f00f.org> References: <200301071622.h07GMj5M015407@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301071622.h07GMj5M015407@oss.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 2242 X-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 Tue, Jan 07, 2003 at 08:22:45AM -0800, bugzilla-daemon@oss.sgi.com wrote: > At reboot, I randomly get a filesystem corruption: the first time > the system wasn't able to mount /, the other times it wasn't able to > read getty, so I coudn't read the other messages. is the hd write-caching disabled? > After the repairs, there was random data loss (entire files with 0 > length). getting this for files that were open for writes is normal, in unrelated file it it not --cw From owner-linux-xfs@oss.sgi.com Tue Jan 7 17:05:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jan 2003 17:06:31 -0800 (PST) Received: from stumpy.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0813x3v001905 for ; Tue, 7 Jan 2003 17:05:52 -0800 Received: from stumpy.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by stumpy.chowhouse.com (8.12.6/8.12.6) with ESMTP id h081G15f007769; Tue, 7 Jan 2003 18:16:01 -0700 Received: from localhost (james@localhost) by stumpy.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id h081G1GR007766; Tue, 7 Jan 2003 18:16:01 -0700 Date: Tue, 7 Jan 2003 18:16:01 -0700 (MST) From: James Rich To: Jameel Akari cc: linux-xfs@oss.sgi.com Subject: Re: linux In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james@chowhouse.com Precedence: bulk X-list: linux-xfs On Fri, 3 Jan 2003, Jameel Akari wrote: > I also thought I had seen dmesg from where some brave soul had > booted a Linux SMP kernel on a Origin or something with like 32 > processors.. no idea if that was a hoax, or what became of it. I've seen this but it was a Sun E10K with 32 cpus. It compiled the kernel in something like 12 seconds. James Rich From owner-linux-xfs@oss.sgi.com Tue Jan 7 17:19:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jan 2003 17:19:51 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h081HO3v002414 for ; Tue, 7 Jan 2003 17:19:17 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h080SiKp006689 for ; Tue, 7 Jan 2003 16:28:44 -0800 Received: from wrlarun (sshgate.corp.sgi.com [169.238.216.146]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with SMTP id RAA59639; Tue, 7 Jan 2003 17:21:41 -0800 (PST) Message-ID: <03e301c2b6b3$df600b90$6601a8c0@attbi.com> From: "John Hawkes" To: "James Rich" , "Jameel Akari" Cc: References: Subject: Re: linux Date: Tue, 7 Jan 2003 17:18:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-archive-position: 2244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hawkes@sgi.com Precedence: bulk X-list: linux-xfs > On Fri, 3 Jan 2003, Jameel Akari wrote: > > > I also thought I had seen dmesg from where some brave soul had > > booted a Linux SMP kernel on a Origin or something with like 32 > > processors.. no idea if that was a hoax, or what became of it. > > I've seen this but it was a Sun E10K with 32 cpus. It compiled the kernel > in something like 12 seconds. > > James Rich It was a 128p Origin 2000. John Hawkes From owner-linux-xfs@oss.sgi.com Tue Jan 7 20:26:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jan 2003 20:26:47 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h084OF3v004144 for ; Tue, 7 Jan 2003 20:26:08 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h084askq014924 for ; Tue, 7 Jan 2003 22:36:55 -0600 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 h084SO3s1180238; Wed, 8 Jan 2003 15:28:25 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h084SMAL1157825; Wed, 8 Jan 2003 15:28:22 +1100 (EST) Date: Wed, 8 Jan 2003 15:28:22 +1100 (EST) From: Nathan Scott Message-Id: <200301080428.h084SMAL1157825@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: olaf@cbk.poznan.pl Subject: TAKE - dmapi include fix X-archive-position: 2245 X-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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix a merge botch after recent build changes. (attr -> xfs - thanks Olaf). Date: Tue Jan 7 20:27:31 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:136268a dmapi/include/builddefs.in - 1.19 From owner-linux-xfs@oss.sgi.com Tue Jan 7 21:05:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jan 2003 21:05:49 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0853M3v004977 for ; Tue, 7 Jan 2003 21:05:15 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h084EiKp019030 for ; Tue, 7 Jan 2003 20:14:44 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA87083 for ; Tue, 7 Jan 2003 23:08:56 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:35aFy78l1LjeFdf3Qv28W8J4KN14AeZm@chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id XAA15163 for ; Tue, 7 Jan 2003 23:08:56 -0600 (CST) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by chuckle.americas.sgi.com (8.12.5/8.12.5) with ESMTP id h0858tx1001030 for ; Tue, 7 Jan 2003 23:08:56 -0600 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.5/8.12.5/Submit) id h0858tPU001028 for linux-xfs@oss.sgi.com; Tue, 7 Jan 2003 23:08:55 -0600 Date: Tue, 7 Jan 2003 23:08:55 -0600 From: Russell Cattelan Message-Id: <200301080508.h0858tPU001028@chuckle.americas.sgi.com> Subject: TAKE - Hopefully fix root file system corruption at shutdown X-archive-position: 2246 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Revisit the remount read only code again. apparently the root file system are not being synced correctly during system shutdown Date: Tue Jan 7 21:08:24 PST 2003 Workarea: chuckle.americas.sgi.com:/misc/xfs2/XFS/x2.4-xfs-devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136269a linux/fs/xfs/xfs_vnodeops.c - 1.580 - New function to do xfs inode reclaim during system shutdown linux/fs/xfs/xfs_inode.h - 1.175 - prototype for xfs_reclaim_all linux/fs/xfs/linux/xfs_lrw.c - 1.178 - call new function xfs_reclaim_all to unmount_ro path From owner-linux-xfs@oss.sgi.com Tue Jan 7 21:46:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Jan 2003 21:47:01 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h085iX3v005804 for ; Tue, 7 Jan 2003 21:46:25 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h084tsKp020633 for ; Tue, 7 Jan 2003 20:55:54 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA60551 for ; Tue, 7 Jan 2003 23:50:06 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:TIxELg3EKN9ua1XrpyIOxqBI1bIylh3V@chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id XAA24430 for ; Tue, 7 Jan 2003 23:50:06 -0600 (CST) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by chuckle.americas.sgi.com (8.12.5/8.12.5) with ESMTP id h085o6x1001536 for ; Tue, 7 Jan 2003 23:50:06 -0600 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.5/8.12.5/Submit) id h085o6ls001534 for linux-xfs@oss.sgi.com; Tue, 7 Jan 2003 23:50:06 -0600 Date: Tue, 7 Jan 2003 23:50:06 -0600 From: Russell Cattelan Message-Id: <200301080550.h085o6ls001534@chuckle.americas.sgi.com> Subject: TAKE - put back a STATIC X-archive-position: 2247 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs put back a change that got dropped in the last checkin Date: Tue Jan 7 21:49:33 PST 2003 Workarea: chuckle.americas.sgi.com:/misc/xfs2/XFS/x2.4-xfs-devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136270a linux/fs/xfs/xfs_vnodeops.c - 1.581 From owner-linux-xfs@oss.sgi.com Wed Jan 8 00:44:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jan 2003 00:44:14 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h088i73v007831 for ; Wed, 8 Jan 2003 00:44:07 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h088i71G007830 for linux-xfs@oss.sgi.com; Wed, 8 Jan 2003 00:44:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h088i63v007818 for ; Wed, 8 Jan 2003 00:44:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h088gCLj007810; Wed, 8 Jan 2003 00:42:12 -0800 Date: Wed, 8 Jan 2003 00:42:12 -0800 Message-Id: <200301080842.h088gCLj007810@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 207] Filesystem corruption at boot, with data loss X-Bugzilla-Reason: AssignedTo X-archive-position: 2248 X-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=207 ------- Additional Comments From cw@f00f.org 2003-01-07 13:28 ------- Subject: Re: New: Filesystem corruption at boot, with data loss On Tue, Jan 07, 2003 at 08:22:45AM -0800, bugzilla-daemon@oss.sgi.com wrote: > At reboot, I randomly get a filesystem corruption: the first time > the system wasn't able to mount /, the other times it wasn't able to > read getty, so I coudn't read the other messages. is the hd write-caching disabled? > After the repairs, there was random data loss (entire files with 0 > length). getting this for files that were open for writes is normal, in unrelated file it it not --cw ------- Additional Comments From dgborin@libero.it 2003-01-08 00:42 ------- 1) My CPU is an AMD Athlon, not K6, I wrote wrong. 2) I get this corruption at boot time: the system was correctly shut down previously, so data loss isn't normal! I don't know if HD write cache is enabled: I kept factory set up, so I think it's not. I will look, but I don't think it could be related, because with 2.4.19 kernel and XFS patch 2002-09-27 all works well. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Jan 8 08:47:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jan 2003 08:47:20 -0800 (PST) Received: from gw-nl6.philips.com (gw-nl6.philips.com [212.153.235.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08Gl63v011598 for ; Wed, 8 Jan 2003 08:47:06 -0800 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl6.philips.com (Postfix) with ESMTP id 82F13A4785 for ; Wed, 8 Jan 2003 10:42:23 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA02807 for ; Wed, 8 Jan 2003 10:42:22 +0100 (MET) From: darren.miller@philips.com Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA12035 for ; Wed, 8 Jan 2003 10:42:22 +0100 (MET) To: linux-xfs@oss.sgi.com Subject: NULL Pointer dereference in 2.4.19-xfs-pre4 with nfsd MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 8 Jan 2003 09:40:06 +0000 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 08/01/2003 10:43:22, Serialize complete at 08/01/2003 10:43:22 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1093 X-archive-position: 2249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: darren.miller@philips.com Precedence: bulk X-list: linux-xfs I keep recieving this little gem amonst other with a new system we are trying to put in, only appears to rear its head when I put in the full amount of RAM being 2GB if I leave the server at 1GB it operates ok, only once has it crashed with this type of error on 1GB of RAM. Here is my system specs: Dual Athlon MP 2000+ A7M266-D Motherboard Raid 5 array using 3Ware 7500-8 64bit card and 8x120GB Maxtor ATA133 disks 2GB of Samsung PC2100 RAM (4x512MB) Intel EtherExpress 1000 Pro Copper 64Bit NIC Am using 2.4.19 XFS Pre 4 and Slackware 8.1 Linux Distribution. Sorry I have lost the oops info, the system didn't log it :( Still can't work out why it only happens with 2GB of RAM. Darren ============================================================================== Darren Miller Senior Systems Support Engineer Microsoft Certified Professional SCO Advanced Certified Engineer Infomation Systems Department (Core Server Support) Philips Semiconductors,Milbrook Industrial Estate,Southampton,SO15 0DJ,England Direct Dial In: (02380) 312681 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Jan 8 09:11:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jan 2003 09:11:13 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08HB83v012647 for ; Wed, 8 Jan 2003 09:11:09 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h08HGmWJ042932; Wed, 8 Jan 2003 18:16:48 +0100 (CET) Message-Id: <4.3.2.7.2.20030108181432.03308468@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Jan 2003 18:16:31 +0100 To: darren.miller@philips.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: NULL Pointer dereference in 2.4.19-xfs-pre4 with nfsd In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 09:40 8-1-2003 +0000, darren.miller@philips.com wrote: >Dual Athlon MP 2000+ >A7M266-D Motherboard > >Sorry I have lost the oops info, the system didn't log it :( Still can't >work out why it only happens with 2GB of RAM. Make sure you have the latest bios. This board has some funnies when the board is filled with the maximum amount of memory IIRC. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jan 8 12:44:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jan 2003 12:44:06 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h08Ki43v019617 for ; Wed, 8 Jan 2003 12:44:04 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h08Ki4Z1019616 for linux-xfs@oss.sgi.com; Wed, 8 Jan 2003 12:44:04 -0800 Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08Ki23v019602; Wed, 8 Jan 2003 12:44:02 -0800 Received: from localhost (localhost [127.0.0.1]) by tapu.f00f.org (Postfix) with ESMTP id 284B8203AE9; Wed, 8 Jan 2003 12:49:44 -0800 (PST) Received: by tapu.f00f.org (Postfix, from userid 1000) id 9B13E203B7E; Wed, 8 Jan 2003 12:49:43 -0800 (PST) Date: Wed, 8 Jan 2003 12:49:43 -0800 From: Chris Wedgwood To: dgborin@libero.it, bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com Subject: Re: [Bug 207] Filesystem corruption at boot, with data loss Message-ID: <20030108204943.GA12968@tapu.f00f.org> References: <200301080842.h088gCLj007810@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301080842.h088gCLj007810@oss.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 2251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Wed, Jan 08, 2003 at 12:42:12AM -0800, bugzilla-daemon@oss.sgi.com wrote: > I don't know if HD write cache is enabled: I kept factory set up, so > I think it's not. I will look, but I don't think it could be > related, because with 2.4.19 kernel and XFS patch 2002-09-27 all > works well. *Many* IDE drives default to write-caching on. The disk may then reorder writes potentially break journalling or worse still, have unflushed data in the cache when it reboots... Please check if this is the case. "hdparm -W0 /dev/sda" or whatever should turn this off... (hdparm man pages calls this dangerous, I've never actually had a problem myself with it). --cw From owner-linux-xfs@oss.sgi.com Wed Jan 8 14:13:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jan 2003 14:13:05 -0800 (PST) Received: from poptart.bithose.com (ip-204-97-176-41.modem.logical.net [204.97.176.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08MCw3v020776 for ; Wed, 8 Jan 2003 14:12:59 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.2/8.12.2) with ESMTP id h08MIeN1053399 for ; Wed, 8 Jan 2003 17:18:40 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.2/8.12.2/Submit) with ESMTP id h08MIedS053396 for ; Wed, 8 Jan 2003 17:18:40 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Wed, 8 Jan 2003 17:18:40 -0500 (EST) From: Jameel Akari To: linux-xfs Subject: SSI Clusters & XFS? In-Reply-To: <20021228140705.GA17731@bonzo.nirvana> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: linux-xfs Has anyone used the Single Systems Image (SSI) for Linux code with XFS in the same kernel? http://ssic-linux.sourceforge.net/install.shtml These assume a 2.4.18 kernel.. I don't see why you couldn't apply the XFS patches to it as well (or apply the SSI patches to a XFS CVS checkout). Seems to me that using XFS for the shared cluster filesystem would be a Good Thing.. The Sourceforge mailing list search doesn't seem to return anything about XFS.. then again it is running suspiciously slow, so I don't know. The SGI Altix 3000 announcement made me think more about clustering... mainly because I can't afford anything like an Altix with a "proper" single image. ;) #!/jameel/akari sleep 4800; make clean && make breakfast From owner-linux-xfs@oss.sgi.com Wed Jan 8 14:44:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jan 2003 14:44:10 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h08Mi83v021729 for ; Wed, 8 Jan 2003 14:44:08 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h08Mi8NH021728 for linux-xfs@oss.sgi.com; Wed, 8 Jan 2003 14:44:08 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h08Mi641021709 for ; Wed, 8 Jan 2003 14:44:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h08MWLVv021282; Wed, 8 Jan 2003 14:32:21 -0800 Date: Wed, 8 Jan 2003 14:32:21 -0800 Message-Id: <200301082232.h08MWLVv021282@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 2253 X-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=197 ------- Additional Comments From cattelan@thebarn.com 2003-01-08 14:32 ------- Created an attachment (id=59) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=59&action=view) This should help prevent the corruption on root FS's at shutdown time ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Jan 8 15:01:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jan 2003 15:02:03 -0800 (PST) Received: from imf04bis.bellsouth.net (mail004.mail.bellsouth.net [205.152.58.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08N1w3v022743 for ; Wed, 8 Jan 2003 15:01:59 -0800 Received: from marsha ([66.156.1.7]) by imf04bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030108230929.FCGT1198.imf04bis.bellsouth.net@marsha>; Wed, 8 Jan 2003 18:09:29 -0500 Date: Wed, 8 Jan 2003 18:05:36 -0500 From: Greg Freemyer Subject: re: SSI Clusters & XFS? To: Jameel Akari , linux-xfs Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20030108230929.FCGT1198.imf04bis.bellsouth.net@marsha> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h08N1x3v022748 X-archive-position: 2254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Jameel, SSI Linux supports OpenGFS and CFS as the shared FS. OpenGFS is robust and can handle a server/node crash. OpenGFS is a full OS and cannot be layered over XFS.. CFS is not yet robust, so IIRC when a node dies your whole cluster goes down. The good part about CFS is that it layers on top of a normal local FS, so I _assume_ it would be compatible with XFS. Per Bruce Walker of the SSI team, they hope to get a HA version of CFS out this month!!! At that point it will be worth testing CFS over XFS in a SSI cluster to see how well the whole thing works together. If you want to pursue it, you should ask on the SSI list if they could make the HA CFS release against a newer kernel. Note: I have no idea what kernel they are currently planning to release against, but since they are "pre-alpha" they have not been very worried about using a old kernel. As of the HA CFS release I suspect they will be getting a wider set of users and a newer kernel will be more important independent of XFS. Greg Freemyer >> Has anyone used the Single Systems Image (SSI) for Linux code with XFS in >> the same kernel? >> http://ssic-linux.sourceforge.net/install.shtml >> These assume a 2.4.18 kernel.. I don't see why you couldn't apply the XFS >> patches to it as well (or apply the SSI patches to a XFS CVS checkout). >> Seems to me that using XFS for the shared cluster filesystem would be a >> Good Thing.. >> The Sourceforge mailing list search doesn't seem to return anything about >> XFS.. then again it is running suspiciously slow, so I don't know. >> The SGI Altix 3000 announcement made me think more about clustering... >> mainly because I can't afford anything like an Altix with a "proper" >> single image. ;) >> #!/jameel/akari >> sleep 4800; >> make clean && make breakfast From owner-linux-xfs@oss.sgi.com Wed Jan 8 15:07:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jan 2003 15:07:38 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h08N7V3v023305 for ; Wed, 8 Jan 2003 15:07:31 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h08LDGG8004590 for ; Wed, 8 Jan 2003 13:13:16 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA96855 for ; Wed, 8 Jan 2003 17:13:07 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:oH9fpU5lo2UOT65Sij8TE3f3j7rYREuy@chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA92429 for ; Wed, 8 Jan 2003 17:13:07 -0600 (CST) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by chuckle.americas.sgi.com (8.12.5/8.12.5) with ESMTP id h08ND7x1006915 for ; Wed, 8 Jan 2003 17:13:07 -0600 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.5/8.12.5/Submit) id h08ND7XT006913 for linux-xfs@oss.sgi.com; Wed, 8 Jan 2003 17:13:07 -0600 Date: Wed, 8 Jan 2003 17:13:07 -0600 From: Russell Cattelan Message-Id: <200301082313.h08ND7XT006913@chuckle.americas.sgi.com> Subject: TAKE - small clean up X-archive-position: 2255 X-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@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs cut and paste error grrr Date: Wed Jan 8 15:12:41 PST 2003 Workarea: chuckle.americas.sgi.com:/misc/xfs2/XFS/x2.4-xfs-devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136364a linux/fs/xfs/xfs_inode.h - 1.176 - Correct name for the proto type From owner-linux-xfs@oss.sgi.com Wed Jan 8 16:50:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Jan 2003 16:50:20 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h090oC3v026481 for ; Wed, 8 Jan 2003 16:50:12 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h090oCI0026480 for linux-xfs@oss.sgi.com; Wed, 8 Jan 2003 16:50:12 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h090oB3x026466 for ; Wed, 8 Jan 2003 16:50:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h090nHOX026451; Wed, 8 Jan 2003 16:49:17 -0800 Date: Wed, 8 Jan 2003 16:49:17 -0800 Message-Id: <200301090049.h090nHOX026451@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 205] make install fails to properly symlink and copy the libraries X-Bugzilla-Reason: AssignedTo X-archive-position: 2256 X-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=205 bootsy52@gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From bootsy52@gmx.net 2003-01-08 16:49 ------- OK, because I'm so annoyed by this bug, I'm proably the one who will fix this. But I have to get deeper into make and autoconf. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jan 9 05:44:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jan 2003 05:44:11 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h09Di83v023291 for ; Thu, 9 Jan 2003 05:44:08 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h09Di8WQ023290 for linux-xfs@oss.sgi.com; Thu, 9 Jan 2003 05:44:08 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h09Di63v023278 for ; Thu, 9 Jan 2003 05:44:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h09DcxrN023262; Thu, 9 Jan 2003 05:38:59 -0800 Date: Thu, 9 Jan 2003 05:38:59 -0800 Message-Id: <200301091338.h09DcxrN023262@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 207] Filesystem corruption at boot, with data loss X-Bugzilla-Reason: AssignedTo X-archive-position: 2257 X-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=207 ------- Additional Comments From cw@f00f.org 2003-01-08 12:44 ------- Subject: Re: Filesystem corruption at boot, with data loss On Wed, Jan 08, 2003 at 12:42:12AM -0800, bugzilla-daemon@oss.sgi.com wrote: > I don't know if HD write cache is enabled: I kept factory set up, so > I think it's not. I will look, but I don't think it could be > related, because with 2.4.19 kernel and XFS patch 2002-09-27 all > works well. *Many* IDE drives default to write-caching on. The disk may then reorder writes potentially break journalling or worse still, have unflushed data in the cache when it reboots... Please check if this is the case. "hdparm -W0 /dev/sda" or whatever should turn this off... (hdparm man pages calls this dangerous, I've never actually had a problem myself with it). --cw ------- Additional Comments From dgborin@libero.it 2003-01-09 05:38 ------- I will check ASAP and I will try disabling it, but I'd like to known why this problem appeared only with these recent patches (and frequently!) and NEVER before: it'a about a year I use XFS with the same hard disk without a problem. You say that write cache could cause a data reordering, but this sould happen always. I don't agree about the flushing: the hard disk should do it if the system shuts it down correctly; again, if it's a problem of this HD, why the problem appears only now? Excuse my bad English. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jan 9 09:54:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jan 2003 09:54:33 -0800 (PST) Received: from mail.epost.de (mail.epost.de [193.28.100.165] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09HsS3v019314 for ; Thu, 9 Jan 2003 09:54:30 -0800 Received: from epost.de (217.110.232.6) by mail.epost.de (6.7.015) (authenticated as rainer.traut@epost.de) id 3E1D6B9400000637 for linux-xfs@oss.sgi.com; Thu, 9 Jan 2003 13:46:44 +0100 Message-ID: <3E1D6F33.6080303@epost.de> Date: Thu, 09 Jan 2003 13:46:43 +0100 From: Rainer Traut User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030108 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Redhat 7.3, patched 2.4.20 Kernel, which xfsprogs? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rainer.traut@epost.de Precedence: bulk X-list: linux-xfs Hi, I'm using a 2.4.20 Kernel with the XFS patches from the ftp server. ftp://oss.sgi.com/projects/xfs/patches/2.4.20/snapshot-xfs-2.4.20-2002-12-18_02%3a00_UTC Which xfsprogs should i use? Because Rh 7.3 uses older glibc i cannot use the latest rpms. Should I compile them from source code? Are these xfs patches I'm using a 1.2 release of xfs or should I install from cvs? Thank you Rainer From owner-linux-xfs@oss.sgi.com Thu Jan 9 10:44:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jan 2003 10:44:14 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h09Ii93v020106 for ; Thu, 9 Jan 2003 10:44:09 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h09Ii981020104 for linux-xfs@oss.sgi.com; Thu, 9 Jan 2003 10:44:09 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h09Ii643020069 for ; Thu, 9 Jan 2003 10:44:07 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h09IPkgI020006; Thu, 9 Jan 2003 10:25:46 -0800 Date: Thu, 9 Jan 2003 10:25:46 -0800 Message-Id: <200301091825.h09IPkgI020006@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 207] Filesystem corruption at boot, with data loss X-Bugzilla-Reason: AssignedTo X-archive-position: 2260 X-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=207 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From cattelan@thebarn.com 2003-01-09 10:25 ------- *** This bug has been marked as a duplicate of 197 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jan 9 10:44:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jan 2003 10:44:12 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h09Ii93v020107 for ; Thu, 9 Jan 2003 10:44:09 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h09Ii9LM020105 for linux-xfs@oss.sgi.com; Thu, 9 Jan 2003 10:44:09 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h09Ii64B020069 for ; Thu, 9 Jan 2003 10:44:08 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h09IPloe020010; Thu, 9 Jan 2003 10:25:47 -0800 Date: Thu, 9 Jan 2003 10:25:47 -0800 Message-Id: <200301091825.h09IPloe020010@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 2259 X-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=197 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dgborin@libero.it ------- Additional Comments From cattelan@thebarn.com 2003-01-09 10:25 ------- *** Bug 207 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jan 9 13:12:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jan 2003 13:12:29 -0800 (PST) Received: from ost1.sturmnet.org (dsl-213-023-013-018.arcor-ip.net [213.23.13.18]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09LCJ3v025387 for ; Thu, 9 Jan 2003 13:12:20 -0800 Received: (qmail 2261 invoked by uid 64014); 9 Jan 2003 21:18:01 -0000 Received: from oliver@sturmnet.org by ost1 by uid 64011 with qmail-scanner-1.15 (uvscan: v4.1.40/v4100. spamassassin: 2.43. Clear:SA:0(-100.2/5.0):. Processed in 1.136187 secs); 09 Jan 2003 21:18:01 -0000 Received: from unknown (HELO lost2) (192.168.100.103) by ost1 with RC4-MD5 encrypted SMTP; 9 Jan 2003 21:17:58 -0000 Subject: XFS and lids From: Oliver Sturm To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vOGE/rVd0cyKBExQIGOv" Organization: Private Message-Id: <1042147078.1167.13.camel@lost2> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 09 Jan 2003 22:17:58 +0100 X-archive-position: 2261 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: oliver@sturmnet.org Precedence: bulk X-list: linux-xfs --=-vOGE/rVd0cyKBExQIGOv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi! Any hints on using Linux XFS together with lids (www.lids.org)? lids seems to work with filesystem objects in some manner, so I was wondering if there are any known facts about XFS/lids compatibility. Thanks! Oliver Sturm --=20 omnibus ex nihilo ducendis sufficit unum Fingerprint: 8085 5C52 60B8 EFBD DAD0 78B8 CE7F 38D7 71D8 6996 6996 Jabber sturm@amessage.de ICQ 27142619 MSN macnapple@hotmail.com Y! macnapple --=-vOGE/rVd0cyKBExQIGOv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+HecGzn8413HYaZYRAs0uAKCVKpPaCqdsj/LBrVwB9ypj3IXhjQCeJDGF x+GkbiGjS97P3ahDzM6wHzw= =D5Q5 -----END PGP SIGNATURE----- --=-vOGE/rVd0cyKBExQIGOv-- From owner-linux-xfs@oss.sgi.com Thu Jan 9 13:18:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Jan 2003 13:18:41 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h09LIc3v025821 for ; Thu, 9 Jan 2003 13:18:39 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h09KUBKp027504 for ; Thu, 9 Jan 2003 12:30:11 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA06368; Thu, 9 Jan 2003 15:24:17 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 18Wk9y-0004ek-00; Thu, 09 Jan 2003 15:24:18 -0600 Date: Thu, 9 Jan 2003 15:24:18 -0600 From: Nathan Straz To: Rainer Traut Cc: linux-xfs@oss.sgi.com Subject: Re: Redhat 7.3, patched 2.4.20 Kernel, which xfsprogs? Message-ID: <20030109212417.GA17744@sgi.com> Mail-Followup-To: Rainer Traut , linux-xfs@oss.sgi.com References: <3E1D6F33.6080303@epost.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1D6F33.6080303@epost.de> User-Agent: Mutt/1.4i X-archive-position: 2262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Jan 09, 2003 at 01:46:43PM +0100, Rainer Traut wrote: > Hi, > I'm using a 2.4.20 Kernel with the XFS patches from the ftp server. > ftp://oss.sgi.com/projects/xfs/patches/2.4.20/snapshot-xfs-2.4.20-2002-12-18_02%3a00_UTC > Which xfsprogs should i use? Use the latest xfsprogs. > Because Rh 7.3 uses older glibc i cannot use the latest rpms. > Should I compile them from source code? You should be able to do an rpm --rebuild on the source rpms and get something you can use on RH 7.3. > Are these xfs patches I'm using a 1.2 release of xfs or > should I install from cvs? The patches you're using are CVS code, not 1.2 based code. I think someone has already merged the 1.2pre4 code up to 2.4.20. Either you'll have to check the archives to find out who, or they'll speak up. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Fri Jan 10 01:04:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jan 2003 01:04:44 -0800 (PST) Received: from web14808.mail.yahoo.com (web14808.mail.yahoo.com [216.136.224.224]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0A94f3v003403 for ; Fri, 10 Jan 2003 01:04:41 -0800 Message-ID: <20030110091029.49057.qmail@web14808.mail.yahoo.com> Received: from [153.110.6.241] by web14808.mail.yahoo.com via HTTP; Fri, 10 Jan 2003 01:10:29 PST Date: Fri, 10 Jan 2003 01:10:29 -0800 (PST) From: Lars Larsen Subject: No automatic xfs module load at boot with RedHat 7.3 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2263 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larsal2003@yahoo.com Precedence: bulk X-list: linux-xfs I'm trying to get xfs file system up and running at boot on a machine running RedHat 7.3. I have installed from the CD image (version 1.1) supplied here at the XFS site. I'am using a SCSI card and the boot device is on a SCSI disk. But the file system there is ext3. It will start OK, but not so with XFS. If I mount a XFS file system after boot, everything seams OK. It looks like the module is not loaded at boot time. Any idees og experience? Regards, Lars __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-linux-xfs@oss.sgi.com Fri Jan 10 03:00:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jan 2003 03:00:06 -0800 (PST) Received: from azrael.blades.cxm (ua3d35hel.dial.kolumbus.fi [62.248.233.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0AAxx3v007508 for ; Fri, 10 Jan 2003 03:00:02 -0800 Received: (from blades@localhost) by azrael.blades.cxm (SGI-8.9.3/8.9.3) id NAA06283 for linux-xfs@oss.sgi.com; Fri, 10 Jan 2003 13:05:46 +0200 (EET) X-Authentication-Warning: azrael.blades.cxm: blades set sender to harri.haataja@kolumbus.fi using -f Date: Fri, 10 Jan 2003 13:05:46 +0200 From: Harri Haataja To: linux-xfs@oss.sgi.com Subject: Re: Redhat 7.3, patched 2.4.20 Kernel, which xfsprogs? Message-ID: <20030110130544.A4704@azrael.blades.cxm> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3E1D6F33.6080303@epost.de> <20030109212417.GA17744@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030109212417.GA17744@sgi.com>; from nstraz@sgi.com on Thu, Jan 09, 2003 at 03:24:18PM -0600 X-archive-position: 2264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: harri.haataja@kolumbus.fi Precedence: bulk X-list: linux-xfs On Thu, Jan 09, 2003 at 03:24:18PM -0600, Nathan Straz wrote: > On Thu, Jan 09, 2003 at 01:46:43PM +0100, Rainer Traut wrote: > > I'm using a 2.4.20 Kernel with the XFS patches from the ftp server. > > ftp://oss.sgi.com/projects/xfs/patches/2.4.20/snapshot-xfs-2.4.20-2002-12-18_02%3a00_UTC > > Which xfsprogs should i use? > Use the latest xfsprogs. > > > Because Rh 7.3 uses older glibc i cannot use the latest rpms. > > Should I compile them from source code? > You should be able to do an rpm --rebuild on the source rpms and get > something you can use on RH 7.3. And that would be rpmbuild --rebuild. As a user who has the build macros set up. -- http://www.math.fu-berlin.de/~guckes/sig/ From owner-linux-xfs@oss.sgi.com Fri Jan 10 09:03:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jan 2003 09:04:03 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0AH3r3v018023 for ; Fri, 10 Jan 2003 09:03:53 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0AGFVKp019933 for ; Fri, 10 Jan 2003 08:15:31 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA86023 for ; Fri, 10 Jan 2003 11:09:37 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA89696 for ; Fri, 10 Jan 2003 11:09:36 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id h0AH8VI21276; Fri, 10 Jan 2003 11:08:31 -0600 Message-Id: <200301101708.h0AH8VI21276@stout.americas.sgi.com> Date: Fri, 10 Jan 2003 11:08:31 -0600 Subject: PARTIAL TAKE 877258 - If an xfs filesystem is corrupted, mount can hang forever X-archive-position: 2265 X-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 Handle mode 0 inodes that find their way onto the unlinked list These shouldn't be there, probably the result of corruption. However, if we find one, handle it specially so that we don't deadlock during unlinked list processing in recovery. Without xfs_iput_new, we'd be waiting on an inode lock we already hold. Date: Fri Jan 10 09:08:14 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:136535a linux/fs/xfs/xfs_log_recover.c - 1.253 From owner-linux-xfs@oss.sgi.com Fri Jan 10 14:21:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jan 2003 14:21:22 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0AMLD3v024010 for ; Fri, 10 Jan 2003 14:21:14 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZBLC7A1P; Fri, 10 Jan 2003 17:27:12 -0500 Received: from wgate.com (sinz.eng.tvol.net [127.0.0.1]) by sinz.eng.tvol.net (8.12.5/8.12.5) with ESMTP id h0AMQ1Pd023697 for ; Fri, 10 Jan 2003 17:26:01 -0500 Message-ID: <3E1F4879.7090909@wgate.com> Date: Fri, 10 Jan 2003 17:26:01 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Strange XFS corruption... References: <20030110091029.49057.qmail@web14808.mail.yahoo.com> In-Reply-To: <20030110091029.49057.qmail@web14808.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs This is with a CVS checkout from the end of December (12/29/2002) Today, I started to get errors trying to access /etc/mtab Everything else looked fine. I then did an "ls" in /etc and got multiple errors about not being able to stat "mtab" (yes, multiple ones) I rebooted onto a different partition and ran XFS_CHECK and XFS_REPAIR on the partition in question and then rebooted. Now, when I do "ls /etc/mtab*" I get 12 files shown, all with the same size/date/etc. I tried to delete /etc/mtab and I got 12 errors. I am doing yet another XFS_REPAIR now, but XFS_CHECK did not report any errors so I doubt that anything would show up. This machine is on a UPS and has not had any crashes/dirty shutdowns in a long time. It has been running XFS for a long time now. I will try to get more details but I was in need of getting that machine running again so did not have a chance to grab as much data as I wish. BTW - The kernel is exactly from CVS with only one patch that I did for named core dumps (based on host name and program name). There are no funky drivers or other items (in fact, the kernel does not even have support for loadable modules enabled) Again, I am sorry that I did not get a chance to dig deeper but this machine needed to be back in service "asap" (one of the reasons it runs XFS :-) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Fri Jan 10 14:34:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jan 2003 14:34:37 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0AMYU3v024538 for ; Fri, 10 Jan 2003 14:34:30 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0AKeOG8002573 for ; Fri, 10 Jan 2003 12:40:24 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA23486; Fri, 10 Jan 2003 16:40:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA29814; Fri, 10 Jan 2003 16:40:15 -0600 (CST) Subject: Re: Strange XFS corruption... From: Eric Sandeen To: Michael Sinz Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E1F4879.7090909@wgate.com> References: <20030110091029.49057.qmail@web14808.mail.yahoo.com> <3E1F4879.7090909@wgate.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 10 Jan 2003 16:39:08 -0600 Message-Id: <1042238348.20737.37.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2267 X-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 We've actually seen this here too, recently. We -think- it is the result of previous filesystem corruption on shutdown, which should now be fixed. Did you have any filesystem shutdowns or other corruption before this? The possible corruption bug that was fixed could even happen on a clean shutdown, unfortunately. -Eric On Fri, 2003-01-10 at 16:26, Michael Sinz wrote: > This is with a CVS checkout from the end of December (12/29/2002) > > Today, I started to get errors trying to access /etc/mtab > Everything else looked fine. > > I then did an "ls" in /etc and got multiple errors about not > being able to stat "mtab" (yes, multiple ones) > > I rebooted onto a different partition and ran XFS_CHECK and XFS_REPAIR > on the partition in question and then rebooted. > > Now, when I do "ls /etc/mtab*" I get 12 files shown, all with the > same size/date/etc. > > I tried to delete /etc/mtab and I got 12 errors. > > I am doing yet another XFS_REPAIR now, but XFS_CHECK did not > report any errors so I doubt that anything would show up. > > This machine is on a UPS and has not had any crashes/dirty shutdowns > in a long time. It has been running XFS for a long time now. > > I will try to get more details but I was in need of getting that > machine running again so did not have a chance to grab as much > data as I wish. > > BTW - The kernel is exactly from CVS with only one patch that I did > for named core dumps (based on host name and program name). There are > no funky drivers or other items (in fact, the kernel does not even > have support for loadable modules enabled) > > Again, I am sorry that I did not get a chance to dig deeper but this > machine needed to be back in service "asap" (one of the reasons it > runs XFS :-) > > -- > Michael Sinz -- Director, Systems Engineering -- Worldgate Communications > A master's secrets are only as good as > the master's ability to explain them to others. > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Jan 10 16:12:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jan 2003 16:13:00 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0B0Ct3v026468 for ; Fri, 10 Jan 2003 16:12:56 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0AKeAG8002537 for ; Fri, 10 Jan 2003 12:40:11 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA86833; Fri, 10 Jan 2003 16:40:01 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 18X7on-0005Cb-00; Fri, 10 Jan 2003 16:40:01 -0600 Date: Fri, 10 Jan 2003 16:40:01 -0600 From: Nathan Straz To: Michael Sinz Cc: linux-xfs@oss.sgi.com Subject: Re: Strange XFS corruption... Message-ID: <20030110224001.GK7156@sgi.com> Mail-Followup-To: Michael Sinz , linux-xfs@oss.sgi.com References: <20030110091029.49057.qmail@web14808.mail.yahoo.com> <3E1F4879.7090909@wgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1F4879.7090909@wgate.com> User-Agent: Mutt/1.4i X-archive-position: 2268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Fri, Jan 10, 2003 at 05:26:01PM -0500, Michael Sinz wrote: > This is with a CVS checkout from the end of December (12/29/2002) > > Today, I started to get errors trying to access /etc/mtab > Everything else looked fine. I think what you're seeing has to do with a remount read-only bug that was fixed on Jan 7-8. See Rusell's TAKE messages. If you still see it after cleaning up the file system and updating your kernel, please let us know. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Fri Jan 10 16:58:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jan 2003 16:58:38 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0B0wU3v027277 for ; Fri, 10 Jan 2003 16:58:31 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h0B14LcX008044; Fri, 10 Jan 2003 19:04:21 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: Strange XFS corruption... From: Russell Cattelan To: Michael Sinz Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E1F4879.7090909@wgate.com> References: <20030110091029.49057.qmail@web14808.mail.yahoo.com> <3E1F4879.7090909@wgate.com> Content-Type: text/plain Organization: Message-Id: <1042247060.34456.1586.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 10 Jan 2003 19:04:21 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs xfs_repair will fix your file system unfortunately it will not get rid of the duplicate entries in the directory. I suggesting that people try this to get their systems in shape. copy the /etc directory to a fresh directory this will get you back to one copy of each file. Move the old directory out of the way and move the new directory in place. rsync -av /etc/ /etcTMP/ mv /etc /etcNOT mv /etc/TMP /etc Try to rm -rf /etcNOT This will probably not fully remove the directory as it won't be able to rm the duplicate files. The system shouldn't have any problems at this point as /etc should be correct. Getting rid of the bad /etc dir will involve some xfs_db tricks that I have not worked out yet. Ohh and make sure to checkout the latest kernel from CVS On Fri, 2003-01-10 at 16:26, Michael Sinz wrote: > This is with a CVS checkout from the end of December (12/29/2002) > > Today, I started to get errors trying to access /etc/mtab > Everything else looked fine. > > I then did an "ls" in /etc and got multiple errors about not > being able to stat "mtab" (yes, multiple ones) > > I rebooted onto a different partition and ran XFS_CHECK and XFS_REPAIR > on the partition in question and then rebooted. > > Now, when I do "ls /etc/mtab*" I get 12 files shown, all with the > same size/date/etc. > > I tried to delete /etc/mtab and I got 12 errors. > > I am doing yet another XFS_REPAIR now, but XFS_CHECK did not > report any errors so I doubt that anything would show up. > > This machine is on a UPS and has not had any crashes/dirty shutdowns > in a long time. It has been running XFS for a long time now. > > I will try to get more details but I was in need of getting that > machine running again so did not have a chance to grab as much > data as I wish. > > BTW - The kernel is exactly from CVS with only one patch that I did > for named core dumps (based on host name and program name). There are > no funky drivers or other items (in fact, the kernel does not even > have support for loadable modules enabled) > > Again, I am sorry that I did not get a chance to dig deeper but this > machine needed to be back in service "asap" (one of the reasons it > runs XFS :-) -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Fri Jan 10 17:01:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Jan 2003 17:07:38 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0B11b3v027755; Fri, 10 Jan 2003 17:01:37 -0800 Received: from [10.0.0.10] (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id h0B17ScX008142; Fri, 10 Jan 2003 19:07:28 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: 1.2 pre5 patches From: Russell Cattelan To: linux-xfs@oss.sgi.com Cc: linux-xfs-announce@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1042247248.34456.1590.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 10 Jan 2003 19:07:28 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Due to the recent problems we have been seeing with root file system corruption, I have put the pre5 patches on oss. The kernel RPMs are not quite done building but I should be able to get those out sometime this weekend. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Sat Jan 11 16:50:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Jan 2003 16:51:15 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0C0ou3v016494 for ; Sat, 11 Jan 2003 16:50:57 -0800 Received: (qmail 1455 invoked from network); 12 Jan 2003 00:56:50 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 12 Jan 2003 00:56:50 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 357933000B8; Sun, 12 Jan 2003 11:56:42 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id B0E6085 for ; Sun, 12 Jan 2003 11:56:42 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: version typo in '2002-12-18 02:00 UTC' patch In-reply-to: Your message of "Sun, 29 Dec 2002 21:53:43 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Jan 2003 11:56:34 +1100 Message-ID: <32390.1042332994@ocs3.intra.ocs.com.au> X-archive-position: 2271 X-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 On Sun, 29 Dec 2002 21:53:43 +0900, Kazuhiko wrote: >The version of the current patch in the following URI: > ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20/ >seems to be '2.4.20-2002-12-18_02:00_UTC' > > README . . . . . . . . . . . . . . . . . Dec 17 18:03 4.49K > snapshot-xfs-2.4.20-2002-12-18_02:00_UTC Dec 17 18:00 0 >But xfs-2.4.20-split-only.bz2 still has such a line. >+#define XFS_VERSION_STRING "snapshot 2.4.20-2002-11-29_01:21_UTC" > >Is it a typo? (or is the file still old?) It is a typo, thanks for spotting it. xfs-2.4.20-split-only has been updated to say "snapshot 2.4.20-2002-12-18_02:00_UTC". From owner-linux-xfs@oss.sgi.com Sat Jan 11 19:37:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Jan 2003 19:37:18 -0800 (PST) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0C3b43v018400 for ; Sat, 11 Jan 2003 19:37:05 -0800 Received: from user-2injgvd.dialup.mindspring.com ([165.121.195.237] helo=nomad) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18XZ1Y-0005LM-00 for linux-xfs@oss.sgi.com; Sat, 11 Jan 2003 19:43:01 -0800 Message-ID: <002301c2b9ec$b0fc2450$2759fea9@nomad> Reply-To: "Richard Smith" From: "Richard Smith" To: Subject: rm hanging intermittently Date: Sat, 11 Jan 2003 19:42:55 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 920 X-archive-position: 2272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rgsmith72@earthlink.net Precedence: bulk X-list: linux-xfs Hello, I am experiencing a problem where a "rm -rf" command acting on a 450GB XFS partition will hang approximately once per day. The system is running a daemon that issues rm commands throughout the day and 99% of commands proceed without hanging. The system is using the 2.4.20-rc1 XFS kernel compiled with gcc 2.96 on a dual P4 xeon server. The XFS partition uses the linux software raid at level 0 with the XFS partition built on the resultant device. Once the rm process is hung, other processes trying to access the XFS filesystem are blocked, but the system is still responsive. Killing the hung process frees up the filesystem and re-issuing the identical command that originally hung will proceed without failure. Could this be a similar problem as the one that caused hanging processes where the kernel was compiled with gcc 2.95? Any help appreciated. Rick Smith [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Jan 11 19:57:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Jan 2003 19:57:59 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0C3vk3v019289 for ; Sat, 11 Jan 2003 19:57:46 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0C23jG8001112 for ; Sat, 11 Jan 2003 18:03:46 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA38809; Sat, 11 Jan 2003 22:03:36 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id WAA05481; Sat, 11 Jan 2003 22:03:36 -0600 (CST) Date: Sat, 11 Jan 2003 22:02:18 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Richard Smith cc: linux-xfs@oss.sgi.com Subject: Re: rm hanging intermittently In-Reply-To: <002301c2b9ec$b0fc2450$2759fea9@nomad> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2273 X-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 Hi Rick - If you have kdb, it might be interesting to look at the backtrace of the stuck rm process, to see where it's at: kdb> btp kdb> go How long have you waited for it to get "unstuck?" -Eric On Sat, 11 Jan 2003, Richard Smith wrote: > Hello, > I am experiencing a problem where a "rm -rf" command acting on a 450GB XFS partition will hang approximately once per day. The system is running a daemon that issues rm commands throughout the day and 99% of commands proceed without hanging. The system is using the 2.4.20-rc1 XFS kernel compiled with gcc 2.96 on a dual P4 xeon server. The XFS partition uses the linux software raid at level 0 with the XFS partition built on the resultant device. > Once the rm process is hung, other processes trying to access the XFS filesystem are blocked, but the system is still responsive. Killing the hung process frees up the filesystem and re-issuing the identical command that originally hung will proceed without failure. Could this be a similar problem as the one that caused hanging processes where the kernel was compiled with gcc 2.95? Any help appreciated. > > Rick Smith > > > [[HTML alternate version deleted]] > > From owner-linux-xfs@oss.sgi.com Sat Jan 11 22:33:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Jan 2003 22:33:20 -0800 (PST) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0C6X23v024905 for ; Sat, 11 Jan 2003 22:33:03 -0800 Received: from user-2injg0l.dialup.mindspring.com ([165.121.192.21] helo=nomad) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18Xblq-0006hp-00; Sat, 11 Jan 2003 22:38:58 -0800 Message-ID: <000701c2ba05$45a2b890$2759fea9@nomad> Reply-To: "Richard Smith" From: "Richard Smith" To: "Eric Sandeen" Cc: References: Subject: Re: rm hanging intermittently Date: Sat, 11 Jan 2003 22:38:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 2274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rgsmith72@earthlink.net Precedence: bulk X-list: linux-xfs I don't currently have the debugger built into this kernel, but I will create a kernel with it installed and post the backtrace the next time the process hangs. To answer your question, we have waited up to an hour for the rm process to return. This system has two xfs partitions installed, a smaller 36GB and a larger 450GB. It seems that when the rm process is hung on one partition, write operations are also halted on the other partition. Is XFS single threaded in this manner? Another data point is that 3 out of the last 4 times, the rm processes were hung just after 5pm. I don't see any cron jobs running at this time of day that would affect the filesystems, so this may be a coincidence. Rick ----- Original Message ----- From: "Eric Sandeen" To: "Richard Smith" Cc: Sent: Saturday, January 11, 2003 8:02 PM Subject: Re: rm hanging intermittently > Hi Rick - > > If you have kdb, it might be interesting to look at the backtrace of > the stuck rm process, to see where it's at: > > kdb> btp > kdb> go > > How long have you waited for it to get "unstuck?" > > -Eric > > On Sat, 11 Jan 2003, Richard Smith wrote: > > > Hello, > > I am experiencing a problem where a "rm -rf" command acting on a 450GB XFS partition will hang approximately once per day. The system is running a daemon that issues rm commands throughout the day and 99% of commands proceed without hanging. The system is using the 2.4.20-rc1 XFS kernel compiled with gcc 2.96 on a dual P4 xeon server. The XFS partition uses the linux software raid at level 0 with the XFS partition built on the resultant device. > > Once the rm process is hung, other processes trying to access the XFS filesystem are blocked, but the system is still responsive. Killing the hung process frees up the filesystem and re-issuing the identical command that originally hung will proceed without failure. Could this be a similar problem as the one that caused hanging processes where the kernel was compiled with gcc 2.95? Any help appreciated. > > > > Rick Smith > > > > > > [[HTML alternate version deleted]] > > > > > From owner-linux-xfs@oss.sgi.com Sun Jan 12 03:43:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 12 Jan 2003 03:44:11 -0800 (PST) Received: from www.storageone.co.kr ([211.234.8.155]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0CBhs3v009338 for ; Sun, 12 Jan 2003 03:43:54 -0800 Received: (qmail 9083 invoked by alias); 12 Jan 2003 11:48:24 -0000 Received: from unknown (HELO COMPAQ) (192.168.0.15) by home.storageone.co.kr with SMTP; 12 Jan 2003 11:48:24 -0000 Message-ID: <007301c2ba30$ae05d6d0$0f00a8c0@COMPAQ> From: "Sean Oh" To: Subject: LVM snapshot volume extendable with XFS? Date: Sun, 12 Jan 2003 20:49:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: oh@storageone.co.kr Precedence: bulk X-list: linux-xfs Hi I am using LVM 1.0.6, kernel 2.4.20 and XFS (from linux-2.4-xfs CVS). My question is that is the snapshot volume extendable? My environment is as follows: /dev/vg01/lv01 ---> XFS, 2G /dev/vg01/lv01_snap --> 256M, snapshot for /dev/vg01/lv01, mounted under /snap with ro,nouuid,usrquota,grpquota,noatime Now I have wrote a small shell scripts that if lv01_snap is more than 50% full, automatically increase the lv01_snap. But it seems to me that it does not work well.. What I did in the shell scripts are 'lvextend -L+256M /dev/vg01/lv01_snap' with/without 'xfs_growfs /snap'. After umounting the /snap and trying to remount /snap, it complaints as below XFS: recovery required required on read-only device XFS: write access unavailabe, cannot proceed XFS: log mount/recovery failed XFS: log mount failed mount: wrong fs type, bad option, bad superblock on /dev/vg01/lv01, or too many mounted file systems (aren't you trying to mount an extended partition, instead of some logical partition inside?) BTW, extending lv01 works fine with lvextend and xfs_growfs. Could someone please help? Thanks in advance From owner-linux-xfs@oss.sgi.com Sun Jan 12 07:32:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 12 Jan 2003 07:33:06 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0CFWq3v017997 for ; Sun, 12 Jan 2003 07:32:53 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA29093 for ; Sun, 12 Jan 2003 15:38:49 GMT Received: from pandora.ecs.soton.ac.uk (pandora.ecs.soton.ac.uk [152.78.68.157]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h0CFcjcd018322 for ; Sun, 12 Jan 2003 15:38:45 GMT Received: from everest.ecs.soton.ac.uk (everest [152.78.70.56]) by pandora.ecs.soton.ac.uk (8.11.6+Sun/8.11.6) with ESMTP id h0CFci428631 for ; Sun, 12 Jan 2003 15:38:45 GMT Received: from tal00r by everest.ecs.soton.ac.uk with local (Exim 3.36 #1 (Debian)) id 18XkBE-00040h-00 for ; Sun, 12 Jan 2003 15:37:44 +0000 Date: Sun, 12 Jan 2003 15:37:44 +0000 To: linux-xfs@oss.sgi.com Subject: Extended attribute for MIME type? Message-ID: <20030112153739.GB15400@everest.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: Thomas Leonard X-ECS-MailScanner: Found to be clean X-archive-position: 2277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tal00r@ecs.soton.ac.uk Precedence: bulk X-list: linux-xfs Content-Length: 697 Lines: 20 Hi everyone, I'm currently updating the freedesktop.org shared MIME database spec[1]. I'd like to add a note about reading the MIME type from an extended attribute, if the filesystem supports it, but I'm not sure what key to use. 'mime', 'MIME-Type', and 'ContentType' have all been suggested. Does anyone here know if there's a canonical key name for this? Sorry if this is the wrong place for such questions. [1] http://www.freedesktop.org/standards/shared-mime-info.html PS: I'm not on the list, so please CC any replies. Thanks, -- Thomas Leonard http://rox.sourceforge.net tal00r@ecs.soton.ac.uk tal197@users.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 From owner-linux-xfs@oss.sgi.com Sun Jan 12 12:44:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 12 Jan 2003 12:44:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0CKi83v020752 for ; Sun, 12 Jan 2003 12:44:08 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0CKi8TY020751 for linux-xfs@oss.sgi.com; Sun, 12 Jan 2003 12:44:08 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0CKi73v020739 for ; Sun, 12 Jan 2003 12:44:07 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0CKdvTv020720; Sun, 12 Jan 2003 12:39:57 -0800 Date: Sun, 12 Jan 2003 12:39:57 -0800 Message-Id: <200301122039.h0CKdvTv020720@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 207] Filesystem corruption at boot, with data loss X-Bugzilla-Reason: AssignedTo X-archive-position: 2278 X-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: 769 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=207 ------- Additional Comments From dgborin@libero.it 2003-01-12 12:39 ------- Some final (?) comments, even if it is marked duplicate... I disabled the HD write cache (yes, it was enabled) e for some boots it was all OK. Then X hanged: I waited for the cache to be written (HD LED blinked), then I hard resetted the system, but syslogd didn't start. Soft reset (ctr+alt+del), then I got again the file system corrupted! I think that a lot of system files are corrupted now, so I don't know if this last report has some interest: I will reinstall all ASAP. Kernel 2.4.20, XFS patch 2002-12-17. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Jan 12 15:54:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 12 Jan 2003 15:54:41 -0800 (PST) Received: from hob.prv.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0CNsM3v022887 for ; Sun, 12 Jan 2003 15:54:23 -0800 Received: from erbenson.alaska.net (84-pm14.nwc.alaska.net [209.112.141.84]) by hob.prv.nwc.acsalaska.net (8.12.6/8.12.6) with ESMTP id h0D00IRn046447; Sun, 12 Jan 2003 15:00:19 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 7AF913A09; Sun, 12 Jan 2003 15:00:17 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id BCD8F4104E2; Sun, 12 Jan 2003 15:00:17 -0900 (AKST) Date: Sun, 12 Jan 2003 15:00:17 -0900 From: Ethan Benson To: Thomas Leonard Cc: linux-xfs@oss.sgi.com Subject: Re: Extended attribute for MIME type? Message-ID: <20030113000017.GA17147@plato.local.lan> Mail-Followup-To: Thomas Leonard , linux-xfs@oss.sgi.com References: <20030112153739.GB15400@everest.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <20030112153739.GB15400@everest.ecs.soton.ac.uk> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 2279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 2023 Lines: 60 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 12, 2003 at 03:37:44PM +0000, Thomas Leonard wrote: > Hi everyone, >=20 > I'm currently updating the freedesktop.org shared MIME database spec[1]. > I'd like to add a note about reading the MIME type from an extended > attribute, if the filesystem supports it, but I'm not sure what key to > use. 'mime', 'MIME-Type', and 'ContentType' have all been suggested. >=20 > Does anyone here know if there's a canonical key name for this? Sorry if > this is the wrong place for such questions. >=20 > [1] http://www.freedesktop.org/standards/shared-mime-info.html >=20 > PS: I'm not on the list, so please CC any replies. Thanks, I wonder why you even want to store mime types in a extended attribute at all? like the filename its really not a good place at all for this kind of information, its FAR to easy for it to become out of sync with reality (anyone who has ever used a MacOS system for any length of time can attest to how flawed a system of storing file type information in the filesystem really is).=20 its akin to putting labels on drinking glasses, the glass, like a file, is merely a container, its contents can and will vary. Therefore the highest precedence should be given only to the file content, ie file(1) magic. I really don't see any compelling reason to waste filesystem space on putti= ng mime-types in extended attributes, its not portable, and its not reliable. as this topic isn't very on topic to linux-xfs please many any replies off-list.=20 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj4iAZEACgkQJKx7GixEevwoQgCfUhOa3q7N2JTG0TZdSLhT97EH m3gAn1AIwwg6WDodqCF6r+VOnkzCcp3V =SwhG -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-linux-xfs@oss.sgi.com Sun Jan 12 20:44:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 12 Jan 2003 20:44:15 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0D4i93v025234 for ; Sun, 12 Jan 2003 20:44:09 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0D4i9go025232 for linux-xfs@oss.sgi.com; Sun, 12 Jan 2003 20:44:09 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0D4i73x025216 for ; Sun, 12 Jan 2003 20:44:07 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0D4OxJv025099; Sun, 12 Jan 2003 20:24:59 -0800 Date: Sun, 12 Jan 2003 20:24:59 -0800 Message-Id: <200301130424.h0D4OxJv025099@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] New: Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 2280 X-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: 1689 Lines: 84 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 Summary: Kernel 2.4.20-xfs memory leaks Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: blocker Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: crypope@gmx.net If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.20-xfs Where did the XFS code come from? (CVS, Linus, your distribution, etc): CVS from cvs@oss.sgi.com Description of Problem: I have memory leaks even if I but in single user mode... How Reproducible: I can send the kernel configuration and I will perform and give the results for any requested debugging task. I can give ftp access to the 2.4.20-xfs sources if this can help... I've also used Netfilter with Patch-O-Matic to compile IPTABLES some fetures built-into the kernel or as modules. Because is my first time when I use Bugzilla to report a bug I need help to do it right. I am a systems administrator and not a developer. Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: If this is a userspace bug, what version of the package are you using: What kernel are you using: Where did the XFS code come from? (CVS, Linus, your distribution, etc): Description of Problem: How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Jan 12 21:14:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 12 Jan 2003 21:14:14 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0D5E93v025910 for ; Sun, 12 Jan 2003 21:14:09 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0D5E8rE025909 for linux-xfs@oss.sgi.com; Sun, 12 Jan 2003 21:14:08 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0D5E73x025895 for ; Sun, 12 Jan 2003 21:14:07 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0D52BcX025787; Sun, 12 Jan 2003 21:02:11 -0800 Date: Sun, 12 Jan 2003 21:02:11 -0800 Message-Id: <200301130502.h0D52BcX025787@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 2281 X-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: 426 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From sandeen@sgi.com 2003-01-12 21:02 ------- Please include some information that explains why you think xfs is leaking memory, and preferably, a way to duplicate it here (i.e. the steps to take which will show the leak). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Jan 12 22:20:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 12 Jan 2003 22:20:17 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0D6KD3v031298 for ; Sun, 12 Jan 2003 22:20:13 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0D6KD35031297 for linux-xfs@oss.sgi.com; Sun, 12 Jan 2003 22:20:13 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0D6KB3x031283 for ; Sun, 12 Jan 2003 22:20:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0D6Fm55029643; Sun, 12 Jan 2003 22:15:48 -0800 Date: Sun, 12 Jan 2003 22:15:48 -0800 Message-Id: <200301130615.h0D6Fm55029643@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 2282 X-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: 885 Lines: 35 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From crypope@gmx.net 2003-01-12 22:15 ------- I boot in single user mode. I use free -k and I see the used memory. After that I open and use any application like mc, cat , vi and close it and the memory is not fully released. For every application that I open and close I got a minimum 4K memory used increase... If I use free -k and look at used memory after I clos any application I see an increased memory after that is not 100% released. Because of this on my Qmail+Apache+MySQL+Coldfusion+PHP+..... server that open/close childs memory is going out fast and need to be rebooted daily.... What do you need to trace this? Chris Popescu QMQIS, System Administrator ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 13 01:26:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 01:26:39 -0800 (PST) Received: from mars.gavitec.de (nets.lemnatec.de [212.66.146.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0D9QU3v003175 for ; Mon, 13 Jan 2003 01:26:31 -0800 Received: from joussen.org ([172.16.1.124]) by mars.gavitec.de over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 10:25:00 +0100 Message-ID: <3E2285EB.8060207@joussen.org> Date: Mon, 13 Jan 2003 10:24:59 +0100 From: Mario Joussen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 X-Accept-Language: de-de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Kernel 2.4.18 + xfs 1.1 + xfsdump = kernel oops X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------070600080701020106000304" X-OriginalArrivalTime: 13 Jan 2003 09:25:00.0118 (UTC) FILETIME=[A52BBF60:01C2BAE5] X-archive-position: 2283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mario@joussen.org Precedence: bulk X-list: linux-xfs Status: RO Content-Length: 6528 Lines: 137 This is a multi-part message in MIME format. --------------070600080701020106000304 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, I have a problem with xfs. I have switched my server from 2.4.16-xfs to=20 2.4.18-xfs-1.1. And now xfsdump segfaults if I try to do a backup of one=20 partition. The kernel also produces an oops (see the attachment). What can I do? Cheers, Mario --=20 ,,, Mario Jou=DFen (o o) mario@joussen.org +--------------------------------oOO--(_)--OOo-----------------------------= ---+ "THE FIRST AMENDMENT DOES NOT COVER BURPING" -- Bart Simpson in 2F22 --------------070600080701020106000304 Content-Type: text/plain; name="xfs.oops" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs.oops" ksymoops 2.4.5 on i686 2.4.18-xfs-1.1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.18-xfs-1.1/ (default) -m /boot/System.map-2.4.18-xfs-1.1 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c0263d10, System.map says c014aaf0. Ignoring ksyms_base entry Jan 11 06:54:50 hyperion kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000007c Jan 11 06:54:50 hyperion kernel: c01ec3d4 Jan 11 06:54:50 hyperion kernel: *pde = 00000000 Jan 11 06:54:50 hyperion kernel: Oops: 0000 Jan 11 06:54:50 hyperion kernel: CPU: 0 Jan 11 06:54:50 hyperion kernel: EIP: 0010:[mraccessf+8/84] Not tainted Jan 11 06:54:50 hyperion kernel: EFLAGS: 00010002 Jan 11 06:54:50 hyperion kernel: eax: 00000074 ebx: 00000074 ecx: d36dc068 edx: c03176e0 Jan 11 06:54:50 hyperion kernel: esi: ffffffe8 edi: df561000 ebp: 00000008 esp: c2c2fb0c Jan 11 06:54:50 hyperion kernel: ds: 0018 es: 0018 ss: 0018 Jan 11 06:54:50 hyperion kernel: Process xfsdump (pid: 25300, stackpage=c2c2f000) Jan 11 06:54:50 hyperion kernel: Stack: 00000008 ffffffe8 df561000 c01bfda7 00000074 00000288 ffffffe8 c6bff6e4 Jan 11 06:54:50 hyperion kernel: c01bf951 ffffffe8 00000008 01cb8fc8 00000000 01cb8fc8 00000000 c01c474d Jan 11 06:54:50 hyperion kernel: df561000 00000000 01cb8fc8 00000000 00000008 c2c2fb80 00000000 00000000 Jan 11 06:54:50 hyperion kernel: Call Trace: [xfs_ilock+111/120] [xfs_iget+241/316] [xfs_bulkstat_one+181/1240] [sys_execve+53/96] [xfs_bulkstat_single+63/360] Warning (Oops_read): Code line not seen, dumping what data is available >>ecx; d36dc068 <_end+1333cee4/234eee7c> >>edx; c03176e0 >>esi; ffffffe8 >>edi; df561000 <_end+1f1c1e7c/234eee7c> >>esp; c2c2fb0c <_end+2890988/234eee7c> Jan 11 06:54:50 hyperion kernel: Code: 83 7b 08 00 74 18 ff 43 04 6a 00 8d 43 24 50 8d 43 0c 50 e8 Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 83 7b 08 00 cmpl $0x0,0x8(%ebx) Code; 00000004 Before first symbol 4: 74 18 je 1e <_EIP+0x1e> 0000001e Before first symbol Code; 00000006 Before first symbol 6: ff 43 04 incl 0x4(%ebx) Code; 00000009 Before first symbol 9: 6a 00 push $0x0 Code; 0000000b Before first symbol b: 8d 43 24 lea 0x24(%ebx),%eax Code; 0000000e Before first symbol e: 50 push %eax Code; 0000000f Before first symbol f: 8d 43 0c lea 0xc(%ebx),%eax Code; 00000012 Before first symbol 12: 50 push %eax Code; 00000013 Before first symbol 13: e8 00 00 00 00 call 18 <_EIP+0x18> 00000018 Before first symbol Jan 12 06:27:52 hyperion kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000132 Jan 12 06:27:52 hyperion kernel: c01bf954 Jan 12 06:27:52 hyperion kernel: *pde = 00000000 Jan 12 06:27:52 hyperion kernel: Oops: 0000 Jan 12 06:27:52 hyperion kernel: CPU: 0 Jan 12 06:27:52 hyperion kernel: EIP: 0010:[xfs_iget+244/316] Not tainted Jan 12 06:27:52 hyperion kernel: EFLAGS: 00010246 Jan 12 06:27:52 hyperion kernel: eax: 00000000 ebx: ffffffe8 ecx: 0000000f edx: c03176e0 Jan 12 06:27:52 hyperion kernel: esi: c6bff6e4 edi: df561000 ebp: 00000000 esp: cf1f1e4c Jan 12 06:27:52 hyperion kernel: ds: 0018 es: 0018 ss: 0018 Jan 12 06:27:52 hyperion kernel: Process find (pid: 2247, stackpage=cf1f1000) Jan 12 06:27:52 hyperion kernel: Stack: 00000000 dc2f93c8 00000000 00000008 c01d46fc df561000 00000000 01cb8fc8 Jan 12 06:27:52 hyperion kernel: 00000000 00000000 cf1f1edc 00000000 00000000 dc2f93e0 dc2f93c8 00000008 Jan 12 06:27:52 hyperion kernel: d796fd60 00000000 0000000d c01bfda7 dc2f9454 c01d8c57 00000000 dc2f93e0 Jan 12 06:27:52 hyperion kernel: Call Trace: [xfs_dir_lookup_int+292/656] [xfs_ilock+111/120] [xfs_lookup+147/256] [linvfs_lookup+122/204] [real_lookup+83/196] Jan 12 06:27:52 hyperion kernel: Code: 66 83 bb 4a 01 00 00 00 75 10 80 a3 3c 01 00 00 f7 53 e8 dd >>ebx; ffffffe8 >>edx; c03176e0 >>esi; c6bff6e4 <_end+6860560/234eee7c> >>edi; df561000 <_end+1f1c1e7c/234eee7c> >>esp; cf1f1e4c <_end+ee52cc8/234eee7c> Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 66 83 bb 4a 01 00 00 cmpw $0x0,0x14a(%ebx) Code; 00000007 Before first symbol 7: 00 Code; 00000008 Before first symbol 8: 75 10 jne 1a <_EIP+0x1a> 0000001a Before first symbol Code; 0000000a Before first symbol a: 80 a3 3c 01 00 00 f7 andb $0xf7,0x13c(%ebx) Code; 00000011 Before first symbol 11: 53 push %ebx Code; 00000012 Before first symbol 12: e8 dd 00 00 00 call f4 <_EIP+0xf4> 000000f4 Before first symbol 3 warnings issued. Results may not be reliable. --------------070600080701020106000304-- From owner-linux-xfs@oss.sgi.com Mon Jan 13 03:31:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 03:31:57 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DBVm3v009846 for ; Mon, 13 Jan 2003 03:31:50 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 7D362AC3D for ; Mon, 13 Jan 2003 12:43:18 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id EE08C190B8 for ; Mon, 13 Jan 2003 12:43:09 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id F1BE630881D for ; Mon, 13 Jan 2003 12:37:40 +0100 (CET) Message-ID: <3E22A504.3280C4C6@ch.sauter-bc.com> Date: Mon, 13 Jan 2003 12:37:40 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: Corruption on ext3 with XFS kernel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 2968 Lines: 66 Hi, I have seven IBM deathstar 60G disks here which have been replaced. I want to use four of them in my home server so I wanted to do some tests to make sure they don't break in the first week. I have connected four drives to a Promise Ultra100TX2 IDE controller and put it into my test server. The box is running kernel-2.4.18-18SGI_XFS_1.2pre3. I have created a softraid5 on the disks creating a 180G device. I then created an ext3 fs with default settings. Mounted the fs on /mnt/md9, mounted my real servers data on /mnt/nfs. Then I used cp -a /mnt/nfs /mnt/md9/nfs[n] five times creating five identical copies of the nfs mounted data (/mnt/md9/nfs1, /mnt/md9/nfs2...) with a size of 28G in 16500 file in each copy (143G used / 81%). Then I did two times five diff's running at the same time and I was very surprised what came out: Test with ext3, first run: [root@crash root]# diff -r /mnt/md9/nfs4 /mnt/md9/nfs5 [root@crash root]# diff -r /mnt/nfs /mnt/md9/nfs3 [root@crash root]# diff -r /mnt/md9/nfs3 /mnt/md9/nfs4 [root@crash root]# diff -r /mnt/md9/nfs3 /mnt/md9/nfs5 [root@crash root]# diff -r /mnt/md9/nfs2 /mnt/md9/nfs3 Binary files /mnt/md9/nfs2/Linux/StarOffice/soa-5_2-ga-bin-windows-de.exe and /mnt/md9/nfs3/Linux/StarOffice/soa-5_2-ga-bin-windows-de.exe differ Test with ext3, second run: [root@crash root]# diff -r /mnt/md9/nfs2 /mnt/md9/nfs3 [root@crash root]# diff -r /mnt/md9/nfs1 /mnt/md9/nfs2 [root@crash root]# diff -r /mnt/md9/nfs2 /mnt/md9/nfs4 [root@crash root]# diff -r /mnt/nfs /mnt/md9/nfs1 [root@crash root]# diff -r /mnt/nfs /mnt/md9/nfs2 Binary files /mnt/nfs/mp3/classic/joseph_haydn-symphonies_101_103.track05.mp3 and /mnt/md9/nfs2/mp3/classic/joseph_haydn-symphonies_101_103.track05.mp3 differ Huh! The first 'diff -r /mnt/md9/nfs2 /mnt/md9/nfs3' showed a difference in a file while the second run didn't. The second run showed another difference!! Now, I tried using XFS to see whether it happens there too. I created an XFS filesystem on the same raid5 volume and did exactly the same steps. Test with XFS, first run: [root@crash root]# diff -r /mnt/md9/nfs4 /mnt/md9/nfs5 [root@crash root]# diff -r /mnt/nfs /mnt/md9/nfs3 [root@crash root]# diff -r /mnt/md9/nfs3 /mnt/md9/nfs4 [root@crash root]# diff -r /mnt/md9/nfs3 /mnt/md9/nfs5 [root@crash root]# diff -r /mnt/md9/nfs2 /mnt/md9/nfs3 Test with XFS, second run: [root@crash root]# diff -r /mnt/md9/nfs2 /mnt/md9/nfs3 [root@crash root]# diff -r /mnt/md9/nfs1 /mnt/md9/nfs2 [root@crash root]# diff -r /mnt/md9/nfs2 /mnt/md9/nfs4 [root@crash root]# diff -r /mnt/nfs /mnt/md9/nfs1 [root@crash root]# diff -r /mnt/nfs /mnt/md9/nfs2 Now, it looks like a problem with ext3. My question is, could it have _something_ to do with the XFS patch in this kernel? Did anybody do similar tests? Unfortunately this box has XFS root so I can't just switch to vanilla or original RedHat kernel and every test takes me ~1day. Is there a way to find out what's going wrong here? Simon From owner-linux-xfs@oss.sgi.com Mon Jan 13 03:46:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 03:46:47 -0800 (PST) Received: from batleth.sapienti-sat.org ([80.190.100.240]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DBki3v010333 for ; Mon, 13 Jan 2003 03:46:45 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id B793A10102F for ; Mon, 13 Jan 2003 12:52:45 +0100 (CET) Received: from warp9.sapienti-sat.org (pD9E7FC80.dip.t-dialin.net [217.231.252.128]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 3941810072C for ; Mon, 13 Jan 2003 12:52:45 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id ED648BC for ; Mon, 13 Jan 2003 12:52:41 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by warp9.sapienti-sat.org (Postfix) with ESMTP id 83A7CAA for ; Mon, 13 Jan 2003 12:52:41 +0100 (CET) Message-ID: <3E22A889.70203@koschikode.com> Date: Mon, 13 Jan 2003 12:52:41 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs Subject: Re: Corruption on ext3 with XFS kernel References: <3E22A504.3280C4C6@ch.sauter-bc.com> In-Reply-To: <3E22A504.3280C4C6@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 1400 Lines: 32 Simon Matter wrote: > Hi, > > I have seven IBM deathstar 60G disks here which have been replaced. I > want to use four of them in my home server so I wanted to do some tests > to make sure they don't break in the first week. I have connected four > drives to a Promise Ultra100TX2 IDE controller and put it into my test > server. The box is running kernel-2.4.18-18SGI_XFS_1.2pre3. I have > created a softraid5 on the disks creating a 180G device. I then created > an ext3 fs with default settings. Mounted the fs on /mnt/md9, mounted my > real servers data on /mnt/nfs. Then I used cp -a /mnt/nfs > /mnt/md9/nfs[n] five times creating five identical copies of the nfs > mounted data (/mnt/md9/nfs1, /mnt/md9/nfs2...) with a size of 28G in > 16500 file in each copy (143G used / 81%). > Then I did two times five diff's running at the same time and I was very > surprised what came out: [SNIP] > Now, it looks like a problem with ext3. My question is, could it have > _something_ to do with the XFS patch in this kernel? Did anybody do > similar tests? Unfortunately this box has XFS root so I can't just > switch to vanilla or original RedHat kernel and every test takes me > ~1day. Is there a way to find out what's going wrong here? You can try to apply the three bugfix-patches for 2.4.20/ext3 at http://www.zip.com.au/~akpm/linux/ext3/ (see "Updates for the 2.4.20 kernel"). Regards, Juri From owner-linux-xfs@oss.sgi.com Mon Jan 13 04:05:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 04:05:22 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DC5B3v011241 for ; Mon, 13 Jan 2003 04:05:12 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZBLC7PGH; Mon, 13 Jan 2003 07:11:22 -0500 Received: from wgate.com (sinz.eng.tvol.net [127.0.0.1]) by sinz.eng.tvol.net (8.12.5/8.12.5) with ESMTP id h0DC9lPd006703; Mon, 13 Jan 2003 07:09:47 -0500 Message-ID: <3E22AC8B.2020906@wgate.com> Date: Mon, 13 Jan 2003 07:09:47 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Strange XFS corruption... References: <20030110091029.49057.qmail@web14808.mail.yahoo.com> <3E1F4879.7090909@wgate.com> <1042238348.20737.37.camel@stout.americas.sgi.com> In-Reply-To: <1042238348.20737.37.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 1385 Lines: 30 Eric Sandeen wrote: > We've actually seen this here too, recently. We -think- it is the > result of previous filesystem corruption on shutdown, which should now > be fixed. Did you have any filesystem shutdowns or other corruption > before this? The possible corruption bug that was fixed could even > happen on a clean shutdown, unfortunately. Well, there was that one time a while back (late November?) where XFS was broken (clean shutdown would prevent a boot due to some block information being confused) I reverted and recovered back then and had not had a crash (unclean shutdown) since then. Also, some more information: xfs_check was returning that the system was clean (all OK, not even a minor warning) and yet I had a number of "mtab" files in /etc. In fact, I had a hard time getting rid of them. Using "rm" did not work well (that would really confuse the directory and required a shutdown/reboot to recover from - and still multiple /etc/mtab files) In finally fixed it my doing a "mv /etc/mtab* /junk/" (I had created that directory. All of the mtab file entries were no gone from /etc and /junk had only one. (and a simple rm -rf /junk cleaned that up) xfs_check still claims all is fine. -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Mon Jan 13 06:08:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 06:08:17 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DE8C3v012881 for ; Mon, 13 Jan 2003 06:08:12 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0DDKAKp018818 for ; Mon, 13 Jan 2003 05:20:10 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA14433; Mon, 13 Jan 2003 08:14:06 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA44152; Mon, 13 Jan 2003 08:14:08 -0600 (CST) Date: Mon, 13 Jan 2003 08:12:36 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Mario Joussen cc: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.18 + xfs 1.1 + xfsdump = kernel oops In-Reply-To: <3E2285EB.8060207@joussen.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2287 X-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: 452 Lines: 19 Can you try this with xfs 1.2pre release, and current xfsdump? Just to be sure we're not hunting a bug that's already fixed? -Eric On Mon, 13 Jan 2003, Mario Joussen wrote: > Hi all, > > I have a problem with xfs. I have switched my server from 2.4.16-xfs to > 2.4.18-xfs-1.1. And now xfsdump segfaults if I try to do a backup of one > partition. The kernel also produces an oops (see the attachment). > > What can I do? > > Cheers, Mario > From owner-linux-xfs@oss.sgi.com Mon Jan 13 06:13:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 06:13:33 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DEDR3v013394 for ; Mon, 13 Jan 2003 06:13:27 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0DDPPKp019067 for ; Mon, 13 Jan 2003 05:25:25 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA65633; Mon, 13 Jan 2003 08:19:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA91237; Mon, 13 Jan 2003 08:19:23 -0600 (CST) Date: Mon, 13 Jan 2003 08:17:51 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Michael Sinz cc: linux-xfs@oss.sgi.com Subject: Re: Strange XFS corruption... In-Reply-To: <3E22AC8B.2020906@wgate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2288 X-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: 1937 Lines: 44 Yep, when we got multiple entries here, neither check nor repair complained. I guess it's not fundamentally inconsistent from a filesystem integrity perspective, but it does not make the operating system happy. We don't have a root cause for this one, we think it's another way that the shutdown problem exhibited itself. If you can run the latest code (1.2pre5) the shutdown problem should be fixed, and if you see it again, let us know! -Eric On Mon, 13 Jan 2003, Michael Sinz wrote: > Eric Sandeen wrote: > > We've actually seen this here too, recently. We -think- it is the > > result of previous filesystem corruption on shutdown, which should now > > be fixed. Did you have any filesystem shutdowns or other corruption > > before this? The possible corruption bug that was fixed could even > > happen on a clean shutdown, unfortunately. > > Well, there was that one time a while back (late November?) where > XFS was broken (clean shutdown would prevent a boot due to some > block information being confused) I reverted and recovered back then > and had not had a crash (unclean shutdown) since then. > > Also, some more information: xfs_check was returning that the system > was clean (all OK, not even a minor warning) and yet I had a number of > "mtab" files in /etc. In fact, I had a hard time getting rid of them. > Using "rm" did not work well (that would really confuse the directory > and required a shutdown/reboot to recover from - and still multiple > /etc/mtab files) > > In finally fixed it my doing a "mv /etc/mtab* /junk/" (I had created > that directory. All of the mtab file entries were no gone from /etc > and /junk had only one. (and a simple rm -rf /junk cleaned that up) > > xfs_check still claims all is fine. > > -- > Michael Sinz -- Director, Systems Engineering -- Worldgate Communications > A master's secrets are only as good as > the master's ability to explain them to others. > From owner-linux-xfs@oss.sgi.com Mon Jan 13 06:57:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 06:57:13 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DEv63v014131 for ; Mon, 13 Jan 2003 06:57:07 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZBLC7QBQ; Mon, 13 Jan 2003 10:03:18 -0500 Received: from wgate.com (sinz.eng.tvol.net [127.0.0.1]) by sinz.eng.tvol.net (8.12.5/8.12.5) with ESMTP id h0DF1fPd006992; Mon, 13 Jan 2003 10:01:41 -0500 Message-ID: <3E22D4D5.2080401@wgate.com> Date: Mon, 13 Jan 2003 10:01:41 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Strange XFS corruption... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 1105 Lines: 26 Eric Sandeen wrote: > Yep, when we got multiple entries here, neither check nor repair complained. > I guess it's not fundamentally inconsistent from a filesystem integrity > perspective, but it does not make the operating system happy. > > We don't have a root cause for this one, we think it's another way > that the shutdown problem exhibited itself. If you can run the latest > code (1.2pre5) the shutdown problem should be fixed, and if you see > it again, let us know! Well, I am now running from CVS as of Jan 11, 2003. I have not seen this elsewhere yet. I wonder how the filesystem thought that this was "fine" since all of the files (the multiple entries) showed exactly the same date/size/etc. (Albeit that may be due to the VFS layer - I am not 100% clear on how those two interact) However, I would think that XFS should not like having multiple file node entries in a directory with the same identifier (file name). -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Mon Jan 13 09:43:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 09:43:40 -0800 (PST) Received: from esds.vss.fsi.com (adsl-66-136-174-212.dsl.stlsmo.swbell.net [66.136.174.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DHha3v017253 for ; Mon, 13 Jan 2003 09:43:37 -0800 Received: from mosix (mosix [198.51.26.70]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id LAA23719 for ; Mon, 13 Jan 2003 11:49:34 -0600 (CST) Subject: XFS mount option From: Matt Schillinger To: linux-xfs@oss.sgi.com In-Reply-To: <3E1F4879.7090909@wgate.com> References: <20030110091029.49057.qmail@web14808.mail.yahoo.com> <3E1F4879.7090909@wgate.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 13 Jan 2003 11:50:40 -0600 Message-Id: <1042480241.12651.5.camel@mosix> Mime-Version: 1.0 X-archive-position: 2290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mschilli@vss.fsi.com Precedence: bulk X-list: linux-xfs Content-Length: 183 Lines: 6 I have heard that xfs mounts will always ignore the mount option 'sync', and mount asynchronously.. Is this true? Is there any danger in this? Matt Schillinger mschilli@vss.fsi.com From owner-linux-xfs@oss.sgi.com Mon Jan 13 09:55:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 09:55:45 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DHtc3v018037 for ; Mon, 13 Jan 2003 09:55:39 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0DG1jG8029691 for ; Mon, 13 Jan 2003 08:01:45 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA13420; Mon, 13 Jan 2003 12:01:36 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA04920; Mon, 13 Jan 2003 12:01:35 -0600 (CST) Subject: Re: XFS mount option From: Eric Sandeen To: Matt Schillinger Cc: linux-xfs@oss.sgi.com In-Reply-To: <1042480241.12651.5.camel@mosix> References: <20030110091029.49057.qmail@web14808.mail.yahoo.com> <3E1F4879.7090909@wgate.com> <1042480241.12651.5.camel@mosix> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 13 Jan 2003 12:00:02 -0600 Message-Id: <1042480802.11829.26.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2291 X-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: 823 Lines: 29 After just a quick glance, it looks like we do handle the sync option. in xfs_write, we do: /* Handle various SYNC-type writes */ if ((file->f_flags & O_SYNC) || IS_SYNC(file->f_dentry->d_inode)) { ... etc ... and the IS_SYNC looks for the MS_SYNCHRONOUS flag on the mount, which is set when you mount with sync. So there's the 10,000-foot handwaving answer. :) You might do some testing to see if this all really works. -Eric On Mon, 2003-01-13 at 11:50, Matt Schillinger wrote: > I have heard that xfs mounts will always ignore the mount option 'sync', > and mount asynchronously.. Is this true? Is there any danger in this? > > Matt Schillinger > mschilli@vss.fsi.com > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Jan 13 10:52:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 10:52:18 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DIqB3v020777 for ; Mon, 13 Jan 2003 10:52:11 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0DGwHG8001968 for ; Mon, 13 Jan 2003 08:58:17 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA78055; Mon, 13 Jan 2003 12:58:07 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA72750; Mon, 13 Jan 2003 12:58:06 -0600 (CST) Received: from rose.americas.sgi.com (localhost [127.0.0.1]) by rose.americas.sgi.com (8.12.6/8.12.5) with ESMTP id h0DJ1Ukx010782; Mon, 13 Jan 2003 13:01:33 -0600 Received: (from cattelan@localhost) by rose.americas.sgi.com (8.12.6/8.12.6/Submit) id h0DJ1RQA010780; Mon, 13 Jan 2003 13:01:27 -0600 X-Authentication-Warning: rose.americas.sgi.com: cattelan set sender to cattelan@xfs.org using -f Subject: Re: Strange XFS corruption... From: Russell Cattelan To: Michael Sinz Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <3E22D4D5.2080401@wgate.com> References: <3E22D4D5.2080401@wgate.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042484486.10751.6.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 (1.2.0-3) Date: 13 Jan 2003 13:01:27 -0600 X-archive-position: 2292 X-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 Content-Length: 1603 Lines: 35 On Mon, 2003-01-13 at 09:01, Michael Sinz wrote: > Eric Sandeen wrote: > > Yep, when we got multiple entries here, neither check nor repair complained. > > I guess it's not fundamentally inconsistent from a filesystem integrity > > perspective, but it does not make the operating system happy. > > > > We don't have a root cause for this one, we think it's another way > > that the shutdown problem exhibited itself. If you can run the latest > > code (1.2pre5) the shutdown problem should be fixed, and if you see > > it again, let us know! > > Well, I am now running from CVS as of Jan 11, 2003. I have not seen > this elsewhere yet. > > I wonder how the filesystem thought that this was "fine" since > all of the files (the multiple entries) showed exactly the same > date/size/etc. (Albeit that may be due to the VFS layer - I am > not 100% clear on how those two interact) Multiple entries in a directory shouldn't happen, and from a FS consistency point it really isn't a fatal problem either. It's basically a "lookup" problem. Checking for multiple entries of the same name is not something xfs_check/xfs_repair checks for and therefore will not report a problem. It's certainly possible to add this check to xfs_repair although it's unlikely we will make it a high priority. > > However, I would think that XFS should not like having multiple > file node entries in a directory with the same identifier (file name). XFS doesn't really care just it just passes whatever it has to the upper layers for it to sort out. This is true of all the FS. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Mon Jan 13 11:10:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 11:10:12 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DJA83v021442 for ; Mon, 13 Jan 2003 11:10:09 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZBLC7RQ7; Mon, 13 Jan 2003 14:16:21 -0500 Received: from wgate.com (sinz.eng.tvol.net [127.0.0.1]) by sinz.eng.tvol.net (8.12.5/8.12.5) with ESMTP id h0DJGBPd007623; Mon, 13 Jan 2003 14:16:11 -0500 Message-ID: <3E23107B.3040100@wgate.com> Date: Mon, 13 Jan 2003 14:16:11 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russell Cattelan CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Strange XFS corruption... References: <3E22D4D5.2080401@wgate.com> <1042484486.10751.6.camel@rose.americas.sgi.com> In-Reply-To: <1042484486.10751.6.camel@rose.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 2373 Lines: 55 Russell Cattelan wrote: > On Mon, 2003-01-13 at 09:01, Michael Sinz wrote: > >>Eric Sandeen wrote: >> >>>Yep, when we got multiple entries here, neither check nor repair complained. >>>I guess it's not fundamentally inconsistent from a filesystem integrity >>>perspective, but it does not make the operating system happy. >>> >>>We don't have a root cause for this one, we think it's another way >>>that the shutdown problem exhibited itself. If you can run the latest >>>code (1.2pre5) the shutdown problem should be fixed, and if you see >>>it again, let us know! >> >>Well, I am now running from CVS as of Jan 11, 2003. I have not seen >>this elsewhere yet. >> >>I wonder how the filesystem thought that this was "fine" since >>all of the files (the multiple entries) showed exactly the same >>date/size/etc. (Albeit that may be due to the VFS layer - I am >>not 100% clear on how those two interact) > > Multiple entries in a directory shouldn't happen, and from a FS > consistency point it really isn't a fatal problem either. > It's basically a "lookup" problem. > Checking for multiple entries of the same name is not something > xfs_check/xfs_repair checks for and therefore will not report a problem. > > It's certainly possible to add this check to xfs_repair although it's > unlikely we will make it a high priority. I can understand that - as it could significantly increase the time needed to do a check and/or repair. If it does not happen, it is not high priority. However, when it does happen, it is a PITA to deal with. >>However, I would think that XFS should not like having multiple >>file node entries in a directory with the same identifier (file name). > > XFS doesn't really care just it just passes whatever it has to the upper > layers for it to sort out. This is true of all the FS. I guess this is why, when I try to delete one of them that things go strange... There still was something strange going on in the system since the rm, while looking like it worked, caused problems (ls would then give an error for each "duplicate" file that was there but not list the file even once) and, after a reboot, they all came back) (Sort of like a bad dream with cats :-) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Mon Jan 13 13:41:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 13:41:42 -0800 (PST) Received: from imf21bis.bellsouth.net (mail221.mail.bellsouth.net [205.152.58.181]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DLfa3v003723 for ; Mon, 13 Jan 2003 13:41:38 -0800 Received: from marsha ([66.156.0.183]) by imf21bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030113214928.NXIW20432.imf21bis.bellsouth.net@marsha>; Mon, 13 Jan 2003 16:49:28 -0500 Date: Mon, 13 Jan 2003 16:47:35 -0500 From: Greg Freemyer Subject: re[2]: [linux-lvm] [Q] LVM snapshot volume extendable? To: LVM Mailing list cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20030113214928.NXIW20432.imf21bis.bellsouth.net@marsha> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0DLfc3v003724 X-archive-position: 2294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1448 Lines: 39 I agree, their seems to be a bug in LVM. I am running XFS Version 1.2pre3 based on the 2.4.19 kernel and I cannot extend a LV with XFS fs on top. In particular this works: >>> xfs_freeze -f /data (I don't have the patch installed) lvcreate --snapshot -L 100M --name data_snap /dev/VG/data xfs_freeze -u /data (I don't have the patch installed) mount -t xfs -o ro,nouuid /dev/VG/data_snap /data_snap <<< And this does not. >>> xfs_freeze -f /data (I don't have the patch installed) lvcreate --snapshot -L 100M --name data_snap /dev/VG/data xfs_freeze -u /data (I don't have the patch installed) lvdisplay /dev/VG/data_snap (verified 0% used) dd if=/dev/zero of=/data/dummy bs=1M count=75 (create a 75 Meg dummy file) lvdisplay /dev/VG/data_snap (verified approx 75% used) lvextend -L +100M /dev/VG/data_snap lvdisplay /dev/VG/data_snap (verified approx 37% used) # Everything looks fine, so I try to mount it mount -t xfs -o ro,nouuid /dev/VG/data_snap /data_snap mount: wrong fs type, bad option, bad superblock on /dev/TruStore-Data/data_snap, or too many mounted file systems <<< Greg Freemyer The Norcross Group From owner-linux-xfs@oss.sgi.com Mon Jan 13 13:58:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 13:58:57 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DLwl3v004288 for ; Mon, 13 Jan 2003 13:58:48 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18YChN-0001PC-00 for linux-xfs@oss.sgi.com; Mon, 13 Jan 2003 22:04:49 +0000 Received: from tolkor.sgi.com ([198.149.18.6]) by phoenix.infradead.org with esmtp (Exim 4.10) id 18YCgy-0001Mo-00 for hch@infradead.org; Mon, 13 Jan 2003 22:04:25 +0000 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0DMBJkq001292 for ; Mon, 13 Jan 2003 16:11:19 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA96097 for ; Mon, 13 Jan 2003 16:03:52 -0600 (CST) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA07172 for ; Mon, 13 Jan 2003 16:03:51 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h0DM3mQb51128334 for ; Mon, 13 Jan 2003 14:03:49 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h0DM1Wla013463 for ; Mon, 13 Jan 2003 23:01:32 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h0DM1WM5013462 for hch@sgi.com; Mon, 13 Jan 2003 23:01:32 +0100 Date: Mon, 13 Jan 2003 23:01:32 +0100 From: Christoph Hellwig Message-Id: <200301132201.h0DM1WM5013462@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.57 To: undisclosed-recipients:; Resent-From: hch@infradead.org Resent-Date: Mon, 13 Jan 2003 22:04:49 +0000 Resent-To: linux-xfs@oss.sgi.com Resent-Message-Id: X-archive-position: 2295 X-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: 59958 Lines: 1503 Date: Mon Jan 13 13:56:57 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:136727a linux/crypto/aes.c - 1.1 linux/drivers/scsi/pcmcia/fdomain_core.c - 1.1 linux/drivers/scsi/pcmcia/qlogic_core.c - 1.1 linux/arch/ppc/configs/redwood6_defconfig - 1.1 linux/arch/ppc/configs/rainier_defconfig - 1.1 linux/arch/ppc/configs/beech_defconfig - 1.1 linux/Documentation/arm/00-INDEX - 1.1 linux/Documentation/arm/Booting - 1.1 linux/include/asm-i386/mach-default/mach_wakecpu.h - 1.1 linux/include/asm-i386/mach-numaq/mach_wakecpu.h - 1.1 linux/include/asm-ppc/ibm_ocp_pci.h - 1.1 linux/include/asm-ppc/ocp.h - 1.1 linux/include/asm-ppc/ocp_ids.h - 1.1 linux/arch/ppc/configs/sycamore_defconfig - 1.1 linux/include/asm-ppc64/xics.h - 1.1 linux/drivers/scsi/zalon.h - 1.1 linux/drivers/scsi/zalon.c - 1.1 linux/Documentation/driver-model/porting.txt - 1.1 linux/drivers/char/watchdog/alim7101_wdt.c - 1.1 linux/net/ipv4/xfrm_algo.c - 1.1 linux/drivers/scsi/pcmcia/aha152x_core.c - 1.1 linux/arch/ppc/kernel/idle_6xx.S - 1.1 linux/arch/ppc/platforms/4xx/Kconfig - 1.1 linux/arch/ppc/platforms/4xx/beech.c - 1.1 linux/arch/ppc/platforms/4xx/beech.h - 1.1 linux/arch/ppc/platforms/4xx/ibm405gpr.c - 1.1 linux/arch/ppc/platforms/4xx/ibm405gpr.h - 1.1 linux/arch/ppc/platforms/4xx/ibm405lp.c - 1.1 linux/arch/ppc/platforms/4xx/ibm405lp.h - 1.1 linux/drivers/char/agp/via-kt400.c - 1.1 linux/drivers/char/watchdog/wafer5823wdt.c - 1.1 linux/arch/ppc/platforms/4xx/ibmnp4gs.c - 1.1 linux/drivers/char/watchdog/indydog.c - 1.1 linux/drivers/char/watchdog/sa1100_wdt.c - 1.1 linux/drivers/char/watchdog/sc1200wdt.c - 1.1 linux/drivers/char/watchdog/sc520_wdt.c - 1.1 linux/arch/ppc/platforms/4xx/ibmnp4gs.h - 1.1 linux/arch/alpha/kernel/module.c - 1.1 linux/drivers/media/video/bt832.h - 1.1 linux/drivers/ide/pci/triflex.c - 1.1 linux/drivers/ide/pci/triflex.h - 1.1 linux/drivers/isdn/hisax/ipac.c - 1.1 linux/arch/ppc/syslib/ppc4xx_dma.c - 1.1 linux/drivers/media/video/bt832.c - 1.1 linux/drivers/media/video/v4l1-compat.c - 1.1 linux/arch/ppc/platforms/4xx/ibmstbx25.c - 1.1 linux/arch/ppc/platforms/4xx/ibmstbx25.h - 1.1 linux/drivers/media/video/tda9887.c - 1.1 linux/arch/ppc/platforms/4xx/oak.h - 1.1 linux/drivers/net/amd8111e.c - 1.1 linux/drivers/net/amd8111e.h - 1.1 linux/arch/ppc/platforms/4xx/sycamore.c - 1.1 linux/arch/ppc/platforms/4xx/sycamore.h - 1.1 linux/arch/ppc/platforms/4xx/oak_setup.c - 1.1 linux/arch/ppc/platforms/4xx/redwood6.h - 1.1 linux/arch/ppc/platforms/4xx/redwood6.c - 1.1 linux/arch/ppc/platforms/4xx/oak_setup.h - 1.1 linux/net/unix/garbage.c - 1.13 linux/net/unix/af_unix.c - 1.51 linux/net/sunrpc/svcsock.c - 1.27 linux/net/sunrpc/svcauth.c - 1.8 linux/net/sunrpc/svc.c - 1.20 linux/net/sunrpc/sunrpc_syms.c - 1.19 linux/net/sunrpc/auth.c - 1.12 linux/net/socket.c - 1.49 linux/net/netsyms.c - 1.57 linux/net/ipv6/udp.c - 1.35 linux/net/ipv6/proc.c - 1.13 linux/net/ipv6/ipv6_sockglue.c - 1.19 linux/net/ipv6/icmp.c - 1.23 linux/net/ipv6/exthdrs.c - 1.7 linux/net/ipv6/af_inet6.c - 1.29 linux/net/ipv4/udp.c - 1.38 linux/net/ipv4/tcp_timer.c - 1.27 linux/net/ipv4/tcp_ipv4.c - 1.57 linux/net/ipv4/tcp_input.c - 1.47 linux/net/ipv4/tcp.c - 1.50 linux/net/ipv4/route.c - 1.42 linux/net/ipv4/raw.c - 1.30 linux/net/ipv4/proc.c - 1.16 linux/net/ipv4/ip_output.c - 1.41 linux/net/ipv4/ip_input.c - 1.20 linux/net/ipv4/ip_fragment.c - 1.18 linux/net/ipv4/icmp.c - 1.36 linux/net/ipv4/fib_hash.c - 1.10 linux/net/ipv4/arp.c - 1.28 linux/net/ipv4/af_inet.c - 1.47 linux/net/ipv4/Makefile - 1.16 linux/net/core/skbuff.c - 1.29 linux/net/core/rtnetlink.c - 1.12 linux/net/core/dev.c - 1.66 linux/mm/swapfile.c - 1.70 linux/mm/swap_state.c - 1.57 linux/mm/swap.c - 1.33 linux/mm/slab.c - 1.48 linux/mm/mremap.c - 1.40 linux/mm/mmap.c - 1.68 linux/mm/memory.c - 1.99 linux/mm/filemap.c - 1.146 linux/kernel/sched.c - 1.91 linux/kernel/printk.c - 1.28 linux/kernel/panic.c - 1.20 linux/kernel/module.c - 1.34 linux/kernel/ksyms.c - 1.178 linux/kernel/fork.c - 1.80 linux/kernel/exit.c - 1.61 linux/kernel/Makefile - 1.41 linux/ipc/shm.c - 1.62 linux/ipc/sem.c - 1.25 linux/ipc/msg.c - 1.19 linux/init/main.c - 1.100 linux/include/net/udp.h - 1.13 linux/include/net/tcp.h - 1.40 linux/include/net/snmp.h - 1.11 linux/include/net/route.h - 1.22 linux/include/net/ipv6.h - 1.13 linux/include/net/ip.h - 1.22 linux/include/net/icmp.h - 1.8 linux/include/linux/watchdog.h - 1.6 linux/include/linux/videodev.h - 1.25 linux/include/linux/swap.h - 1.71 linux/include/linux/sunrpc/svcsock.h - 1.10 linux/include/linux/sunrpc/svcauth.h - 1.5 linux/include/linux/sunrpc/auth.h - 1.8 linux/include/linux/smp.h - 1.24 linux/include/linux/skbuff.h - 1.30 linux/include/linux/signal.h - 1.10 linux/include/linux/sched.h - 1.95 linux/include/linux/rtnetlink.h - 1.15 linux/include/linux/pagemap.h - 1.51 linux/include/linux/nfsd/nfsd.h - 1.19 linux/include/linux/netdevice.h - 1.41 linux/include/linux/msg.h - 1.10 linux/include/linux/module.h - 1.41 linux/include/linux/mm.h - 1.111 linux/include/linux/kernel.h - 1.42 linux/include/linux/init.h - 1.24 linux/include/linux/if_arp.h - 1.14 linux/include/linux/genhd.h - 1.32 linux/include/linux/fs.h - 1.202 linux/include/linux/fb.h - 1.29 linux/include/linux/elf.h - 1.20 linux/include/linux/dirent.h - 1.4 linux/include/asm-sparc64/uaccess.h - 1.9 linux/include/asm-sparc64/statfs.h - 1.3 linux/include/asm-sparc64/smp.h - 1.18 linux/include/asm-sparc64/siginfo.h - 1.14 linux/include/asm-sparc64/posix_types.h - 1.8 linux/include/asm-sparc64/mmu_context.h - 1.19 linux/include/asm-sparc64/ide.h - 1.18 linux/include/asm-sparc64/fcntl.h - 1.16 linux/include/asm-sparc/uaccess.h - 1.10 linux/include/asm-sparc/system.h - 1.18 linux/include/asm-sparc/sbus.h - 1.10 linux/include/asm-sparc/mmu_context.h - 1.8 linux/include/asm-sparc/bitops.h - 1.17 linux/include/asm-ppc/uaccess.h - 1.13 linux/include/asm-ppc/termios.h - 1.10 linux/include/asm-ppc/spinlock.h - 1.18 linux/include/asm-ppc/socket.h - 1.10 linux/include/asm-ppc/signal.h - 1.7 linux/include/asm-ppc/ptrace.h - 1.12 linux/include/asm-ppc/prom.h - 1.16 linux/include/asm-ppc/processor.h - 1.38 linux/include/asm-ppc/pci-bridge.h - 1.13 linux/include/asm-ppc/param.h - 1.8 linux/include/asm-ppc/page.h - 1.20 linux/include/asm-ppc/nvram.h - 1.9 linux/include/asm-ppc/mmu_context.h - 1.16 linux/include/asm-ppc/irq.h - 1.18 linux/include/asm-ppc/io.h - 1.20 linux/include/asm-ppc/cache.h - 1.14 linux/include/asm-ppc/bitops.h - 1.18 linux/include/asm-mips/mmu_context.h - 1.8 linux/include/asm-m68k/mmu_context.h - 1.10 linux/include/asm-i386/uaccess.h - 1.19 linux/include/asm-i386/system.h - 1.31 linux/include/asm-i386/smp.h - 1.26 linux/include/asm-i386/ptrace.h - 1.11 linux/include/asm-i386/mmu_context.h - 1.24 linux/include/asm-i386/elf.h - 1.10 linux/include/asm-arm/unistd.h - 1.26 linux/include/asm-arm/uaccess.h - 1.11 linux/include/asm-arm/semaphore.h - 1.9 linux/include/asm-arm/procinfo.h - 1.13 linux/include/asm-arm/proc-armv/uaccess.h - 1.13 linux/include/asm-arm/mmu_context.h - 1.14 linux/include/asm-arm/irq.h - 1.6 linux/include/asm-arm/io.h - 1.24 linux/include/asm-arm/ecard.h - 1.6 linux/include/asm-arm/current.h - 1.7 linux/include/asm-alpha/uaccess.h - 1.9 linux/include/asm-alpha/mmu_context.h - 1.16 linux/include/asm-alpha/irq.h - 1.6 linux/fs/romfs/inode.c - 1.42 linux/fs/readdir.c - 1.19 linux/fs/proc/array.c - 1.54 linux/fs/nfsd/vfs.c - 1.63 linux/fs/nfsd/nfssvc.c - 1.29 linux/fs/nfsd/nfsproc.c - 1.31 linux/fs/nfsd/nfsfh.c - 1.48 linux/fs/nfsd/nfsctl.c - 1.38 linux/fs/nfsd/nfs3xdr.c - 1.35 linux/fs/nfsd/export.c - 1.46 linux/fs/nfs/write.c - 1.48 linux/fs/nfs/read.c - 1.39 linux/fs/nfs/proc.c - 1.22 linux/fs/nfs/inode.c - 1.61 linux/fs/ncpfs/sock.c - 1.16 linux/fs/namei.c - 1.64 linux/fs/inode.c - 1.89 linux/fs/ext2/inode.c - 1.63 linux/fs/exec.c - 1.75 linux/fs/block_dev.c - 1.71 linux/drivers/video/tgafb.c - 1.23 linux/drivers/video/fbmem.c - 1.57 linux/drivers/sgi/char/usema.c - 1.10 linux/drivers/sgi/char/streamable.c - 1.10 linux/drivers/scsi/sym53c8xx_defs.h - 1.13 linux/drivers/scsi/sym53c416.c - 1.15 linux/drivers/scsi/sr_ioctl.c - 1.32 linux/drivers/scsi/sg.c - 1.47 linux/drivers/scsi/ncr53c8xx.c - 1.30 linux/drivers/scsi/ide-scsi.c - 1.51 linux/drivers/scsi/i91uscsi.c - 1.7 linux/drivers/scsi/gdth.h - 1.12 linux/drivers/scsi/gdth.c - 1.24 linux/drivers/scsi/g_NCR5380.c - 1.19 linux/drivers/scsi/fdomain.c - 1.26 linux/drivers/scsi/esp.c - 1.30 linux/drivers/scsi/aic7xxx/aic7xxx.seq - 1.12 linux/drivers/scsi/aic7xxx/aic7xxx.reg - 1.10 linux/drivers/scsi/aha1542.c - 1.31 linux/drivers/scsi/aha152x.c - 1.35 linux/drivers/scsi/NCR53C9x.c - 1.21 linux/drivers/scsi/Makefile - 1.47 linux/drivers/sbus/sbus.c - 1.20 linux/drivers/sbus/char/envctrl.c - 1.18 linux/drivers/sbus/char/bpp.c - 1.24 linux/drivers/pci/proc.c - 1.32 linux/drivers/net/znet.c - 1.14 linux/drivers/net/yellowfin.c - 1.34 linux/drivers/net/sunlance.c - 1.30 linux/drivers/net/smc9194.c - 1.23 linux/drivers/net/smc-ultra.c - 1.25 linux/drivers/net/sk_g16.c - 1.18 linux/drivers/net/sgiseeq.c - 1.19 linux/drivers/net/seeq8005.c - 1.17 linux/drivers/net/ni65.c - 1.19 linux/drivers/net/ni52.c - 1.19 linux/drivers/net/ni5010.c - 1.17 linux/drivers/net/ne.c - 1.23 linux/drivers/net/lance.c - 1.28 linux/drivers/net/irda/w83977af_ir.c - 1.28 linux/drivers/net/hp100.c - 1.26 linux/drivers/net/fmv18x.c - 1.19 linux/drivers/net/eth16i.c - 1.23 linux/drivers/net/epic100.c - 1.34 linux/drivers/net/eexpress.c - 1.22 linux/drivers/net/eepro100.c - 1.54 linux/drivers/net/eepro.c - 1.29 linux/drivers/net/depca.c - 1.24 linux/drivers/net/de620.c - 1.18 linux/drivers/net/de600.c - 1.21 linux/drivers/net/atp.c - 1.22 linux/drivers/net/atarilance.c - 1.16 linux/drivers/net/atari_bionet.c - 1.16 linux/drivers/net/at1700.c - 1.23 linux/drivers/net/ariadne.c - 1.19 linux/drivers/net/am79c961a.c - 1.16 linux/drivers/net/a2065.c - 1.21 linux/drivers/net/Makefile - 1.66 linux/drivers/net/8390.c - 1.27 linux/drivers/net/82596.c - 1.23 linux/drivers/net/7990.c - 1.11 linux/drivers/net/3c59x.c - 1.43 linux/drivers/net/3c527.c - 1.21 linux/drivers/net/3c523.c - 1.18 linux/drivers/net/3c515.c - 1.26 linux/drivers/net/3c509.c - 1.39 linux/drivers/net/3c507.c - 1.24 linux/drivers/net/3c505.c - 1.32 linux/drivers/net/3c501.c - 1.23 linux/drivers/macintosh/via-pmu.c - 1.23 linux/drivers/isdn/hisax/teles3.c - 1.18 linux/drivers/isdn/hisax/teles0.c - 1.16 linux/drivers/isdn/hisax/teleint.c - 1.15 linux/drivers/isdn/hisax/tei.c - 1.12 linux/drivers/isdn/hisax/sportster.c - 1.15 linux/drivers/isdn/hisax/sedlbauer.c - 1.22 linux/drivers/isdn/hisax/rawhdlc.h - 1.6 linux/drivers/isdn/hisax/rawhdlc.c - 1.7 linux/drivers/isdn/hisax/q931.c - 1.8 linux/drivers/isdn/hisax/niccy.c - 1.20 linux/drivers/isdn/hisax/netjet.c - 1.25 linux/drivers/isdn/hisax/mic.c - 1.14 linux/drivers/isdn/hisax/l3dss1.h - 1.8 linux/drivers/isdn/hisax/l3dss1.c - 1.17 linux/drivers/isdn/hisax/l3_1tr6.c - 1.12 linux/drivers/isdn/hisax/ix1_micro.c - 1.15 linux/drivers/isdn/hisax/isdnl3.h - 1.7 linux/drivers/isdn/hisax/isdnl3.c - 1.16 linux/drivers/isdn/hisax/isdnl2.c - 1.17 linux/drivers/isdn/hisax/isdnl1.h - 1.8 linux/drivers/isdn/hisax/isdnl1.c - 1.20 linux/drivers/isdn/hisax/isac.h - 1.8 linux/drivers/isdn/hisax/isac.c - 1.17 linux/drivers/isdn/hisax/ipac.h - 1.7 linux/drivers/isdn/hisax/hscx_irq.c - 1.11 linux/drivers/isdn/hisax/hscx.h - 1.8 linux/drivers/isdn/hisax/hscx.c - 1.16 linux/drivers/isdn/hisax/hisax.h - 1.33 linux/drivers/isdn/hisax/hfc_2bs0.h - 1.7 linux/drivers/isdn/hisax/hfc_2bs0.c - 1.19 linux/drivers/isdn/hisax/hfc_2bds0.h - 1.7 linux/drivers/isdn/hisax/hfc_2bds0.c - 1.19 linux/drivers/isdn/hisax/elsa.c - 1.23 linux/drivers/isdn/hisax/diva.c - 1.19 linux/drivers/isdn/hisax/config.c - 1.35 linux/drivers/isdn/hisax/callc.c - 1.22 linux/drivers/isdn/hisax/avm_a1.c - 1.15 linux/drivers/isdn/hisax/asuscom.c - 1.18 linux/drivers/isdn/hisax/arcofi.c - 1.12 linux/drivers/isdn/hisax/amd7930.c - 1.16 linux/drivers/isdn/hisax/Makefile - 1.24 linux/drivers/char/ftape/zftape/zftape_syms.h - 1.3 linux/drivers/char/ftape/zftape/zftape-write.c - 1.5 linux/drivers/char/ftape/zftape/zftape-read.c - 1.5 linux/drivers/char/ftape/zftape/zftape-init.c - 1.16 linux/drivers/char/ftape/zftape/zftape-ctl.h - 1.3 linux/drivers/char/ftape/zftape/zftape-ctl.c - 1.6 linux/drivers/char/ftape/zftape/zftape-buffers.c - 1.6 linux/drivers/char/ftape/lowlevel/ftape_syms.h - 1.3 linux/drivers/char/ftape/lowlevel/ftape-setup.c - 1.6 linux/drivers/char/ftape/lowlevel/ftape-init.c - 1.6 linux/drivers/char/ftape/lowlevel/ftape-ctl.c - 1.8 linux/drivers/char/ftape/lowlevel/fdc-isr.c - 1.5 linux/drivers/char/ftape/lowlevel/fdc-io.c - 1.8 linux/drivers/char/ftape/compressor/zftape-compress.c - 1.8 linux/drivers/cdrom/cdrom.c - 1.51 linux/drivers/block/genhd.c - 1.45 linux/drivers/acorn/scsi/powertec.c - 1.20 linux/drivers/acorn/scsi/eesox.c - 1.20 linux/drivers/acorn/scsi/cumana_2.c - 1.20 linux/arch/sparc64/mm/init.c - 1.55 linux/arch/sparc64/mm/fault.c - 1.26 linux/arch/sparc64/mm/extable.c - 1.7 linux/arch/sparc64/kernel/unaligned.c - 1.11 linux/arch/sparc64/kernel/traps.c - 1.25 linux/arch/sparc64/kernel/systbls.S - 1.38 linux/arch/sparc64/kernel/sys_sunos32.c - 1.42 linux/arch/sparc64/kernel/sys_sparc32.c - 1.66 linux/arch/sparc64/kernel/sunos_ioctl32.c - 1.4 linux/arch/sparc64/kernel/ioctl32.c - 1.64 linux/arch/sparc64/defconfig - 1.85 linux/arch/sparc64/Makefile - 1.26 linux/arch/sparc/mm/init.c - 1.34 linux/arch/sparc/mm/fault.c - 1.22 linux/arch/sparc/mm/extable.c - 1.8 linux/arch/sparc/kernel/unaligned.c - 1.9 linux/arch/sparc/kernel/sun4m_irq.c - 1.12 linux/arch/sparc/kernel/sun4d_irq.c - 1.19 linux/arch/sparc/kernel/sun4c_irq.c - 1.11 linux/arch/sparc/kernel/sparc_ksyms.c - 1.34 linux/arch/sparc/kernel/Makefile - 1.21 linux/arch/sparc/boot/Makefile - 1.12 linux/arch/sparc/Makefile - 1.22 linux/arch/ppc/mm/init.c - 1.47 linux/arch/ppc/mm/fault.c - 1.24 linux/arch/ppc/mm/extable.c - 1.8 linux/arch/ppc/mm/Makefile - 1.15 linux/arch/ppc/lib/string.S - 1.11 linux/arch/ppc/kernel/traps.c - 1.28 linux/arch/ppc/kernel/time.c - 1.23 linux/arch/ppc/kernel/setup.c - 1.53 linux/arch/ppc/kernel/process.c - 1.46 linux/arch/ppc/kernel/ppc_ksyms.c - 1.53 linux/arch/ppc/kernel/ppc-stub.c - 1.12 linux/arch/ppc/kernel/misc.S - 1.53 linux/arch/ppc/kernel/irq.c - 1.42 linux/arch/ppc/kernel/head.S - 1.39 linux/arch/ppc/kernel/Makefile - 1.36 linux/arch/ppc/boot/Makefile - 1.22 linux/arch/ppc/Makefile - 1.35 linux/arch/ppc/8xx_io/fec.c - 1.19 linux/arch/mips/mm/init.c - 1.16 linux/arch/mips/kernel/pci.c - 1.9 linux/arch/m68k/mm/init.c - 1.17 linux/arch/m68k/kernel/traps.c - 1.17 linux/arch/i386/mm/init.c - 1.51 linux/arch/i386/mm/fault.c - 1.31 linux/arch/i386/mm/extable.c - 1.7 linux/arch/i386/lib/usercopy.c - 1.9 linux/arch/i386/kernel/vm86.c - 1.23 linux/arch/i386/kernel/traps.c - 1.70 linux/arch/i386/kernel/smp.c - 1.52 linux/arch/i386/kernel/signal.c - 1.32 linux/arch/i386/kernel/ptrace.c - 1.27 linux/arch/i386/kernel/process.c - 1.64 linux/arch/i386/kernel/ioport.c - 1.9 linux/arch/i386/kernel/i386_ksyms.c - 1.64 linux/arch/i386/kernel/entry.S - 1.71 linux/arch/i386/kernel/apm.c - 1.56 linux/arch/i386/Makefile - 1.43 linux/arch/arm/mm/proc-sa110.S - 1.30 linux/arch/arm/mm/init.c - 1.36 linux/arch/arm/mm/fault-common.c - 1.25 linux/arch/arm/mm/extable.c - 1.6 linux/arch/arm/kernel/signal.c - 1.28 linux/arch/arm/kernel/setup.c - 1.39 linux/arch/arm/kernel/irq.c - 1.26 linux/arch/arm/kernel/ecard.c - 1.25 linux/arch/arm/kernel/calls.S - 1.21 linux/arch/arm/kernel/armksyms.c - 1.32 linux/arch/arm/boot/compressed/head.S - 1.23 linux/arch/arm/boot/compressed/Makefile - 1.27 linux/arch/arm/Makefile - 1.41 linux/arch/alpha/mm/init.c - 1.26 linux/arch/alpha/mm/fault.c - 1.21 linux/arch/alpha/mm/extable.c - 1.7 linux/arch/alpha/math-emu/Makefile - 1.10 linux/arch/alpha/lib/Makefile - 1.21 linux/arch/alpha/kernel/traps.c - 1.27 linux/arch/alpha/kernel/sys_alcor.c - 1.14 linux/arch/alpha/kernel/alpha_ksyms.c - 1.39 linux/arch/alpha/kernel/Makefile - 1.28 linux/arch/alpha/boot/Makefile - 1.14 linux/arch/alpha/Makefile - 1.26 linux/Makefile - 1.235 linux/MAINTAINERS - 1.129 linux/CREDITS - 1.95 linux/include/linux/ide.h - 1.73 linux/drivers/isdn/hisax/telespci.c - 1.14 linux/drivers/isdn/hisax/s0box.c - 1.12 linux/drivers/isdn/hisax/isar.h - 1.9 linux/drivers/isdn/hisax/isar.c - 1.22 linux/drivers/isdn/hisax/elsa_ser.c - 1.14 linux/drivers/isdn/hisax/avm_pci.c - 1.19 linux/drivers/isdn/hisax/avm_a1p.c - 1.12 linux/arch/i386/vmlinux.lds.S - 1.15 linux/drivers/net/declance.c - 1.17 linux/drivers/net/bagetlance.c - 1.14 linux/kernel/ptrace.c - 1.29 linux/drivers/char/raw.c - 1.35 linux/drivers/char/sx.c - 1.29 linux/include/linux/isapnp.h - 1.16 linux/fs/partitions/check.c - 1.63 linux/drivers/isdn/hisax/saphir.c - 1.13 linux/drivers/isdn/hisax/jade_irq.c - 1.10 linux/drivers/isdn/hisax/jade.h - 1.6 linux/drivers/isdn/hisax/jade.c - 1.14 linux/drivers/isdn/hisax/isurf.c - 1.15 linux/drivers/isdn/hisax/hfcscard.c - 1.12 linux/drivers/isdn/hisax/hfc_pci.h - 1.8 linux/drivers/isdn/hisax/hfc_pci.c - 1.28 linux/drivers/isdn/hisax/gazel.c - 1.17 linux/drivers/isdn/hisax/bkm_a8.c - 1.16 linux/drivers/isdn/hisax/bkm_a4t.c - 1.16 linux/drivers/isdn/divert/divert_init.c - 1.7 linux/drivers/net/sb1000.c - 1.20 linux/drivers/char/ip2.c - 1.8 linux/drivers/atm/atmtcp.c - 1.12 linux/arch/ppc/kernel/entry.S - 1.32 linux/arch/arm/vmlinux-armv.lds.in - 1.23 linux/arch/arm/vmlinux-armo.lds.in - 1.21 linux/arch/arm/kernel/bios32.c - 1.33 linux/arch/sh/vmlinux.lds.S - 1.16 linux/arch/sh/mm/init.c - 1.21 linux/drivers/scsi/ips.h - 1.20 linux/drivers/scsi/ips.c - 1.34 linux/include/asm-sh/mmu_context.h - 1.12 linux/drivers/pcmcia/i82365.c - 1.31 linux/drivers/pcmcia/cardbus.c - 1.24 linux/drivers/net/sun3lance.c - 1.16 linux/arch/m68k/vmlinux-sun3.lds - 1.13 linux/arch/m68k/mac/iop.c - 1.7 linux/include/linux/spinlock.h - 1.22 linux/drivers/net/starfire.c - 1.29 linux/drivers/net/pcmcia/ray_cs.c - 1.28 linux/include/linux/acpi.h - 1.33 linux/Documentation/filesystems/proc.txt - 1.16 linux/arch/i386/kernel/smpboot.c - 1.55 linux/include/linux/pci_ids.h - 1.81 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.20 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.21 linux/Documentation/vm/locking - 1.8 linux/include/linux/highmem.h - 1.28 linux/include/asm-i386/highmem.h - 1.16 linux/include/asm-arm/pci.h - 1.23 linux/drivers/isdn/hisax/w6692.h - 1.5 linux/drivers/isdn/hisax/w6692.c - 1.17 linux/drivers/pci/pci.ids - 1.56 linux/arch/ppc/kernel/head_4xx.S - 1.11 linux/arch/ppc/configs/walnut_defconfig - 1.21 linux/arch/ppc/configs/pmac_defconfig - 1.12 linux/arch/ppc/configs/oak_defconfig - 1.21 linux/arch/ppc/configs/mbx_defconfig - 1.16 linux/arch/ppc/configs/gemini_defconfig - 1.23 linux/arch/ppc/configs/common_defconfig - 1.33 linux/arch/ppc/configs/apus_defconfig - 1.20 linux/include/linux/agp_backend.h - 1.24 linux/drivers/net/aironet4500_proc.c - 1.15 linux/drivers/net/aironet4500_card.c - 1.20 linux/drivers/char/agp/Makefile - 1.12 linux/drivers/char/agp/agp.h - 1.31 linux/Documentation/video4linux/bttv/CARDLIST - 1.16 linux/drivers/pcmcia/yenta.c - 1.37 linux/include/linux/ixjuser.h - 1.5 linux/drivers/telephony/ixj.h - 1.9 linux/drivers/telephony/ixj.c - 1.26 linux/Documentation/usb/scanner-hp-sane.txt - 1.5 linux/Documentation/usb/scanner.txt - 1.8 linux/arch/i386/kernel/mpparse.c - 1.31 linux/include/asm-i386/io_apic.h - 1.10 linux/drivers/scsi/scsi_scan.c - 1.38 linux/arch/i386/kernel/pci-dma.c - 1.6 linux/include/asm-sparc/ide.h - 1.15 linux/drivers/net/irda/nsc-ircc.c - 1.25 linux/arch/ia64/ia32/sys_ia32.c - 1.38 linux/arch/ia64/vmlinux.lds.S - 1.20 linux/arch/ia64/mm/init.c - 1.24 linux/include/asm-ia64/ia32.h - 1.15 linux/include/linux/raid/md_p.h - 1.4 linux/include/linux/raid/md_k.h - 1.30 linux/include/asm-ia64/mmu_context.h - 1.12 linux/include/asm-arm/proc-armv/locks.h - 1.6 linux/drivers/net/8139too.c - 1.47 linux/drivers/macintosh/via-pmu68k.c - 1.9 linux/arch/arm/mm/consistent.c - 1.13 linux/drivers/isdn/hisax/hfc_sx.c - 1.17 linux/drivers/scsi/pcmcia/qlogic_stub.c - 1.9 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.9 linux/drivers/scsi/pcmcia/Makefile - 1.8 linux/drivers/scsi/pcmcia/aha152x_stub.c - 1.10 linux/drivers/char/nwflash.c - 1.15 linux/include/asm-mips64/mmu_context.h - 1.7 linux/arch/mips64/mm/init.c - 1.10 linux/arch/mips64/sgi-ip27/ip27-rtc.c - 1.11 linux/arch/alpha/kernel/irq_i8259.c - 1.6 linux/drivers/usb/serial/usb-serial.h - 1.27 linux/drivers/usb/serial/usb-serial.c - 1.10 linux/drivers/ide/ide.c - 1.80 linux/drivers/ide/ide-pnp.c - 1.12 linux/Documentation/DocBook/videobook.tmpl - 1.7 linux/Documentation/DocBook/Makefile - 1.40 linux/drivers/scsi/sym53c8xx_comm.h - 1.14 linux/Documentation/DocBook/kernel-api.tmpl - 1.25 linux/net/ipv4/netfilter/ipt_multiport.c - 1.6 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.17 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.19 linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.10 linux/net/ipv4/netfilter/ip_conntrack_ftp.c - 1.11 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.16 linux/include/linux/netfilter_ipv4/ip_nat_helper.h - 1.5 linux/drivers/video/sa1100fb.c - 1.19 linux/fs/nfs/nfs3proc.c - 1.20 linux/drivers/usb/serial/whiteheat.c - 1.37 linux/drivers/usb/serial/visor.c - 1.48 linux/include/linux/nfs_page.h - 1.11 linux/drivers/char/rio/rioctrl.c - 1.9 linux/include/asm-s390/mmu_context.h - 1.4 linux/arch/s390/kernel/traps.c - 1.14 linux/arch/s390/mm/init.c - 1.14 linux/fs/xfs/xfs_dmapi.c - 1.95 linux/kernel/kallsyms.c - 1.17 linux/include/asm-ppc/time.h - 1.12 linux/drivers/usb/storage/transport.h - 1.15 linux/drivers/usb/storage/transport.c - 1.37 linux/drivers/usb/serial/keyspan.c - 1.39 linux/drivers/acpi/tables/tbxface.c - 1.15 linux/drivers/acpi/tables/tbutils.c - 1.16 linux/drivers/acpi/tables/tbinstal.c - 1.16 linux/drivers/acpi/tables/tbget.c - 1.17 linux/drivers/acpi/resources/rsxface.c - 1.11 linux/drivers/acpi/resources/rsutils.c - 1.13 linux/drivers/acpi/resources/rsmisc.c - 1.10 linux/drivers/acpi/resources/rsmemory.c - 1.10 linux/drivers/acpi/resources/rslist.c - 1.12 linux/drivers/acpi/resources/rsirq.c - 1.13 linux/drivers/acpi/resources/rsio.c - 1.12 linux/drivers/acpi/resources/rsdump.c - 1.13 linux/drivers/acpi/resources/rscreate.c - 1.15 linux/drivers/acpi/resources/rscalc.c - 1.14 linux/drivers/acpi/resources/rsaddr.c - 1.11 linux/drivers/acpi/parser/psxface.c - 1.14 linux/drivers/acpi/parser/pswalk.c - 1.11 linux/drivers/acpi/parser/psutils.c - 1.14 linux/drivers/acpi/parser/pstree.c - 1.12 linux/drivers/acpi/parser/psscope.c - 1.10 linux/drivers/acpi/parser/psparse.c - 1.18 linux/drivers/acpi/parser/psopcode.c - 1.17 linux/drivers/acpi/parser/psargs.c - 1.16 linux/drivers/acpi/namespace/nsxfobj.c - 1.16 linux/drivers/acpi/namespace/nsxfname.c - 1.13 linux/drivers/acpi/namespace/nswalk.c - 1.10 linux/drivers/acpi/namespace/nsutils.c - 1.17 linux/drivers/acpi/namespace/nssearch.c - 1.17 linux/drivers/acpi/namespace/nsobject.c - 1.15 linux/drivers/acpi/namespace/nsnames.c - 1.15 linux/drivers/acpi/namespace/nsload.c - 1.16 linux/drivers/acpi/namespace/nseval.c - 1.17 linux/drivers/acpi/namespace/nsalloc.c - 1.15 linux/drivers/acpi/namespace/nsaccess.c - 1.17 linux/arch/arm/mm/proc-arm720.S - 1.17 linux/drivers/acpi/include/amlcode.h - 1.15 linux/drivers/acpi/include/actypes.h - 1.18 linux/drivers/acpi/include/actables.h - 1.14 linux/drivers/acpi/include/acpixf.h - 1.16 linux/drivers/acpi/include/acpiosxf.h - 1.15 linux/drivers/acpi/include/acpi.h - 1.7 linux/drivers/acpi/include/acobject.h - 1.16 linux/drivers/acpi/include/acexcep.h - 1.13 linux/drivers/acpi/hardware/hwregs.c - 1.16 linux/drivers/acpi/hardware/hwgpe.c - 1.13 linux/drivers/acpi/hardware/hwacpi.c - 1.14 linux/drivers/acpi/events/evxfregn.c - 1.14 linux/drivers/acpi/events/evxfevnt.c - 1.13 linux/drivers/acpi/events/evxface.c - 1.16 linux/drivers/acpi/events/evsci.c - 1.11 linux/drivers/acpi/events/evrgnini.c - 1.14 linux/drivers/acpi/events/evregion.c - 1.16 linux/drivers/acpi/events/evmisc.c - 1.15 linux/drivers/acpi/events/evevent.c - 1.19 linux/drivers/acpi/ec.c - 1.15 linux/drivers/acpi/dispatcher/dswstate.c - 1.17 linux/drivers/acpi/dispatcher/dswscope.c - 1.12 linux/drivers/acpi/dispatcher/dswload.c - 1.20 linux/drivers/acpi/dispatcher/dswexec.c - 1.15 linux/drivers/acpi/dispatcher/dsutils.c - 1.17 linux/drivers/acpi/dispatcher/dsopcode.c - 1.18 linux/drivers/acpi/dispatcher/dsobject.c - 1.21 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.15 linux/drivers/acpi/dispatcher/dsmethod.c - 1.15 linux/drivers/acpi/dispatcher/dsfield.c - 1.15 linux/arch/ppc/configs/rpxlite_defconfig - 1.16 linux/arch/ppc/configs/rpxcllf_defconfig - 1.17 linux/arch/ppc/configs/est8260_defconfig - 1.18 linux/arch/ppc/configs/bseip_defconfig - 1.16 linux/net/ipv4/tcp_minisocks.c - 1.21 linux/drivers/usb/storage/freecom.c - 1.19 linux/drivers/net/natsemi.c - 1.26 linux/drivers/media/video/tvmixer.c - 1.12 linux/drivers/media/video/tuner.c - 1.14 linux/drivers/media/video/tda9875.c - 1.10 linux/drivers/media/video/tda7432.c - 1.10 linux/drivers/media/video/msp3400.c - 1.14 linux/drivers/media/video/bttv.h - 1.13 linux/drivers/media/video/bttv-if.c - 1.9 linux/drivers/media/video/bttv-driver.c - 1.26 linux/drivers/media/video/bttv-cards.c - 1.16 linux/drivers/media/video/audiochip.h - 1.3 linux/drivers/media/video/Makefile - 1.13 linux/drivers/media/radio/radio-sf16fmi.c - 1.16 linux/drivers/media/radio/radio-cadet.c - 1.12 linux/drivers/isdn/hisax/nj_u.c - 1.13 linux/drivers/isdn/hisax/nj_s.c - 1.14 linux/drivers/isdn/hisax/netjet.h - 1.5 linux/drivers/isdn/hisax/l3ni1.h - 1.5 linux/drivers/isdn/hisax/l3ni1.c - 1.10 linux/drivers/isdn/hisax/icc.h - 1.5 linux/drivers/isdn/hisax/icc.c - 1.11 linux/arch/arm/tools/mach-types - 1.21 linux/drivers/md/raid1.c - 1.29 linux/drivers/md/raid5.c - 1.39 linux/arch/arm/mach-sa1100/Makefile - 1.17 linux/arch/arm/mm/proc-arm920.S - 1.14 linux/drivers/acpi/include/acconfig.h - 1.23 linux/drivers/acpi/include/acdebug.h - 1.16 linux/drivers/acpi/include/acdispat.h - 1.12 linux/drivers/acpi/include/acevents.h - 1.13 linux/drivers/acpi/include/acglobal.h - 1.17 linux/drivers/acpi/include/achware.h - 1.10 linux/drivers/acpi/include/acinterp.h - 1.16 linux/drivers/acpi/include/aclocal.h - 1.19 linux/drivers/acpi/include/acmacros.h - 1.16 linux/drivers/acpi/include/acnamesp.h - 1.16 linux/drivers/acpi/include/acoutput.h - 1.12 linux/drivers/acpi/include/acparser.h - 1.14 linux/drivers/acpi/include/acresrc.h - 1.9 linux/drivers/acpi/include/actbl.h - 1.11 linux/drivers/acpi/namespace/nsdump.c - 1.16 linux/drivers/char/toshiba.c - 1.9 linux/drivers/md/md.c - 1.66 linux/net/core/dv.c - 1.6 linux/drivers/media/video/tvaudio.c - 1.13 linux/drivers/media/video/bttvp.h - 1.11 linux/include/asm-alpha/module.h - 1.4 linux/include/asm-ppc/module.h - 1.7 linux/include/asm-parisc/mmu_context.h - 1.3 linux/include/asm-m68k/motorola_pgalloc.h - 1.9 linux/drivers/net/lasi_82596.c - 1.15 linux/arch/parisc/mm/init.c - 1.6 linux/drivers/usb/serial/empeg.c - 1.34 linux/arch/parisc/kernel/traps.c - 1.5 linux/include/asm-m68k/sun3_pgalloc.h - 1.10 linux/drivers/acpi/tables/tbconvrt.c - 1.14 linux/drivers/acpi/tables/tbxfroot.c - 1.12 linux/drivers/acpi/namespace/nsinit.c - 1.14 linux/drivers/acpi/include/actbl71.h - 1.8 linux/drivers/acpi/include/actbl2.h - 1.11 linux/drivers/acpi/include/actbl1.h - 1.8 linux/mm/shmem.c - 1.54 linux/drivers/acpi/power.c - 1.11 linux/drivers/acpi/hardware/hwsleep.c - 1.13 linux/drivers/acpi/hardware/hwtimer.c - 1.10 linux/drivers/usb/storage/unusual_devs.h - 1.15 linux/arch/ppc/configs/power3_defconfig - 1.14 linux/arch/ppc/configs/ibmchrp_defconfig - 1.14 linux/arch/s390x/kernel/traps.c - 1.10 linux/include/asm-s390x/mmu_context.h - 1.2 linux/arch/s390x/kernel/linux32.h - 1.5 linux/arch/s390x/kernel/linux32.c - 1.21 linux/arch/s390x/kernel/entry.S - 1.18 linux/arch/s390x/mm/init.c - 1.10 linux/arch/s390x/kernel/wrapper32.S - 1.10 linux/include/asm-arm/mach/irq.h - 1.5 linux/include/asm-cris/mmu_context.h - 1.3 linux/include/asm-ppc/tlb.h - 1.5 linux/drivers/usb/serial/io_edgeport.c - 1.32 linux/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_pci.c - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.11 linux/drivers/scsi/aic7xxx/aic7xxx.h - 1.6 linux/drivers/scsi/aic7xxx/Makefile - 1.12 linux/drivers/net/sungem.c - 1.23 linux/drivers/isdn/hisax/sedlbauer_cs.c - 1.5 linux/arch/ppc/configs/TQM860L_defconfig - 1.16 linux/arch/ppc/configs/TQM850L_defconfig - 1.14 linux/arch/ppc/configs/TQM823L_defconfig - 1.14 linux/arch/ppc/configs/SPD823TS_defconfig - 1.14 linux/arch/ppc/configs/SM850_defconfig - 1.14 linux/arch/ppc/configs/IVMS8_defconfig - 1.16 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.7 linux/drivers/net/irda/irda-usb.c - 1.29 linux/arch/ppc/boot/prep/of1275.h - 1.3 linux/arch/ppc/boot/prep/of1275.c - 1.3 linux/arch/ppc/boot/prep/misc.c - 1.12 linux/drivers/mtd/maps/sa1100-flash.c - 1.4 linux/drivers/acpi/executer/exstore.c - 1.15 linux/drivers/acpi/utilities/utxface.c - 1.9 linux/drivers/acpi/utilities/utobject.c - 1.10 linux/drivers/acpi/utilities/utmisc.c - 1.13 linux/drivers/acpi/utilities/utinit.c - 1.10 linux/drivers/acpi/utilities/utglobal.c - 1.16 linux/drivers/acpi/utilities/uteval.c - 1.11 linux/drivers/acpi/utilities/utdelete.c - 1.11 linux/drivers/acpi/utilities/utdebug.c - 1.11 linux/drivers/acpi/utilities/utcopy.c - 1.13 linux/drivers/acpi/utilities/utalloc.c - 1.8 linux/drivers/acpi/include/acstruct.h - 1.10 linux/drivers/acpi/include/acutils.h - 1.14 linux/drivers/acpi/include/platform/acenv.h - 1.11 linux/drivers/acpi/include/platform/acgcc.h - 1.11 linux/drivers/acpi/include/platform/aclinux.h - 1.11 linux/drivers/acpi/executer/exutils.c - 1.12 linux/drivers/acpi/executer/exsystem.c - 1.7 linux/drivers/acpi/executer/exstorob.c - 1.10 linux/drivers/acpi/executer/exstoren.c - 1.11 linux/drivers/acpi/executer/exconfig.c - 1.11 linux/drivers/acpi/executer/exconvrt.c - 1.13 linux/drivers/acpi/executer/excreate.c - 1.12 linux/drivers/acpi/executer/exdump.c - 1.15 linux/drivers/acpi/executer/exfield.c - 1.9 linux/drivers/acpi/executer/exfldio.c - 1.12 linux/drivers/acpi/executer/exmisc.c - 1.13 linux/drivers/acpi/executer/exmutex.c - 1.8 linux/drivers/acpi/executer/exnames.c - 1.8 linux/drivers/acpi/executer/exprep.c - 1.12 linux/drivers/acpi/executer/exregion.c - 1.10 linux/drivers/acpi/executer/exresnte.c - 1.15 linux/drivers/acpi/executer/exresolv.c - 1.13 linux/drivers/acpi/executer/exresop.c - 1.15 linux/drivers/usb/serial/pl2303.c - 1.26 linux/drivers/net/irda/ali-ircc.c - 1.13 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.14 linux/drivers/scsi/pcmcia/nsp_cs.h - 1.8 linux/drivers/media/video/zr36067.c - 1.11 linux/drivers/net/lp486e.c - 1.9 linux/arch/arm/mach-sa1100/sa1111.c - 1.13 linux/arch/arm/mach-sa1100/sa1111-pcibuf.c - 1.7 linux/arch/arm/mach-sa1100/pcipool.c - 1.4 linux/arch/arm/mach-sa1100/neponset.c - 1.15 linux/arch/arm/mach-sa1100/jornada720.c - 1.10 linux/arch/arm/mach-integrator/cpu.c - 1.9 linux/arch/arm/mach-sa1100/irq.c - 1.9 linux/arch/arm/mach-sa1100/cpu-sa1100.c - 1.8 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.10 linux/arch/ppc/mm/4xx_mmu.c - 1.6 linux/arch/ppc/mm/mmu_context.c - 1.5 linux/arch/ppc/mm/mmu_decl.h - 1.8 linux/arch/ppc/mm/pgtable.c - 1.10 linux/arch/ppc/mm/ppc_mmu.c - 1.8 linux/arch/ppc/mm/tlb.c - 1.8 linux/include/asm-ppc/cputable.h - 1.5 linux/arch/ppc/boot/common/ofcommon.c - 1.4 linux/arch/ppc/kernel/l2cr.S - 1.5 linux/arch/ppc/kernel/cputable.c - 1.9 linux/Documentation/arm/SA1100/DMA - 1.2 linux/drivers/isdn/hisax/st5481.h - 1.7 linux/drivers/isdn/hisax/st5481_b.c - 1.9 linux/drivers/isdn/hisax/st5481_usb.c - 1.14 linux/drivers/scsi/53c700.h - 1.8 linux/drivers/scsi/lasi700.c - 1.6 linux/drivers/isdn/hisax/hisax_debug.h - 1.4 linux/include/asm-ia64/tlb.h - 1.8 linux/include/asm-generic/tlb.h - 1.11 linux/include/asm-arm/tlb.h - 1.6 linux/drivers/mtd/devices/blkmtd.c - 1.18 linux/include/asm-i386/smpboot.h - 1.4 linux/include/asm-ppc/commproc.h - 1.4 linux/drivers/usb/serial/ir-usb.c - 1.25 linux/drivers/pcmcia/sa1100_jornada720.c - 1.5 linux/Documentation/video4linux/bttv/Cards - 1.5 linux/drivers/acpi/executer/exoparg6.c - 1.5 linux/drivers/acpi/utilities/utmath.c - 1.5 linux/drivers/net/irda/sa1100_ir.c - 1.7 linux/drivers/acpi/executer/exoparg3.c - 1.7 linux/drivers/acpi/executer/exoparg2.c - 1.12 linux/drivers/acpi/executer/exoparg1.c - 1.13 linux/arch/arm/mm/proc-arm1020.S - 1.10 linux/arch/arm/mm/proc-arm926.S - 1.10 linux/fs/ext3/inode.c - 1.30 linux/drivers/hotplug/pci_hotplug_core.c - 1.16 linux/fs/nfs/pagelist.c - 1.9 linux/drivers/net/pcmcia/axnet_cs.c - 1.6 linux/include/linux/bio.h - 1.18 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.9 linux/fs/bio.c - 1.25 linux/include/linux/device.h - 1.26 linux/drivers/isdn/hisax/hisax_isac.h - 1.3 linux/drivers/isdn/hisax/hisax_isac.c - 1.4 linux/drivers/isdn/hisax/hisax_fcpcipnp.h - 1.2 linux/init/do_mounts.c - 1.23 linux/mm/mempool.c - 1.16 linux/arch/arm/mm/proc-xscale.S - 1.11 linux/arch/arm/mm/proc-arm922.S - 1.9 linux/include/asm-arm/arch-iop310/memory.h - 1.5 linux/drivers/net/Makefile.lib - 1.4 linux/include/linux/crc32.h - 1.2 linux/lib/crc32.c - 1.5 linux/drivers/net/wireless/wavelan.c - 1.5 linux/drivers/isdn/hisax/hisax_fcclassic.c - 1.2 linux/drivers/isdn/hisax/hisax_hscx.c - 1.3 linux/drivers/isdn/hisax/hisax_hscx.h - 1.2 linux/drivers/net/wireless/wavelan_cs.p.h - 1.5 linux/net/ipv4/netfilter/ipt_ULOG.c - 1.6 linux/drivers/net/mii.c - 1.9 linux/drivers/base/interface.c - 1.12 linux/drivers/base/core.c - 1.21 linux/include/linux/pnpbios.h - 1.7 linux/drivers/input/gameport/ns558.c - 1.6 linux/drivers/input/gameport/gameport.c - 1.6 linux/include/asm-i386/thread_info.h - 1.8 linux/sound/sound_firmware.c - 1.2 linux/sound/pci/ali5451/ali5451.c - 1.13 linux/arch/ppc/boot/simple/Makefile - 1.10 linux/arch/ppc/boot/simple/embed_config.c - 1.5 linux/arch/ppc/boot/simple/misc-embedded.c - 1.5 linux/arch/ppc/boot/simple/misc-spruce.c - 1.3 linux/arch/ppc/configs/FADS_defconfig - 1.5 linux/arch/ppc/configs/TQM8260_defconfig - 1.4 linux/sound/oss/sonicvibes.c - 1.6 linux/arch/ppc/configs/adir_defconfig - 1.5 linux/arch/ppc/configs/ash_defconfig - 1.5 linux/arch/ppc/configs/cpci405_defconfig - 1.7 linux/arch/ppc/configs/ep405_defconfig - 1.5 linux/arch/ppc/configs/ev64260_defconfig - 1.5 linux/arch/ppc/configs/iSeries_defconfig - 1.5 linux/arch/ppc/configs/k2_defconfig - 1.9 linux/arch/ppc/configs/lopec_defconfig - 1.6 linux/arch/ppc/configs/mcpn765_defconfig - 1.5 linux/arch/ppc/configs/menf1_defconfig - 1.9 linux/arch/ppc/configs/mvme5100_defconfig - 1.7 linux/arch/ppc/configs/pcore_defconfig - 1.4 linux/arch/ppc/configs/pplus_defconfig - 1.9 linux/arch/ppc/configs/prpmc750_defconfig - 1.5 linux/arch/ppc/configs/prpmc800_defconfig - 1.5 linux/arch/ppc/configs/redwood5_defconfig - 1.6 linux/arch/ppc/configs/redwood_defconfig - 1.5 linux/arch/ppc/configs/sandpoint_defconfig - 1.10 linux/arch/ppc/configs/spruce_defconfig - 1.5 linux/arch/ppc/configs/zx4500_defconfig - 1.5 linux/arch/ppc/iSeries/HvCall.c - 1.2 linux/arch/ppc/iSeries/HvLpConfig.c - 1.2 linux/arch/ppc/iSeries/HvLpEvent.c - 1.2 linux/arch/ppc/iSeries/ItLpQueue.c - 1.2 linux/arch/ppc/iSeries/LparData.c - 1.3 linux/arch/ppc/iSeries/Makefile - 1.5 linux/arch/ppc/iSeries/XmPciLpEvent.c - 1.2 linux/arch/ppc/iSeries/createReleaseData - 1.2 linux/arch/ppc/iSeries/iSeries_FlightRecorder.c - 1.2 linux/arch/ppc/iSeries/iSeries_IoMmTable.c - 1.2 linux/arch/ppc/iSeries/iSeries_IoMmTable.h - 1.2 linux/arch/ppc/iSeries/iSeries_VpdInfo.c - 1.2 linux/arch/ppc/iSeries/iSeries_fixup.c - 1.2 linux/arch/ppc/iSeries/iSeries_irq.c - 1.3 linux/arch/ppc/iSeries/iSeries_ksyms.c - 1.2 linux/arch/ppc/iSeries/iSeries_pci.c - 1.2 linux/arch/ppc/iSeries/iSeries_pci.h - 1.2 linux/arch/ppc/iSeries/iSeries_pci_proc.c - 1.2 linux/arch/ppc/iSeries/iSeries_proc.c - 1.2 linux/arch/ppc/iSeries/iSeries_reset_device.c - 1.2 linux/arch/ppc/iSeries/mf.c - 1.4 linux/arch/ppc/iSeries/mf_proc.c - 1.2 linux/arch/ppc/iSeries/pmc_proc.c - 1.2 linux/arch/ppc/iSeries/rtc.c - 1.5 linux/sound/oss/opl3sa2.c - 1.6 linux/arch/ppc/kernel/iSeries_asm.h - 1.3 linux/arch/ppc/kernel/iSeries_head.S - 1.7 linux/arch/ppc/kernel/iSeries_misc.S - 1.6 linux/sound/oss/esssolo1.c - 1.8 linux/sound/oss/es1371.c - 1.7 linux/sound/oss/es1370.c - 1.7 linux/arch/ppc/mm/iSeries_hashtable.c - 1.3 linux/arch/ppc/mm/iSeries_mmu.c - 1.4 linux/arch/ppc/platforms/Makefile - 1.10 linux/arch/ppc/platforms/adir_pic.c - 1.2 linux/arch/ppc/platforms/adir_setup.c - 1.4 linux/arch/ppc/platforms/ccm.h - 1.2 linux/arch/ppc/platforms/iSeries_dma.c - 1.2 linux/arch/ppc/platforms/iSeries_pic.c - 1.5 linux/arch/ppc/platforms/iSeries_setup.c - 1.5 linux/arch/ppc/platforms/iSeries_setup.h - 1.2 linux/arch/ppc/platforms/iSeries_smp.c - 1.5 linux/arch/ppc/platforms/iSeries_time.c - 1.4 linux/arch/ppc/platforms/k2_pci.c - 1.3 linux/arch/ppc/platforms/k2_setup.c - 1.5 linux/arch/ppc/platforms/menf1_setup.c - 1.5 linux/arch/ppc/platforms/oak.h - 1.3 linux/arch/ppc/platforms/oak_setup.c - 1.4 linux/arch/ppc/platforms/oak_setup.h - 1.3 linux/arch/ppc/platforms/powerpmc250.c - 1.4 linux/arch/ppc/platforms/pplus_setup.c - 1.9 linux/arch/ppc/platforms/prep_setup.c - 1.12 linux/arch/ppc/platforms/prpmc750_setup.c - 1.4 linux/arch/ppc/platforms/prpmc800_setup.c - 1.4 linux/arch/ppc/platforms/sandpoint_setup.c - 1.7 linux/arch/ppc/platforms/tqm8xx.h - 1.4 linux/sound/oss/cmpci.c - 1.5 linux/arch/x86_64/Makefile - 1.12 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.8 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.12 linux/arch/x86_64/ia32/ia32entry.S - 1.7 linux/arch/x86_64/ia32/sys_ia32.c - 1.12 linux/arch/x86_64/kernel/head.S - 1.7 linux/arch/x86_64/kernel/msr.c - 1.5 linux/arch/x86_64/kernel/process.c - 1.12 linux/arch/x86_64/kernel/ptrace.c - 1.7 linux/arch/x86_64/kernel/setup.c - 1.7 linux/arch/x86_64/kernel/smpboot.c - 1.9 linux/arch/x86_64/kernel/sys_x86_64.c - 1.6 linux/arch/x86_64/kernel/traps.c - 1.11 linux/arch/x86_64/kernel/vsyscall.c - 1.7 linux/arch/x86_64/mm/extable.c - 1.4 linux/arch/x86_64/mm/fault.c - 1.8 linux/arch/x86_64/mm/init.c - 1.11 linux/sound/oss/ad1848.c - 1.7 linux/include/asm-x86_64/segment.h - 1.4 linux/include/asm-x86_64/mmu_context.h - 1.8 linux/include/asm-x86_64/ia32.h - 1.6 linux/include/asm-x86_64/smp.h - 1.4 linux/include/asm-ppc/ppc_asm.h - 1.5 linux/include/asm-ppc/ppc4xx_pic.h - 1.3 linux/include/asm-x86_64/spinlock.h - 1.6 linux/include/asm-ppc/open_pic.h - 1.5 linux/include/asm-ppc/iSeries/veth-proc.h - 1.2 linux/include/asm-ppc/mpc10x.h - 1.3 linux/include/asm-ppc/ibm4xx.h - 1.4 linux/include/asm-ppc/ibm403.h - 1.2 linux/include/asm-ppc/iSeries/pmc_proc.h - 1.2 linux/include/asm-ppc/iSeries/mf_proc.h - 1.2 linux/include/asm-ppc/iSeries/mf.h - 1.2 linux/include/asm-ppc/iSeries/iSeries_proc.h - 1.2 linux/include/asm-ppc/iSeries/iSeries_pci.h - 1.2 linux/include/asm-ppc/iSeries/iSeries_irq.h - 1.2 linux/include/asm-ppc/iSeries/iSeries_io.h - 1.2 linux/include/asm-ppc/iSeries/iSeries_fixup.h - 1.2 linux/include/asm-ppc/iSeries/iSeries_dma.h - 1.2 linux/include/asm-ppc/iSeries/iSeries_VpdInfo.h - 1.2 linux/include/asm-ppc/iSeries/iSeries_FlightRecorder.h - 1.2 linux/include/asm-ppc/iSeries/XmPciLpEvent.h - 1.2 linux/include/asm-ppc/iSeries/Paca.h - 1.2 linux/include/asm-ppc/iSeries/Naca.h - 1.2 linux/include/asm-ppc/iSeries/LparMap.h - 1.2 linux/include/asm-ppc/iSeries/LparData.h - 1.2 linux/include/asm-ppc/iSeries/ItVpdAreas.h - 1.2 linux/include/asm-ppc/iSeries/ItSpCommArea.h - 1.2 linux/include/asm-ppc/iSeries/ItLpRegSave.h - 1.2 linux/include/asm-x86_64/xor.h - 1.5 linux/include/asm-ppc/iSeries/ItLpQueue.h - 1.2 linux/include/asm-ppc/iSeries/ItLpPaca.h - 1.2 linux/include/asm-ppc/iSeries/ItIplParmsReal.h - 1.2 linux/include/asm-ppc/iSeries/ItLpNaca.h - 1.2 linux/include/asm-ppc/iSeries/HvCallSc.h - 1.2 linux/include/asm-ppc/iSeries/IoHriProcessorVpd.h - 1.2 linux/include/asm-ppc/iSeries/IoHriMainStore.h - 1.2 linux/include/asm-ppc/iSeries/HvTypes.h - 1.2 linux/include/asm-ppc/iSeries/HvReleaseData.h - 1.2 linux/include/asm-ppc/iSeries/HvLpEvent.h - 1.2 linux/include/asm-ppc/iSeries/HvLpConfig.h - 1.2 linux/include/asm-ppc/iSeries/HvCallXm.h - 1.2 linux/include/asm-ppc/iSeries/HvCallSm.h - 1.2 linux/include/asm-ppc/iSeries/HvCallPci.h - 1.2 linux/include/asm-ppc/iSeries/HvCallCfg.h - 1.2 linux/include/asm-x86_64/uaccess.h - 1.4 linux/include/asm-ppc/iSeries/HvCallHpt.h - 1.2 linux/include/asm-ppc/iSeries/HvCallEvent.h - 1.2 linux/include/asm-ppc/iSeries/HvCall.h - 1.2 linux/arch/ppc64/mm/fault.c - 1.7 linux/arch/ppc64/mm/init.c - 1.13 linux/arch/ppc64/Makefile - 1.14 linux/arch/ppc64/boot/Makefile - 1.8 linux/arch/ppc64/boot/main.c - 1.3 linux/arch/ppc64/defconfig - 1.13 linux/arch/ppc64/kernel/Makefile - 1.11 linux/arch/ppc64/kernel/chrp_setup.c - 1.10 linux/arch/ppc64/kernel/entry.S - 1.11 linux/arch/ppc64/kernel/head.S - 1.8 linux/arch/ppc64/kernel/init_task.c - 1.3 linux/arch/ppc64/kernel/ioctl32.c - 1.12 linux/arch/ppc64/kernel/irq.c - 1.9 linux/arch/ppc64/kernel/misc.S - 1.12 linux/arch/ppc64/kernel/pSeries_pci.c - 1.9 linux/arch/ppc64/kernel/pci_dma.c - 1.7 linux/arch/ppc64/kernel/prom.c - 1.10 linux/arch/ppc64/kernel/rtc.c - 1.5 linux/arch/ppc64/kernel/setup.c - 1.10 linux/arch/ppc64/kernel/signal32.c - 1.11 linux/arch/ppc64/kernel/smp.c - 1.13 linux/arch/ppc64/kernel/sys_ppc32.c - 1.13 linux/arch/ppc64/kernel/time.c - 1.10 linux/arch/ppc64/kernel/xics.c - 1.9 linux/arch/ppc64/kernel/xics.h - 1.3 linux/arch/ppc64/lib/Makefile - 1.7 linux/arch/ppc64/mm/Makefile - 1.5 linux/arch/ppc64/mm/extable.c - 1.4 linux/arch/ppc64/xmon/Makefile - 1.4 linux/arch/ppc64/xmon/start.c - 1.5 linux/include/asm-ppc64/mmu_context.h - 1.4 linux/include/asm-ppc64/tlb.h - 1.5 linux/include/asm-ppc64/smp.h - 1.6 linux/include/asm-ppc64/ppc32.h - 1.4 linux/include/asm-ppc64/prom.h - 1.5 linux/include/asm-ppc64/pgtable.h - 1.9 linux/include/asm-ppc64/page.h - 1.10 linux/drivers/net/e1000/e1000_main.c - 1.14 linux/drivers/net/e1000/e1000_osdep.h - 1.7 linux/drivers/net/e1000/e1000.h - 1.9 linux/drivers/net/e1000/e1000_ethtool.c - 1.7 linux/drivers/isdn/hisax/hisax_hfcpci.c - 1.5 linux/include/asm-arm/thread_info.h - 1.6 linux/drivers/net/e1000/e1000_param.c - 1.7 linux/drivers/net/e1000/e1000_proc.c - 1.5 linux/fs/jfs/jfs_logmgr.h - 1.9 linux/drivers/hotplug/ibmphp_core.c - 1.9 linux/fs/jfs/file.c - 1.15 linux/fs/jfs/inode.c - 1.20 linux/fs/jfs/jfs_logmgr.c - 1.22 linux/fs/jfs/super.c - 1.20 linux/fs/jfs/jfs_txnmgr.c - 1.21 linux/fs/jfs/jfs_umount.c - 1.7 linux/drivers/pcmcia/sa1111_generic.c - 1.6 linux/drivers/net/tulip/de4x5.c - 1.8 linux/drivers/net/e100/e100.h - 1.11 linux/drivers/net/e100/e100_config.c - 1.7 linux/drivers/net/e100/e100_main.c - 1.13 linux/fs/nfsctl.c - 1.5 linux/Documentation/networking/NAPI_HOWTO.txt - 1.3 linux/drivers/media/video/video-buf.h - 1.5 linux/drivers/media/video/video-buf.c - 1.7 linux/drivers/acpi/acpi_bus.h - 1.7 linux/drivers/acpi/acpi_drivers.h - 1.8 linux/drivers/media/video/bttv-risc.c - 1.4 linux/drivers/media/video/bttv-vbi.c - 1.6 linux/include/asm-ppc64/cacheflush.h - 1.2 linux/lib/radix-tree.c - 1.10 linux/drivers/net/sun3_82586.c - 1.4 linux/drivers/usb/core/hcd.c - 1.16 linux/drivers/usb/core/hub.c - 1.18 linux/drivers/usb/core/usb-debug.c - 1.5 linux/drivers/usb/core/usb.c - 1.25 linux/drivers/usb/host/ehci-dbg.c - 1.10 linux/drivers/usb/host/ehci-hcd.c - 1.15 linux/drivers/usb/host/ehci-q.c - 1.15 linux/drivers/usb/host/ehci.h - 1.8 linux/drivers/usb/host/ohci-dbg.c - 1.11 linux/drivers/usb/host/ohci-hcd.c - 1.16 linux/drivers/usb/host/ohci-hub.c - 1.7 linux/drivers/usb/host/ohci-mem.c - 1.9 linux/drivers/usb/host/ohci-q.c - 1.18 linux/drivers/base/sys.c - 1.8 linux/drivers/base/power.c - 1.8 linux/drivers/usb/image/mdc800.c - 1.11 linux/drivers/usb/image/scanner.c - 1.15 linux/drivers/usb/image/scanner.h - 1.10 linux/include/linux/radix-tree.h - 1.4 linux/kernel/platform.c - 1.4 linux/drivers/net/e100/e100_test.c - 1.6 linux/drivers/usb/net/usbnet.c - 1.16 linux/drivers/usb/net/rtl8150.c - 1.12 linux/drivers/usb/net/pegasus.h - 1.10 linux/drivers/usb/net/pegasus.c - 1.12 linux/drivers/usb/net/kaweth.c - 1.13 linux/mm/readahead.c - 1.14 linux/drivers/usb/misc/Makefile - 1.7 linux/drivers/usb/misc/auerswald.c - 1.12 linux/drivers/usb/misc/rio500.c - 1.7 linux/drivers/isdn/i4l/isdn_tty.c - 1.8 linux/drivers/usb/misc/brlvger.c - 1.11 linux/Documentation/DocBook/scsidrivers.tmpl - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.5 linux/drivers/block/umem.c - 1.18 linux/drivers/macintosh/ans-lcd.c - 1.3 linux/drivers/macintosh/apm_emu.c - 1.4 linux/drivers/pci/hotplug.c - 1.7 linux/drivers/pci/pool.c - 1.7 linux/drivers/pci/probe.c - 1.11 linux/arch/i386/pci/numa.c - 1.6 linux/mm/page-writeback.c - 1.17 linux/drivers/base/bus.c - 1.10 linux/drivers/base/driver.c - 1.9 linux/fs/mpage.c - 1.16 linux/drivers/acpi/pci_bind.c - 1.5 linux/drivers/acpi/battery.c - 1.9 linux/drivers/acpi/bus.c - 1.11 linux/drivers/acpi/pci_root.c - 1.7 linux/drivers/acpi/pci_link.c - 1.6 linux/drivers/acpi/button.c - 1.8 linux/drivers/acpi/pci_irq.c - 1.10 linux/arch/ppc64/lib/memcpy.S - 1.3 linux/drivers/acpi/thermal.c - 1.10 linux/drivers/acpi/system.c - 1.10 linux/drivers/acpi/processor.c - 1.13 linux/drivers/acpi/osl.c - 1.11 linux/drivers/acpi/utils.c - 1.5 linux/drivers/isdn/hisax/amd7930_fn.c - 1.7 linux/drivers/isdn/hisax/amd7930_fn.h - 1.3 linux/drivers/isdn/hisax/enternow.h - 1.2 linux/drivers/isdn/hisax/enternow_pci.c - 1.5 linux/drivers/isdn/hisax/ipacx.c - 1.8 linux/drivers/isdn/hisax/ipacx.h - 1.3 linux/drivers/usb/host/ohci-sa1111.c - 1.11 linux/drivers/usb/core/hcd-pci.c - 1.8 linux/arch/arm/mm/proc-arm2_3.S - 1.3 linux/arch/arm/mm/proc-arm6_7.S - 1.5 linux/arch/x86_64/ia32/ipc32.c - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_reg.h_shipped - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_seq.h_shipped - 1.3 linux/drivers/isdn/hisax/avma1_cs.c - 1.2 linux/drivers/input/mouse/psmouse.c - 1.9 linux/drivers/acpi/tables/tbrsdt.c - 1.7 linux/drivers/acpi/toshiba_acpi.c - 1.4 linux/drivers/acpi/tables/tbgetall.c - 1.6 linux/drivers/acpi/include/amlresrc.h - 1.5 linux/fs/direct-io.c - 1.14 linux/drivers/usb/input/pid.c - 1.4 linux/drivers/input/serio/sa1111ps2.c - 1.4 linux/security/dummy.c - 1.7 linux/drivers/serial/clps711x.c - 1.5 linux/drivers/usb/serial/io_ti.c - 1.8 linux/drivers/serial/uart00.c - 1.6 linux/drivers/serial/sa1100.c - 1.4 linux/Documentation/serial/driver - 1.3 linux/drivers/serial/core.c - 1.8 linux/drivers/char/agp/ali-agp.c - 1.4 linux/drivers/char/agp/sis-agp.c - 1.4 linux/drivers/serial/anakin.c - 1.5 linux/drivers/char/agp/frontend.c - 1.4 linux/drivers/char/agp/hp-agp.c - 1.4 linux/drivers/char/agp/i460-agp.c - 1.4 linux/drivers/acpi/namespace/nsxfeval.c - 1.6 linux/drivers/serial/amba.c - 1.6 linux/drivers/acpi/namespace/nsdumpdv.c - 1.5 linux/mm/rmap.c - 1.10 linux/drivers/char/agp/sworks-agp.c - 1.4 linux/drivers/char/agp/via-agp.c - 1.4 linux/drivers/serial/8250.c - 1.12 linux/drivers/serial/21285.c - 1.5 linux/include/linux/serial_core.h - 1.9 linux/include/linux/security.h - 1.6 linux/fs/jfs/resize.c - 1.5 linux/drivers/serial/sunzilog.c - 1.7 linux/drivers/serial/sunsab.c - 1.4 linux/drivers/serial/sunsu.c - 1.8 linux/include/asm-sparc/thread_info.h - 1.3 linux/drivers/usb/misc/atmsar.c - 1.2 linux/drivers/usb/misc/atmsar.h - 1.2 linux/drivers/usb/misc/speedtouch.c - 1.7 linux/drivers/usb/class/usblp.c - 1.6 linux/fs/aio.c - 1.10 linux/arch/alpha/vmlinux.lds.S - 1.6 linux/drivers/char/genrtc.c - 1.3 linux/drivers/base/intf.c - 1.4 linux/net/ipv4/netfilter/ipt_ECN.c - 1.3 linux/drivers/base/class.c - 1.6 linux/net/sctp/protocol.c - 1.11 linux/include/net/sctp/sctp.h - 1.8 linux/fs/xfs/linux/xfs_aops.c - 1.25 linux/include/asm-i386/numaq.h - 1.5 linux/include/linux/rmap-locking.h - 1.2 linux/drivers/ide/setup-pci.c - 1.8 linux/drivers/ide/pci/slc90e66.c - 1.5 linux/drivers/ide/pci/serverworks.c - 1.6 linux/drivers/ide/pci/piix.c - 1.6 linux/drivers/ide/pci/pdcadma.c - 1.6 linux/drivers/ide/pci/pdc202xx_old.c - 1.6 linux/drivers/ide/pci/pdc202xx_new.c - 1.6 linux/drivers/ide/pci/nvidia.h - 1.5 linux/drivers/ide/pci/nvidia.c - 1.6 linux/drivers/ide/pci/hpt366.c - 1.7 linux/drivers/ide/pci/hpt34x.c - 1.6 linux/drivers/ide/pci/cs5530.c - 1.6 linux/drivers/ide/pci/amd74xx.h - 1.5 linux/drivers/ide/pci/amd74xx.c - 1.6 linux/drivers/ide/pci/aec62xx.c - 1.6 linux/drivers/ide/pci/adma100.c - 1.2 linux/drivers/ide/pci/Makefile - 1.6 linux/arch/um/kernel/mem.c - 1.6 linux/arch/um/kernel/sysrq.c - 1.4 linux/include/asm-um/mmu_context.h - 1.3 linux/arch/m68k/vmlinux-std.lds - 1.4 linux/arch/ppc64/vmlinux.lds.S - 1.4 linux/arch/x86_64/vmlinux.lds.S - 1.5 linux/arch/sparc64/vmlinux.lds.S - 1.6 linux/arch/sparc/vmlinux.lds.S - 1.7 linux/arch/s390x/vmlinux.lds.S - 1.6 linux/arch/cris/vmlinux.lds.S - 1.2 linux/arch/ppc/vmlinux.lds.S - 1.6 linux/arch/s390/vmlinux.lds.S - 1.6 linux/arch/mips/vmlinux.lds.S - 1.2 linux/arch/parisc/vmlinux.lds.S - 1.4 linux/arch/i386/mm/hugetlbpage.c - 1.8 linux/Documentation/driver-model/binding.txt - 1.2 linux/Documentation/driver-model/bus.txt - 1.2 linux/Documentation/driver-model/class.txt - 1.2 linux/Documentation/driver-model/device.txt - 1.2 linux/Documentation/driver-model/driver.txt - 1.2 linux/Documentation/driver-model/interface.txt - 1.2 linux/Documentation/driver-model/overview.txt - 1.2 linux/arch/sparc64/mm/hugetlbpage.c - 1.3 linux/kernel/pid.c - 1.4 linux/net/bridge/netfilter/ebtables.c - 1.4 linux/drivers/acpi/scan.c - 1.4 linux/arch/ppc/boot/openfirmware/Makefile - 1.5 linux/drivers/char/drm/radeon_mem.c - 1.3 linux/drivers/usb/core/driverfs.c - 1.5 linux/include/asm-i386/topology.h - 1.2 linux/include/asm-ppc64/topology.h - 1.2 linux/kernel/cpufreq.c - 1.6 linux/include/linux/cpufreq.h - 1.6 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.4 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.4 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.5 linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.4 linux/fs/nfs/direct.c - 1.2 linux/drivers/usb/misc/usbtest.c - 1.8 linux/arch/ppc/platforms/4xx/walnut.h - 1.3 linux/Documentation/DocBook/journal-api.tmpl - 1.4 linux/drivers/net/irda/donauboe.c - 1.3 linux/Documentation/rpc-cache.txt - 1.2 linux/net/sunrpc/svcauth_unix.c - 1.4 linux/fs/nfsd/nfs4xdr.c - 1.6 linux/fs/nfsd/nfs4proc.c - 1.4 linux/net/sunrpc/cache.c - 1.4 linux/include/asm-ppc/ibm405.h - 1.2 linux/arch/i386/kernel/timers/timer_tsc.c - 1.6 linux/arch/ppc/configs/cedar_defconfig - 1.3 linux/arch/ppc/kernel/asm-offsets.c - 1.3 linux/include/linux/nfsd/xdr4.h - 1.5 linux/arch/ppc/platforms/4xx/Makefile - 1.3 linux/arch/ppc/platforms/4xx/ash.c - 1.2 linux/arch/ppc/platforms/4xx/ash.h - 1.3 linux/arch/ppc/platforms/4xx/cedar.c - 1.2 linux/arch/ppc/platforms/4xx/cedar.h - 1.3 linux/arch/ppc/platforms/4xx/cpci405.c - 1.2 linux/arch/ppc/platforms/4xx/cpci405.h - 1.2 linux/arch/ppc/platforms/4xx/ep405.c - 1.3 linux/arch/ppc/platforms/4xx/ep405.h - 1.3 linux/arch/ppc/platforms/4xx/ibm405gp.c - 1.3 linux/arch/ppc/platforms/4xx/ibm405gp.h - 1.3 linux/arch/ppc/platforms/4xx/ibm_ocp.h - 1.2 linux/arch/ppc/platforms/4xx/ibmnp405h.c - 1.3 linux/arch/ppc/platforms/4xx/ibmnp405h.h - 1.3 linux/arch/ppc/platforms/4xx/ibmnp405l.c - 1.3 linux/arch/ppc/platforms/4xx/ibmnp405l.h - 1.3 linux/arch/ppc/platforms/4xx/ibmstb3.c - 1.3 linux/arch/ppc/platforms/4xx/ibmstb3.h - 1.3 linux/arch/ppc/platforms/4xx/ibmstb4.c - 1.3 linux/arch/ppc/platforms/4xx/ibmstb4.h - 1.3 linux/arch/ppc/platforms/4xx/redwood.c - 1.2 linux/arch/ppc/platforms/4xx/redwood.h - 1.3 linux/arch/ppc/platforms/4xx/redwood5.c - 1.2 linux/arch/ppc/platforms/4xx/walnut.c - 1.3 linux/include/linux/sunrpc/cache.h - 1.4 linux/fs/nfs/nfs4xdr.c - 1.5 linux/arch/x86_64/kernel/pci-gart.c - 1.4 linux/fs/nfs/nfs4proc.c - 1.5 linux/arch/ppc/boot/simple/misc.c - 1.3 linux/include/asm-i386/edd.h - 1.3 linux/Documentation/filesystems/sysfs.txt - 1.2 linux/drivers/pnp/pnpbios/core.c - 1.5 linux/drivers/pnp/resource.c - 1.5 linux/drivers/pnp/core.c - 1.5 linux/drivers/pnp/driver.c - 1.5 linux/fs/sysfs/inode.c - 1.4 linux/arch/i386/kernel/edd.c - 1.5 linux/drivers/pnp/isapnp/proc.c - 1.4 linux/drivers/pnp/system.c - 1.3 linux/include/linux/sysfs.h - 1.4 linux/drivers/pnp/isapnp/core.c - 1.5 linux/drivers/pnp/interface.c - 1.4 linux/include/linux/pnp.h - 1.5 linux/include/linux/kobject.h - 1.4 linux/Documentation/crypto/api-intro.txt - 1.4 linux/drivers/net/Kconfig - 1.6 linux/drivers/net/appletalk/Kconfig - 1.2 linux/drivers/net/arcnet/Kconfig - 1.2 linux/Documentation/kobject.txt - 1.3 linux/drivers/net/tokenring/Kconfig - 1.3 linux/arch/alpha/Kconfig - 1.5 linux/arch/arm/Kconfig - 1.5 linux/arch/cris/Kconfig - 1.4 linux/arch/i386/Kconfig - 1.7 linux/drivers/net/wan/Kconfig - 1.2 linux/arch/ppc/8xx_io/Kconfig - 1.2 linux/drivers/net/wireless/Kconfig - 1.2 linux/drivers/pci/Kconfig - 1.2 linux/arch/i386/mach-voyager/voyager_smp.c - 1.3 linux/arch/ia64/Kconfig - 1.5 linux/arch/m68k/Kconfig - 1.6 linux/arch/mips/Kconfig - 1.5 linux/arch/mips64/Kconfig - 1.5 linux/arch/parisc/Kconfig - 1.5 linux/arch/parisc/kernel/perf.c - 1.4 linux/drivers/pnp/isapnp/compat.c - 1.3 linux/drivers/md/dm.c - 1.4 linux/drivers/md/dm-target.c - 1.3 linux/drivers/md/dm-table.c - 1.4 linux/drivers/md/dm-ioctl.c - 1.4 linux/include/linux/pfkeyv2.h - 1.3 linux/drivers/scsi/Kconfig - 1.5 linux/drivers/char/agp/Kconfig - 1.4 linux/arch/ppc/Kconfig - 1.5 linux/arch/ppc64/Kconfig - 1.5 linux/net/ipv4/ah.c - 1.4 linux/arch/sh/Kconfig - 1.5 linux/drivers/hotplug/acpiphp_glue.c - 1.3 linux/arch/sparc/Kconfig - 1.5 linux/arch/sparc64/Kconfig - 1.4 linux/drivers/ide/Kconfig - 1.3 linux/fs/befs/linuxvfs.c - 1.4 linux/arch/x86_64/Kconfig - 1.6 linux/lib/kobject.c - 1.4 linux/crypto/Kconfig - 1.4 linux/crypto/Makefile - 1.4 linux/crypto/tcrypt.c - 1.4 linux/crypto/tcrypt.h - 1.4 linux/drivers/usb/image/Kconfig - 1.2 linux/net/Kconfig - 1.4 linux/net/ipv4/xfrm_policy.c - 1.5 linux/drivers/isdn/hisax/Kconfig - 1.3 linux/drivers/usb/input/Kconfig - 1.2 linux/include/net/xfrm.h - 1.4 linux/drivers/input/serio/Kconfig - 1.4 linux/init/Kconfig - 1.3 linux/fs/hugetlbfs/inode.c - 1.5 linux/mm/fremap.c - 1.2 linux/include/asm-m68knommu/mmu_context.h - 1.2 linux/include/asm-v850/system.h - 1.2 linux/include/asm-v850/stat.h - 1.3 linux/drivers/media/video/saa7134/saa7134.h - 1.3 linux/drivers/media/video/saa7134/saa7134-video.c - 1.3 linux/drivers/media/video/saa7134/saa7134-vbi.c - 1.3 linux/drivers/media/video/saa7134/saa7134-tvaudio.c - 1.3 linux/drivers/media/video/saa7134/saa7134-ts.c - 1.3 linux/drivers/media/video/saa7134/saa7134-oss.c - 1.3 linux/drivers/media/video/saa7134/saa7134-i2c.c - 1.4 linux/drivers/media/video/saa7134/saa7134-cards.c - 1.3 linux/drivers/base/firmware.c - 1.2 linux/arch/v850/vmlinux.lds.S - 1.4 linux/arch/m68knommu/Kconfig - 1.4 linux/arch/m68knommu/platform/5206/ARNEWSH/ram.ld - 1.2 linux/arch/m68knommu/platform/5206e/MOTOROLA/ram.ld - 1.2 linux/arch/m68knommu/platform/5206e/eLITE/ram.ld - 1.2 linux/arch/m68knommu/platform/5249/MOTOROLA/ram.ld - 1.2 linux/arch/m68knommu/platform/5272/MOTOROLA/ram.ld - 1.2 linux/arch/m68knommu/platform/5272/NETtel/ram.ld - 1.2 linux/arch/m68knommu/platform/5307/ARNEWSH/ram.ld - 1.2 linux/arch/m68knommu/platform/5307/CLEOPATRA/ram.ld - 1.2 linux/arch/m68knommu/platform/5307/MOTOROLA/ram.ld - 1.2 linux/arch/m68knommu/platform/5307/MP3/ram.ld - 1.2 linux/arch/m68knommu/platform/5307/NETtel/ram.ld - 1.2 linux/arch/m68knommu/platform/5407/CLEOPATRA/ram.ld - 1.2 linux/arch/m68knommu/platform/5407/MOTOROLA/ram.ld - 1.2 linux/arch/m68knommu/platform/68360/uCquicc/ram.ld - 1.2 linux/arch/m68knommu/platform/68360/uCquicc/rom.ld - 1.2 linux/arch/m68knommu/platform/68EZ328/ucsimm/fixed.ld - 1.2 linux/arch/m68knommu/platform/68EZ328/ucsimm/ram.ld - 1.2 linux/arch/m68knommu/platform/68VZ328/de2/fixed.ld - 1.2 linux/arch/m68knommu/platform/68VZ328/de2/ram.ld - 1.2 linux/arch/m68knommu/platform/68VZ328/ucdimm/fixed.ld - 1.2 linux/arch/m68knommu/platform/68VZ328/ucdimm/ram.ld - 1.2 linux/include/asm-v850/module.h - 1.3 linux/include/asm-v850/mmu_context.h - 1.3 linux/arch/v850/Kconfig - 1.4 linux/arch/v850/README - 1.2 linux/drivers/serial/68360serial.c - 1.4 linux/drivers/serial/nb85e_uart.c - 1.3 linux/arch/ppc/syslib/todc_time.c - 1.3 linux/arch/ppc/syslib/prom_init.c - 1.2 linux/arch/ppc/syslib/ppc4xx_setup.c - 1.2 linux/net/key/af_key.c - 1.4 linux/arch/ppc/syslib/ppc4xx_pic.c - 1.2 linux/arch/ppc/syslib/ppc405_pci.c - 1.2 linux/arch/ppc/syslib/ppc405_dma.c - 1.2 linux/arch/ppc/syslib/mpc10x_common.c - 1.2 linux/arch/ppc/syslib/cpc710.h - 1.2 linux/arch/ppc/syslib/Makefile - 1.3 linux/arch/ppc/kernel/ppc6xx_idle.c - 1.3 linux/arch/ppc/kernel/iSeries_idle.c - 1.2 linux/drivers/scsi/scsi_sysfs.c - 1.2 linux/include/linux/compat.h - 1.2 linux/scripts/kallsyms.c - 1.3 linux/drivers/pnp/card.c - 1.3 linux/drivers/serial/mux.c - 1.2 linux/drivers/ide/pci/sc1200.c - 1.2 linux/drivers/acpi/namespace/nsparse.c - 1.3 linux/drivers/usb/serial/bus.c - 1.3 linux/arch/sparc64/kernel/module.c - 1.3 linux/include/asm-sparc64/compat.h - 1.3 linux/drivers/usb/serial/ezusb.c - 1.3 linux/drivers/usb/serial/generic.c - 1.3 linux/drivers/acpi/events/evgpe.c - 1.3 linux/drivers/acpi/dispatcher/dsinit.c - 1.3 linux/drivers/char/agp/amd-k7-agp.c - 1.3 linux/drivers/char/agp/amd-k8-agp.c - 1.3 linux/drivers/char/agp/backend.c - 1.3 linux/drivers/char/agp/generic.c - 1.3 linux/arch/arm/kernel/module.c - 1.3 linux/drivers/ide/pci/cs5520.c - 1.2 linux/fs/compat.c - 1.2 linux/include/asm-ppc64/compat.h - 1.2 linux/include/linux/moduleloader.h - 1.3 linux/arch/v850/kernel/module.c - 1.3 linux/drivers/char/agp/intel-agp.c - 1.3 linux/arch/s390x/kernel/module.c - 1.3 linux/arch/s390/kernel/module.c - 1.3 linux/drivers/char/watchdog/Kconfig - 1.2 linux/arch/ppc/kernel/module.c - 1.3 linux/drivers/char/watchdog/Makefile - 1.2 linux/drivers/char/watchdog/acquirewdt.c - 1.2 linux/drivers/char/watchdog/advantechwdt.c - 1.2 linux/drivers/char/watchdog/eurotechwdt.c - 1.2 linux/drivers/char/watchdog/i810-tco.c - 1.2 linux/kernel/compat.c - 1.2 linux/arch/v850/kernel/as85ep1.c - 1.2 linux/drivers/net/r8169.c - 1.2 linux/arch/i386/kernel/module.c - 1.3 linux/kernel/extable.c - 1.2 linux/drivers/char/watchdog/ib700wdt.c - 1.2 linux/drivers/char/watchdog/machzwd.c - 1.2 linux/drivers/char/watchdog/mixcomwd.c - 1.2 linux/drivers/char/watchdog/pcwd.c - 1.2 linux/arch/sparc/kernel/module.c - 1.3 linux/drivers/char/watchdog/sbc60xxwdt.c - 1.2 linux/arch/ppc64/oprofile/Makefile - 1.2 linux/drivers/char/watchdog/wdt977.c - 1.2 linux/drivers/char/watchdog/wdt_pci.c - 1.2 linux/drivers/char/watchdog/shwdt.c - 1.2 linux/drivers/char/watchdog/softdog.c - 1.2 linux/drivers/char/watchdog/wdt.c - 1.2 linux/drivers/char/watchdog/w83877f_wdt.c - 1.2 linux/arch/x86_64/kernel/module.c - 1.2 linux/arch/x86_64/mm/hugetlbpage.c - 1.2 linux/drivers/char/agp/generic-3.0.c - 1.2 linux/drivers/char/agp/i7x05-agp.c - 1.2 linux/include/asm-x86_64/compat.h - 1.2 linux/include/asm-s390x/compat.h - 1.2 linux/arch/i386/kernel/sysenter.c - 1.2 linux/include/asm-ia64/compat.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_core.c - 1.2 linux/include/asm-i386/mach-summit/mach_apic.h - 1.2 linux/include/asm-i386/mach-numaq/mach_apic.h - 1.2 linux/include/asm-i386/mach-default/mach_apic.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_osm.c - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_osm.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_osm_pci.c - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_pci.c - 1.2 linux/include/asm-arm/dma-mapping.h - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_reg_print.c_shipped - 1.2 linux/include/video/tgafb.h - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jan 13 14:05:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 14:05:59 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0DM5m3v004807 for ; Mon, 13 Jan 2003 14:05:49 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0DJZQKp017121 for ; Mon, 13 Jan 2003 11:35:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA89250 for ; Mon, 13 Jan 2003 14:29:17 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA10471 for ; Mon, 13 Jan 2003 14:29:15 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h0E3han03403 for linux-xfs@oss.sgi.com; Mon, 13 Jan 2003 22:43:36 -0500 Resent-Message-Id: <200301140343.h0E3han03403@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA38621 for ; Mon, 13 Jan 2003 13:59:25 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h0DJxMQb50836744 for ; Mon, 13 Jan 2003 11:59:23 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h0DJv52l022194 for ; Mon, 13 Jan 2003 20:57:06 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h0DJv5DE022193 for hch@sgi.com; Mon, 13 Jan 2003 20:57:05 +0100 Date: Mon, 13 Jan 2003 20:57:05 +0100 From: Christoph Hellwig Message-Id: <200301131957.h0DJv5DE022193@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.54 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Mon, 13 Jan 2003 22:43:35 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2296 X-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: 74426 Lines: 1880 2.5.57 will follow real soon, just commit the workarea that I had ready before leaving for skiing.. Date: Mon Jan 13 11:52:52 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:136706a linux/arch/v850/as85ep1-rom.ld - 1.1 linux/arch/x86_64/ia32/syscall32.c - 1.1 linux/Documentation/DMA-API.txt - 1.1 linux/arch/um/util/mk_constants_user.c - 1.1 linux/Documentation/fb/intel810.txt - 1.1 linux/arch/um/util/mk_constants_kern.c - 1.1 linux/arch/x86_64/kernel/module.c - 1.1 linux/arch/x86_64/kernel/mtrr/Makefile - 1.1 linux/arch/x86_64/kernel/suspend.c - 1.1 linux/arch/x86_64/kernel/suspend_asm.S - 1.1 linux/arch/x86_64/mm/hugetlbpage.c - 1.1 linux/arch/x86_64/oprofile/Kconfig - 1.1 linux/Documentation/scsi/aic79xx.txt - 1.1 linux/arch/x86_64/oprofile/Makefile - 1.1 linux/Documentation/sound/alsa/ALSA-Configuration.txt - 1.1 linux/Documentation/sound/alsa/ControlNames.txt - 1.1 linux/include/linux/font.h - 1.1 linux/arch/um/sys-i386/checksum.S - 1.1 linux/drivers/char/agp/generic-3.0.c - 1.1 linux/drivers/char/agp/i7x05-agp.c - 1.1 linux/Documentation/uml/UserModeLinux-HOWTO.txt - 1.1 linux/Documentation/usb/dma.txt - 1.1 linux/arch/um/kernel/tt/uaccess_user.c - 1.1 linux/arch/um/kernel/tt/trap_user.c - 1.1 linux/include/linux/dma-mapping.h - 1.1 linux/arch/um/kernel/tt/tracer.c - 1.1 linux/arch/um/kernel/tt/tlb.c - 1.1 linux/arch/um/kernel/tt/time.c - 1.1 linux/arch/um/kernel/tt/syscall_user.c - 1.1 linux/arch/um/kernel/tt/syscall_kern.c - 1.1 linux/arch/um/kernel/tt/sys-i386/sigcontext.c - 1.1 linux/arch/um/kernel/tt/sys-i386/Makefile - 1.1 linux/arch/um/kernel/tt/ptproxy/wait.h - 1.1 linux/arch/um/kernel/tt/ptproxy/wait.c - 1.1 linux/arch/um/kernel/tt/ptproxy/sysdep.h - 1.1 linux/arch/um/kernel/tt/ptproxy/sysdep.c - 1.1 linux/arch/um/kernel/tt/ptproxy/ptrace.c - 1.1 linux/include/linux/bcd.h - 1.1 linux/arch/um/kernel/tt/ptproxy/ptproxy.h - 1.1 linux/arch/um/kernel/tt/ptproxy/proxy.c - 1.1 linux/arch/um/kernel/tt/ptproxy/Makefile - 1.1 linux/arch/um/kernel/tt/process_kern.c - 1.1 linux/arch/um/kernel/tt/mem.c - 1.1 linux/arch/um/kernel/tt/ksyms.c - 1.1 linux/arch/um/kernel/tt/include/uaccess.h - 1.1 linux/arch/um/kernel/tt/include/tt.h - 1.1 linux/arch/um/kernel/tt/include/ptrace-tt.h - 1.1 linux/include/asm-x86_64/compat.h - 1.1 linux/arch/um/kernel/tt/include/mode_kern.h - 1.1 linux/arch/um/kernel/tt/include/mode.h - 1.1 linux/arch/um/kernel/tt/include/mmu.h - 1.1 linux/arch/um/kernel/tt/include/debug.h - 1.1 linux/arch/um/kernel/tt/gdb_kern.c - 1.1 linux/arch/um/kernel/tt/gdb.c - 1.1 linux/arch/um/kernel/tt/exec_user.c - 1.1 linux/arch/um/kernel/tt/exec_kern.c - 1.1 linux/arch/um/kernel/tt/Makefile - 1.1 linux/drivers/i2c/busses/Kconfig - 1.1 linux/drivers/i2c/busses/Makefile - 1.1 linux/drivers/i2c/busses/i2c-amd756.c - 1.1 linux/include/asm-v850/dma-mapping.h - 1.1 linux/include/asm-um/dma-mapping.h - 1.1 linux/drivers/i2c/busses/i2c-amd8111.c - 1.1 linux/drivers/i2c/chips/Kconfig - 1.1 linux/drivers/i2c/chips/Makefile - 1.1 linux/drivers/i2c/chips/adm1021.c - 1.1 linux/drivers/i2c/chips/lm75.c - 1.1 linux/arch/um/kernel/skas/util/mk_ptregs.c - 1.1 linux/arch/um/kernel/skas/util/Makefile - 1.1 linux/include/asm-sparc64/dma-mapping.h - 1.1 linux/arch/um/kernel/skas/trap_user.c - 1.1 linux/arch/um/kernel/skas/tlb.c - 1.1 linux/arch/um/kernel/skas/time.c - 1.1 linux/include/asm-sparc/dma-mapping.h - 1.1 linux/include/asm-sh/dma-mapping.h - 1.1 linux/arch/um/kernel/skas/syscall_user.c - 1.1 linux/arch/um/kernel/skas/syscall_kern.c - 1.1 linux/arch/um/kernel/skas/sys-i386/sigcontext.c - 1.1 linux/arch/um/kernel/skas/sys-i386/Makefile - 1.1 linux/arch/um/kernel/skas/process_kern.c - 1.1 linux/include/asm-s390x/dma-mapping.h - 1.1 linux/include/asm-s390x/compat.h - 1.1 linux/include/asm-s390/dma-mapping.h - 1.1 linux/include/asm-ppc64/dma-mapping.h - 1.1 linux/arch/um/kernel/skas/process.c - 1.1 linux/arch/um/kernel/skas/mmu.c - 1.1 linux/arch/um/kernel/skas/mem_user.c - 1.1 linux/arch/um/kernel/skas/mem.c - 1.1 linux/arch/um/kernel/skas/include/uaccess.h - 1.1 linux/arch/um/kernel/skas/include/skas_ptrace.h - 1.1 linux/arch/um/kernel/skas/include/skas.h - 1.1 linux/arch/i386/kernel/sysenter.c - 1.1 linux/arch/um/kernel/skas/include/ptrace-skas.h - 1.1 linux/arch/um/kernel/skas/include/proc_mm.h - 1.1 linux/arch/um/kernel/skas/include/mode_kern.h - 1.1 linux/include/asm-ppc/dma-mapping.h - 1.1 linux/include/asm-mips64/dma-mapping.h - 1.1 linux/arch/um/kernel/skas/include/mode.h - 1.1 linux/arch/um/kernel/skas/include/mmu.h - 1.1 linux/arch/um/kernel/skas/exec_user.c - 1.1 linux/arch/i386/mach-default/Makefile - 1.1 linux/arch/i386/mach-default/setup.c - 1.1 linux/arch/i386/mach-default/topology.c - 1.1 linux/arch/um/kernel/skas/exec_kern.c - 1.1 linux/arch/um/kernel/skas/Makefile - 1.1 linux/include/asm-mips/dma-mapping.h - 1.1 linux/arch/um/kernel/checksum.c - 1.1 linux/include/asm-m68knommu/dma-mapping.h - 1.1 linux/arch/um/include/um_uaccess.h - 1.1 linux/arch/um/include/um_mmu.h - 1.1 linux/arch/um/include/sysdep-i386/checksum.h - 1.1 linux/lib/gen_crc32table.c - 1.1 linux/sound/pci/ice1712/envy24ht.h - 1.1 linux/sound/pci/ice1712/amp.h - 1.1 linux/arch/um/include/mode_kern.h - 1.1 linux/include/asm-m68k/dma-mapping.h - 1.1 linux/arch/um/include/mode.h - 1.1 linux/lib/crc32defs.h - 1.1 linux/include/asm-ia64/intrinsics.h - 1.1 linux/include/asm-ia64/dma-mapping.h - 1.1 linux/sound/pci/ice1712/amp.c - 1.1 linux/include/asm-ia64/compat.h - 1.1 linux/arch/um/include/choose-mode.h - 1.1 linux/drivers/scsi/aic7xxx/Kconfig.aic79xx - 1.1 linux/drivers/scsi/aic7xxx/Kconfig.aic7xxx - 1.1 linux/drivers/scsi/aic7xxx/aic7770_osm.c - 1.1 linux/drivers/scsi/aic7xxx/aic79xx.h - 1.1 linux/arch/um/drivers/slirp_user.c - 1.1 linux/arch/um/drivers/slirp_kern.c - 1.1 linux/arch/um/drivers/slirp.h - 1.1 linux/drivers/scsi/aic7xxx/aic79xx.reg - 1.1 linux/arch/um/drivers/slip_proto.h - 1.1 linux/drivers/scsi/aic7xxx/aic79xx.seq - 1.1 linux/drivers/scsi/aic7xxx/aic79xx_core.c - 1.1 linux/include/asm-i386/mach-voyager/setup_arch_pre.h - 1.1 linux/include/asm-i386/mach-voyager/setup_arch_post.h - 1.1 linux/include/asm-i386/mach-voyager/irq_vectors.h - 1.1 linux/include/asm-i386/mach-voyager/entry_arch.h - 1.1 linux/include/asm-i386/mach-voyager/do_timer.h - 1.1 linux/include/asm-i386/mach-visws/smpboot_hooks.h - 1.1 linux/include/asm-i386/mach-visws/setup_arch_pre.h - 1.1 linux/include/asm-i386/mach-visws/setup_arch_post.h - 1.1 linux/include/asm-i386/mach-visws/irq_vectors.h - 1.1 linux/include/asm-i386/mach-visws/entry_arch.h - 1.1 linux/include/asm-i386/mach-visws/do_timer.h - 1.1 linux/include/asm-i386/mach-summit/mach_mpparse.h - 1.1 linux/include/asm-i386/mach-summit/mach_ipi.h - 1.1 linux/include/asm-i386/mach-summit/mach_apic.h - 1.1 linux/include/asm-i386/mach-numaq/mach_mpparse.h - 1.1 linux/include/asm-i386/mach-numaq/mach_ipi.h - 1.1 linux/include/asm-i386/mach-numaq/mach_apic.h - 1.1 linux/include/asm-i386/mach-default/smpboot_hooks.h - 1.1 linux/include/asm-i386/mach-default/setup_arch_pre.h - 1.1 linux/include/asm-i386/mach-default/setup_arch_post.h - 1.1 linux/include/asm-i386/mach-default/mach_mpparse.h - 1.1 linux/include/asm-i386/mach-default/mach_ipi.h - 1.1 linux/include/asm-i386/mach-default/mach_apic.h - 1.1 linux/include/asm-i386/mach-default/irq_vectors.h - 1.1 linux/include/asm-i386/mach-default/entry_arch.h - 1.1 linux/include/asm-i386/mach-default/do_timer.h - 1.1 linux/drivers/scsi/aic7xxx/aic79xx_inline.h - 1.1 linux/drivers/scsi/aic7xxx/aic79xx_osm.c - 1.1 linux/drivers/scsi/aic7xxx/aic79xx_osm.h - 1.1 linux/include/asm-i386/dma-mapping.h - 1.1 linux/drivers/scsi/aic7xxx/aic79xx_osm_pci.c - 1.1 linux/drivers/scsi/aic7xxx/aic79xx_pci.c - 1.1 linux/include/asm-generic/pci-dma-compat.h - 1.1 linux/include/asm-generic/dma-mapping.h - 1.1 linux/include/asm-cris/dma-mapping.h - 1.1 linux/drivers/scsi/aic7xxx/aic79xx_proc.c - 1.1 linux/drivers/scsi/aic7xxx/aic79xx_reg.h_shipped - 1.1 linux/include/asm-arm/dma-mapping.h - 1.1 linux/drivers/scsi/aic7xxx/aic79xx_reg_print.c_shipped - 1.1 linux/drivers/scsi/aic7xxx/aic79xx_seq.h_shipped - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_reg_print.c_shipped - 1.1 linux/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y - 1.1 linux/drivers/scsi/aic7xxx/aicasm/aicasm_macro_scan.l - 1.1 linux/include/asm-alpha/dma-mapping.h - 1.1 linux/drivers/scsi/aic7xxx/aiclib.c - 1.1 linux/drivers/scsi/aic7xxx/aiclib.h - 1.1 linux/drivers/scsi/aic7xxx/scsi_iu.h - 1.1 linux/include/video/tgafb.h - 1.1 linux/drivers/video/i810/Makefile - 1.1 linux/drivers/video/i810/i810.h - 1.1 linux/drivers/video/i810/i810_accel.c - 1.1 linux/drivers/video/i810/i810_dvt.c - 1.1 linux/drivers/video/i810/i810_gtf.c - 1.1 linux/drivers/video/i810/i810_main.c - 1.1 linux/drivers/video/i810/i810_main.h - 1.1 linux/drivers/video/i810/i810_regs.h - 1.1 linux/drivers/video/riva/nv_type.h - 1.1 linux/scripts/ver_linux - 1.11 linux/net/sunrpc/xdr.c - 1.12 linux/net/ipv6/ndisc.c - 1.27 linux/net/ipv4/tcp_ipv4.c - 1.56 linux/net/ipv4/route.c - 1.41 linux/net/core/dev.c - 1.65 linux/net/ax25/af_ax25.c - 1.29 linux/mm/vmscan.c - 1.122 linux/mm/swap_state.c - 1.56 linux/mm/swap.c - 1.32 linux/mm/slab.c - 1.47 linux/mm/page_alloc.c - 1.102 linux/mm/mremap.c - 1.39 linux/mm/filemap.c - 1.145 linux/lib/vsprintf.c - 1.20 linux/lib/Makefile - 1.17 linux/kernel/resource.c - 1.19 linux/kernel/printk.c - 1.27 linux/kernel/module.c - 1.33 linux/kernel/ksyms.c - 1.177 linux/kernel/fork.c - 1.79 linux/kernel/exit.c - 1.60 linux/kernel/exec_domain.c - 1.21 linux/kernel/capability.c - 1.12 linux/kernel/acct.c - 1.23 linux/ipc/shm.c - 1.61 linux/ipc/msg.c - 1.18 linux/init/main.c - 1.99 linux/include/video/font.h - 1.5 linux/include/scsi/scsi.h - 1.9 linux/include/net/dst.h - 1.11 linux/include/linux/types.h - 1.11 linux/include/linux/tty_driver.h - 1.5 linux/include/linux/tty.h - 1.20 linux/include/linux/sysctl.h - 1.68 linux/include/linux/swap.h - 1.70 linux/include/linux/sunrpc/svc.h - 1.13 linux/include/linux/smp.h - 1.23 linux/include/linux/slab.h - 1.27 linux/include/linux/sched.h - 1.94 linux/include/linux/quotaops.h - 1.17 linux/include/linux/quota.h - 1.22 linux/include/linux/personality.h - 1.12 linux/include/linux/pci.h - 1.70 linux/include/linux/nubus.h - 1.7 linux/include/linux/nfsd/xdr.h - 1.9 linux/include/linux/nfs_fs.h - 1.31 linux/include/linux/ncp_fs.h - 1.17 linux/include/linux/msdos_fs.h - 1.26 linux/include/linux/module.h - 1.40 linux/include/linux/mm.h - 1.110 linux/include/linux/mc146818rtc.h - 1.7 linux/include/linux/kernel.h - 1.41 linux/include/linux/ioport.h - 1.14 linux/include/linux/init.h - 1.23 linux/include/linux/i2c.h - 1.17 linux/include/linux/fs.h - 1.201 linux/include/linux/fb.h - 1.28 linux/include/linux/elf.h - 1.19 linux/include/linux/coda_psdev.h - 1.10 linux/include/linux/binfmts.h - 1.15 linux/include/linux/ax25.h - 1.5 linux/include/linux/amigaffs.h - 1.13 linux/include/asm-sparc64/types.h - 1.7 linux/include/asm-sparc64/stat.h - 1.6 linux/include/asm-sparc64/siginfo.h - 1.13 linux/include/asm-sparc64/processor.h - 1.28 linux/include/asm-sparc64/posix_types.h - 1.7 linux/include/asm-sparc64/io.h - 1.20 linux/include/asm-sparc64/fbio.h - 1.4 linux/include/asm-sparc/unistd.h - 1.28 linux/include/asm-sparc/types.h - 1.5 linux/include/asm-sparc/fbio.h - 1.4 linux/include/asm-ppc/unistd.h - 1.30 linux/include/asm-ppc/types.h - 1.14 linux/include/asm-ppc/nvram.h - 1.8 linux/include/asm-ppc/mk48t59.h - 1.5 linux/include/asm-mips/types.h - 1.6 linux/include/asm-mips/ds1286.h - 1.5 linux/include/asm-m68k/types.h - 1.5 linux/include/asm-m68k/system.h - 1.12 linux/include/asm-m68k/mman.h - 1.5 linux/include/asm-m68k/macintosh.h - 1.7 linux/include/asm-m68k/ide.h - 1.10 linux/include/asm-i386/unistd.h - 1.33 linux/include/asm-i386/uaccess.h - 1.18 linux/include/asm-i386/types.h - 1.6 linux/include/asm-i386/system.h - 1.30 linux/include/asm-i386/spinlock.h - 1.28 linux/include/asm-i386/smp.h - 1.25 linux/include/asm-i386/segment.h - 1.4 linux/include/asm-i386/processor.h - 1.47 linux/include/asm-i386/mtrr.h - 1.7 linux/include/asm-i386/msr.h - 1.17 linux/include/asm-i386/irq.h - 1.8 linux/include/asm-i386/fixmap.h - 1.14 linux/include/asm-i386/elf.h - 1.9 linux/include/asm-i386/desc.h - 1.16 linux/include/asm-i386/bugs.h - 1.19 linux/include/asm-arm/types.h - 1.5 linux/include/asm-arm/setup.h - 1.15 linux/include/asm-arm/arch-rpc/io.h - 1.9 linux/include/asm-arm/arch-ebsa285/time.h - 1.15 linux/include/asm-arm/arch-arc/io.h - 1.9 linux/include/asm-alpha/unistd.h - 1.27 linux/include/asm-alpha/uaccess.h - 1.8 linux/include/asm-alpha/types.h - 1.5 linux/include/asm-alpha/dma.h - 1.8 linux/fs/ufs/super.c - 1.40 linux/fs/sysv/inode.c - 1.36 linux/fs/super.c - 1.95 linux/fs/smbfs/proc.c - 1.25 linux/fs/smbfs/inode.c - 1.45 linux/fs/select.c - 1.22 linux/fs/read_write.c - 1.31 linux/fs/qnx4/inode.c - 1.41 linux/fs/qnx4/bitmap.c - 1.14 linux/fs/proc/base.c - 1.46 linux/fs/proc/array.c - 1.53 linux/fs/open.c - 1.46 linux/fs/ntfs/super.c - 1.22 linux/fs/nls/nls_base.c - 1.14 linux/fs/nfsd/vfs.c - 1.62 linux/fs/nfsd/nfsxdr.c - 1.21 linux/fs/nfsd/nfs3xdr.c - 1.34 linux/fs/nfs/write.c - 1.47 linux/fs/nfs/read.c - 1.38 linux/fs/nfs/proc.c - 1.21 linux/fs/nfs/nfs3xdr.c - 1.20 linux/fs/nfs/nfs2xdr.c - 1.24 linux/fs/nfs/inode.c - 1.60 linux/fs/nfs/file.c - 1.40 linux/fs/nfs/dir.c - 1.48 linux/fs/ncpfs/inode.c - 1.41 linux/fs/minix/inode.c - 1.39 linux/fs/isofs/inode.c - 1.42 linux/fs/inode.c - 1.88 linux/fs/hfs/super.c - 1.20 linux/fs/filesystems.c - 1.25 linux/fs/fat/inode.c - 1.54 linux/fs/ext2/super.c - 1.41 linux/fs/ext2/inode.c - 1.62 linux/fs/ext2/ialloc.c - 1.33 linux/fs/ext2/balloc.c - 1.25 linux/fs/exec.c - 1.74 linux/fs/dquot.c - 1.65 linux/fs/coda/upcall.c - 1.21 linux/fs/coda/inode.c - 1.29 linux/fs/buffer.c - 1.145 linux/fs/block_dev.c - 1.70 linux/fs/affs/super.c - 1.30 linux/fs/adfs/super.c - 1.26 linux/drivers/video/tgafb.c - 1.22 linux/drivers/video/skeletonfb.c - 1.15 linux/drivers/video/offb.c - 1.25 linux/drivers/video/igafb.c - 1.21 linux/drivers/video/fbmem.c - 1.56 linux/drivers/video/controlfb.c - 1.26 linux/drivers/video/chipsfb.c - 1.23 linux/drivers/video/atafb.c - 1.20 linux/drivers/video/Makefile - 1.48 linux/drivers/scsi/wd33c93.h - 1.11 linux/drivers/scsi/wd33c93.c - 1.11 linux/drivers/scsi/st.c - 1.60 linux/drivers/scsi/sr_vendor.c - 1.16 linux/drivers/scsi/sr.c - 1.61 linux/drivers/scsi/sg.c - 1.46 linux/drivers/scsi/sd.c - 1.81 linux/drivers/scsi/scsi_syms.c - 1.26 linux/drivers/scsi/scsi_error.c - 1.36 linux/drivers/scsi/scsi_debug.c - 1.28 linux/drivers/scsi/scsi.h - 1.42 linux/drivers/scsi/scsi.c - 1.68 linux/drivers/scsi/pluto.c - 1.17 linux/drivers/scsi/mvme16x.h - 1.7 linux/drivers/scsi/mvme16x.c - 1.9 linux/drivers/scsi/megaraid.c - 1.41 linux/drivers/scsi/mca_53c9x.h - 1.5 linux/drivers/scsi/mca_53c9x.c - 1.12 linux/drivers/scsi/mac_scsi.c - 1.11 linux/drivers/scsi/mac_esp.h - 1.6 linux/drivers/scsi/mac_esp.c - 1.14 linux/drivers/scsi/mac_NCR5380.c - 1.7 linux/drivers/scsi/jazz_esp.h - 1.6 linux/drivers/scsi/jazz_esp.c - 1.9 linux/drivers/scsi/ide-scsi.c - 1.50 linux/drivers/scsi/hosts.h - 1.33 linux/drivers/scsi/hosts.c - 1.38 linux/drivers/scsi/gvp11.h - 1.5 linux/drivers/scsi/gvp11.c - 1.14 linux/drivers/scsi/fcal.c - 1.13 linux/drivers/scsi/fastlane.h - 1.6 linux/drivers/scsi/fastlane.c - 1.12 linux/drivers/scsi/eata_pio_proc.c - 1.4 linux/drivers/scsi/cyberstormII.h - 1.6 linux/drivers/scsi/cyberstormII.c - 1.12 linux/drivers/scsi/cyberstorm.h - 1.6 linux/drivers/scsi/cyberstorm.c - 1.12 linux/drivers/scsi/bvme6000.h - 1.7 linux/drivers/scsi/bvme6000.c - 1.7 linux/drivers/scsi/blz2060.h - 1.6 linux/drivers/scsi/blz2060.c - 1.12 linux/drivers/scsi/blz1230.h - 1.6 linux/drivers/scsi/blz1230.c - 1.12 linux/drivers/scsi/atari_scsi.h - 1.6 linux/drivers/scsi/atari_scsi.c - 1.11 linux/drivers/scsi/atari_NCR5380.c - 1.8 linux/drivers/scsi/amiga7xx.h - 1.7 linux/drivers/scsi/amiga7xx.c - 1.10 linux/drivers/scsi/aic7xxx/scsi_message.h - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx.seq - 1.11 linux/drivers/scsi/aic7xxx/aic7xxx.reg - 1.9 linux/drivers/scsi/a3000.h - 1.7 linux/drivers/scsi/a3000.c - 1.13 linux/drivers/scsi/a2091.h - 1.7 linux/drivers/scsi/a2091.c - 1.16 linux/drivers/scsi/NCR53C9x.h - 1.8 linux/drivers/scsi/NCR53C9x.c - 1.20 linux/drivers/scsi/NCR5380.c - 1.16 linux/drivers/scsi/Makefile - 1.46 linux/drivers/scsi/53c7xx.c - 1.21 linux/drivers/pci/quirks.c - 1.34 linux/drivers/nubus/nubus.c - 1.12 linux/drivers/net/slhc.c - 1.14 linux/drivers/net/plip.c - 1.27 linux/drivers/net/hp100.h - 1.4 linux/drivers/net/hp100.c - 1.25 linux/drivers/net/hamradio/baycom_ser_hdx.c - 1.18 linux/drivers/net/hamradio/baycom_ser_fdx.c - 1.18 linux/drivers/net/hamradio/baycom_epp.c - 1.25 linux/drivers/net/defxx.h - 1.7 linux/drivers/net/atarilance.c - 1.15 linux/drivers/net/atari_pamsnet.c - 1.15 linux/drivers/net/atari_bionet.c - 1.15 linux/drivers/net/ariadne.c - 1.18 linux/drivers/net/a2065.c - 1.20 linux/drivers/macintosh/via-cuda.c - 1.12 linux/drivers/isdn/hisax/callc.c - 1.21 linux/drivers/fc4/socal.c - 1.14 linux/drivers/fc4/soc.c - 1.14 linux/drivers/char/vt.c - 1.31 linux/drivers/char/tty_io.c - 1.59 linux/drivers/char/sysrq.c - 1.34 linux/drivers/char/stallion.c - 1.27 linux/drivers/char/serial167.c - 1.17 linux/drivers/char/rtc.c - 1.35 linux/drivers/char/random.c - 1.37 linux/drivers/char/pty.c - 1.15 linux/drivers/char/n_tty.c - 1.16 linux/drivers/char/mem.c - 1.51 linux/drivers/char/busmouse.c - 1.21 linux/drivers/cdrom/sonycd535.c - 1.34 linux/drivers/block/z2ram.c - 1.26 linux/drivers/block/paride/paride.c - 1.16 linux/drivers/block/genhd.c - 1.44 linux/drivers/block/ataflop.c - 1.36 linux/drivers/block/amiflop.c - 1.36 linux/drivers/block/acsi_slm.c - 1.14 linux/drivers/block/acsi.c - 1.45 linux/arch/sparc64/solaris/fs.c - 1.22 linux/arch/sparc64/kernel/time.c - 1.27 linux/arch/sparc64/kernel/systbls.S - 1.37 linux/arch/sparc64/kernel/sys_sparc32.c - 1.65 linux/arch/sparc64/kernel/sys_sparc.c - 1.28 linux/arch/sparc64/kernel/smp.c - 1.51 linux/arch/sparc64/kernel/signal32.c - 1.31 linux/arch/sparc64/kernel/signal.c - 1.29 linux/arch/sparc64/kernel/ioctl32.c - 1.63 linux/arch/sparc64/boot/Makefile - 1.5 linux/arch/sparc64/Makefile - 1.25 linux/arch/sparc/kernel/signal.c - 1.32 linux/arch/ppc/kernel/smp.c - 1.46 linux/arch/ppc/8xx_io/uart.c - 1.24 linux/arch/mips/sgi/kernel/reset.c - 1.8 linux/arch/mips/kernel/sysirix.c - 1.20 linux/arch/mips/kernel/signal.c - 1.18 linux/arch/m68k/sun3x/time.c - 1.7 linux/arch/m68k/sun3x/dvma.c - 1.4 linux/arch/m68k/q40/q40ints.c - 1.8 linux/arch/m68k/mvme16x/rtc.c - 1.11 linux/arch/m68k/mvme16x/config.c - 1.12 linux/arch/m68k/mvme147/config.c - 1.15 linux/arch/m68k/mm/extable.c - 1.3 linux/arch/m68k/mac/macints.c - 1.11 linux/arch/m68k/mac/macboing.c - 1.6 linux/arch/m68k/mac/config.c - 1.14 linux/arch/m68k/kernel/traps.c - 1.16 linux/arch/m68k/kernel/signal.c - 1.20 linux/arch/m68k/kernel/setup.c - 1.20 linux/arch/m68k/kernel/process.c - 1.19 linux/arch/m68k/kernel/m68k_ksyms.c - 1.14 linux/arch/m68k/kernel/m68k_defs.c - 1.8 linux/arch/m68k/kernel/head.S - 1.10 linux/arch/m68k/kernel/entry.S - 1.20 linux/arch/m68k/bvme6000/rtc.c - 1.11 linux/arch/m68k/bvme6000/config.c - 1.12 linux/arch/m68k/atari/time.c - 1.6 linux/arch/m68k/atari/stram.c - 1.23 linux/arch/m68k/atari/stdma.c - 1.5 linux/arch/m68k/atari/config.c - 1.12 linux/arch/m68k/atari/atasound.c - 1.3 linux/arch/m68k/atari/ataints.c - 1.10 linux/arch/m68k/apollo/config.c - 1.10 linux/arch/m68k/amiga/config.c - 1.17 linux/arch/m68k/amiga/cia.c - 1.8 linux/arch/m68k/Makefile - 1.12 linux/arch/i386/mm/init.c - 1.50 linux/arch/i386/kernel/vm86.c - 1.22 linux/arch/i386/kernel/traps.c - 1.69 linux/arch/i386/kernel/trampoline.S - 1.8 linux/arch/i386/kernel/time.c - 1.32 linux/arch/i386/kernel/sys_i386.c - 1.13 linux/arch/i386/kernel/smp.c - 1.51 linux/arch/i386/kernel/signal.c - 1.31 linux/arch/i386/kernel/setup.c - 1.86 linux/arch/i386/kernel/process.c - 1.63 linux/arch/i386/kernel/ioport.c - 1.8 linux/arch/i386/kernel/io_apic.c - 1.50 linux/arch/i386/kernel/i386_ksyms.c - 1.63 linux/arch/i386/kernel/head.S - 1.30 linux/arch/i386/kernel/entry.S - 1.70 linux/arch/i386/kernel/Makefile - 1.42 linux/arch/i386/defconfig - 1.117 linux/arch/i386/boot/setup.S - 1.31 linux/arch/i386/boot/compressed/misc.c - 1.18 linux/arch/i386/boot/compressed/head.S - 1.9 linux/arch/i386/boot/Makefile - 1.21 linux/arch/i386/Makefile - 1.42 linux/arch/arm/kernel/time.c - 1.21 linux/arch/arm/boot/Makefile - 1.23 linux/arch/arm/Makefile - 1.40 linux/arch/alpha/mm/fault.c - 1.20 linux/arch/alpha/mm/extable.c - 1.6 linux/arch/alpha/lib/strncpy_from_user.S - 1.4 linux/arch/alpha/lib/strlen_user.S - 1.5 linux/arch/alpha/lib/copy_user.S - 1.4 linux/arch/alpha/lib/clear_user.S - 1.3 linux/arch/alpha/kernel/traps.c - 1.26 linux/arch/alpha/kernel/time.c - 1.26 linux/arch/alpha/kernel/smp.c - 1.40 linux/arch/alpha/kernel/osf_sys.c - 1.37 linux/Makefile - 1.234 linux/MAINTAINERS - 1.128 linux/Documentation/sysrq.txt - 1.13 linux/Documentation/sysctl/kernel.txt - 1.7 linux/Documentation/sysctl/fs.txt - 1.5 linux/Documentation/networking/z8530drv.txt - 1.5 linux/Documentation/modules.txt - 1.7 linux/Documentation/Changes - 1.61 linux/CREDITS - 1.94 linux/include/linux/ide.h - 1.72 linux/include/linux/efs_fs.h - 1.12 linux/fs/hpfs/super.c - 1.24 linux/fs/hpfs/hpfs_fn.h - 1.22 linux/fs/efs/super.c - 1.19 linux/drivers/video/vga16fb.c - 1.18 linux/drivers/isdn/eicon/eicon_mod.c - 1.21 linux/drivers/tc/zs.c - 1.12 linux/drivers/sgi/char/ds1286.c - 1.11 linux/drivers/char/dz.c - 1.20 linux/arch/mips/dec/time.c - 1.7 linux/drivers/video/tgafb.h - 1.4 linux/drivers/parport/parport_pc.c - 1.51 linux/drivers/parport/parport_mfc3.c - 1.11 linux/drivers/parport/parport_atari.c - 1.5 linux/drivers/parport/parport_amiga.c - 1.9 linux/drivers/net/ppp_generic.c - 1.33 linux/drivers/net/macsonic.c - 1.16 linux/include/linux/isapnp.h - 1.15 linux/include/asm-i386/hw_irq.h - 1.31 linux/fs/partitions/check.c - 1.62 linux/drivers/scsi/sun3x_esp.h - 1.4 linux/drivers/scsi/sun3x_esp.c - 1.9 linux/drivers/scsi/oktagon_esp.h - 1.4 linux/drivers/scsi/oktagon_esp.c - 1.11 linux/Documentation/isapnp.txt - 1.7 linux/drivers/char/ip2main.c - 1.24 linux/net/core/netfilter.c - 1.19 linux/include/asm-sh/types.h - 1.4 linux/include/asm-ppc/m48t35.h - 1.5 linux/include/asm-i386/pci.h - 1.20 linux/drivers/pcmcia/i82365.c - 1.30 linux/drivers/net/sun3lance.c - 1.15 linux/drivers/block/swim_iop.c - 1.23 linux/arch/m68k/vmlinux-sun3.lds - 1.12 linux/arch/m68k/sun3/sbus.c - 1.4 linux/arch/m68k/sun3/prom/misc.c - 1.3 linux/arch/m68k/sun3/prom/console.c - 1.3 linux/arch/m68k/sun3/dvma.c - 1.4 linux/arch/m68k/sun3/config.c - 1.10 linux/arch/m68k/mm/sun3mmu.c - 1.7 linux/arch/m68k/mac/via.c - 1.5 linux/arch/m68k/mac/iop.c - 1.6 linux/include/asm-m68k/sbus.h - 1.3 linux/fs/udf/super.c - 1.36 linux/drivers/char/drm/drmP.h - 1.21 linux/drivers/char/drm/drm.h - 1.13 linux/drivers/net/wan/cosa.c - 1.28 linux/arch/i386/kernel/smpboot.c - 1.54 linux/include/linux/pci_ids.h - 1.80 linux/drivers/video/tdfxfb.c - 1.26 linux/drivers/scsi/dec_esp.h - 1.5 linux/drivers/scsi/dec_esp.c - 1.8 linux/mm/highmem.c - 1.48 linux/drivers/video/aty128fb.c - 1.31 linux/fs/proc/proc_misc.c - 1.51 linux/fs/bfs/inode.c - 1.30 linux/drivers/scsi/sun3_scsi.h - 1.5 linux/drivers/scsi/sun3_scsi.c - 1.14 linux/include/asm-arm/arch-cl7500/io.h - 1.6 linux/drivers/video/fbmon.c - 1.3 linux/include/linux/mmzone.h - 1.34 linux/include/linux/cache.h - 1.6 linux/include/linux/agp_backend.h - 1.23 linux/drivers/char/agp/Makefile - 1.11 linux/drivers/scsi/scsi_lib.c - 1.56 linux/drivers/char/agp/agp.h - 1.30 linux/include/linux/i2c-algo-bit.h - 1.3 linux/include/linux/i2c-id.h - 1.14 linux/include/linux/i2c-elektor.h - 1.5 linux/drivers/i2c/i2c-velleman.c - 1.8 linux/drivers/i2c/i2c-elv.c - 1.9 linux/drivers/i2c/i2c-philips-par.c - 1.9 linux/drivers/i2c/i2c-elektor.c - 1.14 linux/drivers/i2c/i2c-algo-pcf.c - 1.12 linux/drivers/i2c/i2c-dev.c - 1.23 linux/drivers/i2c/i2c-core.c - 1.19 linux/drivers/i2c/i2c-algo-bit.c - 1.14 linux/drivers/i2c/Makefile - 1.10 linux/include/linux/i2c-dev.h - 1.10 linux/drivers/pcmcia/yenta.c - 1.36 linux/fs/cramfs/inode.c - 1.33 linux/Documentation/usb/usb-serial.txt - 1.24 linux/drivers/ieee1394/ieee1394_core.c - 1.26 linux/arch/i386/kernel/apic.c - 1.38 linux/arch/i386/kernel/mpparse.c - 1.30 linux/drivers/pci/setup-res.c - 1.13 linux/drivers/pci/setup-bus.c - 1.9 linux/drivers/scsi/scsi_scan.c - 1.37 linux/arch/m68k/sun3/intersil.c - 1.5 linux/arch/i386/kernel/pci-dma.c - 1.5 linux/Documentation/DMA-mapping.txt - 1.18 linux/drivers/net/mac89x0.c - 1.13 linux/drivers/net/macmace.c - 1.7 linux/drivers/char/vme_scc.c - 1.13 linux/drivers/char/efirtc.c - 1.12 linux/arch/ia64/kernel/fw-emu.c - 1.11 linux/arch/ia64/kernel/entry.S - 1.33 linux/arch/ia64/kernel/efi.c - 1.20 linux/arch/ia64/kernel/Makefile - 1.17 linux/drivers/acorn/char/pcf8583.c - 1.7 linux/arch/ia64/ia32/sys_ia32.c - 1.37 linux/arch/ia64/ia32/ia32_signal.c - 1.11 linux/arch/ia64/ia32/ia32_entry.S - 1.19 linux/arch/ia64/ia32/binfmt_elf32.c - 1.16 linux/arch/ia64/ia32/Makefile - 1.12 linux/arch/ia64/vmlinux.lds.S - 1.19 linux/arch/ia64/boot/bootloader.c - 1.6 linux/arch/ia64/boot/Makefile - 1.9 linux/arch/ia64/Makefile - 1.23 linux/arch/ia64/tools/Makefile - 1.12 linux/arch/ia64/kernel/setup.c - 1.22 linux/arch/ia64/kernel/signal.c - 1.20 linux/arch/ia64/kernel/smp.c - 1.20 linux/arch/ia64/kernel/sys_ia64.c - 1.17 linux/arch/ia64/kernel/unaligned.c - 1.12 linux/arch/ia64/kernel/sal.c - 1.8 linux/arch/ia64/kernel/ptrace.c - 1.20 linux/arch/ia64/kernel/process.c - 1.24 linux/arch/ia64/mm/tlb.c - 1.15 linux/arch/ia64/kernel/mca.c - 1.16 linux/arch/ia64/mm/fault.c - 1.12 linux/arch/ia64/mm/Makefile - 1.6 linux/include/asm-ia64/ia32.h - 1.14 linux/include/asm-ia64/bitops.h - 1.11 linux/include/asm-ia64/atomic.h - 1.7 linux/include/asm-ia64/mman.h - 1.6 linux/include/asm-ia64/mca_asm.h - 1.7 linux/include/asm-ia64/processor.h - 1.29 linux/include/asm-ia64/mca.h - 1.7 linux/include/asm-ia64/mmu_context.h - 1.11 linux/include/asm-ia64/unistd.h - 1.28 linux/include/asm-ia64/types.h - 1.5 linux/include/asm-ia64/system.h - 1.22 linux/drivers/scsi/sun3_NCR5380.c - 1.8 linux/drivers/macintosh/via-pmu68k.c - 1.8 linux/drivers/macintosh/via-maciisi.c - 1.3 linux/drivers/macintosh/via-macii.c - 1.4 linux/drivers/macintosh/adb-iop.c - 1.3 linux/drivers/char/amiserial.c - 1.16 linux/arch/m68k/mac/misc.c - 1.8 linux/include/linux/devfs_fs_kernel.h - 1.16 linux/fs/devfs/base.c - 1.49 linux/drivers/video/matrox/matroxfb_maven.c - 1.7 linux/drivers/video/matrox/i2c-matroxfb.c - 1.7 linux/drivers/net/ioc3-eth.c - 1.21 linux/include/asm-mips64/ds1286.h - 1.4 linux/include/asm-mips64/types.h - 1.4 linux/include/asm-mips64/m48t35.h - 1.2 linux/arch/mips64/sgi-ip27/ip27-timer.c - 1.10 linux/arch/mips64/sgi-ip27/ip27-rtc.c - 1.10 linux/arch/mips64/kernel/signal32.c - 1.13 linux/arch/mips64/kernel/signal.c - 1.11 linux/arch/mips64/kernel/linux32.c - 1.15 linux/drivers/net/bonding.c - 1.17 linux/include/linux/if_bonding.h - 1.6 linux/drivers/video/riva/riva_tbl.h - 1.5 linux/drivers/video/riva/riva_hw.h - 1.5 linux/drivers/video/riva/riva_hw.c - 1.5 linux/drivers/video/riva/fbdev.c - 1.20 linux/include/linux/usb.h - 1.51 linux/drivers/usb/serial/usb-serial.h - 1.26 linux/drivers/usb/serial/usb-serial.c - 1.9 linux/drivers/ide/ide.c - 1.79 linux/drivers/ide/ide-tape.c - 1.41 linux/Documentation/video4linux/README.cpia - 1.4 linux/include/linux/nfs_xdr.h - 1.14 linux/fs/ramfs/inode.c - 1.35 linux/fs/nfs/nfs3proc.c - 1.19 linux/drivers/usb/serial/keyspan_pda.c - 1.34 linux/drivers/usb/serial/ftdi_sio.c - 1.45 linux/drivers/usb/serial/whiteheat.c - 1.36 linux/drivers/usb/serial/visor.c - 1.47 linux/arch/ia64/kernel/smpboot.c - 1.17 linux/drivers/usb/serial/omninet.c - 1.33 linux/drivers/usb/serial/digi_acceleport.c - 1.34 linux/drivers/net/pppox.c - 1.10 linux/drivers/net/pppoe.c - 1.25 linux/arch/ppc/8260_io/uart.c - 1.14 linux/include/asm-s390/types.h - 1.4 linux/drivers/s390/block/dasd.c - 1.35 linux/arch/s390/kernel/smp.c - 1.18 linux/fs/xfs/xfs_bit.c - 1.21 linux/fs/xfs/linux/xfs_linux.h - 1.98 linux/fs/xfs/linux/xfs_iops.c - 1.191 linux/kernel/kallsyms.c - 1.16 linux/include/linux/kallsyms.h - 1.12 linux/Documentation/filesystems/Locking - 1.20 linux/drivers/usb/storage/usb.c - 1.34 linux/drivers/usb/storage/transport.c - 1.36 linux/drivers/usb/serial/keyspan.h - 1.15 linux/drivers/usb/serial/keyspan.c - 1.38 linux/include/asm-arm/memory.h - 1.8 linux/drivers/acpi/tables/tbxface.c - 1.14 linux/drivers/acpi/tables/tbutils.c - 1.15 linux/drivers/acpi/tables/tbinstal.c - 1.15 linux/drivers/acpi/tables/tbget.c - 1.16 linux/drivers/acpi/resources/rsxface.c - 1.10 linux/drivers/acpi/resources/rsutils.c - 1.12 linux/drivers/acpi/resources/rsmisc.c - 1.9 linux/drivers/acpi/resources/rsmemory.c - 1.9 linux/drivers/acpi/resources/rslist.c - 1.11 linux/drivers/acpi/resources/rsirq.c - 1.12 linux/drivers/acpi/resources/rsio.c - 1.11 linux/drivers/acpi/resources/rsdump.c - 1.12 linux/drivers/acpi/resources/rscreate.c - 1.14 linux/drivers/acpi/resources/rscalc.c - 1.13 linux/drivers/acpi/resources/rsaddr.c - 1.10 linux/drivers/acpi/parser/psxface.c - 1.13 linux/drivers/acpi/parser/pswalk.c - 1.10 linux/drivers/acpi/parser/psutils.c - 1.13 linux/drivers/acpi/parser/pstree.c - 1.11 linux/drivers/acpi/parser/psscope.c - 1.9 linux/drivers/acpi/parser/psparse.c - 1.17 linux/drivers/acpi/parser/psopcode.c - 1.16 linux/drivers/acpi/parser/psargs.c - 1.15 linux/drivers/acpi/namespace/nsxfobj.c - 1.15 linux/drivers/acpi/namespace/nsxfname.c - 1.12 linux/drivers/acpi/namespace/nswalk.c - 1.9 linux/drivers/acpi/namespace/nsutils.c - 1.16 linux/drivers/acpi/namespace/nssearch.c - 1.16 linux/drivers/acpi/namespace/nsobject.c - 1.14 linux/drivers/acpi/namespace/nsnames.c - 1.14 linux/drivers/acpi/namespace/nsload.c - 1.15 linux/fs/jffs/inode-v23.c - 1.35 linux/drivers/acpi/namespace/nseval.c - 1.16 linux/drivers/acpi/namespace/nsalloc.c - 1.14 linux/drivers/acpi/namespace/nsaccess.c - 1.16 linux/drivers/acpi/include/amlcode.h - 1.14 linux/drivers/acpi/include/actypes.h - 1.17 linux/drivers/acpi/include/actables.h - 1.13 linux/drivers/acpi/include/acpixf.h - 1.15 linux/drivers/acpi/include/acpiosxf.h - 1.14 linux/drivers/acpi/include/acpi.h - 1.6 linux/drivers/acpi/include/acobject.h - 1.15 linux/drivers/acpi/include/acexcep.h - 1.12 linux/drivers/acpi/hardware/hwregs.c - 1.15 linux/drivers/acpi/hardware/hwgpe.c - 1.12 linux/drivers/acpi/hardware/hwacpi.c - 1.13 linux/drivers/acpi/events/evxfregn.c - 1.13 linux/drivers/acpi/events/evxfevnt.c - 1.12 linux/drivers/acpi/events/evxface.c - 1.15 linux/drivers/acpi/events/evsci.c - 1.10 linux/drivers/acpi/events/evrgnini.c - 1.13 linux/drivers/acpi/events/evregion.c - 1.15 linux/drivers/acpi/events/evmisc.c - 1.14 linux/drivers/acpi/events/evevent.c - 1.18 linux/drivers/acpi/ec.c - 1.14 linux/drivers/acpi/dispatcher/dswstate.c - 1.16 linux/drivers/acpi/dispatcher/dswscope.c - 1.11 linux/drivers/acpi/dispatcher/dswload.c - 1.19 linux/drivers/acpi/dispatcher/dswexec.c - 1.14 linux/drivers/acpi/dispatcher/dsutils.c - 1.16 linux/drivers/acpi/dispatcher/dsopcode.c - 1.17 linux/drivers/acpi/dispatcher/dsobject.c - 1.20 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.14 linux/drivers/acpi/dispatcher/dsmethod.c - 1.14 linux/drivers/acpi/dispatcher/dsfield.c - 1.14 linux/arch/ia64/kernel/ia64_ksyms.c - 1.17 linux/arch/ia64/kernel/palinfo.c - 1.10 linux/include/linux/mtd/map.h - 1.8 linux/include/linux/mtd/mtd.h - 1.5 linux/drivers/media/video/tvmixer.c - 1.11 linux/drivers/media/video/cpia_usb.c - 1.17 linux/drivers/media/video/cpia.c - 1.18 linux/drivers/media/video/bttv-if.c - 1.8 linux/drivers/md/raid1.c - 1.28 linux/Documentation/kbuild/makefiles.txt - 1.7 linux/drivers/acpi/include/acconfig.h - 1.22 linux/drivers/acpi/include/acdebug.h - 1.15 linux/drivers/acpi/include/acdispat.h - 1.11 linux/drivers/acpi/include/acevents.h - 1.12 linux/drivers/acpi/include/acglobal.h - 1.16 linux/drivers/acpi/include/achware.h - 1.9 linux/drivers/acpi/include/acinterp.h - 1.15 linux/drivers/acpi/include/aclocal.h - 1.18 linux/drivers/acpi/include/acmacros.h - 1.15 linux/drivers/acpi/include/acnamesp.h - 1.15 linux/drivers/acpi/include/acoutput.h - 1.11 linux/drivers/acpi/include/acparser.h - 1.13 linux/drivers/acpi/include/acresrc.h - 1.8 linux/drivers/acpi/include/actbl.h - 1.10 linux/drivers/acpi/namespace/nsdump.c - 1.15 linux/include/asm-ia64/module.h - 1.9 linux/drivers/usb/serial/belkin_sa.c - 1.27 linux/Documentation/usb/hotplug.txt - 1.4 linux/include/asm-i386/cpufeature.h - 1.5 linux/include/asm-m68k/module.h - 1.3 linux/include/asm-ppc/module.h - 1.6 linux/include/asm-parisc/types.h - 1.3 linux/drivers/video/stifb.c - 1.7 linux/arch/alpha/lib/ev6-clear_user.S - 1.2 linux/arch/alpha/lib/ev6-copy_user.S - 1.2 linux/arch/alpha/lib/ev6-strncpy_from_user.S - 1.3 linux/arch/alpha/lib/ev67-strlen_user.S - 1.3 linux/drivers/usb/serial/mct_u232.c - 1.28 linux/drivers/usb/serial/empeg.c - 1.33 linux/drivers/scsi/mvme147.h - 1.3 linux/drivers/scsi/mvme147.c - 1.3 linux/arch/parisc/hpux/sys_hpux.c - 1.5 linux/drivers/acpi/tables/tbconvrt.c - 1.13 linux/drivers/acpi/tables/tbxfroot.c - 1.11 linux/drivers/acpi/namespace/nsinit.c - 1.13 linux/drivers/acpi/include/actbl71.h - 1.7 linux/drivers/acpi/include/actbl2.h - 1.10 linux/drivers/acpi/include/actbl1.h - 1.7 linux/include/asm-ia64/mmu.h - 1.2 linux/mm/shmem.c - 1.53 linux/drivers/acpi/power.c - 1.10 linux/drivers/scsi/osst.c - 1.21 linux/arch/ia64/sn/io/stubs.c - 1.4 linux/include/asm-ia64/sn/addrs.h - 1.4 linux/include/asm-ia64/sn/alenlist.h - 1.4 linux/include/asm-ia64/sn/arch.h - 1.4 linux/include/asm-ia64/sn/clksupport.h - 1.3 linux/include/asm-ia64/sn/eeprom.h - 1.4 linux/include/asm-ia64/sn/hack.h - 1.4 linux/include/asm-ia64/sn/intr.h - 1.4 linux/include/asm-ia64/sn/ioerror.h - 1.4 linux/include/asm-ia64/sn/iograph.h - 1.4 linux/include/asm-ia64/sn/klconfig.h - 1.4 linux/include/asm-ia64/sn/ksys/elsc.h - 1.4 linux/include/asm-ia64/sn/ksys/l1.h - 1.4 linux/include/asm-ia64/sn/module.h - 1.4 linux/include/asm-ia64/sn/xtalk/xwidget.h - 1.3 linux/include/asm-ia64/sn/xtalk/xtalk_private.h - 1.4 linux/include/asm-ia64/sn/xtalk/xtalk.h - 1.4 linux/include/asm-ia64/sn/xtalk/xbow.h - 1.4 linux/include/asm-ia64/sn/vector.h - 1.3 linux/include/asm-ia64/sn/types.h - 1.4 linux/include/asm-ia64/sn/sn_cpuid.h - 1.4 linux/arch/ia64/sn/io/Makefile - 1.8 linux/arch/ia64/sn/io/alenlist.c - 1.4 linux/arch/ia64/sn/io/cdl.c - 1.4 linux/arch/ia64/sn/io/hcl.c - 1.7 linux/arch/ia64/sn/io/hcl_util.c - 1.4 linux/arch/ia64/sn/io/hubdev.c - 1.4 linux/arch/ia64/sn/io/hubspc.c - 1.5 linux/arch/ia64/sn/io/invent.c - 1.4 linux/arch/ia64/sn/io/io.c - 1.4 linux/arch/ia64/sn/io/klgraph_hack.c - 1.5 linux/arch/ia64/sn/io/labelcl.c - 1.4 linux/arch/ia64/sn/io/pci.c - 1.5 linux/arch/ia64/sn/io/pci_dma.c - 1.6 linux/arch/ia64/sn/io/sgi_if.c - 1.4 linux/arch/ia64/sn/io/sgi_io_sim.c - 1.4 linux/include/asm-ia64/sn/nodepda.h - 1.4 linux/arch/ia64/sn/io/xswitch.c - 1.4 linux/arch/ia64/sn/tools/make_textsym - 1.3 linux/include/asm-ia64/sn/sn1/addrs.h - 1.4 linux/include/asm-ia64/sn/sgi.h - 1.4 linux/arch/sh/kernel/rtc.c - 1.6 linux/include/asm-ia64/sn/pci/pciio_private.h - 1.4 linux/include/asm-ia64/sn/pci/pciio.h - 1.4 linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.5 linux/include/asm-ia64/sn/pci/pcibr.h - 1.5 linux/include/asm-ia64/sn/pci/pci_defs.h - 1.3 linux/include/asm-ia64/sn/pci/pci_bus_cvlink.h - 1.4 linux/include/asm-ia64/sn/pci/bridge.h - 1.4 linux/fs/reiserfs/super.c - 1.31 linux/drivers/char/drm/radeon_cp.c - 1.11 linux/drivers/char/drm/radeon_state.c - 1.10 linux/drivers/acpi/hardware/hwsleep.c - 1.12 linux/drivers/acpi/hardware/hwtimer.c - 1.9 linux/fs/reiserfs/bitmap.c - 1.22 linux/drivers/ide/ide-timing.h - 1.5 linux/arch/s390x/kernel/smp.c - 1.15 linux/drivers/video/riva/rivafb.h - 1.4 linux/arch/s390x/kernel/linux32.h - 1.4 linux/arch/s390x/kernel/linux32.c - 1.20 linux/arch/s390x/kernel/ioctl32.c - 1.9 linux/arch/cris/kernel/time.c - 1.8 linux/arch/s390x/kernel/entry.S - 1.17 linux/arch/s390x/kernel/binfmt_elf32.c - 1.6 linux/include/asm-s390x/types.h - 1.3 linux/arch/s390x/kernel/wrapper32.S - 1.9 linux/include/asm-cris/types.h - 1.2 linux/include/asm-cris/rtc.h - 1.3 linux/drivers/usb/serial/io_tables.h - 1.9 linux/drivers/usb/serial/io_edgeport.c - 1.31 linux/drivers/scsi/aic7xxx_old/aic7xxx.h - 1.9 linux/drivers/scsi/aic7xxx_old.c - 1.26 linux/drivers/scsi/aic7xxx/cam.h - 1.4 linux/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h - 1.3 linux/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c - 1.5 linux/drivers/scsi/aic7xxx/aicasm/aicasm_scan.l - 1.4 linux/drivers/scsi/aic7xxx/aicasm/aicasm_insformat.h - 1.3 linux/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y - 1.4 linux/drivers/scsi/aic7xxx/aicasm/aicasm.h - 1.4 linux/drivers/scsi/aic7xxx/aicasm/aicasm.c - 1.4 linux/drivers/scsi/aic7xxx/aicasm/Makefile - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_proc.c - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_pci.c - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.10 linux/drivers/scsi/aic7xxx/aic7xxx_linux_pci.c - 1.8 linux/drivers/scsi/aic7xxx/aic7xxx_linux_host.h - 1.10 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.22 linux/drivers/scsi/aic7xxx/aic7xxx_inline.h - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_93cx6.h - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_93cx6.c - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx.h - 1.5 linux/drivers/scsi/aic7xxx/aic7770_linux.c - 1.5 linux/drivers/scsi/aic7xxx/aic7770.c - 1.6 linux/drivers/scsi/aic7xxx/Makefile - 1.11 linux/drivers/video/pmagb-b-fb.h - 1.2 linux/include/asm-ia64/sn/pci/pciba.h - 1.3 linux/include/asm-ia64/sn/sn_sal.h - 1.3 linux/arch/ia64/kernel/efivars.c - 1.9 linux/arch/ia64/sn/io/pciba.c - 1.5 linux/include/linux/compiler.h - 1.7 linux/fs/freevxfs/vxfs_super.c - 1.13 linux/drivers/net/irda/irda-usb.c - 1.28 linux/drivers/media/video/adv7175.c - 1.9 linux/arch/ppc/boot/prep/vreset.c - 1.5 linux/arch/cris/drivers/ds1302.c - 1.6 linux/drivers/bluetooth/hci_usb.c - 1.19 linux/arch/m68k/sun3x/prom.c - 1.4 linux/drivers/mtd/chips/chipreg.c - 1.3 linux/drivers/media/radio/miropcm20-rds.c - 1.4 linux/drivers/acpi/executer/exstore.c - 1.14 linux/drivers/acpi/utilities/utxface.c - 1.8 linux/drivers/acpi/utilities/utobject.c - 1.9 linux/drivers/acpi/utilities/utmisc.c - 1.12 linux/drivers/acpi/utilities/utinit.c - 1.9 linux/drivers/acpi/utilities/utglobal.c - 1.15 linux/drivers/acpi/utilities/uteval.c - 1.10 linux/drivers/acpi/utilities/utdelete.c - 1.10 linux/drivers/acpi/utilities/utdebug.c - 1.10 linux/drivers/acpi/utilities/utcopy.c - 1.12 linux/drivers/acpi/utilities/utalloc.c - 1.7 linux/drivers/acpi/include/acstruct.h - 1.9 linux/drivers/acpi/include/acutils.h - 1.13 linux/drivers/acpi/include/platform/acenv.h - 1.10 linux/drivers/acpi/include/platform/acgcc.h - 1.10 linux/drivers/acpi/include/platform/aclinux.h - 1.10 linux/drivers/acpi/executer/exutils.c - 1.11 linux/drivers/acpi/executer/exsystem.c - 1.6 linux/drivers/acpi/executer/exstorob.c - 1.9 linux/drivers/acpi/executer/exstoren.c - 1.10 linux/drivers/acpi/executer/exconfig.c - 1.10 linux/drivers/acpi/executer/exconvrt.c - 1.12 linux/drivers/acpi/executer/excreate.c - 1.11 linux/drivers/acpi/executer/exdump.c - 1.14 linux/drivers/acpi/executer/exfield.c - 1.8 linux/drivers/acpi/executer/exfldio.c - 1.11 linux/drivers/acpi/executer/exmisc.c - 1.12 linux/drivers/acpi/executer/exmutex.c - 1.7 linux/drivers/acpi/executer/exnames.c - 1.7 linux/drivers/acpi/executer/exprep.c - 1.11 linux/drivers/acpi/executer/exregion.c - 1.9 linux/drivers/acpi/executer/exresnte.c - 1.14 linux/drivers/acpi/executer/exresolv.c - 1.12 linux/drivers/acpi/executer/exresop.c - 1.14 linux/drivers/usb/serial/cyberjack.c - 1.22 linux/drivers/usb/serial/pl2303.c - 1.25 linux/arch/mips/kernel/old-time.c - 1.4 linux/drivers/usb/usb-skeleton.c - 1.19 linux/drivers/char/ser_a2232.c - 1.6 linux/drivers/net/lp486e.c - 1.8 linux/drivers/message/fusion/mptscsih.h - 1.10 linux/drivers/message/fusion/mptscsih.c - 1.14 linux/drivers/message/fusion/mptctl.c - 1.12 linux/drivers/message/fusion/mptbase.h - 1.9 linux/drivers/message/fusion/mptbase.c - 1.9 linux/drivers/message/fusion/linux_compat.h - 1.7 linux/drivers/video/aty/atyfb_base.c - 1.15 linux/drivers/char/drm/r128.h - 1.4 linux/drivers/char/drm/drm_vm.h - 1.15 linux/drivers/char/drm/drm_dma.h - 1.4 linux/drivers/char/drm/drm_agpsupport.h - 1.9 linux/include/net/irda/vlsi_ir.h - 1.4 linux/drivers/video/sstfb.h - 1.4 linux/drivers/video/sstfb.c - 1.10 linux/drivers/video/radeonfb.c - 1.13 linux/arch/mips/au1000/common/serial.c - 1.6 linux/arch/mips/ddb5xxx/common/rtc_ds1386.c - 1.2 linux/drivers/isdn/hisax/st5481_b.c - 1.8 linux/drivers/isdn/hisax/st5481_d.c - 1.9 linux/drivers/isdn/hisax/st5481_init.c - 1.7 linux/drivers/isdn/hisax/st5481_usb.c - 1.13 linux/drivers/scsi/53c700.c - 1.13 linux/drivers/scsi/53c700.h - 1.7 linux/drivers/scsi/NCR_D700.c - 1.5 linux/drivers/i2c/i2c-adap-ite.c - 1.6 linux/drivers/scsi/lasi700.c - 1.5 linux/drivers/scsi/lasi700.h - 1.4 linux/fs/jffs2/file.c - 1.12 linux/arch/i386/kernel/nmi.c - 1.11 linux/fs/smbfs/proto.h - 1.8 linux/drivers/usb/serial/ir-usb.c - 1.24 linux/fs/quota.c - 1.17 linux/drivers/i2c/i2c-proc.c - 1.8 linux/include/linux/i2c-proc.h - 1.3 linux/drivers/acpi/executer/exoparg6.c - 1.4 linux/drivers/acpi/utilities/utmath.c - 1.4 linux/drivers/acpi/executer/exoparg3.c - 1.6 linux/drivers/acpi/executer/exoparg2.c - 1.11 linux/drivers/acpi/executer/exoparg1.c - 1.12 linux/net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.6 linux/Documentation/networking/ifenslave.c - 1.3 linux/Documentation/networking/bonding.txt - 1.5 linux/fs/jbd/journal.c - 1.17 linux/fs/ext3/ialloc.c - 1.20 linux/fs/ext3/inode.c - 1.29 linux/fs/ext3/namei.c - 1.16 linux/fs/ext3/super.c - 1.29 linux/drivers/hotplug/pci_hotplug_core.c - 1.15 linux/include/linux/ext3_fs_i.h - 1.5 linux/include/linux/ext3_fs.h - 1.14 linux/fs/jbd/transaction.c - 1.13 linux/fs/intermezzo/Makefile - 1.5 linux/fs/bio.c - 1.24 linux/include/linux/device.h - 1.25 linux/mm/mempool.c - 1.15 linux/include/linux/gfp.h - 1.8 linux/drivers/usb/serial/ipaq.c - 1.18 linux/drivers/usb/serial/ipaq.h - 1.5 linux/drivers/usb/serial/kl5kusb105.c - 1.17 linux/Documentation/usb/ehci.txt - 1.4 linux/fs/xfs/pagebuf/page_buf.c - 1.91 linux/lib/crc32.c - 1.4 linux/include/linux/init_task.h - 1.15 linux/fs/ext2/ext2.h - 1.10 linux/drivers/input/joystick/amijoy.c - 1.5 linux/include/asm-i386/thread_info.h - 1.7 linux/sound/synth/emux/emux_seq.c - 1.4 linux/sound/synth/emux/Makefile - 1.6 linux/sound/synth/Makefile - 1.8 linux/sound/pci/trident/trident_main.c - 1.8 linux/sound/pci/trident/trident.c - 1.8 linux/sound/pci/rme9652/rme9652.c - 1.13 linux/sound/pci/rme96.c - 1.12 linux/sound/pci/korg1212/korg1212.c - 1.13 linux/sound/pci/intel8x0.c - 1.12 linux/sound/pci/fm801.c - 1.10 linux/sound/pci/es1968.c - 1.11 linux/sound/pci/es1938.c - 1.10 linux/sound/pci/ens1370.c - 1.14 linux/sound/pci/emu10k1/emu10k1.c - 1.8 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.10 linux/sound/pci/cs4281.c - 1.13 linux/sound/pci/cmipci.c - 1.12 linux/sound/pci/als4000.c - 1.9 linux/sound/pci/ali5451/ali5451.c - 1.12 linux/sound/pci/ac97/ac97_codec.c - 1.10 linux/sound/oss/soundcard.c - 1.6 linux/sound/oss/sequencer.c - 1.4 linux/arch/ppc/iSeries/mf.c - 1.3 linux/sound/oss/nec_vrc5477.c - 1.3 linux/sound/oss/mpu401.c - 1.5 linux/sound/oss/midibuf.c - 1.5 linux/sound/oss/esssolo1.c - 1.7 linux/arch/ppc/platforms/chrp_time.c - 1.3 linux/arch/ppc/platforms/gemini_setup.c - 1.6 linux/arch/ppc/platforms/prep_time.c - 1.3 linux/arch/x86_64/Makefile - 1.11 linux/arch/x86_64/boot/Makefile - 1.10 linux/arch/x86_64/boot/compressed/Makefile - 1.5 linux/arch/x86_64/boot/compressed/misc.c - 1.4 linux/arch/x86_64/defconfig - 1.13 linux/arch/x86_64/ia32/Makefile - 1.9 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.7 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.11 linux/arch/x86_64/ia32/ia32_signal.c - 1.7 linux/arch/x86_64/ia32/ia32entry.S - 1.6 linux/arch/x86_64/ia32/socket32.c - 1.3 linux/arch/x86_64/ia32/sys_ia32.c - 1.11 linux/arch/x86_64/kernel/Makefile - 1.11 linux/arch/x86_64/kernel/apic.c - 1.7 linux/arch/x86_64/kernel/entry.S - 1.7 linux/arch/x86_64/kernel/head.S - 1.6 linux/arch/x86_64/kernel/i387.c - 1.5 linux/arch/x86_64/kernel/i8259.c - 1.5 linux/arch/x86_64/kernel/io_apic.c - 1.4 linux/arch/x86_64/kernel/ldt.c - 1.6 linux/arch/x86_64/kernel/mtrr.c - 1.10 linux/arch/x86_64/kernel/nmi.c - 1.6 linux/arch/x86_64/kernel/process.c - 1.11 linux/arch/x86_64/kernel/setup64.c - 1.7 linux/arch/x86_64/kernel/signal.c - 1.9 linux/arch/x86_64/kernel/smp.c - 1.9 linux/arch/x86_64/kernel/smpboot.c - 1.8 linux/arch/x86_64/kernel/time.c - 1.6 linux/arch/x86_64/kernel/traps.c - 1.10 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.10 linux/arch/x86_64/lib/usercopy.c - 1.4 linux/arch/x86_64/mm/Makefile - 1.5 linux/arch/x86_64/mm/extable.c - 1.3 linux/arch/x86_64/mm/fault.c - 1.7 linux/arch/x86_64/mm/init.c - 1.10 linux/sound/oss/audio.c - 1.4 linux/sound/isa/wavefront/wavefront_synth.c - 1.7 linux/sound/isa/wavefront/wavefront_fx.c - 1.5 linux/sound/isa/sb/sb_mixer.c - 1.5 linux/sound/isa/sb/sb16_main.c - 1.7 linux/sound/isa/sb/sb16.c - 1.8 linux/sound/isa/gus/gus_main.c - 1.6 linux/sound/isa/es18xx.c - 1.11 linux/sound/isa/cs423x/cs4236.c - 1.11 linux/sound/isa/cs423x/cs4231_lib.c - 1.9 linux/sound/drivers/virmidi.c - 1.6 linux/sound/drivers/opl3/opl3_seq.c - 1.6 linux/sound/drivers/opl3/opl3_lib.c - 1.6 linux/sound/drivers/opl3/Makefile - 1.9 linux/sound/drivers/mtpav.c - 1.10 linux/sound/drivers/mpu401/mpu401_uart.c - 1.9 linux/sound/drivers/mpu401/mpu401.c - 1.6 linux/sound/core/timer.c - 1.10 linux/sound/core/sound.c - 1.12 linux/sound/core/seq/seq_virmidi.c - 1.8 linux/sound/core/seq/seq_ports.c - 1.6 linux/sound/core/seq/seq_lock.h - 1.4 linux/sound/core/seq/seq_lock.c - 1.5 linux/sound/core/seq/seq_device.c - 1.6 linux/sound/core/seq/seq.c - 1.5 linux/sound/core/seq/oss/seq_oss_synth.c - 1.6 linux/sound/core/seq/instr/Makefile - 1.10 linux/sound/core/seq/Makefile - 1.16 linux/sound/core/rawmidi.c - 1.12 linux/sound/core/pcm_native.c - 1.12 linux/sound/core/pcm_lib.c - 1.9 linux/sound/core/pcm.c - 1.7 linux/sound/core/oss/pcm_oss.c - 1.13 linux/sound/core/oss/mixer_oss.c - 1.6 linux/sound/core/init.c - 1.8 linux/sound/core/info.c - 1.11 linux/sound/core/device.c - 1.8 linux/sound/core/control.c - 1.8 linux/include/sound/pcm_oss.h - 1.2 linux/include/asm-x86_64/scatterlist.h - 1.2 linux/include/asm-x86_64/processor.h - 1.9 linux/include/asm-x86_64/pgtable.h - 1.10 linux/include/asm-x86_64/page.h - 1.6 linux/include/asm-x86_64/mtrr.h - 1.4 linux/include/asm-x86_64/module.h - 1.3 linux/include/asm-x86_64/mmu_context.h - 1.7 linux/include/asm-x86_64/io_apic.h - 1.5 linux/include/asm-x86_64/io.h - 1.5 linux/include/asm-x86_64/ide.h - 1.9 linux/include/asm-x86_64/ia32_unistd.h - 1.4 linux/include/asm-x86_64/ia32.h - 1.5 linux/include/asm-x86_64/i387.h - 1.5 linux/include/asm-x86_64/hw_irq.h - 1.4 linux/include/asm-x86_64/hardirq.h - 1.3 linux/include/asm-x86_64/elf.h - 1.4 linux/include/asm-x86_64/desc.h - 1.5 linux/include/asm-x86_64/calling.h - 1.4 linux/include/asm-x86_64/bitops.h - 1.6 linux/include/sound/version.h - 1.14 linux/include/sound/trident.h - 1.4 linux/include/sound/sb.h - 1.4 linux/include/sound/pcm.h - 1.8 linux/include/sound/opl3.h - 1.5 linux/include/sound/mpu401.h - 1.4 linux/include/sound/mixer_oss.h - 1.4 linux/include/sound/initval.h - 1.4 linux/include/asm-x86_64/system.h - 1.8 linux/include/sound/cs46xx.h - 1.7 linux/include/sound/core.h - 1.15 linux/include/sound/control.h - 1.2 linux/include/sound/ac97_codec.h - 1.9 linux/include/asm-ppc/todc.h - 1.2 linux/include/asm-x86_64/socket32.h - 1.3 linux/include/asm-x86_64/spinlock.h - 1.5 linux/include/asm-x86_64/unistd.h - 1.10 linux/include/asm-x86_64/uaccess.h - 1.3 linux/include/asm-x86_64/types.h - 1.5 linux/include/asm-x86_64/thread_info.h - 1.5 linux/arch/ppc64/kernel/mf.c - 1.4 linux/arch/ppc64/kernel/rtc.c - 1.4 linux/arch/ppc64/kernel/smp.c - 1.12 linux/include/asm-ppc64/unistd.h - 1.11 linux/include/asm-ppc64/types.h - 1.2 linux/include/asm-ppc64/nvram.h - 1.3 linux/drivers/hotplug/ibmphp_res.c - 1.4 linux/fs/jfs/super.c - 1.19 linux/sound/core/ioctl32/ioctl32.c - 1.8 linux/drivers/net/e100/e100_main.c - 1.12 linux/Documentation/sound/oss/Introduction - 1.2 linux/arch/ia64/sn/fakeprom/fpmem.c - 1.3 linux/arch/ia64/sn/kernel/sv.c - 1.3 linux/arch/ia64/sn/kernel/sn_ksyms.c - 1.2 linux/arch/ia64/sn/kernel/sn_asm.S - 1.2 linux/arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.2 linux/arch/ia64/sn/kernel/sn2/iomv.c - 1.2 linux/arch/ia64/sn/kernel/sn2/Makefile - 1.6 linux/arch/ia64/sn/kernel/sn1/synergy.c - 1.3 linux/arch/ia64/sn/kernel/sn1/sn1_smp.c - 1.3 linux/arch/ia64/sn/kernel/sn1/iomv.c - 1.2 linux/include/asm-ia64/sn/ate_utils.h - 1.2 linux/arch/ia64/sn/kernel/llsc4.h - 1.2 linux/arch/ia64/sn/kernel/sn1/Makefile - 1.6 linux/arch/ia64/sn/kernel/irq.c - 1.3 linux/include/asm-ia64/sn/bte.h - 1.2 linux/arch/ia64/sn/kernel/bte.c - 1.2 linux/arch/ia64/sn/io/ifconfig_net.c - 1.4 linux/fs/jffs2/os-linux.h - 1.6 linux/arch/ia64/sn/kernel/setup.c - 1.5 linux/arch/ia64/sn/kernel/misctest.c - 1.4 linux/arch/ia64/sn/io/ate_utils.c - 1.2 linux/arch/ia64/sn/kernel/machvec.c - 1.2 linux/include/asm-ia64/thread_info.h - 1.4 linux/fs/jffs2/fs.c - 1.6 linux/include/asm-ia64/sn/sndrv.h - 1.2 linux/include/asm-ia64/sn/sn2/sn_private.h - 1.2 linux/include/asm-ia64/sn/sn2/shubio.h - 1.2 linux/include/asm-ia64/sn/sn2/mmzone_sn2.h - 1.2 linux/include/asm-ia64/sn/sn2/intr.h - 1.2 linux/include/asm-ia64/sn/sn2/arch.h - 1.2 linux/include/asm-ia64/sn/sn2/addrs.h - 1.2 linux/include/asm-ia64/sn/sn1/synergy.h - 1.2 linux/include/asm-ia64/sn/sn1/sn_private.h - 1.2 linux/include/asm-ia64/sn/sn1/mmzone_sn1.h - 1.2 linux/include/asm-ia64/sn/sn1/intr_public.h - 1.2 linux/include/asm-ia64/sn/sn1/intr.h - 1.2 linux/include/asm-ia64/sn/pda.h - 1.2 linux/include/asm-ia64/sn/leds.h - 1.2 linux/include/asm-ia64/sn/klclock.h - 1.2 linux/include/asm-ia64/machvec_sn2.h - 1.3 linux/include/asm-ia64/sn/idle.h - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-generic-sp - 1.6 linux/include/asm-ia64/sn/fetchop.h - 1.2 linux/include/asm-ia64/sn/bte_copy.h - 1.3 linux/arch/ia64/sn/configs/sn1/defconfig-hp-sp - 1.4 linux/arch/ia64/sn/io/sn1/hub_intr.c - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp - 1.7 linux/arch/ia64/sn/io/sn1/hubcounters.c - 1.3 linux/arch/ia64/sn/kernel/llsc4.c - 1.5 linux/arch/ia64/sn/io/sn1/huberror.c - 1.2 linux/arch/ia64/sn/kernel/Makefile - 1.6 linux/arch/ia64/sn/io/sn2/shuberror.c - 1.2 linux/arch/ia64/sn/io/sn2/shub_intr.c - 1.2 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.2 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c - 1.2 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.2 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_hints.c - 1.2 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_error.c - 1.2 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_config.c - 1.2 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.2 linux/arch/ia64/sn/io/sn2/ml_SN_intr.c - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-mp - 1.8 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-sp - 1.8 linux/arch/ia64/sn/configs/sn1/defconfig-dig-mp - 1.6 linux/arch/ia64/sn/configs/sn1/defconfig-dig-sp - 1.6 linux/arch/ia64/sn/configs/sn1/defconfig-generic-mp - 1.6 linux/arch/ia64/sn/io/sn1/mem_refcnt.c - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-prom-medusa - 1.6 linux/arch/ia64/sn/io/sn1/ml_SN_intr.c - 1.3 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp-modules - 1.7 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp-syn1-0 - 1.7 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-sp - 1.7 linux/arch/ia64/sn/configs/sn2/defconfig-dig-numa - 1.6 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-dig-mp - 1.6 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-dig-sp - 1.6 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-mp - 1.7 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-mp-modules - 1.7 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-prom-medusa - 1.6 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-sp - 1.7 linux/arch/ia64/sn/fakeprom/Makefile - 1.6 linux/arch/ia64/sn/fakeprom/README - 1.3 linux/arch/ia64/sn/io/sn2/bte_error.c - 1.2 linux/arch/ia64/sn/fakeprom/fpmem.h - 1.2 linux/arch/ia64/sn/fakeprom/fpromasm.S - 1.2 linux/arch/ia64/sn/fakeprom/fw-emu.c - 1.3 linux/arch/ia64/sn/fakeprom/klgraph_init.c - 1.2 linux/arch/ia64/sn/fakeprom/main.c - 1.2 linux/arch/ia64/sn/io/sn1/pcibr.c - 1.4 linux/fs/libfs.c - 1.11 linux/lib/radix-tree.c - 1.9 linux/drivers/net/sun3_82586.c - 1.3 linux/drivers/usb/image/microtek.c - 1.7 linux/drivers/usb/class/audio.c - 1.11 linux/drivers/usb/class/bluetty.c - 1.13 linux/drivers/usb/class/cdc-acm.c - 1.12 linux/drivers/usb/core/devio.c - 1.14 linux/drivers/usb/core/hcd.c - 1.15 linux/drivers/usb/core/hcd.h - 1.11 linux/drivers/usb/core/hub.c - 1.17 linux/drivers/usb/core/inode.c - 1.12 linux/drivers/usb/core/usb-debug.c - 1.4 linux/drivers/usb/input/hid-core.c - 1.12 linux/drivers/usb/core/usb.c - 1.24 linux/drivers/usb/media/konicawc.c - 1.9 linux/drivers/usb/host/ehci-dbg.c - 1.9 linux/drivers/usb/media/pwc-ioctl.h - 1.3 linux/drivers/usb/host/ehci-hcd.c - 1.14 linux/drivers/usb/host/ehci-hub.c - 1.7 linux/drivers/usb/host/ehci-mem.c - 1.5 linux/drivers/usb/host/ehci-q.c - 1.14 linux/drivers/usb/host/ehci-sched.c - 1.12 linux/drivers/usb/host/ehci.h - 1.7 linux/drivers/usb/host/ohci-dbg.c - 1.10 linux/drivers/usb/host/ohci-hcd.c - 1.15 linux/drivers/usb/host/ohci-hub.c - 1.6 linux/drivers/usb/host/ohci-q.c - 1.17 linux/drivers/usb/media/stv680.c - 1.10 linux/drivers/usb/media/stv680.h - 1.3 linux/drivers/usb/media/usbvideo.c - 1.11 linux/drivers/usb/image/hpusbscsi.c - 1.9 linux/arch/i386/kernel/bootflag.c - 1.2 linux/drivers/usb/image/mdc800.c - 1.10 linux/drivers/usb/image/scanner.c - 1.14 linux/drivers/usb/image/scanner.h - 1.9 linux/drivers/usb/input/hid-input.c - 1.6 linux/drivers/usb/input/hid.h - 1.6 linux/drivers/usb/input/usbkbd.c - 1.8 linux/drivers/usb/input/usbmouse.c - 1.7 linux/drivers/usb/input/wacom.c - 1.9 linux/drivers/usb/media/dabusb.c - 1.12 linux/drivers/usb/media/dsbr100.c - 1.6 linux/drivers/usb/media/ibmcam.c - 1.7 linux/drivers/usb/media/ov511.c - 1.10 linux/drivers/usb/media/pwc-ctrl.c - 1.4 linux/drivers/usb/media/pwc-if.c - 1.8 linux/drivers/usb/media/pwc-uncompress.h - 1.3 linux/drivers/usb/media/pwc.h - 1.4 linux/drivers/usb/media/se401.c - 1.12 linux/drivers/usb/net/usbnet.c - 1.15 linux/drivers/usb/net/rtl8150.c - 1.11 linux/drivers/usb/media/ultracam.c - 1.7 linux/drivers/usb/media/usbvideo.h - 1.7 linux/drivers/usb/net/pegasus.c - 1.11 linux/drivers/usb/media/vicam.c - 1.9 linux/drivers/usb/net/kaweth.c - 1.12 linux/drivers/usb/net/cdc-ether.c - 1.10 linux/drivers/usb/net/catc.c - 1.7 linux/include/linux/percpu.h - 1.4 linux/drivers/usb/misc/uss720.c - 1.5 linux/drivers/usb/misc/auerswald.c - 1.11 linux/drivers/usb/misc/rio500.c - 1.6 linux/drivers/usb/misc/tiglusb.c - 1.11 linux/arch/x86_64/ia32/fpu32.c - 1.2 linux/include/asm-ia64/acpi.h - 1.6 linux/arch/x86_64/kernel/bootflag.c - 1.3 linux/arch/ia64/hp/zx1/hpzx1_misc.c - 1.7 linux/arch/x86_64/mm/modutil.c - 1.3 linux/arch/ia64/hp/sim/simscsi.h - 1.5 linux/arch/ia64/hp/sim/simscsi.c - 1.7 linux/include/asm-ia64/tlbflush.h - 1.3 linux/drivers/usb/misc/brlvger.c - 1.10 linux/drivers/isdn/capi/capi.c - 1.8 linux/drivers/isdn/capi/kcapi.c - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.4 linux/sound/pci/rme32.c - 1.8 linux/sound/arm/sa11xx-uda1341.c - 1.8 linux/drivers/usb/host/uhci-debug.c - 1.4 linux/drivers/usb/host/uhci-hcd.c - 1.15 linux/drivers/pci/probe.c - 1.10 linux/include/linux/buffer_head.h - 1.16 linux/drivers/video/cfbcopyarea.c - 1.5 linux/drivers/usb/host/hc_sl811_rh.c - 1.5 linux/drivers/video/cfbfillrect.c - 1.4 linux/drivers/video/cfbimgblt.c - 1.5 linux/include/linux/suspend.h - 1.8 linux/drivers/char/hvc_console.c - 1.7 linux/drivers/acpi/ac.c - 1.7 linux/drivers/usb/core/config.c - 1.4 linux/drivers/acpi/battery.c - 1.8 linux/drivers/acpi/fan.c - 1.6 linux/drivers/acpi/button.c - 1.7 linux/drivers/acpi/thermal.c - 1.9 linux/drivers/acpi/processor.c - 1.12 linux/drivers/acpi/osl.c - 1.10 linux/drivers/usb/host/ohci-sa1111.c - 1.10 linux/drivers/usb/class/usb-midi.c - 1.8 linux/drivers/usb/core/hcd-pci.c - 1.7 linux/arch/i386/kernel/cpu/proc.c - 1.5 linux/arch/i386/kernel/cpu/intel.c - 1.11 linux/drivers/s390/block/dasd_ioctl.c - 1.8 linux/arch/i386/kernel/cpu/common.c - 1.10 linux/drivers/usb/input/aiptek.c - 1.9 linux/arch/x86_64/lib/io.c - 1.2 linux/arch/x86_64/pci/irq.c - 1.3 linux/arch/x86_64/pci/common.c - 1.4 linux/include/asm-x86_64/suspend.h - 1.2 linux/arch/x86_64/ia32/ipc32.c - 1.4 linux/arch/i386/mm/pageattr.c - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_reg.h_shipped - 1.2 linux/sound/pci/rme9652/hdsp.c - 1.7 linux/drivers/scsi/aic7xxx/aic7xxx_seq.h_shipped - 1.2 linux/drivers/message/fusion/mptctl.h - 1.4 linux/sound/pci/rme9652/hammerfall_mem.c - 1.6 linux/drivers/input/mouse/amimouse.c - 1.5 linux/drivers/input/keyboard/amikbd.c - 1.6 linux/drivers/input/joystick/iforce/iforce-usb.c - 1.6 linux/drivers/acpi/tables/tbrsdt.c - 1.6 linux/drivers/acpi/tables/tbgetall.c - 1.5 linux/drivers/acpi/include/amlresrc.h - 1.4 linux/drivers/input/serio/q40kbd.c - 1.4 linux/drivers/usb/input/pid.c - 1.3 linux/drivers/usb/input/powermate.c - 1.8 linux/drivers/usb/input/xpad.c - 1.7 linux/security/security.c - 1.5 linux/security/dummy.c - 1.6 linux/drivers/usb/serial/io_ti.c - 1.7 linux/drivers/serial/core.c - 1.7 linux/drivers/char/agp/ali-agp.c - 1.3 linux/drivers/char/agp/sis-agp.c - 1.3 linux/drivers/char/agp/frontend.c - 1.3 linux/drivers/char/agp/hp-agp.c - 1.3 linux/drivers/char/agp/i460-agp.c - 1.3 linux/drivers/acpi/namespace/nsxfeval.c - 1.5 linux/drivers/acpi/namespace/nsdumpdv.c - 1.4 linux/drivers/serial/8250_pnp.c - 1.4 linux/drivers/char/agp/sworks-agp.c - 1.3 linux/drivers/char/agp/via-agp.c - 1.3 linux/include/asm-m68k/thread_info.h - 1.3 linux/drivers/serial/sunsu.c - 1.7 linux/drivers/usb/core/buffer.c - 1.4 linux/drivers/usb/misc/speedtouch.c - 1.6 linux/drivers/usb/class/usblp.c - 1.5 linux/drivers/usb/misc/usblcd.c - 1.4 linux/arch/i386/kernel/cpu/mtrr/generic.c - 1.4 linux/arch/alpha/vmlinux.lds.S - 1.5 linux/drivers/i2c/i2c-rpx.c - 1.3 linux/drivers/i2c/i2c-frodo.c - 1.3 linux/drivers/i2c/i2c-algo-ibm_ocp.h - 1.2 linux/drivers/i2c/i2c-algo-ibm_ocp.c - 1.2 linux/net/ipv4/netfilter/ipt_ECN.c - 1.2 linux/arch/i386/kernel/cpu/mtrr/amd.c - 1.2 linux/arch/i386/kernel/cpu/mtrr/centaur.c - 1.2 linux/arch/i386/kernel/cpu/mtrr/cyrix.c - 1.3 linux/arch/i386/kernel/cpu/mtrr/if.c - 1.2 linux/arch/i386/kernel/cpu/mtrr/main.c - 1.3 linux/arch/i386/kernel/cpu/mtrr/mtrr.h - 1.4 linux/include/asm-generic/rtc.h - 1.2 linux/net/sctp/sysctl.c - 1.2 linux/net/sctp/ulpevent.c - 1.3 linux/net/sctp/protocol.c - 1.10 linux/include/net/sctp/sctp.h - 1.7 linux/net/sctp/associola.c - 1.7 linux/net/sctp/bind_addr.c - 1.6 linux/net/sctp/input.c - 1.7 linux/net/sctp/ipv6.c - 1.7 linux/include/net/sctp/sm.h - 1.7 linux/net/sctp/sm_make_chunk.c - 1.8 linux/net/sctp/sm_sideeffect.c - 1.9 linux/net/sctp/sm_statefuns.c - 1.8 linux/include/net/sctp/structs.h - 1.8 linux/net/sctp/sm_statetable.c - 1.6 linux/net/sctp/socket.c - 1.9 linux/net/sctp/transport.c - 1.5 linux/arch/um/os-Linux/tty.c - 1.2 linux/arch/um/ptproxy/Makefile - 1.5 linux/drivers/ide/pci/pdc202xx_old.h - 1.5 linux/include/asm-um/uaccess.h - 1.2 linux/include/asm-um/thread_info.h - 1.3 linux/include/asm-um/system-generic.h - 1.3 linux/drivers/ide/legacy/falconide.c - 1.2 linux/include/asm-um/a.out.h - 1.2 linux/arch/um/Makefile - 1.8 linux/arch/um/Makefile-i386 - 1.4 linux/arch/um/boot/Makefile - 1.2 linux/arch/um/config_block.in - 1.2 linux/arch/um/config_char.in - 1.2 linux/arch/um/config_net.in - 1.3 linux/arch/um/config_scsi.in - 1.2 linux/arch/um/drivers/Makefile - 1.5 linux/arch/um/drivers/chan_kern.c - 1.3 linux/arch/um/drivers/chan_user.c - 1.3 linux/arch/um/drivers/fd.c - 1.2 linux/arch/um/drivers/line.c - 1.4 linux/arch/um/drivers/mcast_kern.c - 1.3 linux/arch/um/drivers/mconsole_kern.c - 1.5 linux/arch/um/drivers/net_kern.c - 1.4 linux/arch/um/drivers/null.c - 1.2 linux/arch/um/drivers/port_kern.c - 1.5 linux/arch/um/drivers/port_user.c - 1.3 linux/arch/um/drivers/pty.c - 1.2 linux/arch/um/drivers/slip.h - 1.3 linux/arch/um/drivers/slip_kern.c - 1.3 linux/arch/um/drivers/slip_user.c - 1.2 linux/arch/um/drivers/ssl.c - 1.4 linux/arch/um/drivers/stdio_console.c - 1.4 linux/arch/um/drivers/tty.c - 1.2 linux/arch/um/drivers/ubd_kern.c - 1.8 linux/arch/um/drivers/ubd_user.c - 1.3 linux/arch/um/drivers/xterm.c - 1.4 linux/arch/um/include/chan_kern.h - 1.3 linux/arch/um/include/chan_user.h - 1.3 linux/arch/um/include/debug.h - 1.2 linux/arch/um/include/frame.h - 1.2 linux/arch/um/include/kern.h - 1.3 linux/arch/um/include/kern_util.h - 1.4 linux/arch/um/include/line.h - 1.4 linux/arch/um/include/mconsole_kern.h - 1.2 linux/arch/um/include/mem.h - 1.2 linux/arch/um/include/mem_user.h - 1.3 linux/arch/um/include/net_kern.h - 1.3 linux/arch/um/include/net_user.h - 1.3 linux/arch/um/include/os.h - 1.2 linux/arch/um/include/sigcontext.h - 1.2 linux/arch/um/include/syscall_user.h - 1.2 linux/arch/um/include/sysdep-i386/frame_kern.h - 1.2 linux/arch/um/include/sysdep-i386/ptrace.h - 1.2 linux/arch/um/include/sysdep-i386/sigcontext.h - 1.2 linux/arch/um/include/user_util.h - 1.5 linux/arch/um/kernel/Makefile - 1.7 linux/arch/um/kernel/exec_kern.c - 1.3 linux/arch/um/kernel/exec_user.c - 1.2 linux/arch/um/kernel/exitcode.c - 1.3 linux/arch/um/kernel/frame.c - 1.3 linux/arch/um/kernel/frame_kern.c - 1.2 linux/arch/um/kernel/helper.c - 1.3 linux/arch/um/kernel/init_task.c - 1.2 linux/arch/um/kernel/irq.c - 1.4 linux/arch/um/kernel/irq_user.c - 1.5 linux/arch/um/kernel/ksyms.c - 1.4 linux/arch/um/kernel/mem.c - 1.5 linux/arch/um/kernel/mem_user.c - 1.4 linux/arch/um/kernel/process.c - 1.4 linux/arch/um/kernel/process_kern.c - 1.6 linux/arch/um/kernel/ptrace.c - 1.3 linux/arch/um/kernel/reboot.c - 1.4 linux/arch/um/kernel/setup.c - 1.2 linux/arch/um/kernel/sigio_user.c - 1.3 linux/arch/um/kernel/signal_kern.c - 1.3 linux/arch/um/kernel/signal_user.c - 1.4 linux/arch/um/kernel/smp.c - 1.4 linux/arch/um/kernel/sys_call_table.c - 1.4 linux/arch/um/kernel/syscall_kern.c - 1.3 linux/arch/um/kernel/syscall_user.c - 1.3 linux/arch/um/kernel/sysrq.c - 1.3 linux/arch/um/kernel/time.c - 1.4 linux/arch/um/kernel/time_kern.c - 1.4 linux/arch/um/kernel/tlb.c - 1.4 linux/arch/um/kernel/trap_kern.c - 1.4 linux/arch/um/kernel/trap_user.c - 1.4 linux/arch/um/kernel/tty_log.c - 1.3 linux/arch/um/kernel/uaccess_user.c - 1.2 linux/arch/um/kernel/um_arch.c - 1.4 linux/arch/um/kernel/umid.c - 1.3 linux/arch/um/main.c - 1.3 linux/arch/um/os-Linux/Makefile - 1.4 linux/arch/um/os-Linux/drivers/Makefile - 1.4 linux/arch/um/os-Linux/file.c - 1.4 linux/arch/um/os-Linux/process.c - 1.2 linux/arch/um/sys-i386/ksyms.c - 1.2 linux/arch/um/ptproxy/proxy.c - 1.3 linux/arch/um/ptproxy/ptproxy.h - 1.2 linux/arch/um/ptproxy/ptrace.c - 1.2 linux/arch/um/ptproxy/sysdep.c - 1.2 linux/arch/um/ptproxy/sysdep.h - 1.2 linux/arch/um/ptproxy/wait.c - 1.2 linux/arch/um/ptproxy/wait.h - 1.2 linux/arch/um/sys-i386/Makefile - 1.5 linux/include/asm-um/pgtable.h - 1.4 linux/arch/um/sys-i386/ldt.c - 1.2 linux/arch/um/sys-i386/ptrace.c - 1.2 linux/arch/um/sys-i386/ptrace_user.c - 1.3 linux/arch/um/sys-i386/sigcontext.c - 1.2 linux/arch/um/sys-i386/util/mk_thread_kern.c - 1.2 linux/arch/um/sys-i386/util/mk_thread_user.c - 1.2 linux/arch/um/util/Makefile - 1.5 linux/include/asm-um/ptrace-generic.h - 1.2 linux/include/asm-um/processor-generic.h - 1.3 linux/include/asm-um/page.h - 1.3 linux/include/asm-um/checksum.h - 1.2 linux/include/asm-um/mmu_context.h - 1.2 linux/include/asm-um/mmu.h - 1.2 linux/arch/m68k/vmlinux-std.lds - 1.3 linux/arch/x86_64/vmlinux.lds.S - 1.4 linux/arch/sparc/vmlinux.lds.S - 1.6 linux/arch/i386/mm/hugetlbpage.c - 1.7 linux/arch/i386/mach-visws/smpboot_hooks.h - 1.2 linux/arch/i386/mach-visws/irq_vectors.h - 1.3 linux/drivers/acpi/sleep.c - 1.4 linux/arch/i386/mach-generic/Makefile - 1.5 linux/arch/i386/mach-generic/do_timer.h - 1.4 linux/arch/i386/mach-generic/entry_arch.h - 1.2 linux/arch/i386/mach-generic/irq_vectors.h - 1.3 linux/arch/i386/mach-generic/setup.c - 1.2 linux/arch/i386/mach-generic/setup_arch_post.h - 1.2 linux/arch/i386/mach-generic/setup_arch_pre.h - 1.2 linux/arch/i386/mach-generic/smpboot_hooks.h - 1.2 linux/arch/i386/mach-visws/do_timer.h - 1.3 linux/arch/i386/mach-visws/entry_arch.h - 1.2 linux/arch/i386/mach-visws/setup_arch_post.h - 1.2 linux/arch/i386/mach-visws/setup_arch_pre.h - 1.2 linux/mm/madvise.c - 1.4 linux/arch/ia64/pci/pci.c - 1.3 linux/arch/ia64/mm/hugetlbpage.c - 1.3 linux/arch/ia64/pci/Makefile - 1.3 linux/drivers/char/drm/radeon_irq.c - 1.4 linux/sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.4 linux/sound/pci/cs46xx/dsp_spos.h - 1.4 linux/sound/pci/cs46xx/dsp_spos.c - 1.4 linux/sound/pci/cs46xx/cs46xx_lib.h - 1.4 linux/sound/pci/ac97/ac97_patch.h - 1.4 linux/sound/pci/ac97/ac97_patch.c - 1.4 linux/sound/pci/ac97/ac97_id.h - 1.4 linux/sound/core/pcm_sgbuf.c - 1.4 linux/kernel/cpufreq.c - 1.5 linux/include/sound/cs46xx_dsp_spos.h - 1.4 linux/arch/um/uml.lds.S - 1.4 linux/include/linux/cpufreq.h - 1.5 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.3 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.4 linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.3 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.4 linux/sound/usb/usbquirks.h - 1.4 linux/sound/usb/usbmixer.c - 1.3 linux/sound/usb/usbmidi.c - 1.5 linux/sound/usb/usbaudio.h - 1.4 linux/sound/usb/usbaudio.c - 1.6 linux/sound/pci/via82xx.c - 1.4 linux/sound/pci/ice1712/ice1712.h - 1.4 linux/sound/pci/ice1712/ice1712.c - 1.4 linux/sound/pci/ice1712/hoontech.h - 1.2 linux/sound/pci/ice1712/hoontech.c - 1.2 linux/sound/pci/ice1712/ews.c - 1.4 linux/sound/pci/ice1712/delta.c - 1.4 linux/sound/pci/ice1712/ak4524.c - 1.4 linux/sound/pci/ice1712/Makefile - 1.3 linux/drivers/usb/misc/usbtest.c - 1.7 linux/drivers/i2c/scx200_acb.c - 1.3 linux/drivers/i2c/scx200_i2c.c - 1.2 linux/fs/cifs/cifsfs.c - 1.4 linux/fs/nfsd/nfs4xdr.c - 1.5 linux/fs/cifs/cifsproto.h - 1.4 linux/fs/cifs/cifssmb.c - 1.5 linux/fs/cifs/netmisc.c - 1.4 linux/arch/i386/kernel/timers/Makefile - 1.3 linux/arch/i386/kernel/timers/timer.c - 1.2 linux/arch/i386/kernel/timers/timer_pit.c - 1.3 linux/arch/i386/kernel/timers/timer_tsc.c - 1.5 linux/drivers/isdn/hardware/eicon/i4lididrv.c - 1.3 linux/include/linux/nfs4.h - 1.3 linux/arch/um/include/time_user.h - 1.3 linux/include/linux/sunrpc/cache.h - 1.3 linux/sound/usb/usbmixer_maps.c - 1.2 linux/fs/nfs/nfs4xdr.c - 1.4 linux/drivers/mtd/maps/pcmciamtd.c - 1.2 linux/drivers/oprofile/buffer_sync.c - 1.5 linux/drivers/oprofile/cpu_buffer.c - 1.3 linux/drivers/oprofile/event_buffer.c - 1.2 linux/drivers/oprofile/event_buffer.h - 1.2 linux/drivers/oprofile/oprof.c - 1.2 linux/drivers/oprofile/oprof.h - 1.2 linux/drivers/oprofile/oprofile_files.c - 1.2 linux/drivers/oprofile/oprofilefs.c - 1.2 linux/net/rxrpc/krxsecd.c - 1.3 linux/net/rxrpc/call.c - 1.3 linux/arch/i386/mach-summit/mach_apic.h - 1.2 linux/fs/afs/file.c - 1.3 linux/include/asm-x86_64/proto.h - 1.4 linux/arch/i386/mach-generic/mach_apic.h - 1.2 linux/include/linux/oprofile.h - 1.2 linux/arch/i386/oprofile/init.c - 1.2 linux/arch/i386/oprofile/nmi_int.c - 1.4 linux/arch/i386/oprofile/op_model_athlon.c - 1.3 linux/arch/i386/oprofile/op_model_ppro.c - 1.3 linux/arch/i386/oprofile/timer_int.c - 1.2 linux/arch/um/kernel/tempfile.c - 1.2 linux/arch/x86_64/kernel/pci-gart.c - 1.3 linux/fs/nfs/nfs4proc.c - 1.4 linux/arch/x86_64/kernel/acpi.c - 1.3 linux/drivers/pnp/pnpbios/core.c - 1.4 linux/scripts/Makefile.clean - 1.3 linux/drivers/pnp/resource.c - 1.4 linux/arch/x86_64/kernel/profile.c - 1.2 linux/drivers/pnp/core.c - 1.4 linux/drivers/pnp/driver.c - 1.4 linux/drivers/pnp/isapnp/proc.c - 1.3 linux/drivers/pnp/isapnp/core.c - 1.4 linux/drivers/pnp/isapnp/Makefile - 1.4 linux/drivers/pnp/interface.c - 1.3 linux/include/linux/pnp.h - 1.4 linux/drivers/pnp/idlist.h - 1.2 linux/drivers/media/dvb/av7110/av7110.c - 1.3 linux/drivers/net/Kconfig - 1.5 linux/security/Kconfig - 1.3 linux/drivers/md/dm-linear.c - 1.3 linux/arch/i386/Kconfig - 1.6 linux/sound/usb/Kconfig - 1.2 linux/arch/i386/mach-voyager/do_timer.h - 1.2 linux/arch/i386/mach-voyager/entry_arch.h - 1.2 linux/arch/i386/mach-voyager/irq_vectors.h - 1.2 linux/arch/i386/mach-voyager/setup.c - 1.2 linux/arch/i386/mach-voyager/setup_arch_post.h - 1.2 linux/arch/i386/mach-voyager/setup_arch_pre.h - 1.2 linux/arch/i386/mach-voyager/voyager_basic.c - 1.2 linux/arch/i386/mach-voyager/voyager_smp.c - 1.2 linux/include/linux/dm-ioctl.h - 1.2 linux/include/linux/device-mapper.h - 1.2 linux/arch/ia64/Kconfig - 1.4 linux/scripts/kconfig/Makefile - 1.4 linux/scripts/Makefile.lib - 1.3 linux/drivers/media/dvb/dvb-core/dvb_i2c.c - 1.3 linux/scripts/Makefile.build - 1.4 linux/arch/m68k/Kconfig - 1.5 linux/include/asm-ia64/numa.h - 1.3 linux/include/asm-ia64/mmzone.h - 1.2 linux/include/asm-i386/voyager.h - 1.2 linux/drivers/pnp/isapnp/compat.c - 1.2 linux/arch/parisc/kernel/smp.c - 1.2 linux/arch/parisc/kernel/sys_parisc32.c - 1.4 linux/drivers/md/dm.h - 1.3 linux/drivers/md/dm.c - 1.3 linux/drivers/md/dm-target.c - 1.2 linux/drivers/md/dm-table.c - 1.3 linux/drivers/md/dm-stripe.c - 1.3 linux/drivers/md/dm-ioctl.c - 1.3 linux/drivers/scsi/Kconfig - 1.4 linux/drivers/scsi/aic7xxx/Kconfig - 1.2 linux/drivers/char/agp/Kconfig - 1.3 linux/arch/s390x/Kconfig - 1.5 linux/drivers/i2c/Kconfig - 1.2 linux/arch/um/Kconfig - 1.3 linux/arch/um/Kconfig_block - 1.2 linux/arch/um/Kconfig_char - 1.2 linux/arch/um/Kconfig_net - 1.2 linux/fs/befs/linuxvfs.c - 1.3 linux/arch/x86_64/Kconfig - 1.5 linux/fs/befs/btree.c - 1.2 linux/sound/pci/Kconfig - 1.2 linux/crypto/api.c - 1.4 linux/crypto/des.c - 1.3 linux/crypto/sha1.c - 1.3 linux/net/ipv4/xfrm_policy.c - 1.4 linux/drivers/video/Kconfig - 1.4 linux/drivers/usb/serial/Kconfig - 1.3 linux/sound/oss/Kconfig - 1.3 linux/fs/hugetlbfs/inode.c - 1.4 linux/drivers/scsi/sun3_scsi_vme.c - 1.2 linux/drivers/net/mac8390.c - 1.3 linux/include/asm-v850/unistd.h - 1.3 linux/include/asm-v850/uaccess.h - 1.2 linux/include/asm-v850/types.h - 1.2 linux/include/asm-v850/thread_info.h - 1.2 linux/arch/i386/mach-generic/topology.c - 1.3 linux/drivers/media/video/saa7134/saa7134-i2c.c - 1.3 linux/include/asm-m68knommu/types.h - 1.2 linux/arch/v850/vmlinux.lds.S - 1.3 linux/arch/v850/sim85e2c.ld - 1.3 linux/arch/v850/sim.ld - 1.3 linux/arch/v850/rte_ma1_cb.ld - 1.3 linux/arch/v850/rte_ma1_cb-rom.ld - 1.3 linux/arch/v850/rte_ma1_cb-ksram.ld - 1.3 linux/arch/v850/kernel/time.c - 1.2 linux/arch/v850/kernel/syscalls.c - 1.2 linux/arch/v850/kernel/signal.c - 1.3 linux/arch/v850/kernel/setup.c - 1.3 linux/arch/v850/kernel/semaphore.c - 1.2 linux/include/asm-v850/processor.h - 1.3 linux/include/asm-v850/mmu_context.h - 1.2 linux/arch/v850/kernel/irq.c - 1.3 linux/include/asm-v850/elf.h - 1.3 linux/include/asm-v850/current.h - 1.2 linux/arch/v850/kernel/entry.S - 1.3 linux/arch/v850/fpga85e2c.ld - 1.2 linux/arch/v850/anna.ld - 1.3 linux/arch/v850/anna-rom.ld - 1.3 linux/drivers/net/irda/sir_dev.c - 1.2 linux/drivers/net/irda/sir_dongle.c - 1.2 linux/drivers/serial/68360serial.c - 1.3 linux/crypto/blowfish.c - 1.2 linux/arch/ppc/syslib/todc_time.c - 1.2 linux/arch/i386/kernel/cpu/mcheck/k7.c - 1.2 linux/arch/i386/kernel/cpu/mcheck/p4.c - 1.2 linux/net/key/af_key.c - 1.3 linux/net/core/pktgen.c - 1.2 linux/security/root_plug.c - 1.2 linux/arch/i386/kernel/suspend_asm.S - 1.2 linux/scripts/kallsyms.c - 1.2 linux/drivers/pnp/card.c - 1.2 linux/drivers/acpi/namespace/nsparse.c - 1.2 linux/Documentation/scsi/aic7xxx.txt - 1.2 linux/drivers/usb/serial/bus.c - 1.2 linux/arch/sparc64/kernel/module.c - 1.2 linux/include/asm-sparc64/compat.h - 1.2 linux/drivers/usb/serial/ezusb.c - 1.2 linux/drivers/usb/serial/generic.c - 1.2 linux/drivers/usb/serial/kobil_sct.c - 1.2 linux/drivers/video/console/Kconfig - 1.2 linux/drivers/video/console/Makefile - 1.2 linux/drivers/video/console/dummycon.c - 1.2 linux/drivers/s390/char/tape_core.c - 1.2 linux/drivers/video/console/fbcon-sti.c - 1.2 linux/drivers/video/console/fbcon.c - 1.2 linux/drivers/video/console/fbcon.h - 1.2 linux/drivers/video/console/font.h - 1.2 linux/drivers/video/console/font_6x11.c - 1.2 linux/drivers/video/console/font_8x16.c - 1.2 linux/drivers/video/console/font_8x8.c - 1.2 linux/drivers/video/console/font_acorn_8x8.c - 1.2 linux/drivers/char/drm/r128_irq.c - 1.2 linux/drivers/video/console/font_mini_4x6.c - 1.2 linux/drivers/char/drm/mga_irq.c - 1.2 linux/drivers/video/console/font_pearl_8x8.c - 1.2 linux/drivers/video/console/font_sun12x22.c - 1.2 linux/drivers/video/console/font_sun8x16.c - 1.2 linux/drivers/video/console/fonts.c - 1.2 linux/drivers/video/console/mdacon.c - 1.2 linux/drivers/video/console/newport_con.c - 1.2 linux/drivers/video/console/promcon.c - 1.2 linux/drivers/video/console/sti.h - 1.2 linux/drivers/video/console/sticon.c - 1.2 linux/drivers/video/console/sticore.c - 1.2 linux/drivers/acpi/events/evgpe.c - 1.2 linux/drivers/acpi/dispatcher/dsinit.c - 1.2 linux/drivers/char/agp/amd-k7-agp.c - 1.2 linux/drivers/char/agp/amd-k8-agp.c - 1.2 linux/drivers/char/agp/backend.c - 1.2 linux/drivers/char/agp/generic.c - 1.2 linux/arch/arm/kernel/module.c - 1.2 linux/drivers/video/sticore.h - 1.2 linux/drivers/video/vgastate.c - 1.2 linux/include/linux/moduleloader.h - 1.2 linux/arch/v850/kernel/module.c - 1.2 linux/drivers/char/agp/intel-agp.c - 1.2 linux/include/linux/moduleparam.h - 1.2 linux/arch/s390x/kernel/module.c - 1.2 linux/arch/s390/kernel/module.c - 1.2 linux/arch/ppc/kernel/module.c - 1.2 linux/drivers/ide/ide-io.c - 1.2 linux/arch/um/drivers/xterm_kern.c - 1.2 linux/kernel/params.c - 1.2 linux/arch/i386/kernel/module.c - 1.2 linux/kernel/intermodule.c - 1.2 linux/arch/sparc/kernel/module.c - 1.2 linux/include/video/radeon.h - 1.2 linux/arch/v850/as85ep1.ld - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jan 13 17:30:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 17:30:45 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E1U03v010346 for ; Mon, 13 Jan 2003 17:30:00 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h0DNa6G8028178 for ; Mon, 13 Jan 2003 15:36:07 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04352; Tue, 14 Jan 2003 12:34:42 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 816E6300087; Tue, 14 Jan 2003 12:34:40 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id E49F885; Tue, 14 Jan 2003 12:34:40 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: Announce: XFS split patches for 2.4.20 - respin Date: Tue, 14 Jan 2003 12:34:35 +1100 Message-ID: <11444.1042508075@kao2.melbourne.sgi.com> X-archive-position: 2297 X-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: 968 Lines: 28 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20. The xfs patches for 2.4.20 have been respun as of 2003-01-14 00:43 UTC. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, xattr, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.21/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE+I2kpi4UHNye0ZOoRAsK3AJ4meW2ZYuWbkqp2SYSLA0PMTVAyrwCfQ9bQ 7YeCH8NEeJ58WUEbQliF8Xg= =JF0Z -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Jan 13 18:51:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Jan 2003 18:51:43 -0800 (PST) Received: from bob.samurai.com (bob.samurai.com [205.207.28.75]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0E2pY3v012930 for ; Mon, 13 Jan 2003 18:51:35 -0800 Received: from DU150.N224.ResNet.QueensU.CA (DU150.N224.ResNet.QueensU.CA [130.15.224.150]) by bob.samurai.com (Postfix) with ESMTP id 55D9D1D5C for ; Mon, 13 Jan 2003 21:57:32 -0500 (EST) Subject: 2.5.56: dinode corruption From: Neil Conway To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-HL+EiGc1e2r6OVezLKs1" Organization: Message-Id: <1042513050.393.11.camel@tokyo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 13 Jan 2003 21:57:30 -0500 X-archive-position: 2298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: neilc@samurai.com Precedence: bulk X-list: linux-xfs Content-Length: 16479 Lines: 305 --=-HL+EiGc1e2r6OVezLKs1 Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks, I recently tried to test out Linux 2.5.56 on a personal workstation of mine, that had been previously running 2.4 with XFS (and without any problems). After booting into 2.5.56 (using the version of XFS it contains), I recompiled the kernel again (having realized I forget to make a few configuration changes), reran lilo, and rebooted. As the system was shutting down, I saw this message many times: Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. I rebooted the system into 2.4, and I saw similar messages during the init process. I got an XFS rescue disk, ran xfs_repair on the root partition, and it seemed to be repair the data. I didn't save the output of xfs_repair, except for noting that the nblocks & nextents for the dinode above (171966634) were incorrect. Also, a few files modified during the shutdown process (syslogd.pid, klogd.pid, etc.) had some corruption. If you need any more information, just let me know. I've attached a copy of dmesg (the one produced after rebooting the system into 2.4 after the corruption). Cheers, Neil -- Neil Conway || PGP Key ID: DB3C29FC --=-HL+EiGc1e2r6OVezLKs1 Content-Disposition: attachment; filename=dmesg.txt Content-Type: text/plain; name=dmesg.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 7bit Linux version 2.5.56 (root@tokyo) (gcc version 3.2.2 20030109 (Debian prerelease)) #4 Mon Jan 13 16:24:35 EST 2003 Video mode to be used for restore is ffff BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000002ffeb000 (usable) BIOS-e820: 000000002ffeb000 - 000000002ffef000 (ACPI data) BIOS-e820: 000000002ffef000 - 000000002ffff000 (reserved) BIOS-e820: 000000002ffff000 - 0000000030000000 (ACPI NVS) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 767MB LOWMEM available. On node 0 totalpages: 196587 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 192491 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 ACPI: RSDP (v000 ASUS ) @ 0x000f6650 ACPI: RSDT (v001 ASUS P4T 12336.12337) @ 0x2ffeb000 ACPI: FADT (v001 ASUS P4T 12336.12337) @ 0x2ffeb080 ACPI: BOOT (v001 ASUS P4T 12336.12337) @ 0x2ffeb040 ACPI: DSDT (v001 ASUS P4T 00000.04096) @ 0x00000000 ACPI: BIOS passes blacklist Building zonelist for node : 0 Kernel command line: BOOT_IMAGE=Linux ro root=343 Initializing CPU#0 PID hash table entries: 4096 (order 12: 32768 bytes) Detected 1807.635 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 3571.71 BogoMIPS Memory: 774512k/786348k available (2206k kernel code, 11064k reserved, 520k data, 304k init, 0k highmem) Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) -> /dev -> /dev/console -> /root CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 256K CPU: After generic, caps: 3febf9ff 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU#0: Intel P4/Xeon Extended MCE MSRs (12) available Machine check exception polling timer started. CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket mtrr: v2.0 (20020519) device class 'cpu': registering device class cpu: adding driver system:cpu PCI: PCI BIOS revision 2.10 entry at 0xf0ea0, last bus=2 PCI: Using configuration type 1 device class cpu: adding device CPU 0 interfaces: adding device CPU 0 BIO: pool of 256 setup, 14Kb (56 bytes/bio) biovec pool[0]: 1 bvecs: 256 entries (12 bytes) biovec pool[1]: 4 bvecs: 256 entries (48 bytes) biovec pool[2]: 16 bvecs: 256 entries (192 bytes) biovec pool[3]: 64 bvecs: 256 entries (768 bytes) biovec pool[4]: 128 bvecs: 256 entries (1536 bytes) biovec pool[5]: 256 bvecs: 256 entries (3072 bytes) ACPI: Subsystem revision 20030109 tbxface-0098 [03] acpi_load_tables : ACPI Tables successfully acquired Parsing all Control Methods:................................................................................................................................... Table [DSDT] - 416 Objects with 43 Devices 131 Methods 23 Regions ACPI Namespace successfully loaded at root c0403afc evxfevnt-0073 [04] acpi_enable : Transition to ACPI mode successful evgpe-0262: *** Info: GPE Block0 defined as GPE0 to GPE15 evgpe-0262: *** Info: GPE Block1 defined as GPE16 to GPE31 Executing all Device _STA and_INI methods:.................................... uteval-0090: *** Error: No object was returned from [\_SB_.PCI0.PX40.UAR2._STA] (Node c17d5e28), AE_NOT_EXIST ....... 43 Devices found containing: 42 _STA, 0 _INI methods Completing Region/Field/Buffer/Package initialization:............................................................ Initialized 20/23 Regions 4/4 Fields 22/22 Buffers 14/14 Packages (416 nodes) ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) Transparent bridge - Intel Corp. 82801BA/CA/DB PCI Br ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT] block request queues: 128 requests per read queue 128 requests per write queue 8 requests per batch enter congestion at 31 exit congestion at 33 drivers/usb/core/usb.c: registered new driver hub ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5 ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11 ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 10 ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 5 PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' SBF: Simple Boot Flag extension found and enabled. SBF: Setting boot flags 0x1 Enabling SEP on CPU 0 Total HugeTLB memory allocated, 0 aio_setup: sizeof(struct page) = 40 NTFS driver 2.1.0 [Flags: R/O]. SGI XFS for Linux 2.5.56 with no debug enabled ACPI: Power Button (FF) [PWRF] acpi_processor-2385 [06] acpi_processor_get_inf: Invalid PBLK length [5] ACPI: Processor [CPU0] (supports C1) Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A parport0: PC-style at 0x378 [PCSPP] parport0: cpp_daisy: aa5500ff(18) parport0: assign_addrs: aa5500ff(18) parport0: Printer, EPSON Stylus C60 device class 'tty': registering pty: 256 Unix98 ptys configured lp0: using parport0 (polling). Real Time Clock Driver v1.11 i810_rng: RNG not detected Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected Intel i850 chipset agpgart: Maximum main memory to use for agp memory: 690M agpgart: AGP aperture is 128M @ 0xf0000000 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH2: IDE controller at PCI slot 00:1f.1 ICH2: chipset revision 4 ICH2: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:DMA, hdd:pio hda: Maxtor 5T060H6, ATA DISK drive hdb: Maxtor 5T060H6, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: TDK CDRW241040B, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: host protected area => 1 hda: 120103200 sectors (61493 MB) w/2048KiB Cache, CHS=119150/16/63, UDMA(33) hda: hda1 hdb: host protected area => 1 hdb: 120103200 sectors (61493 MB) w/2048KiB Cache, CHS=119150/16/63, UDMA(33) hdb: hdb1 hdb2 hdb3 drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.0 PCI: Setting latency timer of device 00:1f.2 to 64 uhci-hcd 00:1f.2: Intel Corp. 82801BA/BAM USB (Hub uhci-hcd 00:1f.2: irq 9, io base 0000b400 uhci-hcd 00:1f.2: new USB bus registered, assigned bus number 1 hub 1-0:0: USB hub found hub 1-0:0: 2 ports detected PCI: Setting latency timer of device 00:1f.4 to 64 uhci-hcd 00:1f.4: Intel Corp. 82801BA/BAM USB (Hub uhci-hcd 00:1f.4: irq 9, io base 0000b000 uhci-hcd 00:1f.4: new USB bus registered, assigned bus number 2 hub 2-0:0: USB hub found hub 2-0:0: 2 ports detected drivers/usb/core/usb.c: registered new driver hid drivers/usb/input/hid-core.c: v2.0:USB HID core driver device class 'input': registering register interface 'mouse' with class 'input' mice: PS/2 mouse device common for all mice serio: i8042 AUX port at 0x60,0x64 irq 12 input: AT Set 2 keyboard on isa0060/serio0 serio: i8042 KBD port at 0x60,0x64 irq 1 Advanced Linux Sound Architecture Driver Version 0.9.0rc6 (Tue Dec 17 19:01:13 2002 UTC). request_module[snd-card-0]: not ready request_module[snd-card-1]: not ready request_module[snd-card-2]: not ready request_module[snd-card-3]: not ready request_module[snd-card-4]: not ready request_module[snd-card-5]: not ready request_module[snd-card-6]: not ready request_module[snd-card-7]: not ready PCI: Enabling device 02:09.0 (0004 -> 0005) ALSA device list: #0: Sound Blaster Audigy at 0xd400, irq 10 NET4: Linux TCP/IP 1.0 for NET4.0 IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. request_module[nls_iso8859-1]: not ready Unable to load NLS charset iso8859-1 XFS mounting filesystem ide0(3,67) hub 1-0:0: debounce: port 1: delay 100ms stable 4 status 0x301 Ending clean XFS mount for filesystem: ide0(3,67) VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 304k freed hub 1-0:0: new USB device on port 1, assigned address 2 input: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-00:1f.2-1 Adding 497972k swap on /dev/hdb1. Priority:-1 extents:1 ne2k-pci.c:v1.02 10/19/2000 D. Becker/P. Gortmaker http://www.scyld.com/network/ne2k-pci.html PCI: Enabling device 02:07.0 (0000 -> 0001) eth0: Winbond 89C940 found at 0xd800, IRQ 11, 00:20:78:14:EB:C8. XFS mounting filesystem ide0(3,66) Ending clean XFS mount for filesystem: ide0(3,66) Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. Filesystem "ide0(3,67)": corrupt dinode 171966634, (btree extents). Unmount and run xfs_repair. --=-HL+EiGc1e2r6OVezLKs1-- From owner-linux-xfs@oss.sgi.com Tue Jan 14 05:35:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 05:36:06 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EDZv3v001193 for ; Tue, 14 Jan 2003 05:35:59 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18YRKN-0000EY-00; Tue, 14 Jan 2003 13:42:03 +0000 Date: Tue, 14 Jan 2003 13:42:03 +0000 From: Christoph Hellwig To: Neil Conway Cc: linux-xfs@oss.sgi.com Subject: Re: 2.5.56: dinode corruption Message-ID: <20030114134203.A880@infradead.org> References: <1042513050.393.11.camel@tokyo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1042513050.393.11.camel@tokyo>; from neilc@samurai.com on Mon, Jan 13, 2003 at 09:57:30PM -0500 X-archive-position: 2299 X-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: 627 Lines: 15 On Mon, Jan 13, 2003 at 09:57:30PM -0500, Neil Conway wrote: > Folks, > > I recently tried to test out Linux 2.5.56 on a personal workstation of > mine, that had been previously running 2.4 with XFS (and without any > problems). > > After booting into 2.5.56 (using the version of XFS it contains), I > recompiled the kernel again (having realized I forget to make a few > configuration changes), reran lilo, and rebooted. As the system was > shutting down, I saw this message many times: This looks a bit like the 2.4 rootfs corruption on shutdown issue, I'll merge up the fix to 2.5 today and hopefully send it to Linus. From owner-linux-xfs@oss.sgi.com Tue Jan 14 05:42:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 05:42:43 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EDgc3v001716 for ; Tue, 14 Jan 2003 05:42:39 -0800 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with SMTP id h0EDmho22167 for ; Tue, 14 Jan 2003 14:48:43 +0100 (MET) Received: (qmail 29256 invoked from network); 14 Jan 2003 14:48:43 +0100 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 14 Jan 2003 14:48:43 +0100 Date: Tue, 14 Jan 2003 14:48:43 +0100 From: Christian Guggenberger To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: Announce: XFS split patches for 2.4.20 - respin Message-ID: <20030114144843.C27800@pc9391.uni-regensburg.de> References: <11444.1042508075@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <11444.1042508075@kao2.melbourne.sgi.com>; from kaos@sgi.com on Tue, Jan 14, 2003 at 02:34:35 +0100 X-Mailer: Balsa 1.2.4 X-archive-position: 2300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 77 Lines: 5 Keith, sorry, but I only find xfs-patches dated on Dec. 18th... Christian From owner-linux-xfs@oss.sgi.com Tue Jan 14 05:47:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 05:47:31 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EDlP3v002190 for ; Tue, 14 Jan 2003 05:47:25 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0EE0tkq014086 for ; Tue, 14 Jan 2003 08:00:55 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA15028 for ; Tue, 14 Jan 2003 07:53:25 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA92332 for ; Tue, 14 Jan 2003 07:53:24 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h0EL7io05036 for linux-xfs@oss.sgi.com; Tue, 14 Jan 2003 16:07:44 -0500 Resent-Message-Id: <200301142107.h0EL7io05036@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA30853 for ; Tue, 14 Jan 2003 07:51:43 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h0EDpgQb51383533 for ; Tue, 14 Jan 2003 05:51:42 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h0EDnOdL026834 for ; Tue, 14 Jan 2003 14:49:25 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h0EDnOGF026833 for hch@sgi.com; Tue, 14 Jan 2003 14:49:24 +0100 Date: Tue, 14 Jan 2003 14:49:24 +0100 From: Christoph Hellwig Message-Id: <200301141349.h0EDnOGF026833@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.58 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 14 Jan 2003 16:07:44 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2301 X-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: 15050 Lines: 378 Linus is releasing kernels far too often too merge up, test and prepare patches for mainline.. *sigh* Date: Tue Jan 14 05:42:19 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:136776a linux/include/asm-parisc/bug.h - 1.1 linux/include/linux/sunrpc/rpc_pipe_fs.h - 1.1 linux/Documentation/IPMI.txt - 1.1 linux/include/asm-parisc/compat.h - 1.1 linux/arch/parisc/oprofile/timer_int.c - 1.1 linux/include/asm-ia64/bug.h - 1.1 linux/net/sunrpc/rpc_pipe.c - 1.1 linux/arch/parisc/oprofile/init.c - 1.1 linux/arch/parisc/oprofile/Makefile - 1.1 linux/include/asm-parisc/dma-mapping.h - 1.1 linux/include/asm-s390x/bug.h - 1.1 linux/drivers/char/ipmi/Kconfig - 1.1 linux/include/asm-i386/mach-bigsmp/mach_ipi.h - 1.1 linux/arch/parisc/kernel/profile.c - 1.1 linux/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c - 1.1 linux/net/sunrpc/auth_gss/sunrpcgss_syms.c - 1.1 linux/net/sunrpc/auth_gss/gss_pseudoflavors.c - 1.1 linux/net/sunrpc/auth_gss/gss_mech_switch.c - 1.1 linux/net/sunrpc/auth_gss/gss_krb5_unseal.c - 1.1 linux/net/sunrpc/auth_gss/gss_krb5_seqnum.c - 1.1 linux/net/sunrpc/auth_gss/gss_krb5_seal.c - 1.1 linux/drivers/char/ipmi/Makefile - 1.1 linux/drivers/char/ipmi/ipmi_devintf.c - 1.1 linux/net/sunrpc/auth_gss/gss_krb5_mech.c - 1.1 linux/net/sunrpc/auth_gss/gss_krb5_crypto.c - 1.1 linux/arch/i386/kernel/timers/timer_none.c - 1.1 linux/net/sunrpc/auth_gss/gss_generic_token.c - 1.1 linux/net/sunrpc/auth_gss/auth_gss.c - 1.1 linux/drivers/char/ipmi/ipmi_kcs_intf.c - 1.1 linux/net/sunrpc/auth_gss/Makefile - 1.1 linux/arch/m68knommu/kernel/entry.S - 1.1 linux/include/asm-sh/bug.h - 1.1 linux/include/asm-i386/mach-bigsmp/mach_apic.h - 1.1 linux/include/asm-parisc/parisc-device.h - 1.1 linux/include/asm-mips64/bug.h - 1.1 linux/include/asm-i386/bug.h - 1.1 linux/drivers/char/ipmi/ipmi_kcs_sm.c - 1.1 linux/drivers/parisc/hppb.c - 1.1 linux/include/asm-cris/bug.h - 1.1 linux/arch/parisc/kernel/module.c - 1.1 linux/include/asm-sparc/bug.h - 1.1 linux/include/asm-s390/bug.h - 1.1 linux/include/asm-arm/bug.h - 1.1 linux/include/asm-alpha/bug.h - 1.1 linux/include/asm-sparc64/bug.h - 1.1 linux/drivers/char/ipmi/ipmi_watchdog.c - 1.1 linux/drivers/char/ipmi/ipmi_msghandler.c - 1.1 linux/include/linux/sunrpc/gss_krb5.h - 1.1 linux/include/linux/sunrpc/gss_err.h - 1.1 linux/include/linux/sunrpc/gss_asn1.h - 1.1 linux/include/linux/sunrpc/gss_api.h - 1.1 linux/include/asm-ppc/bug.h - 1.1 linux/include/linux/sunrpc/auth_gss.h - 1.1 linux/include/asm-m68k/bug.h - 1.1 linux/arch/parisc/oprofile/Kconfig - 1.1 linux/drivers/char/ipmi/ipmi_kcs_sm.h - 1.1 linux/include/linux/ipmi.h - 1.1 linux/include/asm-mips/bug.h - 1.1 linux/include/linux/ipmi_smi.h - 1.1 linux/include/linux/ipmi_msgdefs.h - 1.1 linux/net/sunrpc/xprt.c - 1.38 linux/net/sunrpc/sunrpc_syms.c - 1.20 linux/net/sunrpc/clnt.c - 1.26 linux/net/sunrpc/auth_unix.c - 1.11 linux/net/sunrpc/auth_null.c - 1.11 linux/net/sunrpc/auth.c - 1.13 linux/net/sunrpc/Makefile - 1.10 linux/net/irda/qos.c - 1.18 linux/net/irda/irias_object.c - 1.16 linux/net/irda/iriap.c - 1.19 linux/net/802/tr.c - 1.14 linux/kernel/module.c - 1.35 linux/kernel/ksyms.c - 1.179 linux/include/net/irda/qos.h - 1.9 linux/include/net/irda/irias_object.h - 1.8 linux/include/linux/sunrpc/xprt.h - 1.18 linux/include/linux/sunrpc/xdr.h - 1.12 linux/include/linux/sunrpc/sched.h - 1.15 linux/include/linux/sunrpc/msg_prot.h - 1.4 linux/include/linux/sunrpc/clnt.h - 1.14 linux/include/linux/sunrpc/auth.h - 1.9 linux/include/linux/smp.h - 1.25 linux/include/linux/nfs_mount.h - 1.7 linux/include/linux/kernel.h - 1.43 linux/include/linux/elf.h - 1.21 linux/include/linux/dcache.h - 1.32 linux/include/asm-sparc64/page.h - 1.22 linux/include/asm-sparc/page.h - 1.19 linux/include/asm-ppc/processor.h - 1.39 linux/include/asm-ppc/page.h - 1.21 linux/include/asm-mips/page.h - 1.9 linux/include/asm-m68k/page.h - 1.14 linux/include/asm-i386/page.h - 1.33 linux/include/asm-arm/page.h - 1.20 linux/include/asm-alpha/page.h - 1.17 linux/fs/proc/inode.c - 1.28 linux/fs/nfsd/nfsproc.c - 1.32 linux/fs/nfs/inode.c - 1.62 linux/drivers/scsi/st.c - 1.61 linux/drivers/scsi/sd.c - 1.82 linux/drivers/scsi/scsi_error.c - 1.37 linux/drivers/scsi/hosts.h - 1.34 linux/drivers/scsi/hosts.c - 1.39 linux/drivers/net/smc-ultra.c - 1.26 linux/drivers/net/rrunner.c - 1.23 linux/drivers/net/ne.c - 1.24 linux/drivers/net/hamradio/bpqether.c - 1.22 linux/drivers/char/n_hdlc.c - 1.17 linux/drivers/char/Makefile - 1.80 linux/drivers/block/ll_rw_blk.c - 1.125 linux/drivers/block/genhd.c - 1.46 linux/drivers/acorn/scsi/fas216.c - 1.16 linux/arch/sparc64/kernel/ioctl32.c - 1.65 linux/arch/i386/lib/delay.c - 1.7 linux/arch/i386/kernel/time.c - 1.33 linux/arch/i386/Makefile - 1.44 linux/Makefile - 1.236 linux/CREDITS - 1.96 linux/include/asm-i386/hw_irq.h - 1.32 linux/drivers/atm/ambassador.c - 1.20 linux/include/asm-sh/page.h - 1.12 linux/drivers/net/wan/cosa.c - 1.29 linux/drivers/net/aironet4500_card.c - 1.21 linux/drivers/scsi/scsi_lib.c - 1.57 linux/Documentation/usb/proc_usb_info.txt - 1.5 linux/arch/i386/kernel/pci-dma.c - 1.7 linux/include/asm-ia64/page.h - 1.19 linux/drivers/net/skfp/fplustm.c - 1.5 linux/net/bridge/br_ioctl.c - 1.5 linux/include/asm-mips64/page.h - 1.6 linux/drivers/usb/serial/usb-serial.c - 1.11 linux/drivers/ide/ide-probe.c - 1.48 linux/drivers/block/elevator.c - 1.28 linux/include/linux/elevator.h - 1.16 linux/drivers/scsi/sym53c8xx_comm.h - 1.15 linux/drivers/usb/serial/visor.h - 1.15 linux/drivers/usb/serial/visor.c - 1.49 linux/drivers/usb/serial/digi_acceleport.c - 1.35 linux/include/asm-s390/page.h - 1.9 linux/drivers/s390/block/dasd.c - 1.36 linux/arch/mips64/kernel/ioctl32.c - 1.15 linux/drivers/usb/storage/debug.c - 1.11 linux/drivers/scsi/cpqfcTSinit.c - 1.24 linux/arch/parisc/kernel/drivers.c - 1.4 linux/arch/parisc/kernel/entry.S - 1.6 linux/include/asm-parisc/hardware.h - 1.3 linux/include/asm-parisc/linux_logo.h - 1.3 linux/include/asm-parisc/uaccess.h - 1.3 linux/include/asm-parisc/unistd.h - 1.7 linux/include/asm-parisc/page.h - 1.4 linux/include/asm-parisc/ide.h - 1.8 linux/arch/parisc/mm/fault.c - 1.4 linux/arch/parisc/mm/extable.c - 1.3 linux/include/asm-parisc/pci.h - 1.6 linux/include/asm-parisc/keyboard.h - 1.4 linux/include/asm-parisc/posix_types.h - 1.3 linux/include/asm-parisc/irq.h - 1.3 linux/include/asm-parisc/processor.h - 1.9 linux/arch/parisc/kernel/traps.c - 1.6 linux/arch/parisc/kernel/time.c - 1.4 linux/arch/parisc/kernel/syscall.S - 1.5 linux/arch/parisc/kernel/sys_parisc.c - 1.7 linux/arch/parisc/kernel/signal.c - 1.6 linux/arch/parisc/kernel/setup.c - 1.6 linux/arch/parisc/kernel/ptrace.c - 1.7 linux/arch/parisc/kernel/process.c - 1.8 linux/arch/parisc/kernel/pdc_cons.c - 1.6 linux/arch/parisc/kernel/pci.c - 1.5 linux/arch/parisc/kernel/pci-dma.c - 1.5 linux/include/asm-parisc/assembly.h - 1.3 linux/arch/parisc/kernel/parisc_ksyms.c - 1.6 linux/include/asm-parisc/cache.h - 1.4 linux/include/asm-parisc/checksum.h - 1.4 linux/include/asm-parisc/current.h - 1.3 linux/arch/parisc/kernel/inventory.c - 1.3 linux/arch/parisc/kernel/head.S - 1.3 linux/include/asm-parisc/io.h - 1.4 linux/arch/parisc/kernel/Makefile - 1.7 linux/arch/parisc/hpux/fs.c - 1.5 linux/arch/parisc/defconfig - 1.9 linux/arch/parisc/Makefile - 1.11 linux/include/asm-parisc/system.h - 1.5 linux/include/asm-parisc/stat.h - 1.4 linux/drivers/scsi/osst.c - 1.22 linux/fs/reiserfs/super.c - 1.32 linux/fs/reiserfs/hashes.c - 1.5 linux/include/asm-s390x/page.h - 1.7 linux/arch/s390x/kernel/ioctl32.c - 1.10 linux/drivers/s390/net/netiucv.c - 1.13 linux/drivers/s390/net/ctcmain.c - 1.11 linux/include/asm-cris/page.h - 1.4 linux/drivers/media/radio/radio-maxiradio.c - 1.9 linux/drivers/block/paride/bpck6.c - 1.6 linux/drivers/usb/usb-skeleton.c - 1.20 linux/arch/arm/mach-integrator/cpu.c - 1.10 linux/arch/arm/mach-sa1100/cpu-sa1100.c - 1.9 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.11 linux/drivers/scsi/dpt_i2o.c - 1.18 linux/drivers/scsi/53c700.c - 1.14 linux/drivers/char/i8k.c - 1.4 linux/include/linux/jbd.h - 1.11 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.10 linux/include/linux/device.h - 1.27 linux/drivers/base/interface.c - 1.13 linux/drivers/base/core.c - 1.22 linux/sound/pci/korg1212/korg1212.c - 1.14 linux/sound/oss/pas2_pcm.c - 1.3 linux/sound/oss/pas2_mixer.c - 1.2 linux/sound/oss/pas2_midi.c - 1.3 linux/sound/oss/pas2_card.c - 1.4 linux/sound/oss/opl3sa2.c - 1.7 linux/sound/oss/cs4232.c - 1.5 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.13 linux/sound/oss/awe_wave.c - 1.3 linux/sound/oss/ad1848.c - 1.8 linux/sound/isa/opti9xx/opti92x-ad1848.c - 1.8 linux/include/sound/initval.h - 1.5 linux/arch/ppc64/kernel/ioctl32.c - 1.13 linux/drivers/usb/class/audio.c - 1.12 linux/drivers/usb/host/ehci-dbg.c - 1.11 linux/drivers/usb/host/ohci-dbg.c - 1.12 linux/kernel/suspend.c - 1.19 linux/drivers/base/bus.c - 1.11 linux/drivers/acpi/processor.c - 1.14 linux/drivers/usb/class/usb-midi.c - 1.9 linux/drivers/s390/net/lcs.c - 1.7 linux/drivers/s390/cio/chsc.c - 1.4 linux/drivers/usb/input/xpad.c - 1.8 linux/drivers/usb/misc/speedtouch.c - 1.8 linux/drivers/base/class.c - 1.7 linux/drivers/ide/pci/generic.h - 1.5 linux/drivers/ide/pci/amd74xx.c - 1.7 linux/drivers/ide/legacy/umc8672.c - 1.2 linux/arch/parisc/vmlinux.lds.S - 1.5 linux/net/bridge/netfilter/ebt_log.c - 1.2 linux/drivers/block/deadline-iosched.c - 1.5 linux/kernel/cpufreq.c - 1.7 linux/include/linux/cpufreq.h - 1.7 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.5 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.5 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.6 linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.5 linux/arch/i386/kernel/cpu/cpufreq/Makefile - 1.3 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.4 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.5 linux/net/sunrpc/svcauth_unix.c - 1.5 linux/include/asm-i386/timer.h - 1.3 linux/arch/i386/kernel/timers/Makefile - 1.4 linux/arch/i386/kernel/timers/timer_cyclone.c - 1.2 linux/arch/i386/kernel/timers/timer_pit.c - 1.4 linux/arch/i386/kernel/timers/timer_tsc.c - 1.7 linux/drivers/block/scsi_ioctl.c - 1.5 linux/drivers/block/ioctl.c - 1.3 linux/drivers/isdn/i4l/isdn_ppp_ccp.c - 1.3 linux/fs/sysfs/inode.c - 1.5 linux/include/linux/sysfs.h - 1.5 linux/drivers/pnp/isapnp/core.c - 1.6 linux/drivers/pnp/interface.c - 1.5 linux/include/linux/pnp.h - 1.6 linux/include/linux/kobject.h - 1.5 linux/arch/i386/Kconfig - 1.8 linux/include/asm-parisc/thread_info.h - 1.2 linux/include/asm-parisc/module.h - 1.2 linux/drivers/char/Kconfig - 1.3 linux/include/asm-parisc/dma.h - 1.3 linux/arch/parisc/Kconfig - 1.6 linux/arch/parisc/kernel/asm-offsets.c - 1.3 linux/arch/parisc/kernel/binfmt_elf32.c - 1.2 linux/arch/parisc/kernel/head64.S - 1.2 linux/arch/parisc/kernel/ioctl32.c - 1.2 linux/arch/parisc/kernel/perf.c - 1.5 linux/arch/parisc/kernel/processor.c - 1.4 linux/arch/parisc/kernel/signal32.c - 1.2 linux/arch/parisc/kernel/smp.c - 1.3 linux/arch/parisc/kernel/sys32.h - 1.2 linux/arch/parisc/kernel/sys_parisc32.c - 1.5 linux/arch/parisc/kernel/unaligned.c - 1.2 linux/arch/parisc/lib/io.c - 1.2 linux/arch/parisc/math-emu/driver.c - 1.2 linux/arch/parisc/math-emu/fpudispatch.c - 1.2 linux/fs/Kconfig - 1.8 linux/drivers/usb/class/Kconfig - 1.4 linux/init/Kconfig - 1.4 linux/drivers/parisc/wax.c - 1.3 linux/drivers/parisc/superio.c - 1.3 linux/drivers/parisc/sba_iommu.c - 1.3 linux/drivers/parisc/power.c - 1.3 linux/drivers/parisc/led.c - 1.4 linux/drivers/parisc/lba_pci.c - 1.3 linux/drivers/parisc/lasi.c - 1.3 linux/drivers/parisc/iosapic.c - 1.3 linux/drivers/parisc/gsc.h - 1.2 linux/drivers/parisc/eisa.c - 1.4 linux/drivers/parisc/dino.c - 1.4 linux/drivers/parisc/ccio-rm-dma.c - 1.3 linux/drivers/parisc/ccio-dma.c - 1.4 linux/drivers/parisc/asp.c - 1.3 linux/drivers/parisc/Makefile - 1.2 linux/drivers/parisc/Kconfig - 1.3 linux/drivers/net/fec.c - 1.3 linux/include/asm-v850/system.h - 1.3 linux/drivers/base/node.c - 1.3 linux/include/asm-m68knommu/system.h - 1.2 linux/arch/m68knommu/kernel/comempci.c - 1.2 linux/arch/m68knommu/kernel/setup.c - 1.2 linux/arch/m68knommu/kernel/signal.c - 1.3 linux/arch/m68knommu/platform/5206/ARNEWSH/ram.ld - 1.3 linux/arch/m68knommu/platform/5206e/MOTOROLA/ram.ld - 1.3 linux/arch/m68knommu/platform/5206e/eLITE/ram.ld - 1.3 linux/arch/m68knommu/platform/5249/MOTOROLA/ram.ld - 1.3 linux/arch/m68knommu/platform/5272/MOTOROLA/ram.ld - 1.3 linux/arch/m68knommu/platform/5272/NETtel/ram.ld - 1.3 linux/arch/m68knommu/platform/5307/ARNEWSH/ram.ld - 1.3 linux/arch/m68knommu/platform/5307/CLEOPATRA/ram.ld - 1.3 linux/arch/m68knommu/platform/5307/MOTOROLA/ram.ld - 1.3 linux/arch/m68knommu/platform/5307/MP3/ram.ld - 1.3 linux/arch/m68knommu/platform/5307/NETtel/ram.ld - 1.3 linux/arch/m68knommu/platform/5407/CLEOPATRA/ram.ld - 1.3 linux/arch/m68knommu/platform/5407/MOTOROLA/ram.ld - 1.3 linux/arch/m68knommu/platform/68328/pilot/rom.ld - 1.2 linux/arch/m68knommu/platform/68360/uCquicc/ram.ld - 1.3 linux/arch/m68knommu/platform/68360/uCquicc/rom.ld - 1.3 linux/arch/m68knommu/platform/68EZ328/ucsimm/crt0_fixed.S - 1.2 linux/arch/m68knommu/platform/68EZ328/ucsimm/fixed.ld - 1.3 linux/arch/m68knommu/platform/68EZ328/ucsimm/himem.ld - 1.2 linux/arch/m68knommu/platform/68EZ328/ucsimm/ram.ld - 1.3 linux/arch/m68knommu/platform/68EZ328/ucsimm/rom.ld - 1.2 linux/arch/m68knommu/platform/68VZ328/de2/crt0_fixed.S - 1.2 linux/arch/m68knommu/platform/68VZ328/de2/fixed.ld - 1.3 linux/arch/m68knommu/platform/68VZ328/de2/ram.ld - 1.3 linux/arch/m68knommu/platform/68VZ328/de2/rom.ld - 1.2 linux/arch/m68knommu/platform/68VZ328/ucdimm/crt0_fixed.S - 1.2 linux/arch/m68knommu/platform/68VZ328/ucdimm/fixed.ld - 1.3 linux/arch/m68knommu/platform/68VZ328/ucdimm/himem.ld - 1.2 linux/arch/m68knommu/platform/68VZ328/ucdimm/ram.ld - 1.3 linux/arch/m68knommu/platform/68VZ328/ucdimm/rom.ld - 1.2 linux/arch/m68knommu/vmlinux.lds.S - 1.2 linux/arch/v850/Makefile - 1.3 linux/drivers/serial/68360serial.c - 1.5 linux/drivers/serial/mcfserial.h - 1.2 linux/drivers/serial/nb85e_uart.c - 1.4 linux/drivers/scsi/scsi_sysfs.c - 1.3 linux/drivers/pnp/card.c - 1.4 linux/drivers/mca/mca-bus.c - 1.2 linux/drivers/ide/pci/sc1200.c - 1.3 linux/arch/sparc64/kernel/module.c - 1.4 linux/arch/arm/kernel/module.c - 1.4 linux/drivers/ide/pci/cs5520.c - 1.3 linux/drivers/s390/cio/ccwgroup.c - 1.2 linux/drivers/s390/cio/device.c - 1.2 linux/include/linux/moduleloader.h - 1.4 linux/arch/v850/kernel/module.c - 1.4 linux/arch/s390x/kernel/module.c - 1.4 linux/arch/s390/kernel/module.c - 1.4 linux/arch/ppc/kernel/module.c - 1.4 linux/arch/i386/kernel/module.c - 1.4 linux/arch/sparc/kernel/module.c - 1.4 linux/Documentation/DMA-API.txt - 1.2 linux/arch/x86_64/kernel/module.c - 1.3 linux/include/asm-i386/dma-mapping.h - 1.2 linux/include/asm-generic/pci-dma-compat.h - 1.2 linux/include/asm-generic/dma-mapping.h - 1.2 linux/include/asm-arm/dma-mapping.h - 1.3 linux/arch/alpha/kernel/module.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jan 14 06:53:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 06:53:58 -0800 (PST) Received: from ZRHNOG20.converium.com (mail1.converium.com [213.173.163.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EEro3v003504 for ; Tue, 14 Jan 2003 06:53:51 -0800 Subject: xfs fails as / with Debian GNU/Linux 2.4.18-smp - 2nd post To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: "Lucien Meyers" Date: Tue, 14 Jan 2003 15:58:31 +0100 X-MIMETrack: Serialize by Router on ZRHNOG20/Converium-Internet(Release 5.0.10 |March 22, 2002) at 14.01.2003 15:59:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 2302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lucien.meyers@converium.com Precedence: bulk X-list: linux-xfs Content-Length: 4713 Lines: 53 Hi! Here was the last post 10 days ago. Suggestions welcome. |--------------------------------------------------------------------------------------------------| | | | Seth Mos xs4all.nl> writes: | | | | > At 22:24 1-1-2003 +0100, A. Lucien Meyers wrote: | | > >Followed all your suggestions but, alas, exactly the same result. | | > >Here is some of the relevant output during the boot process which | | > >results in having to press the reset button: | | > > | | > >FAT: bogus logical sector size 0 | | > >FAT: bogus logical sector size 0 | | > >invalid operand: 0000 | | > >CPU: | | > >EIP: | | > >EFLAGS: | | > >Process swapper | | > >Call trace: | | > >Code: | | > ><0> Kernel panic: Attempted to kill init! | | > | | > Did you try to use high optimizations for the compile? | | | | Just standard setting, O2. Do you suggest reducing this to 1 or 0? | | | | > Or did you compile a i586 kernel on a AMD K6 machine (which often fails). | | | | No. Compiled a 686 smp kernel. Have 2 Pentium Pro processors. | | | | > I suspect that either the following might be a problem: | | > - Buggy compiler (what are you using) | | | | Used gcc 2.95. Is 3.2 required? | | | | > - Compiling for the wrong architecture (what are you compiling for) | | | | What would you suggest? i386? | | | | > - Hardware problem (Failing fan, memory). | | | | Probably not, as the SuSE distrib boots from an xfs partition perfectly | | on another disk in the same system. | | | | Lucien | | | | | |--------------------------------------------------------------------------------------------------| From owner-linux-xfs@oss.sgi.com Tue Jan 14 07:19:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 07:20:00 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EFJt3v004266 for ; Tue, 14 Jan 2003 07:19:56 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 3D689AC47 for ; Tue, 14 Jan 2003 16:31:38 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id B138519020 for ; Tue, 14 Jan 2003 16:31:29 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id C0A4730881D for ; Tue, 14 Jan 2003 16:25:52 +0100 (CET) Message-ID: <3E242C00.47E95E68@ch.sauter-bc.com> Date: Tue, 14 Jan 2003 16:25:52 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: Re: Corruption on ext3 with XFS kernel References: <3E22A504.3280C4C6@ch.sauter-bc.com> <3E22A889.70203@koschikode.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2303 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1875 Lines: 45 Juri Haberland schrieb: > > Simon Matter wrote: > > Hi, > > > > I have seven IBM deathstar 60G disks here which have been replaced. I > > want to use four of them in my home server so I wanted to do some tests > > to make sure they don't break in the first week. I have connected four > > drives to a Promise Ultra100TX2 IDE controller and put it into my test > > server. The box is running kernel-2.4.18-18SGI_XFS_1.2pre3. I have > > created a softraid5 on the disks creating a 180G device. I then created > > an ext3 fs with default settings. Mounted the fs on /mnt/md9, mounted my > > real servers data on /mnt/nfs. Then I used cp -a /mnt/nfs > > /mnt/md9/nfs[n] five times creating five identical copies of the nfs > > mounted data (/mnt/md9/nfs1, /mnt/md9/nfs2...) with a size of 28G in > > 16500 file in each copy (143G used / 81%). > > Then I did two times five diff's running at the same time and I was very > > surprised what came out: > > [SNIP] > > > Now, it looks like a problem with ext3. My question is, could it have > > _something_ to do with the XFS patch in this kernel? Did anybody do > > similar tests? Unfortunately this box has XFS root so I can't just > > switch to vanilla or original RedHat kernel and every test takes me > > ~1day. Is there a way to find out what's going wrong here? > > You can try to apply the three bugfix-patches for 2.4.20/ext3 at > http://www.zip.com.au/~akpm/linux/ext3/ (see "Updates for the 2.4.20 > kernel"). RedHat has an updated kernel too, but this kernel fixes a problem which only affects ext3 filesystems mounted with data=journal, see http://rhn.redhat.com/errata/RHBA-2002-292.html I have now tested the same with 2.4.9-34SGI_XFS_1.1 and the error doesn't occur. My next step is building kernel-2.4.18-19SGI_XFS_1.2pre5, which is the newest errata kernel and XFS 1.2pre5 added. Simon > > Regards, > Juri From owner-linux-xfs@oss.sgi.com Tue Jan 14 07:44:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 07:44:20 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EFiC3v004925 for ; Tue, 14 Jan 2003 07:44:14 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18YTKV-0001Bj-00; Tue, 14 Jan 2003 15:50:19 +0000 Date: Tue, 14 Jan 2003 15:50:18 +0000 From: Christoph Hellwig To: Lucien Meyers Cc: linux-xfs@oss.sgi.com Subject: Re: xfs fails as / with Debian GNU/Linux 2.4.18-smp - 2nd post Message-ID: <20030114155018.A4521@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from lucien.meyers@converium.com on Tue, Jan 14, 2003 at 03:58:31PM +0100 X-archive-position: 2304 X-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: 325 Lines: 8 On Tue, Jan 14, 2003 at 03:58:31PM +0100, Lucien Meyers wrote: > Hi! Here was the last post 10 days ago. Suggestions welcome. It looks like your kernel tries to mount the rootfs as fat. Try compiling a kernel without support for fat/msdosfs. Maybe we should move xfs above fat in the makefile to have it probed earlier.. From owner-linux-xfs@oss.sgi.com Tue Jan 14 08:14:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 08:14:10 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EGE63v006924 for ; Tue, 14 Jan 2003 08:14:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0EEKHG8008875 for ; Tue, 14 Jan 2003 06:20:17 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA15361 for ; Tue, 14 Jan 2003 10:20:07 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA40777 for ; Tue, 14 Jan 2003 10:20:07 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h0ENYR805712 for linux-xfs@oss.sgi.com; Tue, 14 Jan 2003 18:34:27 -0500 Resent-Message-Id: <200301142334.h0ENYR805712@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA44552 for ; Tue, 14 Jan 2003 10:02:00 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h0EG1vQb51332030 for ; Tue, 14 Jan 2003 08:01:58 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h0EFxeAj011232 for ; Tue, 14 Jan 2003 16:59:40 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h0EFxeLx011231 for hch@sgi.com; Tue, 14 Jan 2003 16:59:40 +0100 Date: Tue, 14 Jan 2003 16:59:40 +0100 From: Christoph Hellwig Message-Id: <200301141559.h0EFxeLx011231@lab343.munich.sgi.com> Subject: TAKE - bring 2.5 back in line with 2.4 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 14 Jan 2003 18:34:27 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2305 X-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: 3325 Lines: 132 Fix the cmn_err stuff to mask the error level before it checks for max value Date: Tue Jan 14 06:41:48 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs Author: cattelan Merged by: hch Merged mods: 2.4.x-xfs:slinx:135869a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:135869a linux/fs/xfs/support/debug.c - 1.14 - Merge of 2.4.x-xfs:slinx:135869a by hch. Subject: TAKE - some more rename cleanups Date: Tue Jan 14 06:59:15 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs Author: hch Merged by: hch Merged mods: 2.4.x-xfs:slinx:135919a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:135919a linux/fs/xfs/xfs_rename.c - 1.45 - Merge of 2.4.x-xfs:slinx:135919a by hch. xfs_lock_for_rename can't return EAGAIN anymore, no need to handle it; use vname terminology more consistantly Subject: TAKE - xfs_getattr should be static Date: Tue Jan 14 07:09:14 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs Author: hch Merged by: hch Merged mods: 2.4.x-xfs:slinx:135920a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:135920a linux/fs/xfs/xfs_vnodeops.c - 1.580 - Merge of 2.4.x-xfs:slinx:135920a by hch. Subject: TAKE - make *cmn_err interrupt safe Date: Tue Jan 14 07:19:17 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs Author: cattelan Merged by: hch Merged mods: 2.4.x-xfs:slinx:136126a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:136126a linux/fs/xfs/support/debug.c - 1.15 - Merge of 2.4.x-xfs:slinx:136126a by hch. Subject: TAKE - Revisit the remount read only code again. apparently the root file system are not being synced correctly during system shutdown Date: Tue Jan 14 07:33:09 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs Author: cattelan Merged by: hch Merged mods: 2.4.x-xfs:slinx:136269a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:136269a linux/fs/xfs/xfs_vnodeops.c - 1.581 - Merge of 2.4.x-xfs:slinx:136269a by hch. New function to do xfs inode reclaim during system shutdown linux/fs/xfs/xfs_inode.h - 1.176 - Merge of 2.4.x-xfs:slinx:136269a by hch. prototype for xfs_reclaim_all linux/fs/xfs/linux/xfs_lrw.c - 1.180 - Merge of 2.4.x-xfs:slinx:136269a by hch. call new function xfs_reclaim_all to unmount_ro path Subject: TAKE - remount r/o fixes Date: Tue Jan 14 08:00:49 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs Merged by: hch Merged mods: 2.4.x-xfs:slinx:136270a,2.4.x-xfs:slinx:136364a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:136795a linux/fs/xfs/xfs_vnodeops.c - 1.582 - Merge of 2.4.x-xfs:slinx:136270a originally by cattelan on 01/07/03 put back a change that got dropped in the last checkin linux/fs/xfs/xfs_inode.h - 1.177 - Merge of 2.4.x-xfs:slinx:136364a originally by cattelan on 01/08/03 cut and paste error grrr Correct name for the proto type From owner-linux-xfs@oss.sgi.com Tue Jan 14 10:19:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 10:19:42 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EIJY3v013033 for ; Tue, 14 Jan 2003 10:19:35 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0EGPjG8018640 for ; Tue, 14 Jan 2003 08:25:45 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA33885 for ; Tue, 14 Jan 2003 12:25:36 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA89012 for ; Tue, 14 Jan 2003 12:25:35 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h0F1dsm06561 for linux-xfs@oss.sgi.com; Tue, 14 Jan 2003 20:39:54 -0500 Resent-Message-Id: <200301150139.h0F1dsm06561@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA61234 for ; Tue, 14 Jan 2003 12:15:26 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h0EIFOQb51416927 for ; Tue, 14 Jan 2003 10:15:25 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h0EID51E011834 for ; Tue, 14 Jan 2003 19:13:05 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h0EID5xc011805 for hch@sgi.com; Tue, 14 Jan 2003 19:13:05 +0100 Date: Tue, 14 Jan 2003 19:13:05 +0100 From: Christoph Hellwig Message-Id: <200301141813.h0EID5xc011805@lab343.munich.sgi.com> Subject: TAKE - fix namespace pullution To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 14 Jan 2003 20:39:54 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2306 X-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: 304 Lines: 12 Date: Tue Jan 14 10:14:50 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:136827a linux/fs/xfs/xfs_vfsops.c - 1.400 - use XFS_PREEMPT_MASK instead of PREEMPT_MASK From owner-linux-xfs@oss.sgi.com Tue Jan 14 11:21:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 11:21:44 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EJLd3v014398 for ; Tue, 14 Jan 2003 11:21:40 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18YWhg-0005sm-00 for ; Tue, 14 Jan 2003 20:26:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18YWhf-0005sT-00 for ; Tue, 14 Jan 2003 20:26:27 +0100 Path: wassern.consult-meyers.com!news From: "A. L. Meyers" Subject: Re: xfs fails as / with Debian GNU/Linux 2.4.18-smp - 2nd post Date: Tue, 14 Jan 2003 19:58:23 +0100 Organization: Meyers Consulting http://www.consult-meyers.com Message-ID: <87lm1no8xc.fsf@wassern.consult-meyers.com> References: <20030114155018.A4521@infradead.org> Reply-To: "A. L. Meyers" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2 (i386-debian-linux-gnu) Cancel-Lock: sha1:3DP6Ov66xB3C36wP4NC8JERAXWI= X-archive-position: 2307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: me@privacy.net Precedence: bulk X-list: linux-xfs Content-Length: 992 Lines: 24 Christoph Hellwig writes: > On Tue, Jan 14, 2003 at 03:58:31PM +0100, Lucien Meyers wrote: >> Hi! Here was the last post 10 days ago. Suggestions welcome. > > It looks like your kernel tries to mount the rootfs as fat. Try compiling > a kernel without support for fat/msdosfs. > > Maybe we should move xfs above fat in the makefile to have it probed earlier.. Thanks for the suggestion, Christoph. However, this would make it impossible to access my only windoze partition from Debian GNU/Linux, currently serving to run an accounting programme not yet ported to Linux. Occasionally require the accounting data in Linux. Meanwhile have reformatted / partition as ext3 until we find a suitable solution. Lucien -- If you receive this by error, please delete it and inform the sender. PGP key fingerprint=F1C0 D9AE 1B18 1405 4DFA B4CC 6DC7 FF78 C76E FB15 To Big Brother Echelon from "spook": domestic disruption Honduras Iraq opus dei Nazi Ft. Bragg DES heroine From owner-linux-xfs@oss.sgi.com Tue Jan 14 14:05:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 14:05:42 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EM5V3v018116 for ; Tue, 14 Jan 2003 14:05:32 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id A49A3180B5F7; Tue, 14 Jan 2003 14:11:39 -0800 (PST) Date: Tue, 14 Jan 2003 14:11:39 -0800 From: Chris Wedgwood To: Lucien Meyers Cc: linux-xfs@oss.sgi.com Subject: Re: xfs fails as / with Debian GNU/Linux 2.4.18-smp - 2nd post Message-ID: <20030114221139.GA4264@f00f.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2308 X-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: 392 Lines: 21 On Tue, Jan 14, 2003 at 03:58:31PM +0100, Lucien Meyers wrote: >FAT: bogus logical sector size 0 >FAT: bogus logical sector size 0 >invalid operand: 0000 >CPU: >EIP: >EFLAGS: >Process swapper >Call trace: >Code: ><0> Kernel panic: Attempted to kill init! fatfs (or similar) is buggy/broken if fatfs can't mount the filesystem it should give-up and let the next filesystem try... --cw From owner-linux-xfs@oss.sgi.com Tue Jan 14 14:16:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 14:16:38 -0800 (PST) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EMGU3v019552 for ; Tue, 14 Jan 2003 14:16:31 -0800 Received: from mnsu.edu (j3gum-3.MNSU.EDU [134.29.1.30]) by mail.mnsu.edu (8.9.3/8.9.3) with ESMTP id QAA11920; Tue, 14 Jan 2003 16:22:23 -0600 (CST) Message-ID: <3E248C8B.9020908@mnsu.edu> Date: Tue, 14 Jan 2003 16:17:47 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: Lucien Meyers , linux-xfs@oss.sgi.com Subject: Re: xfs fails as / with Debian GNU/Linux 2.4.18-smp - 2nd post References: <20030114221139.GA4264@f00f.org> In-Reply-To: <20030114221139.GA4264@f00f.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs Content-Length: 970 Lines: 44 I've had a similar problem with floppies when I have the fstab set to mount type=auto. It happens when I have a floppy with an ms-dos filesystem that then gets formatted with ext2. Apparently auto sees enough of the ms-dos filesystem to assume incorrectly that it is ms-dos. I've gotten around this by dd'ing a few sectors of /dev/zero to the floppy, before putting a different filesystem on in. BTW: could you also get around your problem by putting ms-dos fs in as a module? -- jeffrey hundstad Chris Wedgwood wrote: >On Tue, Jan 14, 2003 at 03:58:31PM +0100, Lucien Meyers wrote: > > > >>FAT: bogus logical sector size 0 >>FAT: bogus logical sector size 0 >>invalid operand: 0000 >>CPU: >>EIP: >>EFLAGS: >>Process swapper >>Call trace: >>Code: >><0> Kernel panic: Attempted to kill init! >> >> > >fatfs (or similar) is buggy/broken > >if fatfs can't mount the filesystem it should give-up and let the next >filesystem try... > > > --cw > > > > From owner-linux-xfs@oss.sgi.com Tue Jan 14 14:30:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 14:30:39 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EMUY3v020109 for ; Tue, 14 Jan 2003 14:30:35 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 6156A180B5F7; Tue, 14 Jan 2003 14:36:43 -0800 (PST) Date: Tue, 14 Jan 2003 14:36:43 -0800 From: Chris Wedgwood To: "Jeffrey E. Hundstad" Cc: Lucien Meyers , linux-xfs@oss.sgi.com Subject: Re: xfs fails as / with Debian GNU/Linux 2.4.18-smp - 2nd post Message-ID: <20030114223643.GA4462@f00f.org> References: <20030114221139.GA4264@f00f.org> <3E248C8B.9020908@mnsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E248C8B.9020908@mnsu.edu> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2310 X-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: 233 Lines: 13 On Tue, Jan 14, 2003 at 04:17:47PM -0600, Jeffrey E. Hundstad wrote: > BTW: could you also get around your problem by putting ms-dos fs in > as a module? yes, that will also work however, fatfs really needs to be fixed --cw From owner-linux-xfs@oss.sgi.com Tue Jan 14 14:46:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 14:46:07 -0800 (PST) Received: from morrigan.bus.okstate.edu (morrigan.bus.okstate.edu [139.78.88.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0EMjw3v020609 for ; Tue, 14 Jan 2003 14:45:59 -0800 Received: from bus.okstate.edu (joines.bus.okstate.edu [139.78.89.31]) by morrigan.bus.okstate.edu (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h0EMpqsf016886 for ; Tue, 14 Jan 2003 16:51:53 -0600 Message-ID: <3E249449.50909@bus.okstate.edu> Date: Tue, 14 Jan 2003 16:50:49 -0600 From: Jason Joines User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030112 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux XFS Users Subject: xfsdump max file size X-Enigmail-Version: 0.71.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joines@bus.okstate.edu Precedence: bulk X-list: linux-xfs Content-Length: 66 Lines: 2 What's the maximum file size for a file to be dumped by xfsdump? From owner-linux-xfs@oss.sgi.com Tue Jan 14 15:52:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 15:52:02 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0ENq03v021944 for ; Tue, 14 Jan 2003 15:52:00 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h0ELwBG8010071 for ; Tue, 14 Jan 2003 13:58:12 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15134; Wed, 15 Jan 2003 10:56:46 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id B83053000B8; Wed, 15 Jan 2003 10:56:45 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 2008385; Wed, 15 Jan 2003 10:56:45 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Christian Guggenberger Cc: linux-xfs@oss.sgi.com Subject: Re: Announce: XFS split patches for 2.4.20 - respin In-reply-to: Your message of "Tue, 14 Jan 2003 14:48:43 BST." <20030114144843.C27800@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 2003 10:56:38 +1100 Message-ID: <9595.1042588598@kao2.melbourne.sgi.com> X-archive-position: 2312 X-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: 232 Lines: 6 On Tue, 14 Jan 2003 14:48:43 +0100, Christian Guggenberger wrote: >sorry, but I only find xfs-patches dated on Dec. 18th... rsync -n :(. oss.sgi.com has really been updated now. From owner-linux-xfs@oss.sgi.com Tue Jan 14 17:46:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 17:46:51 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0F1ke3v023462 for ; Tue, 14 Jan 2003 17:46:41 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0F20Fkq030634 for ; Tue, 14 Jan 2003 20:00:15 -0600 Received: from sgi.com (syntegra.americas.sgi.com [128.162.232.81]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h0F1phQb51699130; Tue, 14 Jan 2003 17:51:43 -0800 (PST) Message-ID: <3E24BEAE.1080604@sgi.com> Date: Tue, 14 Jan 2003 19:51:42 -0600 From: Mandy Kirkconnell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Joines CC: Linux XFS Users Subject: Re: xfsdump max file size References: <3E249449.50909@bus.okstate.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 907 Lines: 30 Jason Joines wrote: > What's the maximum file size for a file to be dumped by xfsdump? xfsdump doesn't (really) have a maximum file size limitation. There is a maximum file size defined in xfsdump/dump/content.c but it is set to the largest theoretical file size, 18 million terabytes. The definition is defined in bytes: /* max "unsigned long long int" */ #define ULONGLONG_MAX 18446744073709551615LLU Obviously this maximum limit is impossible to hit, which is why I say xfsdump doesn't have a max file size limit. You should be able to dump the biggest possible file you can create. There is, however, a command line option (-z) to set a maximum file size for your dump. This option allows you to specify a maximum file size, in kilobytes. Files over this size will be excluded from the dump. -- Mandy Kirkconnell SGI, Storage Software Engineer alkirkco@sgi.com 651-683-3422 From owner-linux-xfs@oss.sgi.com Tue Jan 14 23:31:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 23:31:54 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0F7Vl3v030341 for ; Tue, 14 Jan 2003 23:31:47 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.55.176]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0F5bxG8029694 for ; Tue, 14 Jan 2003 21:38:00 -0800 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id SAA18298 for linux-xfs@oss.sgi.com; Wed, 15 Jan 2003 18:36:50 +1100 Date: Wed, 15 Jan 2003 18:36:50 +1100 From: FSG QA Message-Id: <200301150736.SAA18298@bruce.melbourne.sgi.com> Subject: TAKE - acl X-archive-position: 2314 X-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: 799 Lines: 33 Check in Andreas Gruenbacher's patch for setfacl. Add 'X' permission specification for setfacl. --Tim Date: Tue Jan 14 23:34:06 PST 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:136921a cmd/acl/VERSION - 1.41 - Add 'X' permission specification for setfacl. cmd/acl/doc/CHANGES - 1.48 - Add 'X' permission specification for setfacl. cmd/acl/man/man1/setfacl.1 - 1.9 - Add 'X' permission specification for setfacl. cmd/acl/setfacl/sequence.h - 1.2 - Add 'X' permission specification for setfacl. cmd/acl/setfacl/parse.c - 1.4 - Add 'X' permission specification for setfacl. cmd/acl/setfacl/do_set.c - 1.11 - Add 'X' permission specification for setfacl. From owner-linux-xfs@oss.sgi.com Tue Jan 14 23:52:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Jan 2003 23:52:43 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0F7qd3v030931 for ; Tue, 14 Jan 2003 23:52:40 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 7A2FAAC4C for ; Wed, 15 Jan 2003 09:04:29 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id F1B9019097 for ; Wed, 15 Jan 2003 09:04:20 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 3D07930881E for ; Wed, 15 Jan 2003 08:58:39 +0100 (CET) Message-ID: <3E2514AF.B384F161@ch.sauter-bc.com> Date: Wed, 15 Jan 2003 08:58:39 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: Re: Corruption on ext3 with XFS kernel References: <3E22A504.3280C4C6@ch.sauter-bc.com> <3E22A889.70203@koschikode.com> <3E242C00.47E95E68@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2315 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 2199 Lines: 55 Simon Matter schrieb: > > Juri Haberland schrieb: > > > > Simon Matter wrote: > > > Hi, > > > > > > I have seven IBM deathstar 60G disks here which have been replaced. I > > > want to use four of them in my home server so I wanted to do some tests > > > to make sure they don't break in the first week. I have connected four > > > drives to a Promise Ultra100TX2 IDE controller and put it into my test > > > server. The box is running kernel-2.4.18-18SGI_XFS_1.2pre3. I have > > > created a softraid5 on the disks creating a 180G device. I then created > > > an ext3 fs with default settings. Mounted the fs on /mnt/md9, mounted my > > > real servers data on /mnt/nfs. Then I used cp -a /mnt/nfs > > > /mnt/md9/nfs[n] five times creating five identical copies of the nfs > > > mounted data (/mnt/md9/nfs1, /mnt/md9/nfs2...) with a size of 28G in > > > 16500 file in each copy (143G used / 81%). > > > Then I did two times five diff's running at the same time and I was very > > > surprised what came out: > > > > [SNIP] > > > > > Now, it looks like a problem with ext3. My question is, could it have > > > _something_ to do with the XFS patch in this kernel? Did anybody do > > > similar tests? Unfortunately this box has XFS root so I can't just > > > switch to vanilla or original RedHat kernel and every test takes me > > > ~1day. Is there a way to find out what's going wrong here? > > > > You can try to apply the three bugfix-patches for 2.4.20/ext3 at > > http://www.zip.com.au/~akpm/linux/ext3/ (see "Updates for the 2.4.20 > > kernel"). > > RedHat has an updated kernel too, but this kernel fixes a problem which > only affects ext3 filesystems mounted with data=journal, see > http://rhn.redhat.com/errata/RHBA-2002-292.html > > I have now tested the same with 2.4.9-34SGI_XFS_1.1 and the error > doesn't occur. My next step is building kernel-2.4.18-19SGI_XFS_1.2pre5, > which is the newest errata kernel and XFS 1.2pre5 added. For the archives: I have not compiled the kernel mentioned above but installed the original RedHat errata kernel on a new root fs. Did the same tests and the fs corruption is still there! Time for bugzilla. Simon > > Simon > > > > > Regards, > > Juri From owner-linux-xfs@oss.sgi.com Wed Jan 15 00:16:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 00:16:33 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0F8GO3v031962 for ; Wed, 15 Jan 2003 00:16:26 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0F8MXM2076012; Wed, 15 Jan 2003 09:22:33 +0100 (CET) Message-Id: <4.3.2.7.2.20030115091833.03406828@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Jan 2003 09:22:29 +0100 To: Simon Matter , linux-xfs From: Seth Mos Subject: Re: Corruption on ext3 with XFS kernel In-Reply-To: <3E2514AF.B384F161@ch.sauter-bc.com> References: <3E22A504.3280C4C6@ch.sauter-bc.com> <3E22A889.70203@koschikode.com> <3E242C00.47E95E68@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 890 Lines: 24 At 08:58 15-1-2003 +0100, Simon Matter wrote: >Simon Matter schrieb: > > I have now tested the same with 2.4.9-34SGI_XFS_1.1 and the error > > doesn't occur. My next step is building kernel-2.4.18-19SGI_XFS_1.2pre5, > > which is the newest errata kernel and XFS 1.2pre5 added. > >For the archives: >I have not compiled the kernel mentioned above but installed the >original RedHat errata kernel on a new root fs. Did the same tests and >the fs corruption is still there! Time for bugzilla. Yes, and this kernel tree already has a lot of bug reports. More so then the previous kernels. The tg3 hangs of your system combined with some systems nog booting with an smp kernel makes for a flaky kernl. My gut says changing something drastically might be a good way to solve it, if the subtle touches don't work ofcourse. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jan 15 00:46:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 00:46:26 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0F8kM3v000820 for ; Wed, 15 Jan 2003 00:46:23 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id F242FAC40; Wed, 15 Jan 2003 09:58:13 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 544A1190D3; Wed, 15 Jan 2003 09:57:57 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 3A1C630881D; Wed, 15 Jan 2003 09:52:15 +0100 (CET) Message-ID: <3E25213F.E87983A2@ch.sauter-bc.com> Date: Wed, 15 Jan 2003 09:52:15 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Seth Mos Cc: linux-xfs Subject: Re: Corruption on ext3 with XFS kernel References: <3E22A504.3280C4C6@ch.sauter-bc.com> <3E22A889.70203@koschikode.com> <3E242C00.47E95E68@ch.sauter-bc.com> <4.3.2.7.2.20030115091833.03406828@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1076 Lines: 33 Seth Mos schrieb: > > At 08:58 15-1-2003 +0100, Simon Matter wrote: > >Simon Matter schrieb: > > > I have now tested the same with 2.4.9-34SGI_XFS_1.1 and the error > > > doesn't occur. My next step is building kernel-2.4.18-19SGI_XFS_1.2pre5, > > > which is the newest errata kernel and XFS 1.2pre5 added. > > > >For the archives: > >I have not compiled the kernel mentioned above but installed the > >original RedHat errata kernel on a new root fs. Did the same tests and > >the fs corruption is still there! Time for bugzilla. > > Yes, and this kernel tree already has a lot of bug reports. More so then > the previous kernels. The tg3 hangs of your system combined with some > systems nog booting with an smp kernel makes for a flaky kernl. I'm sure I know why RedHat Advances Server still uses the 2.4.9-34 series. > > My gut says changing something drastically might be a good way to solve it, Well, they could switch the filesystem.... > if the subtle touches don't work ofcourse. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jan 15 01:18:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 01:18:29 -0800 (PST) Received: from web14606.mail.yahoo.com (web14606.mail.yahoo.com [216.136.224.86]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0F9IN3v002120 for ; Wed, 15 Jan 2003 01:18:24 -0800 Message-ID: <20030115092433.84127.qmail@web14606.mail.yahoo.com> Received: from [202.188.158.195] by web14606.mail.yahoo.com via HTTP; Wed, 15 Jan 2003 01:24:33 PST Date: Wed, 15 Jan 2003 01:24:33 -0800 (PST) From: Arindam Dey Subject: XFS with RH 7.3 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lfsdeveloper@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1138 Lines: 41 Hi all, I used the RedHat installer with XFS provided on the download site to install XFS on my system along with RH 7.3. I did not compile my kernel did NOT do any changes at all. Just used the default options. This is the first time i am trying out XFS so did not mess around. At the end, when the time to create bootdisk came the Installer consistently failed initially i attributed this to the floppies i had. When the system booted up then i tried to create the bootdisk again using mkbootdisk 2.4.**** but it failed saying unable to locate the root partition. The fstab had LABEL defined for the partitions which RH uses upon removing the LABEL=/ with the proper /dev/hda* mkbootdisk started working. But i tried the same thing on an RH 7.3 m/c and mkbootdisk works even with the LABEL=/. Anybody there who could point me to the right direction???? Sorry for the long mail. Thanks in advance, Arindam Dey ===== The mind is not a vessel to be filled but a fire to be kindled. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-linux-xfs@oss.sgi.com Wed Jan 15 04:34:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 04:34:23 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@dhcp024-208-195-177.indy.rr.com [24.208.195.177]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FCYG3v013055 for ; Wed, 15 Jan 2003 04:34:17 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 921564B7EA4; Wed, 15 Jan 2003 07:40:34 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id A4B0E4B7E7A; Wed, 15 Jan 2003 07:40:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 7D8A8C026BC; Wed, 15 Jan 2003 07:40:31 -0500 (EST) Date: Wed, 15 Jan 2003 07:40:31 -0500 (EST) From: Mike Burger To: Arindam Dey Cc: linux-xfs@oss.sgi.com Subject: Re: XFS with RH 7.3 In-Reply-To: <20030115092433.84127.qmail@web14606.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 2319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 1365 Lines: 42 As I recall, this is fairly common...the kernel that ships with the installer is a bit too large. Try looking for one of the kernel RPMs with the word "BOOT" in the package name. These are the right size for floppy boot disk creation. On Wed, 15 Jan 2003, Arindam Dey wrote: > Hi all, > > I used the RedHat installer with XFS provided on the > download site to install XFS on my system along with > RH 7.3. I did not compile my kernel did NOT do any > changes at all. Just used the default options. This is > the first time i am trying out XFS so did not mess > around. > > At the end, when the time to create bootdisk came the > Installer consistently failed initially i attributed > this to the floppies i had. > > When the system booted up then i tried to create the > bootdisk again using mkbootdisk 2.4.**** but it failed > saying unable to locate the root partition. > > The fstab had LABEL defined for the partitions which > RH uses upon removing the LABEL=/ with the proper > /dev/hda* mkbootdisk started working. But i tried the > same thing on an RH 7.3 m/c and mkbootdisk works even > with the LABEL=/. > > Anybody there who could point me to the right > direction???? > > Sorry for the long mail. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 From owner-linux-xfs@oss.sgi.com Wed Jan 15 04:43:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 04:43:49 -0800 (PST) Received: from K-7.stesmi.com (root@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FChf3v013554 for ; Wed, 15 Jan 2003 04:43:42 -0800 Received: from stesmi.com (stesmi@as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.4/8.12.4) with ESMTP id h0FCnk4C011397 for ; Wed, 15 Jan 2003 13:49:47 +0100 Message-ID: <3E2558EA.80409@stesmi.com> Date: Wed, 15 Jan 2003 13:49:46 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [ANNOUNCE] RedHat 8.0 XFS DVD v0.0.9 Released Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by K-7.stesmi.com id h0FCnk4C011397 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0FChh3v013555 X-archive-position: 2320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 2387 Lines: 60 Hi. A new version of the RedHat 8.0 XFS DVD has been released. It can be fetched from ftp://ftp.uninett.no/pub/linux/RH-XFS-DVD/ It should be up within an hour or so. What's on this DVD: * RedHat 8.0 "Psyche" CDs 1-5, including the SRPMS. * All updates that were released up to and including 2003-01-14 at 21:30 GMT. They are installed automatically when the system is installed. The DVD does not contain the old RPMS. * The installer from the XFS 1.2pre1 release from SGI. * All RPMS from the XFS 1.2pre5 release from SGI. Version history: 0.0.1 2002-12-xx Initial version. Not released. Worked fine. I could even verify the DVD with the MD5 function of the installer. Had the bug that made it ask for the XFS CD after verifying MD5. 0.0.2 2002-12-xx Updated version. Contained a few extra RPMS in the contrib directory. Minor tweaks. Not released. Had a fix for the problem above. 0.0.3 2002-12-xx Same as 0.0.2 but this time I didn't forget to implant the MD5 sum into the image (stupid me). Not released. 0.0.4 2002-12-12 Added latest updates. Verified it works from a DVD-RW. Not released. 0.0.5 2002-12-13 Added latest updates: httpd and mod_ssl. Finished my script that I use to build the DVD with. Not released. 0.0.6 2002-12-18 The ethernet and pcmcia on the laptop died and I had the whole build system on there. Took some time to get the relevant info off of it and start building again. SGI also released 1.2pre4 of the kernel so I updated all files to that. Added updated net-snmp. Not released. 0.0.7 2002-12-20 Found out that the kernel from 1.2pre4 is wrong so I waited for the respin to come out and released it when it had. No other changes. First public release. 0.0.8 2003-01-10 Updated a few RPMs. No other changes. Not really released. 0.0.9 2003-01-15 Updated some more RPMs. Switched to 1.2pre5 from SGI. Thanx must go to: (In no particular order) Nicolai Langfeldt Ragnar Kjørstad George Georgalis Ajay Ramaswamy Russel Cattelan Eric Sandeen Nathan Straz and the rest of the XFS team! This DVD wouldn't have existed without you! // Stefan From owner-linux-xfs@oss.sgi.com Wed Jan 15 04:45:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 04:45:43 -0800 (PST) Received: from silver.digirati.com.br (silver.digirati.com.br [200.185.109.126]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FCjd3v013994 for ; Wed, 15 Jan 2003 04:45:40 -0800 Received: from wsmichel (RJ227107.user.veloxzone.com.br [200.165.227.107]) (authenticated (0 bits)) by silver.digirati.com.br (8.11.6/8.11.6) with ESMTP id h0FCpjP16174 for ; Wed, 15 Jan 2003 10:51:46 -0200 Message-ID: <007601c2bc94$dfc58240$1601070a@mz.digirati.com.br> From: "Michel Machado" To: References: Subject: Elevator algorithm Date: Wed, 15 Jan 2003 10:51:45 -0200 Organization: Digirati MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 2321 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michel@digirati.com.br Precedence: bulk X-list: linux-xfs Content-Length: 188 Lines: 10 Hi, Does the Linux I/O elevator algorithm (http://lwn.net/2000/1123/kernel.php3) work well with XFS? Does the XFS work better with elevator enable or disable? [ ]'s Michel Machado From owner-linux-xfs@oss.sgi.com Wed Jan 15 05:48:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 05:49:00 -0800 (PST) Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FDmo3v014866 for ; Wed, 15 Jan 2003 05:48:51 -0800 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id h0FDsxs20240 for linux-xfs@oss.sgi.com.KAV; Wed, 15 Jan 2003 14:54:59 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id h0FDswU20232 for ; Wed, 15 Jan 2003 14:54:59 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h0FDsOwc004423 for ; Wed, 15 Jan 2003 14:54:25 +0100 Subject: How to make filenames case insensitive From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 15 Jan 2003 14:54:24 +0100 Message-Id: <1042638865.2612.9.camel@venus> Mime-Version: 1.0 X-archive-position: 2322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 473 Lines: 23 Hi, I have many CDs copied onto disk. They contain documentation in PDF files. The files are linked each other. But I'm unable to use them because they were created in Windows, and they have filenames in wrong case eg: I have file XXX and YYY I open XXX, and I have a link Yyy, so acrobat reader fails to open it. I can use these CDs when mounted with option check=relaxed, but XFS doesn't have this option. What can I do to get it working? Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Wed Jan 15 06:23:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 06:23:07 -0800 (PST) Received: from morrigan.bus.okstate.edu (morrigan.bus.okstate.edu [139.78.88.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FEN43v016190 for ; Wed, 15 Jan 2003 06:23:04 -0800 Received: from bus.okstate.edu (joines.bus.okstate.edu [139.78.89.31]) by morrigan.bus.okstate.edu (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h0FESxsf021977 for ; Wed, 15 Jan 2003 08:29:00 -0600 Message-ID: <3E256FEC.30206@bus.okstate.edu> Date: Wed, 15 Jan 2003 08:27:56 -0600 From: Jason Joines User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030112 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux XFS Users Subject: Re: xfsdump max file size References: <3E249449.50909@bus.okstate.edu> <3E24BEAE.1080604@sgi.com> In-Reply-To: <3E24BEAE.1080604@sgi.com> X-Enigmail-Version: 0.71.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joines@bus.okstate.edu Precedence: bulk X-list: linux-xfs Content-Length: 1156 Lines: 34 Mandy Kirkconnell wrote: > Jason Joines wrote: > >> What's the maximum file size for a file to be dumped by xfsdump? > > > > xfsdump doesn't (really) have a maximum file size limitation. There > is a maximum file size defined in xfsdump/dump/content.c but it is set > to the largest theoretical file size, 18 million terabytes. The > definition is defined in bytes: > > /* max "unsigned long long int" > */ > #define ULONGLONG_MAX 18446744073709551615LLU > > Obviously this maximum limit is impossible to hit, which is why I say > xfsdump doesn't have a max file size limit. You should be able to > dump the biggest possible file you can create. > > There is, however, a command line option (-z) to set a maximum file > size for your dump. This option allows you to specify a maximum file > size, in kilobytes. Files over this size will be excluded from the > dump. > When running a dump with "xfsdump -F -e -f /local/backup/weekly/sdb3.dmp -l 0 /dev/sdb3" I get the message, "xfsdump: WARNING: could not open regular file ino 4185158 mode 0x000081b0: File too large: not dumped". The file in question is 5.0 GB. Jason =========== From owner-linux-xfs@oss.sgi.com Wed Jan 15 07:28:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 07:28:44 -0800 (PST) Received: from imf12bis.bellsouth.net (mail012.mail.bellsouth.net [205.152.58.32]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FFSb3v017167 for ; Wed, 15 Jan 2003 07:28:38 -0800 Received: from marsha ([66.156.0.183]) by imf12bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030115153637.TUXB19222.imf12bis.bellsouth.net@marsha>; Wed, 15 Jan 2003 10:36:37 -0500 Date: Wed, 15 Jan 2003 10:34:47 -0500 From: Greg Freemyer Subject: re: How to make filenames case insensitive To: Olaf Fr±czyk , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20030115153637.TUXB19222.imf12bis.bellsouth.net@marsha> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0FFSc3v017168 X-archive-position: 2324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 662 Lines: 22 If XFS doesn't have a native way, you could export them via samba, then mount them to an alternate mount point with smbmount. >> Hi, >> I have many CDs copied onto disk. >> They contain documentation in PDF files. >> The files are linked each other. >> But I'm unable to use them because they were created in Windows, and >> they have filenames in wrong case eg: >> I have file XXX and YYY >> I open XXX, and I have a link Yyy, so acrobat reader fails to open it. >> I can use these CDs when mounted with option check=relaxed, but XFS >> doesn't have this option. >> What can I do to get it working? >> Regards, >> Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Wed Jan 15 07:35:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 07:35:07 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FFZ33v017627 for ; Wed, 15 Jan 2003 07:35:03 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FElFKp028206 for ; Wed, 15 Jan 2003 06:47:15 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA40366; Wed, 15 Jan 2003 09:41:05 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA83630; Wed, 15 Jan 2003 09:41:07 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h0FFf7V16366; Wed, 15 Jan 2003 09:41:07 -0600 Subject: re: How to make filenames case insensitive From: Steve Lord To: Greg Freemyer Cc: Olaf =?ISO-8859-1?Q?Fr=B1czyk?= , linux-xfs@oss.sgi.com In-Reply-To: <20030115153637.TUXB19222.imf12bis.bellsouth.net@marsha> References: <20030115153637.TUXB19222.imf12bis.bellsouth.net@marsha> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042645267.16153.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 15 Jan 2003 09:41:07 -0600 X-archive-position: 2325 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1062 Lines: 29 On Wed, 2003-01-15 at 09:34, Greg Freemyer wrote: > If XFS doesn't have a native way, you could export them via samba, then mount them to an alternate mount point with smbmount. > > > >> Hi, > > >> I have many CDs copied onto disk. > >> They contain documentation in PDF files. > >> The files are linked each other. > >> But I'm unable to use them because they were created in Windows, and > >> they have filenames in wrong case eg: > >> I have file XXX and YYY > >> I open XXX, and I have a link Yyy, so acrobat reader fails to open it. > >> I can use these CDs when mounted with option check=relaxed, but XFS > >> doesn't have this option. > >> What can I do to get it working? > XFS does not have a native way, there has been someone working on a case insensitive XFS, but that involved changing the hash algorithm XFS uses internally and on the disk, so it would not help here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 15 07:52:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 07:52:29 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FFqP3v018138 for ; Wed, 15 Jan 2003 07:52:25 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FG64kq009879 for ; Wed, 15 Jan 2003 10:06:04 -0600 Received: from sgi.com (syntegra.americas.sgi.com [128.162.232.81]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h0FFvTQb51798023; Wed, 15 Jan 2003 07:57:30 -0800 (PST) Message-ID: <3E2584E8.8080102@sgi.com> Date: Wed, 15 Jan 2003 09:57:28 -0600 From: Mandy Kirkconnell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Joines CC: Linux XFS Users Subject: Re: xfsdump max file size References: <3E249449.50909@bus.okstate.edu> <3E24BEAE.1080604@sgi.com> <3E256FEC.30206@bus.okstate.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1841 Lines: 58 Jason Joines wrote: > Mandy Kirkconnell wrote: > >> Jason Joines wrote: >> >>> What's the maximum file size for a file to be dumped by xfsdump? >> >> >> xfsdump doesn't (really) have a maximum file size limitation. There >> is a maximum file size defined in xfsdump/dump/content.c but it is >> set to the largest theoretical file size, 18 million terabytes. The >> definition is defined in bytes: >> >> /* max "unsigned long long int" >> */ >> #define ULONGLONG_MAX 18446744073709551615LLU >> >> Obviously this maximum limit is impossible to hit, which is why I say >> xfsdump doesn't have a max file size limit. You should be able to >> dump the biggest possible file you can create. >> >> There is, however, a command line option (-z) to set a maximum file >> size for your dump. This option allows you to specify a maximum file >> size, in kilobytes. Files over this size will be excluded from the >> dump. >> > When running a dump with "xfsdump -F -e -f > /local/backup/weekly/sdb3.dmp -l 0 /dev/sdb3" I get the message, > "xfsdump: WARNING: could not open regular file ino 4185158 mode > 0x000081b0: File too large: not dumped". The file in question is 5.0 GB. > > Jason > =========== > xfsdump does not set EFBIG (errno 27) anywhere. It looks like the error is coming from the filesystem on the first attempt to open the file. What version of xfs are you running? Are you using the released version of xfsdump, or have you built your own copy? Perhaps you could also use xfs_db to look at the extents of the file: # xfs_db -r /dev/sdb3 xfs_db: inode 4185158 p We are able to dump a file of 4.5 GB without hitting the error. Perhaps we can figure out what's different between our environments and go from there. -- Mandy Kirkconnell SGI, Storage Software Engineer alkirkco@sgi.com 651-683-3422 From owner-linux-xfs@oss.sgi.com Wed Jan 15 08:08:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 08:08:13 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FG8B3v018763 for ; Wed, 15 Jan 2003 08:08:11 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FGLokq010400 for ; Wed, 15 Jan 2003 10:21:50 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA34175; Wed, 15 Jan 2003 10:14:16 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA57280; Wed, 15 Jan 2003 10:14:16 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h0FGEGA17398; Wed, 15 Jan 2003 10:14:16 -0600 Subject: Re: Elevator algorithm From: Steve Lord To: Michel Machado Cc: linux-xfs@oss.sgi.com In-Reply-To: <007601c2bc94$dfc58240$1601070a@mz.digirati.com.br> References: <007601c2bc94$dfc58240$1601070a@mz.digirati.com.br> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042647255.16150.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 15 Jan 2003 10:14:16 -0600 X-archive-position: 2327 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 411 Lines: 18 On Wed, 2003-01-15 at 06:51, Michel Machado wrote: > Hi, > > Does the Linux I/O elevator algorithm > (http://lwn.net/2000/1123/kernel.php3) work well with XFS? > > Does the XFS work better with elevator enable or disable? > Enabled should be better. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 15 08:22:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 08:22:06 -0800 (PST) Received: from virtualhost.dk (mail@ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FGM03v019270 for ; Wed, 15 Jan 2003 08:22:01 -0800 Received: from brick.kernel.dk ([80.160.188.86] helo=burns.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.35 #1) id 18YqOf-0001Fl-00; Wed, 15 Jan 2003 17:28:09 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 4.10) id 18YqOX-0000Vi-00; Wed, 15 Jan 2003 17:28:01 +0100 Date: Wed, 15 Jan 2003 17:28:01 +0100 From: Jens Axboe To: Steve Lord , Michel Machado Cc: linux-xfs@oss.sgi.com Subject: Re: Elevator algorithm Message-ID: <20030115162801.GF1713@suse.de> References: <007601c2bc94$dfc58240$1601070a@mz.digirati.com.br> <1042647255.16150.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1042647255.16150.6.camel@jen.americas.sgi.com> X-archive-position: 2328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 453 Lines: 18 On Wed, Jan 15 2003, Steve Lord wrote: > On Wed, 2003-01-15 at 06:51, Michel Machado wrote: > > Hi, > > > > Does the Linux I/O elevator algorithm > > (http://lwn.net/2000/1123/kernel.php3) work well with XFS? > > > > Does the XFS work better with elevator enable or disable? > > > > Enabled should be better. Very much so. Note that the url above has little, if any, relevance to 2.4 and 2.5 today. 2.5 is radically different. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Jan 15 09:16:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 09:17:05 -0800 (PST) Received: from morrigan.bus.okstate.edu (morrigan.bus.okstate.edu [139.78.88.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FHGv3v021213 for ; Wed, 15 Jan 2003 09:16:58 -0800 Received: from bus.okstate.edu (joines.bus.okstate.edu [139.78.89.31]) by morrigan.bus.okstate.edu (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h0FHMrsf023295 for ; Wed, 15 Jan 2003 11:22:54 -0600 Message-ID: <3E2598AD.5030502@bus.okstate.edu> Date: Wed, 15 Jan 2003 11:21:49 -0600 From: Jason Joines User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030112 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux XFS Users Subject: Re: xfsdump max file size References: <3E249449.50909@bus.okstate.edu> <3E24BEAE.1080604@sgi.com> <3E256FEC.30206@bus.okstate.edu> <3E2584E8.8080102@sgi.com> In-Reply-To: <3E2584E8.8080102@sgi.com> X-Enigmail-Version: 0.71.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joines@bus.okstate.edu Precedence: bulk X-list: linux-xfs Content-Length: 2925 Lines: 97 Mandy Kirkconnell wrote: > > Jason Joines wrote: > >> Mandy Kirkconnell wrote: >> >>> Jason Joines wrote: >>> >>>> What's the maximum file size for a file to be dumped by xfsdump? >>> >>> >>> >>> xfsdump doesn't (really) have a maximum file size limitation. There >>> is a maximum file size defined in xfsdump/dump/content.c but it is >>> set to the largest theoretical file size, 18 million terabytes. The >>> definition is defined in bytes: >>> >>> /* max "unsigned long long int" >>> */ >>> #define ULONGLONG_MAX 18446744073709551615LLU >>> >>> Obviously this maximum limit is impossible to hit, which is why I >>> say xfsdump doesn't have a max file size limit. You should be able >>> to dump the biggest possible file you can create. >>> >>> There is, however, a command line option (-z) to set a maximum file >>> size for your dump. This option allows you to specify a maximum >>> file size, in kilobytes. Files over this size will be excluded >>> from the dump. >>> >> When running a dump with "xfsdump -F -e -f >> /local/backup/weekly/sdb3.dmp -l 0 /dev/sdb3" I get the message, >> "xfsdump: WARNING: could not open regular file ino 4185158 mode >> 0x000081b0: File too large: not dumped". The file in question is 5.0 >> GB. >> >> Jason >> =========== >> > xfsdump does not set EFBIG (errno 27) anywhere. It looks like the > error is coming from the filesystem on the first attempt to open the > file. What version of xfs are you running? Are you using the released > version of xfsdump, or have you built your own copy? > > Perhaps you could also use xfs_db to look at the extents of the file: > > # xfs_db -r /dev/sdb3 > xfs_db: inode 4185158 p > > We are able to dump a file of 4.5 GB without hitting the error. > Perhaps we can figure out what's different between our environments > and go from there. > Actually, I'm not quite sure what version of xfs it is. How do I tell? I am using a 2.4.18 kernel compiled by SuSE. I installed and looked at the source for this kernel but couldn't find anything that said what version of xfs it is. My xfsdump version is version 3.0. It is from a SuSE rpm as well. xfs_db gave: # xfs_db -r /dev/sdb3 xfs_db: inode 4185158 xfs_db: p core.magic = 0xfeff core.mode = 0 core.version = 4 core.format = 0 (dev) core.uid = 0 core.gid = 0 core.atime.sec = Wed Dec 6 15:33:04 1916 core.atime.nsec = -1818818560 core.mtime.sec = Mon Dec 14 15:16:30 1992 core.mtime.nsec = 1140850688 core.ctime.sec = Tue Feb 6 19:52:21 1973 core.ctime.nsec = -1674700016 core.size = -7811766231833445970 core.nblocks = 5764888998212337664 core.extsize = 201326592 core.nextents = 16777216 core.naextents = 26624 core.forkoff = 0 core.aformat = 0 (dev) core.dmevmask = 0xf000000 core.dmstate = 28672 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.gen = 83886080 next_unlinked = 2483027968 u.dev = 0x6000000 xfs_db: q Jason =========== From owner-linux-xfs@oss.sgi.com Wed Jan 15 09:26:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 09:27:24 -0800 (PST) Received: from akira.ep-ka.de (akira.ep-ag.com [194.120.231.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FHQq3v021706 for ; Wed, 15 Jan 2003 09:26:54 -0800 Received: from eigner.com ([194.120.231.18]) by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id SAA08319; Wed, 15 Jan 2003 18:30:06 +0100 Message-ID: <3E259AD6.7010709@eigner.com> Date: Wed, 15 Jan 2003 18:31:02 +0100 From: Klaus Strebel Organization: EIGNER Germany GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?Olaf_Fr=B1czyk?= CC: linux-xfs@oss.sgi.com Subject: Re: How to make filenames case insensitive References: <1042638865.2612.9.camel@venus> In-Reply-To: <1042638865.2612.9.camel@venus> Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-MailScanner: Found to be clean X-MIME-Autoconverted: from 8bit to quoted-printable by akira.ep-ka.de id SAA08319 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0FHQs3v021708 X-archive-position: 2330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@eigner.com Precedence: bulk X-list: linux-xfs Content-Length: 734 Lines: 32 Olaf Fr±czyk wrote: > Hi, > > I have many CDs copied onto disk. > They contain documentation in PDF files. > The files are linked each other. > But I'm unable to use them because they were created in Windows, and > they have filenames in wrong case eg: > I have file XXX and YYY > I open XXX, and I have a link Yyy, so acrobat reader fails to open it. > I can use these CDs when mounted with option check=relaxed, but XFS > doesn't have this option. > What can I do to get it working? Well, me method with less effort will be just doing symlinks from YYY to Yyy: ln -s YYY Yyy and that's it. Ciao Klaus -- Klaus Strebel UNIX-Engineer klaus.strebel@eigner.com EIGNER - Precision Lifecycle Management - From owner-linux-xfs@oss.sgi.com Wed Jan 15 10:50:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 10:50:44 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FIod3v031574 for ; Wed, 15 Jan 2003 10:50:41 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18YshH-0005sY-00 for ; Wed, 15 Jan 2003 19:55:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18YshC-0005rq-00 for ; Wed, 15 Jan 2003 19:55:26 +0100 Path: wassern.consult-meyers.com!news From: "A. L. Meyers" Subject: Re: xfs fails as / with Debian GNU/Linux 2.4.18-smp - 2nd post Date: Wed, 15 Jan 2003 19:39:57 +0100 Organization: Meyers Consulting http://www.consult-meyers.com Message-ID: <87el7ei7eq.fsf@wassern.consult-meyers.com> References: <20030114221139.GA4264@f00f.org> <3E248C8B.9020908@mnsu.edu> <20030114223643.GA4462@f00f.org> Reply-To: "A. L. Meyers" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2 (i386-debian-linux-gnu) Cancel-Lock: sha1:5QzTRm81kYXbhoKnkmkrhwWApnM= X-archive-position: 2331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: me@privacy.net Precedence: bulk X-list: linux-xfs Content-Length: 1388 Lines: 43 Chris Wedgwood writes: > On Tue, Jan 14, 2003 at 04:17:47PM -0600, Jeffrey E. Hundstad wrote: > >> BTW: could you also get around your problem by putting ms-dos fs in >> as a module? > > yes, that will also work > > however, fatfs really needs to be fixed > > --cw Have no modules at all with the kernel, BSD-style. Here is fstab: # /etc/fstab: static file system information. # # /dev/hda2 / ext3 errors=remount-ro 0 1 /dev/sda1 none swap sw 0 0 /dev/hda3 none swap sw 0 0 proc /proc proc defaults 0 0 /dev/fd0 /floppy auto user,noauto 0 0 /dev/cdrom /cdrom iso9660 ro,user,noauto 0 0 /dev/scd0 /cdrom1 iso9660 ro,user,noauto 0 0 /dev/scd1 /cdrom2 iso9660 ro,user,noauto 0 0 /dev/hda5 /tmp xfs defaults 0 2 /dev/hda6 /var xfs defaults 0 2 /dev/hda7 /home xfs defaults 0 2 /dev/hda8 /opt xfs defaults 0 2 /dev/hda9 /usr xfs defaults 0 2 /dev/hda10 /usr/local xfs defaults 0 2 /dev/sda2 /mnt/ibm xfs noauto 0 0 /dev/hda1 /mnt/vfat vfat user,noauto 0 0 Please note that /dev/hda2 would be the xfs / partition. Lucien -- If you receive this by error, please delete it and inform the sender. PGP key fingerprint=F1C0 D9AE 1B18 1405 4DFA B4CC 6DC7 FF78 C76E FB15 To Big Brother Echelon from "spook": opus dei NSA class struggle NORAD cracking KGB Rule Psix cryptographic From owner-linux-xfs@oss.sgi.com Wed Jan 15 10:59:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 10:59:24 -0800 (PST) Received: from www.promopipe.com ([66.70.114.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FIxK3v032089 for ; Wed, 15 Jan 2003 10:59:20 -0800 Received: (qmail 22495 invoked from network); 15 Jan 2003 18:40:14 -0000 Received: from localhost (HELO www.promopipe.com) (127.0.0.1) by localhost with SMTP; 15 Jan 2003 18:40:14 -0000 Received: from 128.138.134.61 (SquirrelMail authenticated user hartwigm) by www.bouldercustomhomes.com with HTTP; Wed, 15 Jan 2003 13:40:14 -0500 (EST) Message-ID: <1385.128.138.134.61.1042656014.squirrel@www.bouldercustomhomes.com> Date: Wed, 15 Jan 2003 13:40:14 -0500 (EST) Subject: nfs and xfs on 1.1T partition From: "Mark Hartwig" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Reply-To: hartwigm@BoulderCustomHomes.com X-Mailer: SquirrelMail (version 1.2.4) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hartwigm@BoulderCustomHomes.com Precedence: bulk X-list: linux-xfs Content-Length: 1365 Lines: 26 Hello all, I'm having a problem with nfsd (from Mandrake 9.0 install 2.4.19 kernel) on a xfs partition. I am running an IDE RAID5 with 3Ware's Escalade 7500 controller. The xfs partition as 1.1T. I can nfs cp large ammounts of small files on to the xfs partition without any problems, but as soon as I try to transfer a large file to the partition, the entire server freezes when about 200 megs have been transfered. At this point, the server is completely frozen and can only be restarted manually. I can, however, nfs cp large files to the same server, but on to a smaller 100G ext3 partition. All other disk-intensive processes cause the xfs partition no problems, other than NFS. I can scp, rcp, rsh, and rsync to and from the XFS partition perfectly. I can also copy large files to and from it locally with no problems. The server seems to hang only when I transfer large files via NFS to or from the xfs partition. I can, for example, nfs cp -R a directory that is 1G to the xfs partition as long as each file within the directory is less than about 200M. However, a nfs cp of a single file that is 260M freezes the server every time. Ideally, I would like to find a work around the issue without having to re-format the entire RAID. Any help would be greatly appreciated. -- Mark Hartwig Boulder Custom Homes 720-530-4102 hartwigm@BoulderCustomHomes.com From owner-linux-xfs@oss.sgi.com Wed Jan 15 11:15:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 11:15:37 -0800 (PST) Received: from mx01.netapp.com (mx01.netapp.com [198.95.226.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FJFX3v032633 for ; Wed, 15 Jan 2003 11:15:33 -0800 Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01.netapp.com (8.12.6/8.12.6/NTAP-1.4) with ESMTP id h0FJLeYW012845 for ; Wed, 15 Jan 2003 11:21:40 -0800 (PST) Received: from ussvlexc01.corp.netapp.com (ussvlexc01.corp.netapp.com [10.10.22.169]) by frejya.corp.netapp.com (8.12.6/8.12.6/NTAP-1.4) with ESMTP id h0FJLeLq020309 for ; Wed, 15 Jan 2003 11:21:40 -0800 (PST) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 11:21:39 -0800 Message-ID: From: "Browning, Jeff" To: "'linux-xfs@oss.sgi.com'" Subject: XFS "lockfs" Functionality Date: Wed, 15 Jan 2003 11:21:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/related; boundary="----_=_NextPart_000_01C2BCCB.510F5D7E"; type="multipart/alternative" X-archive-position: 2333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeff.browning@netapp.com Precedence: bulk X-list: linux-xfs Content-Length: 13702 Lines: 379 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2BCCB.510F5D7E Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BCCB.510F5D7E" ------_=_NextPart_001_01C2BCCB.510F5D7E Content-Type: text/plain All: I am interested in being able to duplicate the functionality of the Solaris lockfs command on Linux. This command effectively does the following: 1. Flush all data in the local file system buffer cache to disk (effectively a synchronous sync); 2. Halt all pending I/O to the file system until unlockfs is issued. (If the file system is mounted hard, all processes attempting to access the file system simply hang for this period.) The reason I wish to do this is so that we can do a snapshot on this file system, and be reasonably sure that the file system will be clean when this event occurs. Can this be done with XFS? Any input you might provide would be appreciated. Regards, Jeff ------_=_NextPart_001_01C2BCCB.510F5D7E Content-Type: text/html Content-Transfer-Encoding: quoted-printable

All:

 

I am interested in being able to duplicate the functiona= lity of the Solaris lockfs command on Linux. This co= mmand effectively does the following:

 

= 1.     Fl= ush all data in the local file system buffer cache to disk (effectively a synchrono= us sync);

= 2.     Ha= lt all pending I/O to the file system until unlockfs is issued. (If the file system is mounted hard, all processes attempting to ac= cess the file system simply hang for this period.) =

 

The reason I wish to do this is so that we can do a snap= shot on this file system, and be reasonably sure that the file system will be cl= ean when this event occurs.

 

Can this be done with XFS? Any input you might provide w= ould be appreciated.

 

Regards,

Jeff

 

 

------_=_NextPart_001_01C2BCCB.510F5D7E-- ------_=_NextPart_000_01C2BCCB.510F5D7E Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="image001.jpg" Content-ID: /9j/4AAQSkZJRgABAgEASABIAAD/7QSqUGhvdG9zaG9wIDMuMAA4QklNA+kA AAAAAHgAAwAAAEgASAAAAAAC2gIo/+H/4QL5AkUDRwUoA/wAAgAAAEgASAAA AAAC2AIoAAEAAABkAAAAAQADAwMAAAABJw8AAQABAAAAAAAAAAAAAAAAYAgA GQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4QklNA+0AAAAA ABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoA AAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2Zm AAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYA AAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////// //////////////////8D6AAAAAD/////////////////////////////A+gA AAAA/////////////////////////////wPoAAAAAP////////////////// //////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIAADhCSU0E CAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBAkAAAAAApkAAAABAAAAgAAA AAEAAAGAAAABgAAAAn0AGAAB/9j/4AAQSkZJRgABAgEASABIAAD//gAnRmls ZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9iZQBk gAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwM EQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4U FA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDP/AABEIAAEAgAMBIgACEQEDEQH/3QAEAAj/xAE/AAABBQEBAQEBAQAA AAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj 80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQAC AgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi 4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhED EQA/APTqPon4/wAAir5XSQGyn6oSXyukip+qEl8rpJKfqhJfK6SSn6oSXyuk kp+qEl8rpJKfqhJfK6SSn6oSXyukkp//2QA4QklNBAYAAAAAAAcABAAAAAEB AP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0LjAA/+4A DkFkb2JlAGQAAAAAAf/bAIQABgQEBwUHCwYGCw4KCAoOEQ4ODg4RFhMTExMT FhEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAEHCQkTDBMi ExMiFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwM/8AAEQgAAwZAAwERAAIRAQMRAf/dAAQAyP/EAaIAAAAH AQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAAAQAC AwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEU MpGhBxWxQiPBUtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uII JoMJChgZhJRFRqS0VtNVKBry4/PE1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3 R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZqbnJ2en5KjpKWmp6 ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEy obHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZF GidkdFU38qOzwygp0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2 R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqK mqq6ytrq+v/aAAwDAQACEQMRAD8A9N/vv+Lv+SWFhv5/7F377/i7/kliu/n/ ALFbJ63H/dv0+lTFd/P/AGKj++/y/wDkliu/n/sVa29Tl8fSn7fCn/JPfFIR H/AYGTv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq 7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFX f8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wAB irv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gM Vd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Bi rv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+ AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/w GKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8A gMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3 /AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/ 4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd /wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq 7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFX f8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wAB irv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gM Vd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Bi rv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+ AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq/wD/2Q== ------_=_NextPart_000_01C2BCCB.510F5D7E-- From owner-linux-xfs@oss.sgi.com Wed Jan 15 11:19:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 11:19:40 -0800 (PST) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FJJZ3v000647 for ; Wed, 15 Jan 2003 11:19:37 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18YtAW-0005lB-00; Wed, 15 Jan 2003 19:25:44 +0000 Date: Wed, 15 Jan 2003 19:25:44 +0000 From: Christoph Hellwig To: "Browning, Jeff" Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: XFS "lockfs" Functionality Message-ID: <20030115192544.A22134@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jeff.browning@netapp.com on Wed, Jan 15, 2003 at 11:21:34AM -0800 X-archive-position: 2334 X-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: 278 Lines: 8 On Wed, Jan 15, 2003 at 11:21:34AM -0800, Browning, Jeff wrote: > > All: > > I am interested in being able to duplicate the functionality of the Solaris lockfs command on Linux. This command effectively does the following: You might want to try the XFS_IOC_FREEZE ioctl. From owner-linux-xfs@oss.sgi.com Wed Jan 15 11:21:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 11:21:56 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FJLr3v001109 for ; Wed, 15 Jan 2003 11:21:54 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FHS9G8007435 for ; Wed, 15 Jan 2003 09:28:09 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA76997; Wed, 15 Jan 2003 13:27:59 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 18YtCh-0008U9-00; Wed, 15 Jan 2003 13:27:59 -0600 Date: Wed, 15 Jan 2003 13:27:59 -0600 From: Nathan Straz To: "Browning, Jeff" Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: XFS "lockfs" Functionality Message-ID: <20030115192759.GD26512@sgi.com> Mail-Followup-To: "Browning, Jeff" , "'linux-xfs@oss.sgi.com'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 2335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 604 Lines: 14 On Wed, Jan 15, 2003 at 11:21:34AM -0800, Browning, Jeff wrote: > 1. Flush all data in the local file system buffer cache to disk > (effectively a synchronous sync); > 2. Halt all pending I/O to the file system until unlockfs is > issued. (If the file system is mounted hard, all processes attempting > to access the file system simply hang for this period.) man xfs_freeze -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Wed Jan 15 11:22:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 11:22:41 -0800 (PST) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FJMW3v001306 for ; Wed, 15 Jan 2003 11:22:38 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18YtDP-0005o5-00; Wed, 15 Jan 2003 19:28:43 +0000 Date: Wed, 15 Jan 2003 19:28:43 +0000 From: Christoph Hellwig To: Mark Hartwig Cc: linux-xfs@oss.sgi.com Subject: Re: nfs and xfs on 1.1T partition Message-ID: <20030115192843.B22134@infradead.org> References: <1385.128.138.134.61.1042656014.squirrel@www.bouldercustomhomes.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: <1385.128.138.134.61.1042656014.squirrel@www.bouldercustomhomes.com>; from hartwigm@BoulderCustomHomes.com on Wed, Jan 15, 2003 at 01:40:14PM -0500 X-archive-position: 2336 X-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: 1533 Lines: 23 On Wed, Jan 15, 2003 at 01:40:14PM -0500, Mark Hartwig wrote: > Hello all, I'm having a problem with nfsd (from Mandrake 9.0 install 2.4.19 > kernel) on a xfs partition. I am running an IDE RAID5 with 3Ware's Escalade > 7500 controller. The xfs partition as 1.1T. I can nfs cp large ammounts of > small files on to the xfs partition without any problems, but as soon as I > try to transfer a large file to the partition, the entire server freezes > when about 200 megs have been transfered. At this point, the server is > completely frozen and can only be restarted manually. I can, however, nfs > cp large files to the same server, but on to a smaller 100G ext3 partition. > All other disk-intensive processes cause the xfs partition no problems, > other than NFS. I can scp, rcp, rsh, and rsync to and from the XFS > partition perfectly. I can also copy large files to and from it locally > with no problems. The server seems to hang only when I transfer large files > via NFS to or from the xfs partition. I can, for example, nfs cp -R a > directory that is 1G to the xfs partition as long as each file within the > directory is less than about 200M. However, a nfs cp of a single file that > is 260M freezes the server every time. Ideally, I would like to find a work > around the issue without having to re-format the entire RAID. Any help > would be greatly appreciated. Is this reproducible with a volume slightly under 1TB? There's a bunch of linux block driver code that doesn't know about unsigned types unfortunately.. From owner-linux-xfs@oss.sgi.com Wed Jan 15 11:34:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 11:34:41 -0800 (PST) Received: from imf02bis.bellsouth.net (mail002.mail.bellsouth.net [205.152.58.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FJYb3v002422 for ; Wed, 15 Jan 2003 11:34:38 -0800 Received: from marsha ([66.156.0.183]) by imf02bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030115194239.CJFU24258.imf02bis.bellsouth.net@marsha>; Wed, 15 Jan 2003 14:42:39 -0500 Date: Wed, 15 Jan 2003 14:40:48 -0500 From: Greg Freemyer Subject: re[2]: XFS "lockfs" Functionality To: Nathan Straz , "Browning, Jeff" cc: "'linux-xfs@oss.sgi.com'" Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20030115194239.CJFU24258.imf02bis.bellsouth.net@marsha> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0FJYd3v002428 X-archive-position: 2337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 753 Lines: 18 >> On Wed, Jan 15, 2003 at 11:21:34AM -0800, Browning, Jeff wrote: >> > 1. Flush all data in the local file system buffer cache to disk >> > (effectively a synchronous sync); >> > 2. Halt all pending I/O to the file system until unlockfs is >> > issued. (If the file system is mounted hard, all processes attempting >> > to access the file system simply hang for this period.) >> man xfs_freeze There is also a kernel patch available from the LVM project that does this automatically when you perform an LVM snapshot. (Search for "VFS lock patch") The SuSE kernels already have this patch installed, I don't know about the other distros. Of course, if you are not doing LVM snapshots, the patch is useless. Greg Freemyer From owner-linux-xfs@oss.sgi.com Wed Jan 15 11:50:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 11:50:12 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FJo93v003041 for ; Wed, 15 Jan 2003 11:50:10 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h0FJuIH30464; Wed, 15 Jan 2003 14:56:18 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 15 Jan 2003 14:56:18 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Christoph Hellwig cc: Mark Hartwig , Subject: Re: nfs and xfs on 1.1T partition In-Reply-To: <20030115192843.B22134@infradead.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2338 X-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: 1997 Lines: 39 On Wed, 15 Jan 2003 at 7:28pm, Christoph Hellwig wrote > On Wed, Jan 15, 2003 at 01:40:14PM -0500, Mark Hartwig wrote: > > Hello all, I'm having a problem with nfsd (from Mandrake 9.0 install 2.4.19 > > kernel) on a xfs partition. I am running an IDE RAID5 with 3Ware's Escalade > > 7500 controller. The xfs partition as 1.1T. I can nfs cp large ammounts of > > small files on to the xfs partition without any problems, but as soon as I > > try to transfer a large file to the partition, the entire server freezes > > when about 200 megs have been transfered. At this point, the server is > > completely frozen and can only be restarted manually. I can, however, nfs > > cp large files to the same server, but on to a smaller 100G ext3 partition. > > All other disk-intensive processes cause the xfs partition no problems, > > other than NFS. I can scp, rcp, rsh, and rsync to and from the XFS > > partition perfectly. I can also copy large files to and from it locally > > with no problems. The server seems to hang only when I transfer large files > > via NFS to or from the xfs partition. I can, for example, nfs cp -R a > > directory that is 1G to the xfs partition as long as each file within the > > directory is less than about 200M. However, a nfs cp of a single file that > > is 260M freezes the server every time. Ideally, I would like to find a work > > around the issue without having to re-format the entire RAID. Any help > > would be greatly appreciated. > > Is this reproducible with a volume slightly under 1TB? There's a bunch of > linux block driver code that doesn't know about unsigned types unfortunately.. For the record, I just did a cp of a 1.7GB file to a 1.8TB NFS mounted XFS partition. The server is running 2.4.18-xfs-1.1, and the XFS partition is a software RAID0 stripe across 2 3ware 7500-8 cards. I don't have any servers (yet) w/ >1TB partitions running more recent code. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Jan 15 11:53:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 11:53:52 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FJrn3v003496 for ; Wed, 15 Jan 2003 11:53:50 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0FJxtOd020094 for ; Wed, 15 Jan 2003 14:59:55 -0500 Received: from d03nm800.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0FJxYN5058798 for ; Wed, 15 Jan 2003 14:59:53 -0500 Subject: dm_handle_to_path To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: James A Goodwin Date: Wed, 15 Jan 2003 13:59:31 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 01/15/2003 12:59:54 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 2339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jagoodwi@us.ibm.com Precedence: bulk X-list: linux-xfs Content-Length: 523 Lines: 22 dm_handle_to_path() is listed as a DMAPI function that does not work. Is this because nobody knows how to write it or just because nobody has really needed it yet? If it's the second case, would it be possible to get it working? We are considering adding new functionality to our software, but it would never work unless we could count on using dm_handle_to_path(). Regards, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 From owner-linux-xfs@oss.sgi.com Wed Jan 15 11:56:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 11:56:44 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FJue3v003971 for ; Wed, 15 Jan 2003 11:56:41 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18YtkQ-000650-00; Wed, 15 Jan 2003 20:02:50 +0000 Date: Wed, 15 Jan 2003 20:02:49 +0000 From: Christoph Hellwig To: James A Goodwin Cc: linux-xfs@oss.sgi.com Subject: Re: dm_handle_to_path Message-ID: <20030115200249.A23356@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jagoodwi@us.ibm.com on Wed, Jan 15, 2003 at 01:59:31PM -0600 X-archive-position: 2340 X-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: 308 Lines: 7 > dm_handle_to_path() is listed as a DMAPI function that does not work. Is > this because nobody knows how to write it or just because nobody has really > needed it yet? If it's the second case, would it be possible to get it > working? A quick grep over the source tree seems to imply it's implemented. From owner-linux-xfs@oss.sgi.com Wed Jan 15 12:08:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 12:08:49 -0800 (PST) Received: from hotmail.com (f54.sea2.hotmail.com [207.68.165.54]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FK8k3v004538 for ; Wed, 15 Jan 2003 12:08:47 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Jan 2003 12:14:54 -0800 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 15 Jan 2003 20:14:53 GMT X-Originating-IP: [208.244.233.175] From: "Rick Smith" To: sandeen@sgi.com Cc: linux-xfs@oss.sgi.com, rgsmith72@earthlink.net, willy@debian.org Subject: RE: rm hanging intermittently Date: Wed, 15 Jan 2003 12:14:53 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jan 2003 20:14:54.0125 (UTC) FILETIME=[C43C85D0:01C2BCD2] X-archive-position: 2341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 3085 Lines: 57 Eric, I was able to successfully capture a backtrace of the hanging rm problem today. It looks like it (and several other processes) are stuck in the schedule() function. After searching the mailing list archive, there were several other similar problems concerning deadlock, but the closest was posted by Matthew Wilcox at debian on 10-30-02 with the subject "unlink deadlock". The backtrace that he posted is quite similar to mine and we are both using raid 0. I, however, am not using IA-64 architecture. For me the problem seems to happen when there are multiple writes (to two different XFS partitions) very close to each other. Has this deadlock been addressed in kernels later than 2.4.20-rc1-xfs? Thanks for your help. The backtrace follows: [2]kdb> btp 18758 0xd5812000 00018758 00018739 0 002 stop 0xd5812370 rm ESP EIP Function (args) 0xd5813d38 0xc0116063 schedule+0x493 (0x1, 0xd5812000, 0xf7c3ad8c, 0xf7c3ad8c, 0xf7580700) kernel .text 0xc0100000 0xc0115bd0 0xc0116120 0xd5813d78 0xc0107828 __down+0x68 kernel .text 0xc0100000 0xc01077c0 0xc0107890 0xd5813d94 0xc01079d4 __down_failed+0x8 (0x33c, 0xd5813df8, 0xf711f3cc, 0xd5813dfc, 0xc01ec543) kernel .text 0xc0100000 0xc01079cc 0xc01079d8 0xd5813da4 0xc01ee0eb .text.lock.xfs_log+0xdb kernel .text 0xc0100000 0xc01ee010 0xc01ee250 0xd5813da4 0xc01eccb2 xlog_state_get_iclog_space+0x62 (0xf7c3ad80, 0x33c, 0xd5813df8, 0xf711f3cc, 0xd5813dfc) kernel .text 0xc0100000 0xc01ecc50 0xc01ecda0 0xd5813db8 0xc01ec543 xlog_write+0x153 (0xf6ff8c00, 0xd5813e68, 0xc, 0xf711f3cc, 0xdf8b2c5c) kernel .text 0xc0100000 0xc01ec3f0 0xc01ec800 0xd5813e18 0xc01eb51c xfs_log_write+0x3c (0xf6ff8c00, 0xd5813e68, 0xc, 0xf711f3cc, 0xdf8b2c5c) kernel .text 0xc0100000 0xc01eb4e0 0xc01eb550 0xd5813e3c 0xc01f7b24 xfs_trans_commit+0x184 (0xdf8b2c10, 0x4, 0x0, 0xd5813f2c, 0x11) kernel .text 0xc0100000 0xc01f79a0 0xc01f7c50 0xd5813efc 0xc01fe6b8 xfs_remove+0x398 (0xd8c876d8, 0xd8c85580, 0x0) kernel .text 0xc0100000 0xc01fe320 0xc01fe790 0xd5813f54 0xc0209fbe linvfs_unlink+0x1e (0xd8c86da0, 0xd8c85580) kernel .text 0xc0100000 0xc0209fa0 0xc020a000 0xd5813f70 0xc0145d35 vfs_unlink+0x135 (0xd8c86da0, 0xd8c85580, 0xd8c8e180, 0xf7cd2e40, 0xf2df9000) kernel .text 0xc0100000 0xc0145c00 0xc0145da0 0xd5813f8c 0xc0145e29 sys_unlink+0x89 (0x8053dab, 0x1, 0x0, 0x8053dab, 0x0) kernel .text 0xc0100000 0xc0145da0 0xc0145e90 0xd5813fc4 0xc0108c2b system_call+0x33 kernel .text 0xc0100000 0xc0108bf8 0xc0108c30 [2]kdb> go Rick Smith _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From owner-linux-xfs@oss.sgi.com Wed Jan 15 12:42:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 12:42:02 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FKfx3v005199 for ; Wed, 15 Jan 2003 12:42:00 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id E8006183069A; Wed, 15 Jan 2003 12:48:11 -0800 (PST) Date: Wed, 15 Jan 2003 12:48:11 -0800 From: Chris Wedgwood To: "A. L. Meyers" Cc: linux-xfs@oss.sgi.com Subject: Re: xfs fails as / with Debian GNU/Linux 2.4.18-smp - 2nd post Message-ID: <20030115204811.GB9367@f00f.org> References: <20030114221139.GA4264@f00f.org> <3E248C8B.9020908@mnsu.edu> <20030114223643.GA4462@f00f.org> <87el7ei7eq.fsf@wassern.consult-meyers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87el7ei7eq.fsf@wassern.consult-meyers.com> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2342 X-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: 185 Lines: 9 On Wed, Jan 15, 2003 at 07:39:57PM +0100, A. L. Meyers wrote: > Please note that /dev/hda2 would be the xfs / partition. he saw on oops ... therefore something needs fixing --cw From owner-linux-xfs@oss.sgi.com Wed Jan 15 12:43:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 12:43:42 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FKhe3v005624 for ; Wed, 15 Jan 2003 12:43:40 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id E4AA2183069A; Wed, 15 Jan 2003 12:49:52 -0800 (PST) Date: Wed, 15 Jan 2003 12:49:52 -0800 From: Chris Wedgwood To: Jason Joines Cc: Linux XFS Users Subject: Re: xfsdump max file size Message-ID: <20030115204952.GC9367@f00f.org> References: <3E249449.50909@bus.okstate.edu> <3E24BEAE.1080604@sgi.com> <3E256FEC.30206@bus.okstate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E256FEC.30206@bus.okstate.edu> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2343 X-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: 413 Lines: 15 On Wed, Jan 15, 2003 at 08:27:56AM -0600, Jason Joines wrote: > When running a dump with "xfsdump -F -e -f > /local/backup/weekly/sdb3.dmp -l 0 /dev/sdb3" I get the message, > "xfsdump: WARNING: could not open regular file ino 4185158 mode > 0x000081b0: File too large: not dumped". The file in question is > 5.0 GB. how large is the file? whate kernel version and what glibc version are you using? --cw From owner-linux-xfs@oss.sgi.com Wed Jan 15 12:45:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 12:45:04 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FKj13v006062 for ; Wed, 15 Jan 2003 12:45:01 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FJvFKp019561 for ; Wed, 15 Jan 2003 11:57:15 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA59951; Wed, 15 Jan 2003 14:51:01 -0600 (CST) Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA03003; Wed, 15 Jan 2003 14:51:01 -0600 (CST) Received: from chewtoy.americas.sgi.com by chewtoy.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id OAA16232; Wed, 15 Jan 2003 14:51:01 -0600 (CST) Message-Id: <200301152051.OAA16232@chewtoy.americas.sgi.com> To: James A Goodwin cc: linux-xfs@oss.sgi.com Subject: Re: dm_handle_to_path Date: Wed, 15 Jan 2003 14:51:00 -0600 From: Dean Roehrich X-archive-position: 2344 X-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: 581 Lines: 18 >From: James A Goodwin >dm_handle_to_path() is listed as a DMAPI function that does not work. Is >this because nobody knows how to write it or just because nobody has really >needed it yet? If it's the second case, would it be possible to get it >working? > >We are considering adding new functionality to our software, but it would >never work unless we could count on using dm_handle_to_path(). dm_handle_to_path ... James Goodwin....dm_handle_to_path.... Must have been a nightmare. But if Christoph say's it's done, then maybe it wasn't... Dean From owner-linux-xfs@oss.sgi.com Wed Jan 15 12:50:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 12:50:46 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FKoh3v006541 for ; Wed, 15 Jan 2003 12:50:43 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FK2uKp019930 for ; Wed, 15 Jan 2003 12:02:57 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA61387; Wed, 15 Jan 2003 14:56:49 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 18Yuaf-0000VQ-00; Wed, 15 Jan 2003 14:56:49 -0600 Date: Wed, 15 Jan 2003 14:56:49 -0600 From: Nathan Straz To: Jason Joines Cc: Linux XFS Users Subject: Re: xfsdump max file size Message-ID: <20030115205649.GE26512@sgi.com> Mail-Followup-To: Jason Joines , Linux XFS Users References: <3E249449.50909@bus.okstate.edu> <3E24BEAE.1080604@sgi.com> <3E256FEC.30206@bus.okstate.edu> <3E2584E8.8080102@sgi.com> <3E2598AD.5030502@bus.okstate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E2598AD.5030502@bus.okstate.edu> User-Agent: Mutt/1.4i X-archive-position: 2345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1446 Lines: 45 On Wed, Jan 15, 2003 at 11:21:49AM -0600, Jason Joines wrote: > Mandy Kirkconnell wrote: > >Jason Joines wrote: > > >When running a dump with "xfsdump -F -e -f > > >/local/backup/weekly/sdb3.dmp -l 0 /dev/sdb3" I get the message, > > >"xfsdump: WARNING: could not open regular file ino 4185158 mode > > >0x000081b0: File too large: not dumped". The file in question is 5.0 > > >GB. > > > >Perhaps you could also use xfs_db to look at the extents of the file: > > > ># xfs_db -r /dev/sdb3 > >xfs_db: inode 4185158 p > > # xfs_db -r /dev/sdb3 > xfs_db: inode 4185158 > xfs_db: p > core.magic = 0xfeff > core.mode = 0 > core.version = 4 > core.format = 0 (dev) > core.uid = 0 > core.gid = 0 > core.atime.sec = Wed Dec 6 15:33:04 1916 > core.atime.nsec = -1818818560 > core.mtime.sec = Mon Dec 14 15:16:30 1992 > core.mtime.nsec = 1140850688 > core.ctime.sec = Tue Feb 6 19:52:21 1973 > core.ctime.nsec = -1674700016 Those times look really wrong. Perhaps should should run xfs_check on your file system. > core.size = -7811766231833445970 > core.nblocks = 5764888998212337664 That doesn't look right to me either. Run xfs_check and xfs_repair -n on the file system. I'd wager you'll get some interesting output. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Wed Jan 15 12:55:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 12:55:14 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FKtB3v007052 for ; Wed, 15 Jan 2003 12:55:12 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18Yuf0-0006rz-00; Wed, 15 Jan 2003 21:01:18 +0000 Date: Wed, 15 Jan 2003 21:01:18 +0000 From: Christoph Hellwig To: Dean Roehrich Cc: James A Goodwin , linux-xfs@oss.sgi.com Subject: Re: dm_handle_to_path Message-ID: <20030115210118.A26363@infradead.org> References: <200301152051.OAA16232@chewtoy.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200301152051.OAA16232@chewtoy.americas.sgi.com>; from roehrich@sgi.com on Wed, Jan 15, 2003 at 02:51:00PM -0600 X-archive-position: 2346 X-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: 358 Lines: 9 On Wed, Jan 15, 2003 at 02:51:00PM -0600, Dean Roehrich wrote: > dm_handle_to_path ... James Goodwin....dm_handle_to_path.... > > Must have been a nightmare. But if Christoph say's it's done, then maybe it > wasn't... Hey, _you_ are the dmapi guru, right? :) I just said there is an implementation in libdm, I can't/won't comment on how good it works.. From owner-linux-xfs@oss.sgi.com Wed Jan 15 13:04:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 13:04:10 -0800 (PST) Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FL473v008480 for ; Wed, 15 Jan 2003 13:04:07 -0800 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C5AC530104 for ; Wed, 15 Jan 2003 13:10:19 -0800 (PST) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 1847030104 for ; Wed, 15 Jan 2003 13:10:19 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id BF4F51967B for ; Wed, 15 Jan 2003 13:10:08 -0800 (PST) Subject: mount -o loop problem From: Florin Andrei To: linux-xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 15 Jan 2003 13:10:08 -0800 Message-Id: <1042665008.1360.19.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 2347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2135 Lines: 54 I took a copy of an XFS partition from an Irix system, using dd: dd if=/dev/dsk/dks1d1s0 of=somesystem.img bs=1024k Then i put the image on a Linux system running an XFS-enabled kernel and i tried to mount it via loopback. I started with this command: mount -t xfs -o loop,ro,noatime,nodev,nofsck somesystem.img image/ ...which of course didn't worked. After dropping a few parameters, i ended up trying this: mount -o loop,noatime,nodev somesystem.img image/ At this moment i got this error on the command line: [root@stantz somesystem]# mount -o loop,noatime,nodev somesystem.img image/ mount: wrong fs type, bad option, bad superblock on /dev/loop0, or too many mounted file systems [root@stantz somesystem]# ...and this error in syslog: Jan 15 13:00:34 stantz kernel: XFS: dirty log written in incompatible format - can't recoverXFS: log mount/recovery failedXFS: log mount failedXFS mounting filesystem loop(7,0) Jan 15 13:00:34 stantz kernel: XFS: nil uuid in log - IRIX style logStarting XFS recovery on filesystem: loop(7,0) (dev: 7/0) I'm not exactly happy with not using "-o ro" and not being able to use "nofsck" because i need to disturb as little as possible on this image (a low-level analysis must be performed on it). But anyhow, at this moment i'd be content to mount it in any way that works (i can create another copy if i have to). So, what's wrong? How can i mount the image via loopback, while at the same time preserving its state exactly as it is (within reason, i'd like to do as little writes as possible when mounting it for the first time)? The reason i need to loopback-mount it on Linux is that i have to run an analysis tool on it, and i couldn't compile the tool on Irix yet; i may be able to do that in the future but, for the short term, loopback seems like a quicker solution. -- Florin Andrei "The Indians of the American Southwest called him Coyote, those of the Pacific Coast called him Raven. Europeans called him Reynard the Fox. African-Americans called him Br'er Rabbit. In 20-century literature he appears first as Bugs Bunny and then as the Hacker." - Neal Stephenson From owner-linux-xfs@oss.sgi.com Wed Jan 15 13:10:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 13:10:15 -0800 (PST) Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FLAC3v009056 for ; Wed, 15 Jan 2003 13:10:13 -0800 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3B32C30104 for ; Wed, 15 Jan 2003 13:16:25 -0800 (PST) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 7503E30104 for ; Wed, 15 Jan 2003 13:16:24 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 1F7C51967B for ; Wed, 15 Jan 2003 13:16:14 -0800 (PST) Subject: Re: mount -o loop problem From: Florin Andrei To: linux-xfs In-Reply-To: <1042665008.1360.19.camel@stantz.corp.sgi.com> References: <1042665008.1360.19.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 15 Jan 2003 13:16:14 -0800 Message-Id: <1042665374.1360.26.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 2349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2687 Lines: 67 Forgot to tell you, the partition was clean and unmounted when i run dd on it on Irix. On Wed, 2003-01-15 at 13:10, Florin Andrei wrote: > I took a copy of an XFS partition from an Irix system, using dd: > > dd if=/dev/dsk/dks1d1s0 of=somesystem.img bs=1024k > > Then i put the image on a Linux system running an XFS-enabled kernel and > i tried to mount it via loopback. I started with this command: > > mount -t xfs -o loop,ro,noatime,nodev,nofsck somesystem.img image/ > > ...which of course didn't worked. After dropping a few parameters, i > ended up trying this: > > mount -o loop,noatime,nodev somesystem.img image/ > > At this moment i got this error on the command line: > > [root@stantz somesystem]# mount -o loop,noatime,nodev somesystem.img > image/ > mount: wrong fs type, bad option, bad superblock on /dev/loop0, > or too many mounted file systems > [root@stantz somesystem]# > > ...and this error in syslog: > > Jan 15 13:00:34 stantz kernel: XFS: dirty log written in incompatible > format - can't recoverXFS: log mount/recovery failedXFS: log mount > failedXFS mounting filesystem > loop(7,0) > Jan 15 13:00:34 stantz kernel: XFS: nil uuid in log - IRIX style > logStarting XFS recovery on filesystem: loop(7,0) (dev: 7/0) > > I'm not exactly happy with not using "-o ro" and not being able to use > "nofsck" because i need to disturb as little as possible on this image > (a low-level analysis must be performed on it). But anyhow, at this > moment i'd be content to mount it in any way that works (i can create > another copy if i have to). > > So, what's wrong? How can i mount the image via loopback, while at the > same time preserving its state exactly as it is (within reason, i'd like > to do as little writes as possible when mounting it for the first time)? > > The reason i need to loopback-mount it on Linux is that i have to run an > analysis tool on it, and i couldn't compile the tool on Irix yet; i may > be able to do that in the future but, for the short term, loopback seems > like a quicker solution. > > -- > Florin Andrei > > "The Indians of the American Southwest called him Coyote, those of the > Pacific Coast called him Raven. Europeans called him Reynard the Fox. > African-Americans called him Br'er Rabbit. In 20-century literature he > appears first as Bugs Bunny and then as the Hacker." - Neal Stephenson > > -- Florin Andrei "The Indians of the American Southwest called him Coyote, those of the Pacific Coast called him Raven. Europeans called him Reynard the Fox. African-Americans called him Br'er Rabbit. In 20-century literature he appears first as Bugs Bunny and then as the Hacker." - Neal Stephenson From owner-linux-xfs@oss.sgi.com Wed Jan 15 13:09:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 13:10:02 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FL9w3v008951 for ; Wed, 15 Jan 2003 13:09:59 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FLNekq018817 for ; Wed, 15 Jan 2003 15:23:40 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA77807; Wed, 15 Jan 2003 15:16:04 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA40745; Wed, 15 Jan 2003 15:16:04 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h0FLG4915791; Wed, 15 Jan 2003 15:16:04 -0600 Subject: Re: mount -o loop problem From: Steve Lord To: Florin Andrei Cc: linux-xfs In-Reply-To: <1042665008.1360.19.camel@stantz.corp.sgi.com> References: <1042665008.1360.19.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042665364.15552.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 15 Jan 2003 15:16:04 -0600 X-archive-position: 2348 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2334 Lines: 58 On Wed, 2003-01-15 at 15:10, Florin Andrei wrote: > I took a copy of an XFS partition from an Irix system, using dd: > > dd if=/dev/dsk/dks1d1s0 of=somesystem.img bs=1024k > > Then i put the image on a Linux system running an XFS-enabled kernel and > i tried to mount it via loopback. I started with this command: > > mount -t xfs -o loop,ro,noatime,nodev,nofsck somesystem.img image/ > > ...which of course didn't worked. After dropping a few parameters, i > ended up trying this: > > mount -o loop,noatime,nodev somesystem.img image/ > > At this moment i got this error on the command line: > > [root@stantz somesystem]# mount -o loop,noatime,nodev somesystem.img > image/ > mount: wrong fs type, bad option, bad superblock on /dev/loop0, > or too many mounted file systems > [root@stantz somesystem]# > > ...and this error in syslog: > > Jan 15 13:00:34 stantz kernel: XFS: dirty log written in incompatible > format - can't recoverXFS: log mount/recovery failedXFS: log mount > failedXFS mounting filesystem > loop(7,0) > Jan 15 13:00:34 stantz kernel: XFS: nil uuid in log - IRIX style > logStarting XFS recovery on filesystem: loop(7,0) (dev: 7/0) > > I'm not exactly happy with not using "-o ro" and not being able to use > "nofsck" because i need to disturb as little as possible on this image > (a low-level analysis must be performed on it). But anyhow, at this > moment i'd be content to mount it in any way that works (i can create > another copy if i have to). > > So, what's wrong? How can i mount the image via loopback, while at the > same time preserving its state exactly as it is (within reason, i'd like > to do as little writes as possible when mounting it for the first time)? > > The reason i need to loopback-mount it on Linux is that i have to run an > analysis tool on it, and i couldn't compile the tool on Irix yet; i may > be able to do that in the future but, for the short term, loopback seems > like a quicker solution. You need to zero the log to get it to mount on linux, looks like it was not cleanly unmounted on Irix. xfs_repair -L will do this, but it may change other stuff too. Try xfs_repair -n to see what it would do. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 15 13:11:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 13:11:32 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FLBT3v009791 for ; Wed, 15 Jan 2003 13:11:30 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FLPBkq018868 for ; Wed, 15 Jan 2003 15:25:11 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA67832; Wed, 15 Jan 2003 15:17:36 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id PAA58254; Wed, 15 Jan 2003 15:17:36 -0600 (CST) Subject: Re: mount -o loop problem From: Eric Sandeen To: Florin Andrei Cc: linux-xfs In-Reply-To: <1042665008.1360.19.camel@stantz.corp.sgi.com> References: <1042665008.1360.19.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 15 Jan 2003 15:15:43 -0600 Message-Id: <1042665343.738.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2350 X-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: 886 Lines: 28 On Wed, 2003-01-15 at 15:10, Florin Andrei wrote: > ...and this error in syslog: > > Jan 15 13:00:34 stantz kernel: XFS: dirty log written in incompatible > format - can't recoverXFS: log mount/recovery failedXFS: log mount > failedXFS mounting filesystem > loop(7,0) > Jan 15 13:00:34 stantz kernel: XFS: nil uuid in log - IRIX style > logStarting XFS recovery on filesystem: loop(7,0) (dev: 7/0) > So, what's wrong? Just what it says... "dirty log written in incompatible format" - mount & unmount it on Irix, then re-dd it. The endian-ness of the log is machine native so you can't replay an Irix log on Linux. If you absolutely can't mount/unmount on Irix, then xfs_repair -L will obliterate the log, but there are losses associated with that. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Jan 15 13:40:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 13:40:53 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FLek3v013528 for ; Wed, 15 Jan 2003 13:40:47 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FLsSkq019647 for ; Wed, 15 Jan 2003 15:54:28 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA84919; Wed, 15 Jan 2003 15:46:52 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA15872; Wed, 15 Jan 2003 15:46:52 -0600 (CST) Received: from rose.americas.sgi.com (localhost [127.0.0.1]) by rose.americas.sgi.com (8.12.6/8.12.5) with ESMTP id h0FLkxKu004809; Wed, 15 Jan 2003 15:47:00 -0600 Received: (from cattelan@localhost) by rose.americas.sgi.com (8.12.6/8.12.6/Submit) id h0FLkv8f004807; Wed, 15 Jan 2003 15:46:58 -0600 X-Authentication-Warning: rose.americas.sgi.com: cattelan set sender to cattelan@xfs.org using -f Subject: RE: rm hanging intermittently From: Russell Cattelan To: Rick Smith Cc: sandeen@sgi.com, linux-xfs@oss.sgi.com, rgsmith72@earthlink.net, willy@debian.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042667216.2955.26.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 (1.2.0-3) Date: 15 Jan 2003 15:46:56 -0600 X-archive-position: 2351 X-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 Content-Length: 3550 Lines: 67 Before this gets lost can you open a bug in bugzilla and add this BT to it. And actually a bta (back trace all) would probably be more helpful since it usually informative to see what the kernel threads bdflush kswapd, kupdated, and the pagebuf daemons are doing. On Wed, 2003-01-15 at 14:14, Rick Smith wrote: > Eric, > I was able to successfully capture a backtrace of the hanging rm > problem today. It looks like it (and several other processes) are stuck in > the schedule() function. After searching the mailing list archive, there > were several other similar problems concerning deadlock, but the closest was > posted by Matthew Wilcox at debian on 10-30-02 with the subject "unlink > deadlock". The backtrace that he posted is quite similar to mine and we are > both using raid 0. I, however, am not using IA-64 architecture. > For me the problem seems to happen when there are multiple writes (to > two different XFS partitions) very close to each other. Has this deadlock > been addressed in kernels later than 2.4.20-rc1-xfs? Thanks for your help. > The backtrace follows: > > [2]kdb> btp 18758 > 0xd5812000 00018758 00018739 0 002 stop 0xd5812370 rm > ESP EIP Function (args) > 0xd5813d38 0xc0116063 schedule+0x493 (0x1, 0xd5812000, 0xf7c3ad8c, > 0xf7c3ad8c, 0xf7580700) > kernel .text 0xc0100000 0xc0115bd0 0xc0116120 > 0xd5813d78 0xc0107828 __down+0x68 > kernel .text 0xc0100000 0xc01077c0 0xc0107890 > 0xd5813d94 0xc01079d4 __down_failed+0x8 (0x33c, 0xd5813df8, 0xf711f3cc, > 0xd5813dfc, 0xc01ec543) > kernel .text 0xc0100000 0xc01079cc 0xc01079d8 > 0xd5813da4 0xc01ee0eb .text.lock.xfs_log+0xdb > kernel .text 0xc0100000 0xc01ee010 0xc01ee250 > 0xd5813da4 0xc01eccb2 xlog_state_get_iclog_space+0x62 (0xf7c3ad80, 0x33c, > 0xd5813df8, 0xf711f3cc, 0xd5813dfc) > kernel .text 0xc0100000 0xc01ecc50 0xc01ecda0 > 0xd5813db8 0xc01ec543 xlog_write+0x153 (0xf6ff8c00, 0xd5813e68, 0xc, > 0xf711f3cc, 0xdf8b2c5c) > kernel .text 0xc0100000 0xc01ec3f0 0xc01ec800 > 0xd5813e18 0xc01eb51c xfs_log_write+0x3c (0xf6ff8c00, 0xd5813e68, 0xc, > 0xf711f3cc, 0xdf8b2c5c) > kernel .text 0xc0100000 0xc01eb4e0 0xc01eb550 > 0xd5813e3c 0xc01f7b24 xfs_trans_commit+0x184 (0xdf8b2c10, 0x4, 0x0, > 0xd5813f2c, 0x11) > kernel .text 0xc0100000 0xc01f79a0 0xc01f7c50 > 0xd5813efc 0xc01fe6b8 xfs_remove+0x398 (0xd8c876d8, 0xd8c85580, 0x0) > kernel .text 0xc0100000 0xc01fe320 0xc01fe790 > 0xd5813f54 0xc0209fbe linvfs_unlink+0x1e (0xd8c86da0, 0xd8c85580) > kernel .text 0xc0100000 0xc0209fa0 0xc020a000 > 0xd5813f70 0xc0145d35 vfs_unlink+0x135 (0xd8c86da0, 0xd8c85580, 0xd8c8e180, > 0xf7cd2e40, 0xf2df9000) > kernel .text 0xc0100000 0xc0145c00 0xc0145da0 > 0xd5813f8c 0xc0145e29 sys_unlink+0x89 (0x8053dab, 0x1, 0x0, 0x8053dab, 0x0) > kernel .text 0xc0100000 0xc0145da0 0xc0145e90 > 0xd5813fc4 0xc0108c2b system_call+0x33 > kernel .text 0xc0100000 0xc0108bf8 0xc0108c30 > [2]kdb> go > > Rick Smith > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Wed Jan 15 15:07:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 15:07:52 -0800 (PST) Received: from imf16bis.bellsouth.net (mail016.mail.bellsouth.net [205.152.58.36]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FN7m3v022264 for ; Wed, 15 Jan 2003 15:07:48 -0800 Received: from marsha ([66.156.0.183]) by imf16bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030115231552.HLCU11238.imf16bis.bellsouth.net@marsha> for ; Wed, 15 Jan 2003 18:15:52 -0500 Date: Wed, 15 Jan 2003 18:13:58 -0500 From: Greg Freemyer Subject: xfsdump prerelease To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20030115231552.HLCU11238.imf16bis.bellsouth.net@marsha> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0FN7n3v022283 X-archive-position: 2353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 409 Lines: 18 I'm trying to install the cmd tars for the latest pre-release on SuSE 8.0 WIth xfsdump I'm getting the ./configure complaint about no curses support. This was fixed in CVS on Nov 7, 2002 http://marc.theaimsgroup.com/?l=linux-xfs&m=103668265017904&w=2 Unfortunately it is not in the pre-release version. I can live without it, but it would be nice to get that into the pre-release. TIA Greg Freemyer From owner-linux-xfs@oss.sgi.com Wed Jan 15 15:07:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 15:07:40 -0800 (PST) Received: from imf16bis.bellsouth.net (mail116.mail.bellsouth.net [205.152.58.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FN7W3v022221 for ; Wed, 15 Jan 2003 15:07:33 -0800 Received: from marsha ([66.156.0.183]) by imf16bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030115231537.HKWX11238.imf16bis.bellsouth.net@marsha> for ; Wed, 15 Jan 2003 18:15:37 -0500 Date: Wed, 15 Jan 2003 18:13:44 -0500 From: Greg Freemyer Subject: re[2]: xfsdump max file size To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20030115231537.HKWX11238.imf16bis.bellsouth.net@marsha> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0FN7Y3v022222 X-archive-position: 2352 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 3650 Lines: 115 Jason, Thanks for the heads up. I am running suse 8.0, but with the xfs 1.2 p3 kernel. I'm using the original userland tools. I'm having the same problem, but never noticed. I'm now trying to install new tools compiled from source. ftp://oss.sgi.com/projects/xfs/Release-1.2pre5/cmd_tars I'll let you know if that fixes the problem for me or not. Greg >> Mandy Kirkconnell wrote: >> > >> > Jason Joines wrote: >> > >> >> Mandy Kirkconnell wrote: >> >> >> >>> Jason Joines wrote: >> >>> >> >>>> What's the maximum file size for a file to be dumped by xfsdump? >> >>> >> >>> >> >>> >> >>> xfsdump doesn't (really) have a maximum file size limitation. There >> >>> is a maximum file size defined in xfsdump/dump/content.c but it is >> >>> set to the largest theoretical file size, 18 million terabytes. The >> >>> definition is defined in bytes: >> >>> >> >>> /* max "unsigned long long int" >> >>> */ >> >>> #define ULONGLONG_MAX 18446744073709551615LLU >> >>> >> >>> Obviously this maximum limit is impossible to hit, which is why I >> >>> say xfsdump doesn't have a max file size limit. You should be able >> >>> to dump the biggest possible file you can create. >> >>> >> >>> There is, however, a command line option (-z) to set a maximum file >> >>> size for your dump. This option allows you to specify a maximum >> >>> file size, in kilobytes. Files over this size will be excluded >> >>> from the dump. >> >>> >> >> When running a dump with "xfsdump -F -e -f >> >> /local/backup/weekly/sdb3.dmp -l 0 /dev/sdb3" I get the message, >> >> "xfsdump: WARNING: could not open regular file ino 4185158 mode >> >> 0x000081b0: File too large: not dumped". The file in question is 5.0 >> >> GB. >> >> >> >> Jason >> >> =========== >> >> >> > xfsdump does not set EFBIG (errno 27) anywhere. It looks like the >> > error is coming from the filesystem on the first attempt to open the >> > file. What version of xfs are you running? Are you using the released >> > version of xfsdump, or have you built your own copy? >> > >> > Perhaps you could also use xfs_db to look at the extents of the file: >> > >> > # xfs_db -r /dev/sdb3 >> > xfs_db: inode 4185158 p >> > >> > We are able to dump a file of 4.5 GB without hitting the error. >> > Perhaps we can figure out what's different between our environments >> > and go from there. >> > >> Actually, I'm not quite sure what version of xfs it is. How do I >> tell? I am using a 2.4.18 kernel compiled by SuSE. I installed and >> looked at the source for this kernel but couldn't find anything that >> said what version of xfs it is. My xfsdump version is version 3.0. It >> is from a SuSE rpm as well. >> xfs_db gave: >> # xfs_db -r /dev/sdb3 >> xfs_db: inode 4185158 >> xfs_db: p >> core.magic = 0xfeff >> core.mode = 0 >> core.version = 4 >> core.format = 0 (dev) >> core.uid = 0 >> core.gid = 0 >> core.atime.sec = Wed Dec 6 15:33:04 1916 >> core.atime.nsec = -1818818560 >> core.mtime.sec = Mon Dec 14 15:16:30 1992 >> core.mtime.nsec = 1140850688 >> core.ctime.sec = Tue Feb 6 19:52:21 1973 >> core.ctime.nsec = -1674700016 >> core.size = -7811766231833445970 >> core.nblocks = 5764888998212337664 >> core.extsize = 201326592 >> core.nextents = 16777216 >> core.naextents = 26624 >> core.forkoff = 0 >> core.aformat = 0 (dev) >> core.dmevmask = 0xf000000 >> core.dmstate = 28672 >> core.newrtbm = 0 >> core.prealloc = 0 >> core.realtime = 0 >> core.gen = 83886080 >> next_unlinked = 2483027968 >> u.dev = 0x6000000 >> xfs_db: q >> Jason >> =========== From owner-linux-xfs@oss.sgi.com Wed Jan 15 15:35:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 15:35:44 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FNZB3v023737 for ; Wed, 15 Jan 2003 15:35:11 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FMlOKp030657 for ; Wed, 15 Jan 2003 14:47:25 -0800 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA82223; Thu, 16 Jan 2003 10:40:00 +1100 (AEDT) Date: Thu, 16 Jan 2003 10:40:00 +1100 From: Tim Shimmin To: Mandy Kirkconnell Cc: Jason Joines , Linux XFS Users Subject: Re: xfsdump max file size Message-ID: <20030116104000.B2986373@boing.melbourne.sgi.com> References: <3E249449.50909@bus.okstate.edu> <3E24BEAE.1080604@sgi.com> <3E256FEC.30206@bus.okstate.edu> <3E2584E8.8080102@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3E2584E8.8080102@sgi.com>; from alkirkco@sgi.com on Wed, Jan 15, 2003 at 09:57:28AM -0600 X-archive-position: 2354 X-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: 1969 Lines: 54 On Wed, Jan 15, 2003 at 09:57:28AM -0600, Mandy Kirkconnell wrote: > > Jason Joines wrote: > > > Mandy Kirkconnell wrote: > > > >> Jason Joines wrote: > >> > >>> What's the maximum file size for a file to be dumped by xfsdump? > >> > >> > >> xfsdump doesn't (really) have a maximum file size limitation. There > >> is a maximum file size defined in xfsdump/dump/content.c but it is > >> set to the largest theoretical file size, 18 million terabytes. The > >> definition is defined in bytes: > >> > >> /* max "unsigned long long int" > >> */ > >> #define ULONGLONG_MAX 18446744073709551615LLU > >> > >> Obviously this maximum limit is impossible to hit, which is why I say > >> xfsdump doesn't have a max file size limit. You should be able to > >> dump the biggest possible file you can create. > >> > >> There is, however, a command line option (-z) to set a maximum file > >> size for your dump. This option allows you to specify a maximum file > >> size, in kilobytes. Files over this size will be excluded from the > >> dump. > >> > > When running a dump with "xfsdump -F -e -f > > /local/backup/weekly/sdb3.dmp -l 0 /dev/sdb3" I get the message, > > "xfsdump: WARNING: could not open regular file ino 4185158 mode > > 0x000081b0: File too large: not dumped". The file in question is 5.0 GB. > > > > Jason > > =========== > > > xfsdump does not set EFBIG (errno 27) anywhere. It looks like the error > is coming from the filesystem on the first attempt to open the file. Another thing to note is that in April 2002 a fix went into libhandle which xfsdump uses: xfsprogs/doc/CHANGES: xfsprogs-2.0.2 (4 April 2002) - Bumped version of libhandle to libhandle.so.1.0.1 This changes open_by_handle() and friends so that O_LARGEFILE is added to the open flags. This allows xfsdump to dump files greater than 2^31-1 bytes instead of not dumping the large files and giving warning messages. --Tim From owner-linux-xfs@oss.sgi.com Wed Jan 15 15:44:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Jan 2003 15:44:32 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0FNiR3v024341 for ; Wed, 15 Jan 2003 15:44:28 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0FMueKp031187 for ; Wed, 15 Jan 2003 14:56:41 -0800 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA06598; Thu, 16 Jan 2003 10:49:17 +1100 (AEDT) Date: Thu, 16 Jan 2003 10:49:17 +1100 From: Tim Shimmin To: Jason Joines Cc: Linux XFS Users Subject: Re: xfsdump max file size Message-ID: <20030116104917.C2986373@boing.melbourne.sgi.com> References: <3E249449.50909@bus.okstate.edu> <3E24BEAE.1080604@sgi.com> <3E256FEC.30206@bus.okstate.edu> <3E2584E8.8080102@sgi.com> <3E2598AD.5030502@bus.okstate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3E2598AD.5030502@bus.okstate.edu>; from joines@bus.okstate.edu on Wed, Jan 15, 2003 at 11:21:49AM -0600 X-archive-position: 2355 X-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: 329 Lines: 14 Hi Jason, FYI On Wed, Jan 15, 2003 at 11:21:49AM -0600, Jason Joines wrote: > My xfsdump version is version 3.0. Which is the dump format version number. From xfsdump-2.0.4 (14 June 2002), xfsdump should report the program version number like this: xfsdump: version 2.2.6 (dump format 3.0) - Running single-threaded --Tim From owner-linux-xfs@oss.sgi.com Thu Jan 16 02:44:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jan 2003 02:44:14 -0800 (PST) Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0GAi53v026185 for ; Thu, 16 Jan 2003 02:44:07 -0800 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id h0GAoFl01622 for linux-xfs@oss.sgi.com.KAV; Thu, 16 Jan 2003 11:50:15 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id h0GAoDu01608; Thu, 16 Jan 2003 11:50:13 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h0GAngC9008612; Thu, 16 Jan 2003 11:49:43 +0100 Subject: Re: How to make filenames case insensitive From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Klaus Strebel Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E259AD6.7010709@eigner.com> References: <1042638865.2612.9.camel@venus> <3E259AD6.7010709@eigner.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 16 Jan 2003 11:49:42 +0100 Message-Id: <1042714183.8476.9.camel@venus> Mime-Version: 1.0 X-archive-position: 2356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 528 Lines: 24 On Wed, 2003-01-15 at 18:31, Klaus Strebel wrote: > > Well, > > me method with less effort will be just doing symlinks from YYY to Yyy: > > ln -s YYY Yyy > > and that's it. Hi, Thanks for all responses. I'll use vfat filesystem. The disadvantage is lack of permissions (not mentioning about acls :) And lack of journaling. The mount via loopback is not a solution as I often store part of CD. And linking is also not a solution if you store many CDs, and on each you have problem with hundreds of files. Regards, Olaf From owner-linux-xfs@oss.sgi.com Thu Jan 16 02:47:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jan 2003 02:47:22 -0800 (PST) Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0GAlH3v026621 for ; Thu, 16 Jan 2003 02:47:19 -0800 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id h0GArVI03743 for linux-xfs@oss.sgi.com.KAV; Thu, 16 Jan 2003 11:53:31 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id h0GArUu03728; Thu, 16 Jan 2003 11:53:30 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h0GAqvC9008628; Thu, 16 Jan 2003 11:52:58 +0100 Subject: re: How to make filenames case insensitive From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1042645267.16153.4.camel@jen.americas.sgi.com> References: <20030115153637.TUXB19222.imf12bis.bellsouth.net@marsha> <1042645267.16153.4.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 16 Jan 2003 11:52:57 +0100 Message-Id: <1042714378.8477.14.camel@venus> Mime-Version: 1.0 X-archive-position: 2357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 395 Lines: 15 On Wed, 2003-01-15 at 16:41, Steve Lord wrote: > XFS does not have a native way, there has been someone working on a > case insensitive XFS, but that involved changing the hash algorithm > XFS uses internally and on the disk, so it would not help here. Is it in active development or it has been dropped? Or you know a case-insensitive filesystem for linux with journaling? Regards, Olaf From owner-linux-xfs@oss.sgi.com Thu Jan 16 06:30:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jan 2003 06:31:03 -0800 (PST) Received: from ZRHNOG20.converium.com (mail1.converium.com [213.173.163.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0GEUt3v030289 for ; Thu, 16 Jan 2003 06:30:58 -0800 Subject: Re: xfs fails as / with Debian GNU/Linux 2.4.18-smp - 2nd post To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: "Lucien Meyers" Date: Thu, 16 Jan 2003 15:37:00 +0100 X-MIMETrack: Serialize by Router on ZRHNOG20/Converium-Internet(Release 5.0.10 |March 22, 2002) at 16.01.2003 15:37:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 2358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lucien.meyers@converium.com Precedence: bulk X-list: linux-xfs Content-Length: 212 Lines: 9 Debian testing has posted an update to the xfs kernel source patches this week. Could someone here please tell us the reasons for that update and if it addresses the issue we have been discussing here? Lucien From owner-linux-xfs@oss.sgi.com Thu Jan 16 14:00:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jan 2003 14:00:48 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0GM0e3v006451 for ; Thu, 16 Jan 2003 14:00:41 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0GK71G8008997 for ; Thu, 16 Jan 2003 12:07:01 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA25009; Thu, 16 Jan 2003 16:06:51 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA90640; Thu, 16 Jan 2003 16:06:50 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h0GM6o007964; Thu, 16 Jan 2003 16:06:50 -0600 Subject: re: How to make filenames case insensitive From: Steve Lord To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <1042714378.8477.14.camel@venus> References: <20030115153637.TUXB19222.imf12bis.bellsouth.net@marsha> <1042645267.16153.4.camel@jen.americas.sgi.com> <1042714378.8477.14.camel@venus> Content-Type: text/plain; charset=iso-8859-2 Organization: Message-Id: <1042754809.15555.103.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 16 Jan 2003 16:06:49 -0600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0GM0g3v006452 X-archive-position: 2359 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 771 Lines: 19 On Thu, 2003-01-16 at 04:52, Olaf Fr±czyk wrote: > On Wed, 2003-01-15 at 16:41, Steve Lord wrote: > > XFS does not have a native way, there has been someone working on a > > case insensitive XFS, but that involved changing the hash algorithm > > XFS uses internally and on the disk, so it would not help here. > Is it in active development or it has been dropped? > Or you know a case-insensitive filesystem for linux with journaling? Well, I think it was being done by people who worked for Quantum, then Quantum spun off their NAS division, but layed off the developers. Not sure if there is still activity or not. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 16 14:28:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jan 2003 14:28:45 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0GMSe3v007085 for ; Thu, 16 Jan 2003 14:28:41 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id A058614C81; Thu, 16 Jan 2003 23:34:51 +0100 (MET) Date: Thu, 16 Jan 2003 23:34:50 +0100 From: Andi Kleen To: =?iso-8859-1?Q?Olaf_Fr=B1czyk?= Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: How to make filenames case insensitive Message-ID: <20030116233450.A21639@oldwotan.suse.de> References: <20030115153637.TUXB19222.imf12bis.bellsouth.net@marsha> <1042645267.16153.4.camel@jen.americas.sgi.com> <1042714378.8477.14.camel@venus> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <1042714378.8477.14.camel@venus>; from olaf@cbk.poznan.pl on Thu, Jan 16, 2003 at 11:52:57AM +0100 X-archive-position: 2360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 180 Lines: 7 On Thu, Jan 16, 2003 at 11:52:57AM +0100, Olaf Fr±czyk wrote: > Or you know a case-insensitive filesystem for linux with journaling? JFS supports case insensitive mounts. -Andi From owner-linux-xfs@oss.sgi.com Thu Jan 16 18:04:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Jan 2003 18:04:24 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0H24J3v010649 for ; Thu, 16 Jan 2003 18:04:21 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 93F8B1831617; Thu, 16 Jan 2003 18:10:36 -0800 (PST) Date: Thu, 16 Jan 2003 18:10:36 -0800 From: Chris Wedgwood To: Andi Kleen Cc: Olaf =?iso-8859-1?Q?Fr=B1czyk?= , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: How to make filenames case insensitive Message-ID: <20030117021036.GA15565@f00f.org> References: <20030115153637.TUXB19222.imf12bis.bellsouth.net@marsha> <1042645267.16153.4.camel@jen.americas.sgi.com> <1042714378.8477.14.camel@venus> <20030116233450.A21639@oldwotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030116233450.A21639@oldwotan.suse.de> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2361 X-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: 179 Lines: 15 On Thu, Jan 16, 2003 at 11:34:50PM +0100, Andi Kleen wrote: > JFS supports case insensitive mounts. how does it work when a directory contains Foo and foo ? --cw From owner-linux-xfs@oss.sgi.com Fri Jan 17 00:31:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 00:31:43 -0800 (PST) Received: from hob.prv.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0H8Vb3v015693 for ; Fri, 17 Jan 2003 00:31:38 -0800 Received: from erbenson.alaska.net (116-pm18.nwc.alaska.net [209.112.142.116]) by hob.prv.nwc.acsalaska.net (8.12.6/8.12.6) with ESMTP id h0H8bs3U009145 for ; Thu, 16 Jan 2003 23:37:54 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id DAFAC3A07 for ; Thu, 16 Jan 2003 23:37:50 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id B23004104E2; Thu, 16 Jan 2003 23:37:50 -0900 (AKST) Date: Thu, 16 Jan 2003 23:37:50 -0900 From: Ethan Benson To: linux-xfs Subject: Re: mount -o loop problem Message-ID: <20030117083750.GD25488@plato.local.lan> Mail-Followup-To: linux-xfs References: <1042665008.1360.19.camel@stantz.corp.sgi.com> <1042665343.738.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZJcv+A0YCCLh2VIg" Content-Disposition: inline In-Reply-To: <1042665343.738.14.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 2362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 789 Lines: 30 --ZJcv+A0YCCLh2VIg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 15, 2003 at 03:15:43PM -0600, Eric Sandeen wrote: > & unmount it on Irix, then re-dd it. The endian-ness of the log is > machine native so you can't replay an Irix log on Linux. even if your running linux on a big endian architecture? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --ZJcv+A0YCCLh2VIg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj4nwN4ACgkQJKx7GixEevx5TQCgnmQQWJl602t1PQH4dBOYFY/X xc0AnRIHprQAtRAK+U+xyZu0ATZHGVMX =O78m -----END PGP SIGNATURE----- --ZJcv+A0YCCLh2VIg-- From owner-linux-xfs@oss.sgi.com Fri Jan 17 07:21:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 07:21:19 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HFLA3v007155 for ; Fri, 17 Jan 2003 07:21:11 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0HFZ6kq029171 for ; Fri, 17 Jan 2003 09:35:06 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA30563; Fri, 17 Jan 2003 09:27:24 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA74398; Fri, 17 Jan 2003 09:27:24 -0600 (CST) Date: Fri, 17 Jan 2003 09:25:14 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ethan Benson cc: linux-xfs Subject: Re: mount -o loop problem In-Reply-To: <20030117083750.GD25488@plato.local.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2363 X-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: 691 Lines: 18 On Thu, 16 Jan 2003, Ethan Benson wrote: > On Wed, Jan 15, 2003 at 03:15:43PM -0600, Eric Sandeen wrote: > > & unmount it on Irix, then re-dd it. The endian-ness of the log is > > machine native so you can't replay an Irix log on Linux. > > even if your running linux on a big endian architecture? Hm, I did mix-and-match that a bit, didn't I. Now I'm not sure. There is endian-ness in the logs, but there are also some differences in the log, I think (at least right after mkfs). However, I -think- that logs are portable between machines of the same endian-ness. I'd have to go dig for a while to know for sure. Steve can probably say for sure off the top of his head. :) -Eric From owner-linux-xfs@oss.sgi.com Fri Jan 17 07:54:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 07:54:49 -0800 (PST) Received: from mailserver.globalintech.pl (helios.globalintech.pl [62.89.81.98]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HFsh3v007881 for ; Fri, 17 Jan 2003 07:54:45 -0800 Received: from ima.pl (blizbor.globalintech.pl [172.26.25.88]) (authenticated) by mailserver.globalintech.pl (8.11.6/8.11.6) with ESMTP id h0HG10S02747 for ; Fri, 17 Jan 2003 17:01:00 +0100 Message-ID: <3E2828BE.8010308@ima.pl> Date: Fri, 17 Jan 2003 17:01:02 +0100 From: "Blizbor (IMA)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: How to make filenames case insensitive References: <20030115153637.TUXB19222.imf12bis.bellsouth.net@marsha> <1042645267.16153.4.camel@jen.americas.sgi.com> <1042714378.8477.14.camel@venus> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 2364 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tb670725@ima.pl Precedence: bulk X-list: linux-xfs Content-Length: 1191 Lines: 39 Olaf Fra;czyk wrote: > On Wed, 2003-01-15 at 16:41, Steve Lord wrote: > >>XFS does not have a native way, there has been someone working on a >>case insensitive XFS, but that involved changing the hash algorithm >>XFS uses internally and on the disk, so it would not help here. > > Is it in active development or it has been dropped? > Or you know a case-insensitive filesystem for linux with journaling? > > Regards, > > Olaf Really, I cant see a good reason for porting Microsoft "case insensitive filenames bug" into a really good filesystem. Have you any other reason for such a change ? Olaf, could I suggest you something: dd if=/dev/cdrom of=/MyISOImages/image01.img losetup /dev/loop0 /MyISOImages/image01.img mkdir /mnt/myarch01 mount /dev/loop0 /mnt/myarch01 Another way is to copy files to a xfs, rename all files and directories to a smallcase letters. Then write a module with "hook" for the open() call. This call should work in two steps: call open.original without case change, if success return if failed again call open() with case changed to small. Should be quick and simple and most important doesent require change in a big well tuned code. Regards, Blizbor From owner-linux-xfs@oss.sgi.com Fri Jan 17 09:29:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 09:29:34 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HHTT3v010739 for ; Fri, 17 Jan 2003 09:29:29 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0HHhPkq000790 for ; Fri, 17 Jan 2003 11:43:25 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA64005; Fri, 17 Jan 2003 11:35:43 -0600 (CST) Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA15347; Fri, 17 Jan 2003 11:35:43 -0600 (CST) Received: from chewtoy.americas.sgi.com by chewtoy.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id LAA23194; Fri, 17 Jan 2003 11:35:42 -0600 (CST) Message-Id: <200301171735.LAA23194@chewtoy.americas.sgi.com> To: James A Goodwin cc: linux-xfs@oss.sgi.com Subject: Re: dm_handle_to_path Date: Fri, 17 Jan 2003 11:35:42 -0600 From: Dean Roehrich X-archive-position: 2365 X-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: 394 Lines: 17 >From: James A Goodwin > > > > >Dean, > >I remember asking about this call before, but I seem to remember that the >implementation only worked under certain circumstances. Is that still the >case, or does it really work now? It's still listed in the DMAPI Status >file as a function that does not work. I had forgotten about the Status file--it's out of date. Dean From owner-linux-xfs@oss.sgi.com Fri Jan 17 09:46:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 09:46:29 -0800 (PST) Received: from mail.aspec.ru (mail.aspec.ru [217.14.198.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HHkO3v012038 for ; Fri, 17 Jan 2003 09:46:26 -0800 Received: from [192.168.30.20] (HELO dm) by mail.aspec.ru (CommuniGate Pro SMTP 4.0.3) with SMTP id 1037809 for linux-xfs@oss.sgi.com; Fri, 17 Jan 2003 21:52:38 +0400 Message-ID: <000501c2be51$81511bc0$141ea8c0@dm> From: "Dmitry Melekhov" To: Subject: xfs for Oracle datafiles Date: Fri, 17 Jan 2003 21:54:37 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 2366 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dm@belkam.com Precedence: bulk X-list: linux-xfs Content-Length: 291 Lines: 11 Hello! I'm afraid this is offtopic here, but... We are going to install new Oracle server next week. Usually we use ext2 for datafiles, but we use xfs on fileservers and it is excellent! Could you tell me is xfs good choise for Oracle datafiles, is there performance problems? Thank you! From owner-linux-xfs@oss.sgi.com Fri Jan 17 09:56:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 09:56:10 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HHu33v012584 for ; Fri, 17 Jan 2003 09:56:04 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0HI2M1h073026 for ; Fri, 17 Jan 2003 19:02:23 +0100 (CET) Message-Id: <4.3.2.7.2.20030117185540.035e08e8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 Jan 2003 19:02:18 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Patched 1.2Pre5 kernel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 783 Lines: 24 This kernel is brought to you by Seth' Remarkebly Unreliable Kernel service. This kernel is based on the Red Hat 2.4.18-19.8.0 kernel with the XFS patch from 1.2Pre5 patched into it. This means that people using broadcom gigabit cards (bcm5700 ot tg3 module) who see a lot of crashes or mysterious hangs might find this interesting. The i686 build fails at the moment but so you will have to do with the kernel-source rpm instead. The i686 build will follow later. Disclaimer: The kernel compiles, boots and so far survived 60 simultaneous Bonnie processes on a software raid 5 volume. That means that it might not eat your disk after all :-) Still not scared? Go here http://iserv.nl/files/xfs/ Have a nice day, -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Jan 17 10:05:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 10:05:37 -0800 (PST) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HI5X3v013220 for ; Fri, 17 Jan 2003 10:05:34 -0800 Received: from e31.co.us.ibm.com (e31.esmtp.ibm.com [9.14.4.129]) by pokfb.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id h0HHTVPB078948 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 17 Jan 2003 12:29:34 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0HHJQRV018662; Fri, 17 Jan 2003 12:19:27 -0500 Received: from d03nm800.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0HHNIE2024526; Fri, 17 Jan 2003 10:23:19 -0700 Subject: Re: dm_handle_to_path To: Dean Roehrich Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: James A Goodwin Date: Fri, 17 Jan 2003 11:18:49 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 01/17/2003 10:19:14 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 2368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jagoodwi@us.ibm.com Precedence: bulk X-list: linux-xfs Content-Length: 2234 Lines: 57 Dean, I remember asking about this call before, but I seem to remember that the implementation only worked under certain circumstances. Is that still the case, or does it really work now? It's still listed in the DMAPI Status file as a function that does not work. Regards, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich cc: linux-xfs@oss.sgi.com Subject: Re: dm_handle_to_path 01/15/2003 02:51 PM >From: James A Goodwin >dm_handle_to_path() is listed as a DMAPI function that does not work. Is >this because nobody knows how to write it or just because nobody has really >needed it yet? If it's the second case, would it be possible to get it >working? > >We are considering adding new functionality to our software, but it would >never work unless we could count on using dm_handle_to_path(). dm_handle_to_path ... James Goodwin....dm_handle_to_path.... Must have been a nightmare. But if Christoph say's it's done, then maybe it wasn't... Dean From owner-linux-xfs@oss.sgi.com Fri Jan 17 10:33:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 10:33:56 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HIXp3v014122 for ; Fri, 17 Jan 2003 10:33:54 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0HGeDG8014262 for ; Fri, 17 Jan 2003 08:40:15 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA02764 for ; Fri, 17 Jan 2003 12:40:03 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA14299 for ; Fri, 17 Jan 2003 12:40:03 -0600 (CST) Received: from rose.americas.sgi.com (localhost [127.0.0.1]) by rose.americas.sgi.com (8.12.6/8.12.5) with ESMTP id h0HIePKu014313 for ; Fri, 17 Jan 2003 12:40:25 -0600 Received: (from cattelan@localhost) by rose.americas.sgi.com (8.12.6/8.12.6/Submit) id h0HIePPx014311 for linux-xfs@oss.sgi.com; Fri, 17 Jan 2003 12:40:25 -0600 X-Authentication-Warning: rose.americas.sgi.com: cattelan set sender to cattelan@xfs.org using -f Subject: cvs access to oss shut down From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042828824.11863.85.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 (1.2.0-3) Date: 17 Jan 2003 12:40:24 -0600 X-archive-position: 2370 X-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 Content-Length: 170 Lines: 9 Due to a security hole in cvs It is unclear when a proper fix will be available. cvsup access to the repository is available. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Fri Jan 17 10:32:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 10:32:54 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HIWo3v013919 for ; Fri, 17 Jan 2003 10:32:51 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0HIdAvk025458; Fri, 17 Jan 2003 13:39:10 -0500 Received: from d03nm800.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0HIbsWt051694; Fri, 17 Jan 2003 11:37:54 -0700 Subject: Re: dm_handle_to_path To: Dean Roehrich Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: James A Goodwin Date: Fri, 17 Jan 2003 12:37:29 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 01/17/2003 11:37:55 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 2369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jagoodwi@us.ibm.com Precedence: bulk X-list: linux-xfs Content-Length: 1852 Lines: 48 So are you saying that dm_handle_to_path works now? That would be excellent news. -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich cc: linux-xfs@oss.sgi.com Subject: Re: dm_handle_to_path 01/17/2003 11:35 AM >From: James A Goodwin > > > > >Dean, > >I remember asking about this call before, but I seem to remember that the >implementation only worked under certain circumstances. Is that still the >case, or does it really work now? It's still listed in the DMAPI Status >file as a function that does not work. I had forgotten about the Status file--it's out of date. Dean From owner-linux-xfs@oss.sgi.com Fri Jan 17 11:05:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 11:05:18 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HJ5F3v032303 for ; Fri, 17 Jan 2003 11:05:15 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0HHBdG8016730 for ; Fri, 17 Jan 2003 09:11:39 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA10781; Fri, 17 Jan 2003 13:11:23 -0600 (CST) Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA63524; Fri, 17 Jan 2003 13:11:23 -0600 (CST) Received: from chewtoy.americas.sgi.com by chewtoy.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id NAA23390; Fri, 17 Jan 2003 13:11:23 -0600 (CST) Message-Id: <200301171911.NAA23390@chewtoy.americas.sgi.com> To: James A Goodwin cc: linux-xfs@oss.sgi.com Subject: Re: dm_handle_to_path Date: Fri, 17 Jan 2003 13:11:23 -0600 From: Dean Roehrich X-archive-position: 2371 X-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: 184 Lines: 13 >From: James A Goodwin > > > > >So are you saying that dm_handle_to_path works now? That would be >excellent news. It was working last May, I believe. Dean From owner-linux-xfs@oss.sgi.com Fri Jan 17 12:00:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Jan 2003 12:02:51 -0800 (PST) Received: from sl.pt (mail.sl.pt [212.55.140.13]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0HK0n3v000981 for ; Fri, 17 Jan 2003 12:00:51 -0800 Received: (qmail 24807 invoked by uid 0); 17 Jan 2003 20:07:04 -0000 Received: from unknown (HELO angelina.tp.telepac.local) ([172.16.150.17]) (envelope-sender ) by mail.sl.pt (qmail-ldap-1.03) with SMTP for ; 17 Jan 2003 20:07:04 -0000 Received: (from nmr@localhost) by angelina.tp.telepac.local (8.11.6+Sun/8.11.6) id h0HK73b15804; Fri, 17 Jan 2003 20:07:03 GMT Date: Fri, 17 Jan 2003 20:07:03 +0000 From: Nuno Rodrigues To: Dmitry Melekhov Cc: linux-xfs@oss.sgi.com Subject: Re: xfs for Oracle datafiles Message-ID: <20030117200703.GD12606@angelina.tp.telepac.local> References: <000501c2be51$81511bc0$141ea8c0@dm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000501c2be51$81511bc0$141ea8c0@dm> User-Agent: Mutt/1.4i X-archive-position: 2372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nmr@ptm.pt Precedence: bulk X-list: linux-xfs Content-Length: 829 Lines: 30 On Fri, Jan 17, 2003 at 09:54:37PM +0400, Dmitry Melekhov wrote: > Hello! > > I'm afraid this is offtopic here, but... > We are going to install new Oracle server next week. > Usually we use ext2 for datafiles, but we use xfs on fileservers and it is > excellent! > Could you tell me is xfs good choise for Oracle datafiles, is there > performance problems? > Thank you! > > > Hello there, We've been running Oracle 9i, on Linux 2.4.18-xfs, for some time now, without any trouble. The XFS utility `xfs_mkfile' is particularly useful for creating the datafiles with one extend (XFS extend, physically contiguous on disk), with the obvious performance improvements. It permits taking advantage of the temporal and spacial access locality to avoid disk seeks. Regards, -- Nuno M. Rodrigues From owner-linux-xfs@oss.sgi.com Sat Jan 18 09:10:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 18 Jan 2003 09:10:55 -0800 (PST) Received: from wideangle.nameip.net (IDENT:4f9/kikJCiP7Qx2sBnh/qZlsCxwf6B/E@[210.205.154.126]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0IHAC3v018109 for ; Sat, 18 Jan 2003 09:10:21 -0800 Received: (qmail 5981 invoked by uid 500); 18 Jan 2003 17:16:34 -0000 Subject: CPU overhead when handling large files? From: Seung-yeong Oh To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1042910194.2187.15.camel@wideangle.nameip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 19 Jan 2003 02:16:34 +0900 X-archive-position: 2374 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: so1713@orgio.net Precedence: bulk X-list: linux-xfs Content-Length: 721 Lines: 15 Hello, Originally, I installed RedHat7.2 + SGI XFS 1.0.2. I now have fully updated RedHat7.2 + SGI XFS 1.2pre5 (rebuilt kernel RPM to be installed on RedHat 7.x). For current seup, I'm wondering if the following behavior is normal; When handling large files, for example, copying a few 700MB files from one directory to another, at some point in the middle of the process or at the end of it, the process hangs for several minutes taking up 99% of CPU. A friend of mine told me it might take some time to rewrite inodes as it's a journaling file system, but I don't remember the XFS acted this way before when I was using 1.0.2 of it. And 1.1 for that matter... I'd appreciate any input. Thank you. Have a nice weekend. From owner-linux-xfs@oss.sgi.com Sat Jan 18 10:49:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 18 Jan 2003 10:49:07 -0800 (PST) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0IIn43v020240 for ; Sat, 18 Jan 2003 10:49:05 -0800 Received: from user-2injgj8.dsl.mindspring.com ([165.121.194.104] helo=nomad) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18Zy7s-0001P8-00 for linux-xfs@oss.sgi.com; Sat, 18 Jan 2003 10:55:28 -0800 Message-ID: <000e01c2bf23$2a371a10$2759fea9@nomad> Reply-To: "Richard Smith" From: "Richard Smith" To: Subject: Fw: rm hanging intermittently Date: Sat, 18 Jan 2003 10:55:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 2375 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rgsmith72@earthlink.net Precedence: bulk X-list: linux-xfs Content-Length: 7493 Lines: 197 ----- Original Message ----- From: "Richard Smith" To: "Russell Cattelan" ; "Rick Smith" Cc: ; ; Sent: Friday, January 17, 2003 9:52 PM Subject: Re: rm hanging intermittently > Russell, > Below are the bdflush, kswapd, kupdated and pagebufd backtraces from the > lastest hanging process. They all seem to be paused in the same place. If I > kill the hung rm process, everyone wakes back up and the system continues > normally. > Where do I create a new bugzilla bug? Thanks for your help. > > Rick > > [2]kdb> btp 8 > 0xf7cd0000 00000008 00000001 0 002 stop 0xf7cd0370 bdflush > ESP EIP Function (args) > 0xf7cd1f84 0xc0116063 schedule+0x493 (0x0, 0xf7cd0000, 0xc040d538, > 0xc040d538, 0x1f4) > kernel .text 0xc0100000 0xc0115bd0 0xc0116120 > 0xf7cd1fc4 0xc01164ca interruptible_sleep_on+0x4a (0x10f00, 0xf7ffbfb8) > kernel .text 0xc0100000 0xc0116480 0xc0116500 > 0xf7cd1fe4 0xc013e6b7 bdflush+0xc7 > kernel .text 0xc0100000 0xc013e5f0 0xc013e6c0 > 0xf7cd1ff4 0xc0107296 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0107270 0xc01072a0 > [2]kdb> go > > [0]kdb> btp 7 > 0xf7cd4000 00000007 00000001 0 000 stop 0xf7cd4370 kswapd > ESP EIP Function (args) > 0xf7cd5f94 0xc0116063 schedule+0x493 (0x0, 0xf7cd4000, 0xc040cad4, > 0xc040cad4, 0x10f00) > kernel .text 0xc0100000 0xc0115bd0 0xc0116120 > 0xf7cd5fd4 0xc0132d66 kswapd+0x86 > kernel .text 0xc0100000 0xc0132ce0 0xc0132d96 > 0xf7cd5ff4 0xc0107296 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0107270 0xc01072a0 > [0]kdb> go > > [3]kdb> btp 9 > 0xf7cce000 00000009 00000001 0 003 stop 0xf7cce370 kupdated > ESP EIP Function (args) > 0xf7ccff68 0xc0116063 schedule+0x493 (0xf7ccffac, 0xc04abd04, 0xc044a7fc, > 0x1bc3472, 0xf7cce000) > kernel .text 0xc0100000 0xc0115bd0 0xc0116120 > 0xf7ccffa8 0xc0115b1e schedule_timeout+0x7e (0x0, 0x10f00, 0xf7ffbfac, > 0xc0105000) > kernel .text 0xc0100000 0xc0115aa0 0xc0115b40 > 0xf7ccffdc 0xc013e764 kupdate+0xa4 > kernel .text 0xc0100000 0xc013e6c0 0xc013e800 > 0xf7ccfff4 0xc0107296 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0107270 0xc01072a0 > [3]kdb> go > > [2]kdb> btp 10 > 0xf7c98000 00000010 00000001 0 002 stop 0xf7c98370 pagebufd > ESP EIP Function (args) > 0xf7c99f48 0xc0116063 schedule+0x493 (0x0, 0xf7c98000, 0xc04130e8, > 0xc04130e8, 0xf7c99fc0) > kernel .text 0xc0100000 0xc0115bd0 0xc0116120 > 0xf7c99f88 0xc01164ca interruptible_sleep_on+0x4a (0xf7c99fc0, 0xf7c99fc0, > 0xf7c99fc0, 0xf7c98000, 0xf7c99fb8) > kernel .text 0xc0100000 0xc0116480 0xc0116500 > 0xf7c99fa8 0xc02044a3 pagebuf_daemon+0xd3 > kernel .text 0xc0100000 0xc02043d0 0xc0204640 > 0xf7c99ff4 0xc0107296 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0107270 0xc01072a0 > [2]kdb> go > > ----- Original Message ----- > From: "Russell Cattelan" > To: "Rick Smith" > Cc: ; ; ; > > Sent: Wednesday, January 15, 2003 1:46 PM > Subject: RE: rm hanging intermittently > > > > Before this gets lost can you open a bug in bugzilla and > > add this BT to it. > > > > And actually a bta (back trace all) would probably be more helpful > > since it usually informative to see what the kernel threads bdflush > > kswapd, kupdated, and the pagebuf daemons are doing. > > > > On Wed, 2003-01-15 at 14:14, Rick Smith wrote: > > > Eric, > > > I was able to successfully capture a backtrace of the hanging rm > > > problem today. It looks like it (and several other processes) are stuck > in > > > the schedule() function. After searching the mailing list archive, there > > > were several other similar problems concerning deadlock, but the closest > was > > > posted by Matthew Wilcox at debian on 10-30-02 with the subject "unlink > > > deadlock". The backtrace that he posted is quite similar to mine and we > are > > > both using raid 0. I, however, am not using IA-64 architecture. > > > For me the problem seems to happen when there are multiple writes > (to > > > two different XFS partitions) very close to each other. Has this > deadlock > > > been addressed in kernels later than 2.4.20-rc1-xfs? Thanks for your > help. > > > The backtrace follows: > > > > > > [2]kdb> btp 18758 > > > 0xd5812000 00018758 00018739 0 002 stop 0xd5812370 rm > > > ESP EIP Function (args) > > > 0xd5813d38 0xc0116063 schedule+0x493 (0x1, 0xd5812000, 0xf7c3ad8c, > > > 0xf7c3ad8c, 0xf7580700) > > > kernel .text 0xc0100000 0xc0115bd0 > 0xc0116120 > > > 0xd5813d78 0xc0107828 __down+0x68 > > > kernel .text 0xc0100000 0xc01077c0 > 0xc0107890 > > > 0xd5813d94 0xc01079d4 __down_failed+0x8 (0x33c, 0xd5813df8, 0xf711f3cc, > > > 0xd5813dfc, 0xc01ec543) > > > kernel .text 0xc0100000 0xc01079cc > 0xc01079d8 > > > 0xd5813da4 0xc01ee0eb .text.lock.xfs_log+0xdb > > > kernel .text 0xc0100000 0xc01ee010 > 0xc01ee250 > > > 0xd5813da4 0xc01eccb2 xlog_state_get_iclog_space+0x62 (0xf7c3ad80, > 0x33c, > > > 0xd5813df8, 0xf711f3cc, 0xd5813dfc) > > > kernel .text 0xc0100000 0xc01ecc50 > 0xc01ecda0 > > > 0xd5813db8 0xc01ec543 xlog_write+0x153 (0xf6ff8c00, 0xd5813e68, 0xc, > > > 0xf711f3cc, 0xdf8b2c5c) > > > kernel .text 0xc0100000 0xc01ec3f0 > 0xc01ec800 > > > 0xd5813e18 0xc01eb51c xfs_log_write+0x3c (0xf6ff8c00, 0xd5813e68, 0xc, > > > 0xf711f3cc, 0xdf8b2c5c) > > > kernel .text 0xc0100000 0xc01eb4e0 > 0xc01eb550 > > > 0xd5813e3c 0xc01f7b24 xfs_trans_commit+0x184 (0xdf8b2c10, 0x4, 0x0, > > > 0xd5813f2c, 0x11) > > > kernel .text 0xc0100000 0xc01f79a0 > 0xc01f7c50 > > > 0xd5813efc 0xc01fe6b8 xfs_remove+0x398 (0xd8c876d8, 0xd8c85580, 0x0) > > > kernel .text 0xc0100000 0xc01fe320 > 0xc01fe790 > > > 0xd5813f54 0xc0209fbe linvfs_unlink+0x1e (0xd8c86da0, 0xd8c85580) > > > kernel .text 0xc0100000 0xc0209fa0 > 0xc020a000 > > > 0xd5813f70 0xc0145d35 vfs_unlink+0x135 (0xd8c86da0, 0xd8c85580, > 0xd8c8e180, > > > 0xf7cd2e40, 0xf2df9000) > > > kernel .text 0xc0100000 0xc0145c00 > 0xc0145da0 > > > 0xd5813f8c 0xc0145e29 sys_unlink+0x89 (0x8053dab, 0x1, 0x0, 0x8053dab, > 0x0) > > > kernel .text 0xc0100000 0xc0145da0 > 0xc0145e90 > > > 0xd5813fc4 0xc0108c2b system_call+0x33 > > > kernel .text 0xc0100000 0xc0108bf8 > 0xc0108c30 > > > [2]kdb> go > > > > > > Rick Smith > > > > > > _________________________________________________________________ > > > MSN 8 with e-mail virus protection service: 2 months FREE* > > > http://join.msn.com/?page=features/virus > > -- > > Russell Cattelan > From owner-linux-xfs@oss.sgi.com Sat Jan 18 12:04:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 18 Jan 2003 12:04:55 -0800 (PST) Received: from CPE014280010574.cpe.net.cable.rogers.com (CPE0080c6e90c22-CM014280010574.cpe.net.cable.rogers.com [24.43.161.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0IK4m3v021150 for ; Sat, 18 Jan 2003 12:04:51 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by CPE014280010574.cpe.net.cable.rogers.com (8.11.6/8.11.6) with ESMTP id h0IKB8920984; Sat, 18 Jan 2003 15:11:08 -0500 Subject: 1.2pre5 patch release issues From: Jeremy Jackson To: linux-xfs@oss.sgi.com Cc: cattelan@thebarn.com Content-Type: text/plain Organization: Message-Id: <1042920670.1727.49.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 18 Jan 2003 15:11:10 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 982 Lines: 28 I've seen corruption of open files/dirs on shutdown twice. xfs_repair worked, and I was able to recreate a few dirs under /var by hand the first time. The second xfs_repair did it all. The first time I blamed myself for compiling with an inadequate heatsink on the CPU. The second was a mystery until I saw the other posts. I'm using 2.4.19 with EVMS 1.2.1 now. I was using EVMS 1.2.0, which would resync the raid on every reboot due to a bug. I think it might be related. In the message: http://oss.sgi.com/projects/xfs/mail_archive/200301/msg00089.html the 1.2pre5 releases are announced. It's not on the web page yet, hint, hint. Also, the naming has changed... on purpose? There is no CHANGELOG yet, does it include the fix described in message: http://oss.sgi.com/projects/xfs/mail_archive/200301/msg00072.html I'd also like to request the releases to include patches against 2.4.20 Keep up the good work! XFS rocks! -- Jeremy Jackson From owner-linux-xfs@oss.sgi.com Sat Jan 18 12:14:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 18 Jan 2003 12:14:26 -0800 (PST) Received: from CPE014280010574.cpe.net.cable.rogers.com (CPE0080c6e90c22-CM014280010574.cpe.net.cable.rogers.com [24.43.161.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0IKEM3v021646 for ; Sat, 18 Jan 2003 12:14:22 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by CPE014280010574.cpe.net.cable.rogers.com (8.11.6/8.11.6) with ESMTP id h0IKKk920995; Sat, 18 Jan 2003 15:20:46 -0500 Subject: Re: XFS "lockfs" Functionality From: Jeremy Jackson To: linux-xfs@oss.sgi.com Cc: jeff.browning@netapp.com Content-Type: text/plain Organization: Message-Id: <1042921249.1735.58.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 18 Jan 2003 15:20:49 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2377 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 1036 Lines: 23 Someone else pointed out that LVM's snapshots take advantage of a VFS lock patch and to this automagically. I'd like to point out that EVMS also includes a patch of this nature, and I have used EVMS and the xfs-VFS-lock patch successfully with XFS. It pauses the fs, flushes the XFS journal, syncs the disk, marks the fs clean, takes the snapshot, unpauses the fs. Works with other fs also. The only trick is that you have to mount the snapshot with -o nouuid so that XFS's isn't too smart for itsself. It normally won't allow mounting of two fs with same UUID, to catch the case where someone clones a disk and connects it to the same system (messes up xfsdump). Since it was snapshotted in the clean shutdown state, it can be mounted read-only (although evms allows read-write shapshots too) I laughed out loud the first time I tried it, it was so easy. I remember writing scripts to shut down all services, remount root read-only, copy to another disk (took 30 mintes!), restart... -- Jeremy Jackson From owner-linux-xfs@oss.sgi.com Sat Jan 18 14:17:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 18 Jan 2003 14:17:04 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0IMGw3v022927 for ; Sat, 18 Jan 2003 14:17:00 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id F01A71831DF6; Sat, 18 Jan 2003 14:23:23 -0800 (PST) Date: Sat, 18 Jan 2003 14:23:23 -0800 From: Chris Wedgwood To: Seung-yeong Oh Cc: linux-xfs@oss.sgi.com Subject: Re: CPU overhead when handling large files? Message-ID: <20030118222323.GA23585@f00f.org> References: <1042910194.2187.15.camel@wideangle.nameip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1042910194.2187.15.camel@wideangle.nameip.net> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2378 X-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: 864 Lines: 23 On Sun, Jan 19, 2003 at 02:16:34AM +0900, Seung-yeong Oh wrote: > For current seup, I'm wondering if the following behavior is normal; > When handling large files, for example, copying a few 700MB files from > one directory to another, at some point in the middle of the process or > at the end of it, the process hangs for several minutes taking up 99% of > CPU. It could be the nasty 2.4.x VM... or maybe not. How full is your disk when doing this? How fragmented (xfs_bmap) are the files when you are done? > A friend of mine told me it might take some time to rewrite inodes > as it's a journaling file system, but I don't remember the XFS acted > this way before when I was using 1.0.2 of it. And 1.1 for that > matter... I'd appreciate any input. Thank you. Have a nice > weekend. Writing/updating the inodes shouldn't be barely noticeable. --cw From owner-linux-xfs@oss.sgi.com Sun Jan 19 10:35:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jan 2003 10:35:56 -0800 (PST) Received: from wideangle.nameip.net (IDENT:ZLrIN67WoiVSe1tnf8xA5GYpCx74clJm@[210.205.154.126]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0JIZn3v006606 for ; Sun, 19 Jan 2003 10:35:50 -0800 Received: (qmail 7460 invoked by uid 500); 19 Jan 2003 18:42:16 -0000 Subject: recommended compiler? From: Seung-yeong Oh To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1043001736.1855.18.camel@wideangle.nameip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 20 Jan 2003 03:42:16 +0900 X-archive-position: 2379 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: so1713@orgio.net Precedence: bulk X-list: linux-xfs Content-Length: 884 Lines: 20 Hello, I'm still trying to figure out what the source of my problem is; http://oss.sgi.com/projects/xfs/mail_archive/200301/msg00194.html Anyway, what is the recommended compiler for XFS 1.2? Up to 1.1, I've read that SGI developer team recommends kgcc in the Makefile, I don't see that sort of NOTE in the Makefile in kernel 2.4.18-18SGI_XFS_1.2pre5. If kernel rpm with XFS1.2 is made for RedHat 8.0 AND RedHat8.0 uses gcc3 as the default compiler, then would the binary made in RedHat7.x cause some sort of problems when the default compiler in RedHat7.x is used, which is ver. 2.96? Also, what about glibc version? The main reason I rebuilt kernel source rpm with XFS 1.2 was that the binary rpm's were built with glibc2.3. If binary cmd & kernel rpm's made with glibc2.2 in RedHat7.x are used, would that cause some compatibility issue? I'd appreciate any comment. Thank you. From owner-linux-xfs@oss.sgi.com Sun Jan 19 12:28:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jan 2003 12:28:35 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0JKSV3v007876 for ; Sun, 19 Jan 2003 12:28:32 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0JKYtFa063401; Sun, 19 Jan 2003 21:34:56 +0100 (CET) Message-Id: <4.3.2.7.2.20030119213050.0418e958@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 19 Jan 2003 21:34:52 +0100 To: Seung-yeong Oh , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: recommended compiler? In-Reply-To: <1043001736.1855.18.camel@wideangle.nameip.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1482 Lines: 39 At 03:42 20-1-2003 +0900, Seung-yeong Oh wrote: >Hello, >I'm still trying to figure out what the source of my problem is; > >http://oss.sgi.com/projects/xfs/mail_archive/200301/msg00194.html > >Anyway, what is the recommended compiler for XFS 1.2? Up to 1.1, I've >read that SGI developer team recommends kgcc in the Makefile, I don't >see that sort of NOTE in the Makefile in kernel >2.4.18-18SGI_XFS_1.2pre5. I build my kernels with gcc-2.96 these days which seem to do fine. The kgcc was mainly needed in the pre 11 releases. A lot of people use the (updated!) 2.96 which seems to work fairly well. >If kernel rpm with XFS1.2 is made for RedHat 8.0 AND RedHat8.0 uses gcc3 >as the default compiler, then would the binary made in RedHat7.x cause >some sort of problems when the default compiler in RedHat7.x is used, >which is ver. 2.96? I suspect that using gcc-3.0 will turn up more problems then compiling with 2.96. I don't even have one 8.0 box around to compile those things. >Also, what about glibc version? The main reason I rebuilt kernel source >rpm with XFS 1.2 was that the binary rpm's were built with glibc2.3. If >binary cmd & kernel rpm's made with glibc2.2 in RedHat7.x are used, >would that cause some compatibility issue? I don't see why the kernel needs to have a glibc dependency. The same sources build fine on a glibc-2.2 system along as you do a make mrproper before building. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sun Jan 19 13:47:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jan 2003 13:48:02 -0800 (PST) Received: from net.bluemoon.net (root@net.bluemoon.net [63.237.147.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0JLlv3v008695 for ; Sun, 19 Jan 2003 13:47:59 -0800 Received: from localhost (fantom@localhost) by net.bluemoon.net (8.12.4/8.12.4) with ESMTP id h0JLsMaY061667; Sun, 19 Jan 2003 16:54:22 -0500 (EST) (mail-from fant@pobox.com) X-Authentication-Warning: net.bluemoon.net: fantom owned process doing -bs Date: Sun, 19 Jan 2003 16:54:22 -0500 (EST) From: Andrew Fant X-X-Sender: fantom@net.bluemoon.net To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: recommended compiler? In-Reply-To: <4.3.2.7.2.20030119213050.0418e958@pop.xs4all.nl> Message-ID: <20030119164735.S59620-100000@net.bluemoon.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fant@pobox.com Precedence: bulk X-list: linux-xfs Content-Length: 1502 Lines: 34 On Sun, 19 Jan 2003, Seth Mos wrote: > At 03:42 20-1-2003 +0900, Seung-yeong Oh wrote: > >Anyway, what is the recommended compiler for XFS 1.2? Up to 1.1, I've > >read that SGI developer team recommends kgcc in the Makefile, I don't > >see that sort of NOTE in the Makefile in kernel > >2.4.18-18SGI_XFS_1.2pre5. > > I build my kernels with gcc-2.96 these days which seem to do fine. The kgcc > was mainly needed in the pre 11 releases. > > A lot of people use the (updated!) 2.96 which seems to work fairly well. > > >If kernel rpm with XFS1.2 is made for RedHat 8.0 AND RedHat8.0 uses gcc3 > >as the default compiler, then would the binary made in RedHat7.x cause > >some sort of problems when the default compiler in RedHat7.x is used, > >which is ver. 2.96? > > I suspect that using gcc-3.0 will turn up more problems then compiling with > 2.96. I don't even have one 8.0 box around to compile those things. I have been using the XFS sources kernel in Gentoo 1.4_rc1 and rc2 (which uses gcc3.2 and glibc2.3) for the past 4 months without any troubles. Yes, gcc 3.2 is rather anal, but most of the problems I have seen are with c++ idioms that the development team disapproves of. The kernel with XFS compiles with nary a hitch. Andrew Fant | This | "If I could walk THAT way... Molecular Geek | Space | I wouldn't need the talcum powder!" fant@pobox.com | For | G. Marx (apropos of Aerosmith) Boston, MA USA | Hire | http://www.pharmawulf.com From owner-linux-xfs@oss.sgi.com Sun Jan 19 14:25:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jan 2003 14:25:51 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0JMPl3v017629 for ; Sun, 19 Jan 2003 14:25:47 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0JKWKG8030558 for ; Sun, 19 Jan 2003 12:32:20 -0800 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 h0JMUs3s2449375 for ; Mon, 20 Jan 2003 09:30:54 +1100 (EST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h0JMUsT42423438 for linux-xfs@oss.sgi.com; Mon, 20 Jan 2003 09:30:54 +1100 (EST) Date: Mon, 20 Jan 2003 09:30:54 +1100 (EST) From: Timothy Shimmin Message-Id: <200301192230.h0JMUsT42423438@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl.5 X-archive-position: 2382 X-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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 353 Lines: 16 acl 5 man page correction Date: Sun Jan 19 14:30:22 PST 2003 Workarea: snort.melbourne.sgi.com:/home/tes/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:137310a cmd/acl/man/man5/acl.5 - 1.16 - correction from AG for mistake in acl 5 man page. ACL_MASK -> ACL_OTHER From owner-linux-xfs@oss.sgi.com Sun Jan 19 19:14:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jan 2003 19:14:14 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0K3E73v021191 for ; Sun, 19 Jan 2003 19:14:08 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h0K3KXlx018590 for ; Sun, 19 Jan 2003 19:20:33 -0800 From: "LA Walsh" To: Subject: xfs vs. jfs results: why? Date: Sun, 19 Jan 2003 19:20:33 -0800 Message-ID: <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 1784 Lines: 41 CONCLUSION: We are not able to reproduce the excellent numbers described at: http://home.fnal.gov/~yocum/storageServerTechnicalNote.html It appears that the best performance for read-orientated and mixed workloads is obtained with JFS, for write-orientated XFS. --- From page: http://pcbunn.cacr.caltech.edu/gae/3ware_raid_tests.htm Basic thrust was JFS anywhere from 12-28% faster on reads, XFS up to 33% faster on writes. Writes are good, but the aren't what I do the most of (though wasn't xfs designed with tuning for dmedia recording in real-time as a priority?). XFS seemed to, _very_ slightly outperform reads on Reiser though Reiser's worse times were sometimes better than our worst. Reiser performed about 20% better than XFS for writes when 3ware native RAID5 was enabled. So XFS not clearly an across the board champ in reads or writes though overall, as article claims, XFS as 2nd. So...wazzup? Isn't JFS newer? Hasn't XFS been around longer and had benefit of years of tuning? Is it just the linux integration that has slowed things down? Maybe I've just read too many of our own marketing docs, but I thought XFS was close to stellar among FS's...? Is this testing bogus? A fluke? Or should I start getting a grip with reality and becoming disillusioned (illusions of marketing tripe instilled in head being laid to rest...?) BTW -- hope this goes through, ok...my email has been weird since around midnight this morning. Getting some spatterings of outside email, but no list email from any of my list subscriptions. Very weird since they are from disparate list servers. Other connectivity seems unchanged... If you respond to this, please 'cc' me too so I can hopefully get a copy...I'm not sure what would be blocking listmails... tnx, -l From owner-linux-xfs@oss.sgi.com Sun Jan 19 23:57:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Jan 2003 23:57:56 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0K7vp3v005635 for ; Sun, 19 Jan 2003 23:57:52 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 920AAAC43; Mon, 20 Jan 2003 09:10:37 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id A30B8190D5; Mon, 20 Jan 2003 09:10:36 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 76BCB308825; Mon, 20 Jan 2003 09:04:20 +0100 (CET) Message-ID: <3E2BAD84.89D62FEC@ch.sauter-bc.com> Date: Mon, 20 Jan 2003 09:04:20 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Patched 1.2Pre5 kernel References: <4.3.2.7.2.20030117185540.035e08e8@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1355 Lines: 46 Seth Mos schrieb: > > This kernel is brought to you by Seth' Remarkebly Unreliable Kernel service. > > This kernel is based on the Red Hat 2.4.18-19.8.0 kernel with the XFS patch > from 1.2Pre5 patched into it. Seth, that's cool! > > This means that people using broadcom gigabit cards (bcm5700 ot tg3 module) > who see a lot of crashes or mysterious hangs might find this interesting. > > The i686 build fails at the moment but so you will have to do with the > kernel-source rpm instead. The i686 build will follow later. Well, I had the same problem when I created such kernel rpms in the past (on RedHat 7.2). I finally was able to compile all of them like this: In the .spec, I changed this: %define buildUML 0 Then, it's important to call the build processs for every architecture at once, like this: rpm -ba --target "i386,i586,i686,athlon" kernel....src.rpm or, maybe it was rpm -ba --target=i386,i586,i686,athlon depending on RPM version. I'll try it but I don't have a fast box to compile. Simon > > Disclaimer: > The kernel compiles, boots and so far survived 60 simultaneous Bonnie > processes on a software raid 5 volume. > That means that it might not eat your disk after all :-) > > Still not scared? Go here > http://iserv.nl/files/xfs/ > > Have a nice day, > -- > Seth > It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jan 20 00:31:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 00:31:55 -0800 (PST) Received: from ZRHNOG20.converium.com (mail1.converium.com [213.173.163.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0K8Vp3v011648 for ; Mon, 20 Jan 2003 00:31:52 -0800 Subject: Re: recommended compiler? To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: "Lucien Meyers" Date: Mon, 20 Jan 2003 09:22:25 +0100 X-MIMETrack: Serialize by Router on ZRHNOG20/Converium-Internet(Release 5.0.10 |March 22, 2002) at 20.01.2003 09:38:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 2385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lucien.meyers@converium.com Precedence: bulk X-list: linux-xfs Content-Length: 357 Lines: 13 Hi! Compiled a new non-modules kernel 2.4.19-smp including xfs Debian package using gcc-3.2 without any hiccups. And it boots, subjectively seems a bit faster, but that might be (partially) due to 2.4.19 replacing 2.4.18. Still don't know if boot from an xfs / partition will work, however, because I haven't yet found the time to reformat etc. Lucien From owner-linux-xfs@oss.sgi.com Mon Jan 20 00:44:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 00:44:09 -0800 (PST) Received: from GANS ([217.89.68.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0K8i53v012136 for ; Mon, 20 Jan 2003 00:44:06 -0800 Message-Id: <200301200844.h0K8i53v012136@oss.sgi.com> From: To: Subject: Re: Document Date: Mon, 20 Jan 2003 10:15:38 +0100 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0033F5F0" X-archive-position: 2386 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: big@boss.com Precedence: bulk X-list: linux-xfs Content-Length: 213 Lines: 10 This is a multipart message in MIME format --CSmtpMsgPart123X456_000_0033F5F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached file: --CSmtpMsgPart123X456_000_0033F5F0-- From owner-linux-xfs@oss.sgi.com Mon Jan 20 01:29:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 01:29:21 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0K9TH3v013164 for ; Mon, 20 Jan 2003 01:29:18 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0K9ZmTG001801; Mon, 20 Jan 2003 10:35:48 +0100 (CET) Message-Id: <4.3.2.7.2.20030120103529.042f3d50@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Jan 2003 10:35:36 +0100 To: "LA Walsh" , From: Seth Mos Subject: Re: xfs vs. jfs results: why? In-Reply-To: <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 662 Lines: 23 At 19:20 19-1-2003 -0800, LA Walsh wrote: >CONCLUSION: >We are not able to reproduce the excellent numbers described at: >http://home.fnal.gov/~yocum/storageServerTechnicalNote.html >It appears that the best performance for read-orientated and mixed >workloads is obtained with JFS, for write-orientated XFS. >--- > From page: http://pcbunn.cacr.caltech.edu/gae/3ware_raid_tests.htm Since you are using 2.4.19. Did you compile this kernel with HIGMEM and HIGHMEM IO? There have been some performance problems in 2.4.19 if you did not have HIGHMEM IO turned on. Can you check this please? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jan 20 01:33:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 01:33:21 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0K9XH3v013630 for ; Mon, 20 Jan 2003 01:33:18 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0K9dmTG004497; Mon, 20 Jan 2003 10:39:48 +0100 (CET) Message-Id: <4.3.2.7.2.20030120103543.04306668@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Jan 2003 10:39:34 +0100 To: Simon Matter From: Seth Mos Subject: Re: Patched 1.2Pre5 kernel Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E2BAD84.89D62FEC@ch.sauter-bc.com> References: <4.3.2.7.2.20030117185540.035e08e8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1114 Lines: 35 At 09:04 20-1-2003 +0100, Simon Matter wrote: >Seth Mos schrieb: > > The i686 build fails at the moment but so you will have to do with the > > kernel-source rpm instead. The i686 build will follow later. > >Well, I had the same problem when I created such kernel rpms in the past >(on RedHat 7.2). I finally was able to compile all of them like this: > >In the .spec, I changed this: >%define buildUML 0 I already disabled the UML build. It fails with an internal compiler error on my fast 7.1 box. I am now compiling on my testbox which is a single PIII 450 with 256MB ram. So yes it it still compiling here and I suspect for a few more hours. >Then, it's important to call the build processs for every architecture >at once, like this: >rpm -ba --target "i386,i586,i686,athlon" kernel....src.rpm >or, maybe it was rpm -ba --target=i386,i586,i686,athlon >depending on RPM version. Hmm, I built the i386 only on my first go. That was enough to get me the kernel-source rpm. >I'll try it but I don't have a fast box to compile. Okidoki Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jan 20 01:56:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 01:56:21 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0K9uF3v014329 for ; Mon, 20 Jan 2003 01:56:16 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0KA2k5u069739; Mon, 20 Jan 2003 11:02:46 +0100 (CET) Message-Id: <4.3.2.7.2.20030120110145.04095890@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Jan 2003 11:02:41 +0100 To: Jens Axboe , LA Walsh , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfs vs. jfs results: why? In-Reply-To: <20030120094121.GB22177@suse.de> References: <4.3.2.7.2.20030120103529.042f3d50@pop.xs4all.nl> <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> <4.3.2.7.2.20030120103529.042f3d50@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 318 Lines: 16 At 10:41 20-1-2003 +0100, Jens Axboe wrote: >2.4.19 did not have the block highmem feature, so that's not correct. >2.4.20, as released, does not have the bug either. It was in the -pre >series. My bad. in-memory corruption at coffee.c line 268. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jan 20 02:00:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 02:00:58 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0KA0t3v014782 for ; Mon, 20 Jan 2003 02:00:56 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id F30F214A15; Mon, 20 Jan 2003 11:07:21 +0100 (MET) Date: Mon, 20 Jan 2003 11:07:17 +0100 From: Andi Kleen To: Seth Mos , LA Walsh , linux-xfs@oss.sgi.com Subject: Re: xfs vs. jfs results: why? Message-ID: <20030120100717.GA32608@wotan.suse.de> References: <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> <4.3.2.7.2.20030120103529.042f3d50@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030120103529.042f3d50@pop.xs4all.nl> User-Agent: Mutt/1.4i X-archive-position: 2390 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1237 Lines: 33 On Mon, Jan 20, 2003 at 10:35:36AM +0100, Seth Mos wrote: > At 19:20 19-1-2003 -0800, LA Walsh wrote: > >CONCLUSION: > >We are not able to reproduce the excellent numbers described at: > >http://home.fnal.gov/~yocum/storageServerTechnicalNote.html > >It appears that the best performance for read-orientated and mixed > >workloads is obtained with JFS, for write-orientated XFS. > >--- > >From page: http://pcbunn.cacr.caltech.edu/gae/3ware_raid_tests.htm > > Since you are using 2.4.19. Did you compile this kernel with HIGMEM and > HIGHMEM IO? > > There have been some performance problems in 2.4.19 if you did not have > HIGHMEM IO turned on. > > Can you check this please? If it was an highio bouncing problem then all tested file systems because they always used the same drivers. Wild theory: Older 2.4 XFS (1.1) used a different read path that was more oriented towards efficient use of extents and big IO. Later in 1.2 this was rewritten to use the generic_file_read function in linux, which allocates much more buffer_heads and is likely a bit more CPU intensive. They may be hit by that. Linux 2.5 has a new block device layer which should support big IO requests and extents as XFS does them much better. -Andi From owner-linux-xfs@oss.sgi.com Mon Jan 20 02:08:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 02:08:48 -0800 (PST) Received: from virtualhost.dk (mail@ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0KA8j3v015302 for ; Mon, 20 Jan 2003 02:08:46 -0800 Received: from brick.kernel.dk ([80.160.188.86] helo=burns.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.35 #1) id 18aYQv-0004om-00; Mon, 20 Jan 2003 10:41:33 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 4.10) id 18aYQj-0005wt-00; Mon, 20 Jan 2003 10:41:21 +0100 Date: Mon, 20 Jan 2003 10:41:21 +0100 From: Jens Axboe To: Seth Mos , LA Walsh , linux-xfs@oss.sgi.com Subject: Re: xfs vs. jfs results: why? Message-ID: <20030120094121.GB22177@suse.de> References: <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> <4.3.2.7.2.20030120103529.042f3d50@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030120103529.042f3d50@pop.xs4all.nl> X-archive-position: 2391 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 795 Lines: 23 On Mon, Jan 20 2003, Seth Mos wrote: > At 19:20 19-1-2003 -0800, LA Walsh wrote: > >CONCLUSION: > >We are not able to reproduce the excellent numbers described at: > >http://home.fnal.gov/~yocum/storageServerTechnicalNote.html > >It appears that the best performance for read-orientated and mixed > >workloads is obtained with JFS, for write-orientated XFS. > >--- > >From page: http://pcbunn.cacr.caltech.edu/gae/3ware_raid_tests.htm > > Since you are using 2.4.19. Did you compile this kernel with HIGMEM and > HIGHMEM IO? > > There have been some performance problems in 2.4.19 if you did not have > HIGHMEM IO turned on. 2.4.19 did not have the block highmem feature, so that's not correct. 2.4.20, as released, does not have the bug either. It was in the -pre series. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Mon Jan 20 04:57:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 04:57:50 -0800 (PST) Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0KCvZ3v027220 for ; Mon, 20 Jan 2003 04:57:40 -0800 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id h0KD45d19923 for linux-xfs@oss.sgi.com.KAV; Mon, 20 Jan 2003 14:04:05 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id h0KD42419875; Mon, 20 Jan 2003 14:04:03 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h0KD3TWe004370; Mon, 20 Jan 2003 14:03:30 +0100 Subject: Re: recommended compiler? From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Seung-yeong Oh Cc: linux-xfs@oss.sgi.com In-Reply-To: <1043001736.1855.18.camel@wideangle.nameip.net> References: <1043001736.1855.18.camel@wideangle.nameip.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Jan 2003 14:03:29 +0100 Message-Id: <1043067811.4281.9.camel@venus> Mime-Version: 1.0 X-archive-position: 2392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 415 Lines: 18 On Sun, 2003-01-19 at 19:42, Seung-yeong Oh wrote: > Hello, > I'm still trying to figure out what the source of my problem is; > I have compiled with gcc 3.2 (from RH8.0). XFS was from CVS about 2 weeks ago. As far (2 weeks) it runs without any problems. I also use it on root partition. I don't use it for NFS at now, but will use later (not for big traffic - just to boot remote Xterminals). Regards, Olaf From owner-linux-xfs@oss.sgi.com Mon Jan 20 07:07:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 07:07:29 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0KF7O3v029566 for ; Mon, 20 Jan 2003 07:07:24 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0KEKAKp003110 for ; Mon, 20 Jan 2003 06:20:10 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA31104; Mon, 20 Jan 2003 09:13:50 -0600 (CST) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-97.corp.sgi.com [134.15.64.97]) by tulip-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA87494; Mon, 20 Jan 2003 09:13:49 -0600 (CST) Subject: Re: xfs vs. jfs results: why? From: Stephen Lord To: LA Walsh Cc: linux-xfs@oss.sgi.com In-Reply-To: <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> References: <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 20 Jan 2003 09:13:43 -0600 Message-Id: <1043075625.1777.29.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 2393 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2882 Lines: 68 On Sun, 2003-01-19 at 21:20, LA Walsh wrote: > CONCLUSION: > We are not able to reproduce the excellent numbers described at: > http://home.fnal.gov/~yocum/storageServerTechnicalNote.html > It appears that the best performance for read-orientated and mixed > workloads is obtained with JFS, for write-orientated XFS. > --- > >From page: http://pcbunn.cacr.caltech.edu/gae/3ware_raid_tests.htm > > Basic thrust was JFS anywhere from 12-28% faster on reads, XFS > up to 33% faster on writes. > > Writes are good, but the aren't what I do the most of (though wasn't > xfs designed with tuning for dmedia recording in real-time as a > priority?). XFS seemed to, _very_ slightly outperform reads on Reiser > though Reiser's worse times were sometimes better than our worst. > Reiser performed about 20% better than XFS for writes when 3ware native RAID5 was enabled. > > So XFS not clearly an across the board champ in reads or writes though > overall, as article claims, XFS as 2nd. > > So...wazzup? Isn't JFS newer? Hasn't XFS been around longer and had > benefit of years of tuning? Is it just the linux integration that > has slowed things down? Maybe I've just read too many of our own > marketing docs, but I thought XFS was close to stellar among FS's...? > > Is this testing bogus? A fluke? Or should I start getting a grip > with reality and becoming disillusioned (illusions of marketing tripe > instilled in head being laid to rest...?) > > BTW -- hope this goes through, ok...my email has been weird since > around midnight this morning. Getting some spatterings of outside > email, but no list email from any of my list subscriptions. Very > weird since they are from disparate list servers. Other connectivity > seems unchanged... > > If you respond to this, please 'cc' me too so I can hopefully get a > copy...I'm not sure what would be blocking listmails... > > tnx, > -l > One thing the paper did not talk about at all was any parameters used in the build configuration or the mkfs/mount options used. The correct mkfs options on xfs can make extents line up on stripe boundaries which helps I/O. It also does not state the size of the test files in relationship to memory size - which makes the difference between reading/writing from cache and actually using the disks. Since they talk about being almost cpu bound this would seem to indicate that anything in the code which could be turned off should be turned off to improve performance. In the case of xfs there are three things which will influence the performance, posix acls, quotas and dmapi. Turning each of these off reduces the code path. I am also not sure which code base was used for XFS, they say redhat 2.4.19 - which does not include XFS. So all in all, my conclusion is there is too little information here to deduce what might be possible with the hardware. Steve From owner-linux-xfs@oss.sgi.com Mon Jan 20 07:18:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 07:18:14 -0800 (PST) Received: from CPE014280010574.cpe.net.cable.rogers.com (CPE0080c6e90c22-CM014280010574.cpe.net.cable.rogers.com [24.43.161.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0KFIA3v030057 for ; Mon, 20 Jan 2003 07:18:11 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by CPE014280010574.cpe.net.cable.rogers.com (8.11.6/8.11.6) with ESMTP id h0KFOR930447; Mon, 20 Jan 2003 10:24:28 -0500 Subject: Re: Patched 1.2Pre5 kernel From: Jeremy Jackson To: Seth Mos Cc: Simon Matter , linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20030120103543.04306668@pop.xs4all.nl> References: <4.3.2.7.2.20030117185540.035e08e8@pop.xs4all.nl> <4.3.2.7.2.20030120103543.04306668@pop.xs4all.nl> Content-Type: text/plain Organization: Message-Id: <1043076274.3286.1.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 20 Jan 2003 10:24:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2394 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 1419 Lines: 42 On Mon, 2003-01-20 at 04:39, Seth Mos wrote: > At 09:04 20-1-2003 +0100, Simon Matter wrote: > >Seth Mos schrieb: > > > The i686 build fails at the moment but so you will have to do with the > > > kernel-source rpm instead. The i686 build will follow later. > > > >Well, I had the same problem when I created such kernel rpms in the past > >(on RedHat 7.2). I finally was able to compile all of them like this: > > > >In the .spec, I changed this: > >%define buildUML 0 > > I already disabled the UML build. It fails with an internal compiler error > on my fast 7.1 box. I am now compiling on my testbox which is a single PIII > 450 with 256MB ram. So yes it it still compiling here and I suspect for a > few more hours. > Any time I've had "internal compiler error", it's been a hardware problem. ie bad heatsing or memory. I suggest running memtest86.com's test utility. > >Then, it's important to call the build processs for every architecture > >at once, like this: > >rpm -ba --target "i386,i586,i686,athlon" kernel....src.rpm > >or, maybe it was rpm -ba --target=i386,i586,i686,athlon > >depending on RPM version. > > Hmm, I built the i386 only on my first go. That was enough to get me the > kernel-source rpm. > > >I'll try it but I don't have a fast box to compile. > > Okidoki > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. -- Jeremy Jackson From owner-linux-xfs@oss.sgi.com Mon Jan 20 08:05:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 08:05:38 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0KG5Y3v030890 for ; Mon, 20 Jan 2003 08:05:35 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0KGBoR2040946; Mon, 20 Jan 2003 17:11:52 +0100 (CET) Message-Id: <4.3.2.7.2.20030120163751.0356b140@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Jan 2003 17:11:46 +0100 To: Jeremy Jackson From: Seth Mos Subject: Re: Patched 1.2Pre5 kernel Cc: Simon Matter , linux-xfs@oss.sgi.com In-Reply-To: <1043076274.3286.1.camel@contact.skynet.coplanar.net> References: <4.3.2.7.2.20030120103543.04306668@pop.xs4all.nl> <4.3.2.7.2.20030117185540.035e08e8@pop.xs4all.nl> <4.3.2.7.2.20030120103543.04306668@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2395 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 574 Lines: 19 At 10:24 20-1-2003 -0500, Jeremy Jackson wrote: > > >Any time I've had "internal compiler error", it's been a hardware >problem. ie bad heatsing or memory. I suggest running memtest86.com's >test utility. That's not the case here. In fact the error is that the kdb symbols are not ending up in the right place when it is linking as far I can tell. The internal compiler error is from the UML build by the way. And it's reproducable on 2 machines. Both have ecc memory and are well cooled machines. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jan 20 09:26:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 09:26:06 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0KHQ23v031953 for ; Mon, 20 Jan 2003 09:26:03 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h0KHWQlx031499 for ; Mon, 20 Jan 2003 09:32:26 -0800 From: "LA Walsh" To: Subject: RE: xfs vs. jfs results: why? Date: Mon, 20 Jan 2003 09:32:26 -0800 Message-ID: <000b01c2c0a9$e69dea30$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1043075625.1777.29.camel@localhost.localdomain> X-archive-position: 2396 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 3744 Lines: 81 > One thing the paper did not talk about at all was any > parameters used in the build configuration or the mkfs/mount > options used. --- Good point. > > The correct mkfs options on xfs can make extents line up on > stripe boundaries which helps I/O. --- Yeah...just reading the mkfs.xfs manpage might help on that, though if there are optimization issues not touched on there, I wouldn't have expected them to do anything other than the 'default'. Too bad mkfs doesn't or can't determine disk partition params like a 'stripe size' to use in optimally setting default params when formatting (or is mkfs smarter than I realize? That'd be way cool!). > It also does not state the size of the test files in > relationship to memory size - which makes the difference > between reading/writing from cache and actually using the disks. --- Hmmm...yeah...though I'd +hope+ to try something on the order of copying a single multi-gig file, existing, alone, on a freshly formatted RAID partition. There could also be variables in the per-disk cache and RAID-card cache that'd I'd also hope would be negligible on a all-out speed test (though accounting for those or best ways to optimize for various disk-cache and RAID cache size at 'mkfs.xfs' time would be even more arcana though even I would figure that setting stripe size such that no 'write' exceeded an individual disk's write cache size should have a positive effect on throughput). > > Since they talk about being almost cpu bound this would seem > to indicate that anything in the code which could be turned > off should be turned off to improve performance. In the case > of xfs there are three things which will influence the > performance, posix acls, quotas and dmapi. Turning each of > these off reduces the code path. I am also not sure which > code base was used for XFS, they say redhat 2.4.19 - which > does not include XFS. --- WAG, but I'd think they'd have gone with defaults or minimums -- if they wanted maximum throughput, I'd hope they'd turn off any superfluous disk options. Given that they did more tests with xfs, I'd almost guess they had a partiality to xfs and wanted to maximize throughput on any of the filesystems used, since the primary purpose of the testing wasn't to test the disks but to get maximum throughput to test a 10-Gigabit network connection from Sunnyvale to Chicago. I could see them not doing a "super thorough" job on disk param setup since disks were secondary to their prime objective. I would have tried something, using a block partition, raw partition or a xfs-real-time section. RH not including xfs with their 2419 kernel? Dang! Even SuSE is on their second xfs included release (first in their 8.0, which contained 2418, I believe). (Parenthetically speaking: any ideas on when we might see xfs in a vanilla stable series or is that still in the "nobody's looked at that yet", phase?) > So all in all, my conclusion is there is too little > information here to deduce what might be possible with the hardware. --- Yeah...though I haven't run into any definitive tests, so far, in my semi-random, non-thorough, net readings. BTW -- my list email is indeed screwed. Got all the 'cc's, but none of the message copies sent to the list. Very peculiar -- since I'm seeing _no_ emails from outside my domain that don't me in the "To" line. Seems to not be making it to my ISP...my logs indicate the emails never make it into their 'in queue(s)' for my address. Very weird. Also annoying is that I don't see bounce messages (if any). Thanks for everyone's detailed deconstruction of the benchmark's shortcomings. I should try to see if that person has tried anything newer since that test... Linda From owner-linux-xfs@oss.sgi.com Mon Jan 20 17:36:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 17:36:52 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0L1af3v009059 for ; Mon, 20 Jan 2003 17:36:43 -0800 Received: (qmail 29684 invoked from network); 20 Jan 2003 21:14:09 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 20 Jan 2003 21:14:09 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id CC6DE300087; Tue, 21 Jan 2003 08:13:59 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id A535385; Tue, 21 Jan 2003 08:13:59 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Patched 1.2Pre5 kernel In-reply-to: Your message of "Mon, 20 Jan 2003 17:11:46 BST." <4.3.2.7.2.20030120163751.0356b140@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Jan 2003 08:13:54 +1100 Message-ID: <3929.1043097234@ocs3.intra.ocs.com.au> X-archive-position: 2397 X-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: 496 Lines: 13 On Mon, 20 Jan 2003 17:11:46 +0100, Seth Mos wrote: >At 10:24 20-1-2003 -0500, Jeremy Jackson wrote: >> > >>Any time I've had "internal compiler error", it's been a hardware >>problem. ie bad heatsing or memory. I suggest running memtest86.com's >>test utility. > >That's not the case here. In fact the error is that the kdb symbols are not >ending up in the right place when it is linking as far I can tell. Details please, my telepathy is not working this morning ... From owner-linux-xfs@oss.sgi.com Mon Jan 20 22:52:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 22:52:07 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0L6px3v012368 for ; Mon, 20 Jan 2003 22:52:00 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.55.176]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0L64nKp032254 for ; Mon, 20 Jan 2003 22:04:50 -0800 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id RAA13932 for linux-xfs@oss.sgi.com; Tue, 21 Jan 2003 17:57:28 +1100 Date: Tue, 21 Jan 2003 17:57:28 +1100 From: FSG QA Message-Id: <200301210657.RAA13932@bruce.melbourne.sgi.com> Subject: TAKE - acl.5 X-archive-position: 2398 X-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: 412 Lines: 16 incorporate some acl.5 changes from AG for the ACL access check algorithm --Tim Date: Mon Jan 20 22:56:35 PST 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:137354a cmd/acl/man/man5/acl.5 - 1.17 - incorporate some changes from AG for the ACL access check algorithm description From owner-linux-xfs@oss.sgi.com Mon Jan 20 23:26:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 23:27:01 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0L7Qs3v013519 for ; Mon, 20 Jan 2003 23:26:55 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0L7XT5o003577; Tue, 21 Jan 2003 08:33:29 +0100 (CET) Message-Id: <4.3.2.7.2.20030121083122.032eebf8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Jan 2003 08:33:26 +0100 To: Keith Owens From: Seth Mos Subject: Re: Patched 1.2Pre5 kernel Cc: linux-xfs@oss.sgi.com In-Reply-To: <3929.1043097234@ocs3.intra.ocs.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2399 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 2409 Lines: 58 At 08:13 21-1-2003 +1100, Keith Owens wrote: >On Mon, 20 Jan 2003 17:11:46 +0100, >Seth Mos wrote: > >At 10:24 20-1-2003 -0500, Jeremy Jackson wrote: > >> > > >>Any time I've had "internal compiler error", it's been a hardware > >>problem. ie bad heatsing or memory. I suggest running memtest86.com's > >>test utility. > > > >That's not the case here. In fact the error is that the kdb symbols are not > >ending up in the right place when it is linking as far I can tell. > >Details please, my telepathy is not working this morning ... kallsyms pass 1 init/main.o: In function `parse_options': init/main.o(.text.init+0x5e6): undefined reference to `kdb_on' init/main.o(.text.init+0x5eb): undefined reference to `kdb_flags' init/main.o(.text.init+0x622): undefined reference to `kdb_on' init/main.o(.text.init+0x64f): undefined reference to `kdb_on' init/main.o(.text.init+0x674): undefined reference to `kdb_flags' init/main.o(.text.init+0x67f): undefined reference to `kdb_on' init/main.o(.text.init+0x687): undefined reference to `kdb_flags' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2aba): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2ac4): undefined reference to `kdb_symbol_print' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2ad1): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2ae9): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2af3): undefined reference to `kdb_symbol_print' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2afd): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2b07): undefined reference to `kdb_symbol_print' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2b14): undefined reference to `kdb_printf' /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o: In function `fetch_data': /usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2b79): undefined reference to `kdb_printf' make[1]: *** [kallsyms] Fout 1 make: *** [vmlinux] Fout 2 error: Bad exit status from /var/tmp/rpm-tmp.14321 (%build) Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jan 20 23:39:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 23:39:30 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0L7dR3v014122 for ; Mon, 20 Jan 2003 23:39:27 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h0L5k6G8002145 for ; Mon, 20 Jan 2003 21:46:07 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA10963; Tue, 21 Jan 2003 18:44:41 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 21BA0300087; Tue, 21 Jan 2003 18:44:40 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 8FE1585; Tue, 21 Jan 2003 18:44:40 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Patched 1.2Pre5 kernel In-reply-to: Your message of "Tue, 21 Jan 2003 08:33:26 BST." <4.3.2.7.2.20030121083122.032eebf8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Jan 2003 18:44:34 +1100 Message-ID: <11036.1043135074@kao2.melbourne.sgi.com> X-archive-position: 2400 X-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: 650 Lines: 14 On Tue, 21 Jan 2003 08:33:26 +0100, Seth Mos wrote: >kallsyms pass 1 >init/main.o: In function `parse_options': >init/main.o(.text.init+0x5e6): undefined reference to `kdb_on' >init/main.o(.text.init+0x5eb): undefined reference to `kdb_flags' >/usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2aba): >undefined reference to `kdb_printf' You did not build kdb/kdbmain.o, kdb/kdb_io.o etc. or you did not link them in or you have a mixture of code with CONFIG_KDB=y and CONFIG_KDB=n. That can occur if you do not run make dep after applying a patch that contains config options, kbuild 2.4 gets confused. From owner-linux-xfs@oss.sgi.com Mon Jan 20 23:59:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Jan 2003 23:59:29 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0L7xO3v014759 for ; Mon, 20 Jan 2003 23:59:25 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0L85xB7079515; Tue, 21 Jan 2003 09:05:59 +0100 (CET) Message-Id: <4.3.2.7.2.20030121090228.0419a250@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Jan 2003 09:05:46 +0100 To: Keith Owens From: Seth Mos Subject: Re: Patched 1.2Pre5 kernel Cc: linux-xfs@oss.sgi.com In-Reply-To: <11036.1043135074@kao2.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 888 Lines: 24 At 18:44 21-1-2003 +1100, Keith Owens wrote: >On Tue, 21 Jan 2003 08:33:26 +0100, >Seth Mos wrote: > >kallsyms pass 1 > >init/main.o: In function `parse_options': > >init/main.o(.text.init+0x5e6): undefined reference to `kdb_on' > >init/main.o(.text.init+0x5eb): undefined reference to `kdb_flags' > >/usr/src/redhat/BUILD/kernel-2.4.18/linux/arch/i386/kdb/kdba.o(.text+0x2a > ba): > >undefined reference to `kdb_printf' > >You did not build kdb/kdbmain.o, kdb/kdb_io.o etc. or you did not link >them in or you have a mixture of code with CONFIG_KDB=y and >CONFIG_KDB=n. That can occur if you do not run make dep after applying >a patch that contains config options, kbuild 2.4 gets confused. Ah, I'm building this kernel with rpmbuild so it might have to do with some of the target options. Thank you. -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Jan 21 03:49:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Jan 2003 03:49:05 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0LBn23v022352 for ; Tue, 21 Jan 2003 03:49:02 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZBLC961A; Tue, 21 Jan 2003 06:55:51 -0500 Received: from wgate.com (sinz.eng.tvol.net [127.0.0.1]) by sinz.eng.tvol.net (8.12.5/8.12.5) with ESMTP id h0LBsSPd019988; Tue, 21 Jan 2003 06:54:28 -0500 Message-ID: <3E2D34F4.9000108@wgate.com> Date: Tue, 21 Jan 2003 06:54:28 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seth Mos CC: Seung-yeong Oh , linux-xfs@oss.sgi.com Subject: Re: recommended compiler? References: <4.3.2.7.2.20030119213050.0418e958@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20030119213050.0418e958@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 1376 Lines: 35 Seth Mos wrote: > At 03:42 20-1-2003 +0900, Seung-yeong Oh wrote: > >> Hello, >> I'm still trying to figure out what the source of my problem is; >> >> http://oss.sgi.com/projects/xfs/mail_archive/200301/msg00194.html >> >> Anyway, what is the recommended compiler for XFS 1.2? Up to 1.1, I've >> read that SGI developer team recommends kgcc in the Makefile, I don't >> see that sort of NOTE in the Makefile in kernel >> 2.4.18-18SGI_XFS_1.2pre5. > > > I build my kernels with gcc-2.96 these days which seem to do fine. The > kgcc was mainly needed in the pre 11 releases. > > A lot of people use the (updated!) 2.96 which seems to work fairly well. For the past few months, I have been building systems with the latest XFS from CVS using GCC 3.2... I have yet to run into a problem that was due to the compiler. The systems are all over the map, from dual Xeon servers with lots of disk to PIII-M laptops to Athelon workstations to even a 486 "honey pot" machine. All are running XFS as their only filesystem (modulo ISO-9660 and NFS) and some have been very heavily used. I just wish we had our big cluster running this stuff yet. However, our product plans had to slow down due to resources... -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Tue Jan 21 04:00:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Jan 2003 04:00:43 -0800 (PST) Received: from ZRHNOG20.converium.com (mail1.converium.com [213.173.163.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0LC0e3v022881 for ; Tue, 21 Jan 2003 04:00:40 -0800 Subject: Re: xfs fails as / with Debian GNU/Linux 2.4.18-smp - 2nd post To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: "Lucien Meyers" Date: Tue, 21 Jan 2003 12:50:41 +0100 X-MIMETrack: Serialize by Router on ZRHNOG20/Converium-Internet(Release 5.0.10 |March 22, 2002) at 21.01.2003 13:07:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 2403 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lucien.meyers@converium.com Precedence: bulk X-list: linux-xfs Content-Length: 158 Lines: 9 Hi! Have tested Debian 2.4.19-smp with the most recent Debian xfs package. Still exactly the same boot error as previously reported here. No go. Lucien From owner-linux-xfs@oss.sgi.com Tue Jan 21 05:33:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Jan 2003 05:33:21 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0LDXB3v026620 for ; Tue, 21 Jan 2003 05:33:13 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0LDdmbh018919 for ; Tue, 21 Jan 2003 14:39:48 +0100 (CET) Message-Id: <4.3.2.7.2.20030121143729.040b10d0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Jan 2003 14:39:39 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Patched 1.2Pre5 kernel In-Reply-To: <4.3.2.7.2.20030121090228.0419a250@pop.xs4all.nl> References: <11036.1043135074@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2404 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 424 Lines: 20 At 09:05 21-1-2003 +0100, Seth Mos wrote: >Ah, I'm building this kernel with rpmbuild so it might have to do with >some of the target options. Not building the debug kernels works. I just uploaded the i686 kernels to my server. http://iserv.nl/files/xfs/ My test box survived the weekend without hickups or problems so I consider them good enough. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Jan 21 10:25:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Jan 2003 10:26:05 -0800 (PST) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0LIPu3v012752 for ; Tue, 21 Jan 2003 10:25:56 -0800 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 13:32:28 -0500 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC0920FA@THOR.goeci.com> From: Murthy Kambhampaty To: linux-xfs@oss.sgi.com Subject: External log mtce Date: Tue, 21 Jan 2003 13:32:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 2405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 1754 Lines: 44 I wanted to verify the steps required for moving an external log device for an xfs filesystem. In my case, I want to move the logdev from an LV on an md1 to an LV on an md0 on two md1s, with chunk-size of 512k for the md0; the log device got sunit=2 blocks (8K) from the mkfs.xfs options for the filesystem. Step 1. # log device backup umount /mnt/fs_xfs1; dd if=/dev/vg_XFSLOGS/lv_XFSLOG_fs1 of=/mnt/backup/xfslog_fs1 bs=512 Step 2. # log device restore #(This is just an example that involves restoring the log device to a different logical volume than previous. It could also be a newly create LV of the same name as before, but the PV might have changed) dd if=/mnt/backup/xfslog_fs1 of=/dev/vg_NEW_XFSLOGS/lv_NEW_XFSLOG_fs1 bs=512 # ( I suppose one could reduce Steps 1 and 2 to # umount /mnt/xfs_fs1; dd if=/dev/vg_XFSLOGS/lv_XFSLOG_fs1 of=/dev/vg_NEW_XFSLOGS/lv_NEW_XFSLOG_fs1 bs=512 # ) Step 3. # (re) mount filesystem using restored log device mount -t xfs -o logdev=/dev/vg_NEW_XFSLOGS/lv_NEW_XFSLOG_fs1 /dev/vg_XFSDATA/lv_XFS_fs1 /mnt/xfs_fs1 Is this correct? Is an intermediate step required for the "new" log device? Also, is "xfs_growfs -l -L /mnt/xfs_fs1" likely to be implemented anytime soon (without the -i and -x options)? This would, for example, permit moving to a larger external log device as the filesystem size grew. Thanks, Murthy PS: In a recent discussion, Mihail RUSU made the suggestion to archive the log device, for disaster recovery (http://marc.theaimsgroup.com/?l=linux-xfs&m=104186705903040&w=2). Err, won't the data part have the changes in the logdev pretty quickly, making the logdev backup "obsolete" or at least "inconsistent", so that the only real option is to mirror the log device? From owner-linux-xfs@oss.sgi.com Tue Jan 21 12:51:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Jan 2003 12:52:00 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0LKpo3v019022 for ; Tue, 21 Jan 2003 12:51:51 -0800 Received: from attbi.com (12-253-73-46.client.attbi.com[12.253.73.46]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2003011901271000200mkksae>; Sun, 19 Jan 2003 01:27:10 +0000 Message-ID: <3E29FF4F.2000809@attbi.com> Date: Sat, 18 Jan 2003 18:28:47 -0700 From: "D. Stimits" Reply-To: stimits@attbi.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: CPU overhead when handling large files? References: <1042910194.2187.15.camel@wideangle.nameip.net> In-Reply-To: <1042910194.2187.15.camel@wideangle.nameip.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2406 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stimits@attbi.com Precedence: bulk X-list: linux-xfs Content-Length: 944 Lines: 22 Seung-yeong Oh wrote: > Hello, > Originally, I installed RedHat7.2 + SGI XFS 1.0.2. > I now have fully updated RedHat7.2 + SGI XFS 1.2pre5 (rebuilt kernel RPM > to be installed on RedHat 7.x). > For current seup, I'm wondering if the following behavior is normal; > When handling large files, for example, copying a few 700MB files from > one directory to another, at some point in the middle of the process or > at the end of it, the process hangs for several minutes taking up 99% of > CPU. > A friend of mine told me it might take some time to rewrite inodes as > it's a journaling file system, but I don't remember the XFS acted this > way before when I was using 1.0.2 of it. And 1.1 for that matter... > I'd appreciate any input. Thank you. > Have a nice weekend. > FYI, if you use IDE drives, and do not have UDMA on, it will always use tons of cpu power to do copies, no matter what filesystem. D. Stimits, stimits AT attbi DOT com From owner-linux-xfs@oss.sgi.com Tue Jan 21 13:41:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Jan 2003 13:41:44 -0800 (PST) Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0LLfc3v019751 for ; Tue, 21 Jan 2003 13:41:38 -0800 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E4C732FB3B for ; Tue, 21 Jan 2003 13:48:16 -0800 (PST) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 46BCC2FB3B for ; Tue, 21 Jan 2003 13:48:13 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id EE0131967B for ; Tue, 21 Jan 2003 13:48:02 -0800 (PST) Subject: Re: xfs vs. jfs results: why? From: Florin Andrei To: linux-xfs In-Reply-To: <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> References: <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 21 Jan 2003 13:48:02 -0800 Message-Id: <1043185682.26351.30.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 2407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 931 Lines: 23 On Sun, 2003-01-19 at 19:20, LA Walsh wrote: > http://home.fnal.gov/~yocum/storageServerTechnicalNote.html > Basic thrust was JFS anywhere from 12-28% faster on reads, XFS > up to 33% faster on writes. > Writes are good, but the aren't what I do the most of (though wasn't > xfs designed with tuning for dmedia recording in real-time as a > priority?). As someone who's dealing with heavy-duty multimedia apps on Linux on an almost daily basis, i can tell you i don't quite care about read performance (well, i do, but you know what i mean), while i do care a lot about write performance. Ok, so it also depends on what you're doing. Perhaps other people need a lot of read speed for their apps. But, as a rule of thumb: reading is easy, writing is difficult. -- Florin Andrei "I'm only arguing against stupid people who think they need a revolution to improve - most real improvements are evolutionary." - Linus Torvalds From owner-linux-xfs@oss.sgi.com Wed Jan 22 01:41:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jan 2003 01:41:41 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0M9fV3v025824 for ; Wed, 22 Jan 2003 01:41:33 -0800 Received: (qmail 29294 invoked by uid 1000); 22 Jan 2003 10:08:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Jan 2003 10:08:05 -0000 Date: Wed, 22 Jan 2003 12:08:05 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Murthy Kambhampaty cc: Subject: Re: External log mtce In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC0920FA@THOR.goeci.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 1128 Lines: 28 Hi On Tue, 21 Jan 2003, Murthy Kambhampaty wrote: > PS: In a recent discussion, Mihail RUSU made the suggestion to archive the > log device, for disaster recovery > (http://marc.theaimsgroup.com/?l=linux-xfs&m=104186705903040&w=2). Err, > won't the data part have the changes in the logdev pretty quickly, making > the logdev backup "obsolete" or at least "inconsistent", so that the only > real option is to mirror the log device? I ment to say to backup the external log only after a clean unmount. So the external log in that case is "empty". The only use is when you loose your log device thus you can xfs_repair -L with logdev on the backed up log (so we ignore the log contents anyway, if the system crashed when you lost your logdevice then you will posibly loose some data there). I tested this and it worked for me (I tested moving the logdevice on different partitions/disks). ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Wed Jan 22 01:46:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jan 2003 01:46:32 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0M9kT3v026311 for ; Wed, 22 Jan 2003 01:46:30 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0M9r7n7010749; Wed, 22 Jan 2003 10:53:08 +0100 (CET) Message-Id: <4.3.2.7.2.20030122105112.03093088@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Jan 2003 10:52:49 +0100 To: Florin Andrei , linux-xfs From: Seth Mos Subject: Re: xfs vs. jfs results: why? In-Reply-To: <1043185682.26351.30.camel@stantz.corp.sgi.com> References: <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> <000001c2c032$e4edc240$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 496 Lines: 18 At 13:48 21-1-2003 -0800, Florin Andrei wrote: >Ok, so it also depends on what you're doing. Perhaps other people need a >lot of read speed for their apps. But, as a rule of thumb: reading is >easy, writing is difficult. On another note, reading you can cache with large amounts of ram. Writing you can not. Writing multiple times makes disk IO everytime. Reading multiple times makes disk IO once (if you have enough ram) Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jan 22 06:47:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jan 2003 06:48:05 -0800 (PST) Received: from imf06bis.bellsouth.net (mail006.mail.bellsouth.net [205.152.58.26]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0MElt3v013969 for ; Wed, 22 Jan 2003 06:47:58 -0800 Received: from marsha ([66.156.0.41]) by imf06bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030122145628.QHIB765.imf06bis.bellsouth.net@marsha>; Wed, 22 Jan 2003 09:56:28 -0500 Date: Wed, 22 Jan 2003 09:54:34 -0500 From: Greg Freemyer Subject: re: Regarding Snapshot with XFS To: suresh grandhi cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20030122145628.QHIB765.imf06bis.bellsouth.net@marsha> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0MElw3v013970 X-archive-position: 2411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1088 Lines: 39 >> Hi, >> I am testing LVM Snapshot on XFS filesystem with >> RedHat kernel 2.4.18. I am able to create snapshot >> fine, if i execute the commands in the order >> xfs_freeze -f /volumes/vol1 >> lvcreate -s -L1G -nsnap /dev/volume1/vol >> xfs_freeze -u /volumes/vol1 >> where >> /volumes/vol1 = Mounted XFS filesystem >> /dev/volume1/vol is LV with VG volume1 >> But when I execute the command >> dd if=/dev/zero of=/volumes/vol1/img1 bs=1M count=1000 >> in one shell and the above commands in other shell >> xfs_freeze is succeeded, but then lvcreate is getting >> locked up. >> This is getting freed when i execute xfs_freeze -u >> /volumes/vol1 in another shell. >> Is there a way to make these commands work >> independently. >> Your help is greatly appreciated >> Tbanks in advance >> -Suresh Suresh, What version of XFS are you using. My experience is that XFS 1.1 has the problem you are experiencing, but the XFS 1.2 pre-release has it resolved. I admit to not personally having tested it in several months. Greg Freemyer From owner-linux-xfs@oss.sgi.com Wed Jan 22 21:57:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jan 2003 21:58:00 -0800 (PST) Received: from web14602.mail.yahoo.com (web14602.mail.yahoo.com [216.136.224.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0N5vv3v028452 for ; Wed, 22 Jan 2003 21:57:58 -0800 Message-ID: <20030123060442.4575.qmail@web14602.mail.yahoo.com> Received: from [202.188.158.195] by web14602.mail.yahoo.com via HTTP; Wed, 22 Jan 2003 22:04:42 PST Date: Wed, 22 Jan 2003 22:04:42 -0800 (PST) From: Arindam Dey Subject: XFS Query.... To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lfsdeveloper@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1092 Lines: 36 Hi all, This is the first time i used XFS. I installed it using the RedHat 7.3 installer provided by SGI. I am facing the following problem - Whenever any file is edited and viewed immedaitely after that it shows the changes, everything is hunky dory till here. But on hard shutdown immediately after that and on booting up the file has been changed to a one line data file with junk stuff in it. On smooth shutdown this stuff does not happen. Is it only me facing this problem becuase i have removed some RPMS from the system? But I have not removed the XFS pertinent RPMS. Also sadly i was messing aroung with rc.sysinit and rc.local when this error first came up. So now my rc files are screwed up and the system does not boot up normally passing init=/bin/bash is ok. SO can somebody help me by pointing me in the right direction. Thanks in advance, Arindam Dey ===== The mind is not a vessel to be filled but a fire to be kindled. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-linux-xfs@oss.sgi.com Wed Jan 22 23:54:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Jan 2003 23:54:20 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0N7s93v031535 for ; Wed, 22 Jan 2003 23:54:10 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0N80reU091751; Thu, 23 Jan 2003 09:00:53 +0100 (CET) Message-Id: <4.3.2.7.2.20030123084840.0357b2d8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 08:58:45 +0100 To: Arindam Dey , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS Query.... In-Reply-To: <20030123060442.4575.qmail@web14602.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 726 Lines: 26 At 22:04 22-1-2003 -0800, Arindam Dey wrote: >Hi all, > >This is the first time i used XFS. I installed it >using the RedHat 7.3 installer provided by SGI. > >I am facing the following problem - > >Whenever any file is edited and viewed immedaitely >after that it shows the changes, everything is hunky >dory till here. But on hard shutdown immediately after >that and on booting up the file has been changed to a >one line data file with junk stuff in it. This is the NULL files issue. It is explained in detail in the FAQ. http://oss.sgi.com/projects/xfs/faq.html#nulls You could also try using a newer release like the 1.2pre5 which is currently out. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jan 23 00:04:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Jan 2003 00:04:28 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0N8483v032048 for ; Thu, 23 Jan 2003 00:04:09 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 052E1AC4D; Thu, 23 Jan 2003 08:45:50 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 206AE190B8; Thu, 23 Jan 2003 08:45:49 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 237B730881D; Thu, 23 Jan 2003 08:39:12 +0100 (CET) Message-ID: <3E2F9C1F.2B6EC838@ch.sauter-bc.com> Date: Thu, 23 Jan 2003 08:39:11 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Arindam Dey Cc: linux-xfs@oss.sgi.com Subject: Re: XFS Query.... References: <20030123060442.4575.qmail@web14602.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1328 Lines: 44 Arindam Dey schrieb: > > Hi all, > > This is the first time i used XFS. I installed it > using the RedHat 7.3 installer provided by SGI. > > I am facing the following problem - > > Whenever any file is edited and viewed immedaitely > after that it shows the changes, everything is hunky > dory till here. But on hard shutdown immediately after > that and on booting up the file has been changed to a > one line data file with junk stuff in it. On smooth > shutdown this stuff does not happen. Is it only me > facing this problem becuase i have removed some RPMS > from the system? But I have not removed the XFS > pertinent RPMS. Also sadly i was messing aroung with > rc.sysinit and rc.local when this error first came up. > So now my rc files are screwed up and the system does > not boot up normally passing init=/bin/bash is ok. Everything is okay with your box. Did you upgrade your kernel? Try using one of the 1.2pre series, they will improve this behaviour. Simon > > SO can somebody help me by pointing me in the right > direction. > > Thanks in advance, > > Arindam Dey > > ===== > The mind is not a vessel to be > filled but a fire to be kindled. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com From owner-linux-xfs@oss.sgi.com Thu Jan 23 00:08:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Jan 2003 00:08:10 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0N8863v032531 for ; Thu, 23 Jan 2003 00:08:07 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id BA26BAC3A; Thu, 23 Jan 2003 09:21:27 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 49908190B8; Thu, 23 Jan 2003 09:21:27 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id E86F630881D; Thu, 23 Jan 2003 09:14:49 +0100 (CET) Message-ID: <3E2FA479.B48B682C@ch.sauter-bc.com> Date: Thu, 23 Jan 2003 09:14:49 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Patched 1.2Pre5 kernel References: <11036.1043135074@kao2.melbourne.sgi.com> <4.3.2.7.2.20030121143729.040b10d0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 623 Lines: 29 Seth Mos schrieb: > > At 09:05 21-1-2003 +0100, Seth Mos wrote: > > >Ah, I'm building this kernel with rpmbuild so it might have to do with > >some of the target options. > > Not building the debug kernels works. Removing the KDB patches has worked for me (it's not enabled anyway). I have built on RH 7.2 and 7.3. Thanks for the source package. Simon > > I just uploaded the i686 kernels to my server. > > http://iserv.nl/files/xfs/ > > My test box survived the weekend without hickups or problems so I consider > them good enough. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jan 23 04:45:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Jan 2003 04:45:12 -0800 (PST) Received: from silver.digirati.com.br (silver.digirati.com.br [200.185.109.126]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0NCj33v013144 for ; Thu, 23 Jan 2003 04:45:05 -0800 Received: from wsmichel (RJ227252.user.veloxzone.com.br [200.165.227.252]) (authenticated (0 bits)) by silver.digirati.com.br (8.11.6/8.11.6) with ESMTP id h0NCpiP32696 for ; Thu, 23 Jan 2003 10:51:45 -0200 Message-ID: <009d01c2c2de$392cf0d0$1601070a@mz.digirati.com.br> From: "Michel Machado" To: "XFS" Subject: ACL / Mode Date: Thu, 23 Jan 2003 10:51:54 -0200 Organization: Digirati MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 2416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michel@digirati.com.br Precedence: bulk X-list: linux-xfs Content-Length: 158 Lines: 8 Hi, The XFS shows and edits the mask ACL entry on group mode. Is there a fashion to disable this feature? With a mount parameter? [ ]'s Michel Machado From owner-linux-xfs@oss.sgi.com Thu Jan 23 06:09:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Jan 2003 06:09:30 -0800 (PST) Received: from relay-3v.club-internet.fr (relay-3v.club-internet.fr [194.158.96.114]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0NE9L3v014147 for ; Thu, 23 Jan 2003 06:09:22 -0800 Received: from agnes (lns06v-7-19.w.club-internet.fr [212.194.114.19]) by relay-3v.club-internet.fr (Postfix) with ESMTP id C10531740; Thu, 23 Jan 2003 13:44:08 +0100 (CET) Subject: Re: CPU overhead when handling large files? From: Jean Francois Martinez To: stimits@attbi.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3E29FF4F.2000809@attbi.com> References: <1042910194.2187.15.camel@wideangle.nameip.net> <3E29FF4F.2000809@attbi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 23 Jan 2003 13:49:11 +0100 Message-Id: <1043326152.1144.182.camel@agnes.fremen.dune> Mime-Version: 1.0 X-archive-position: 2417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jfm2@club-internet.fr Precedence: bulk X-list: linux-xfs Content-Length: 1226 Lines: 31 On Sun, 2003-01-19 at 02:28, D. Stimits wrote: > Seung-yeong Oh wrote: > > > Hello, > > Originally, I installed RedHat7.2 + SGI XFS 1.0.2. > > I now have fully updated RedHat7.2 + SGI XFS 1.2pre5 (rebuilt kernel RPM > > to be installed on RedHat 7.x). > > For current seup, I'm wondering if the following behavior is normal; > > When handling large files, for example, copying a few 700MB files from > > one directory to another, at some point in the middle of the process or > > at the end of it, the process hangs for several minutes taking up 99% of > > CPU. > > A friend of mine told me it might take some time to rewrite inodes as > > it's a journaling file system, but I don't remember the XFS acted this > > way before when I was using 1.0.2 of it. And 1.1 for that matter... > > I'd appreciate any input. Thank you. > > Have a nice weekend. > > > FYI, if you use IDE drives, and do not have UDMA on, it will always use > tons of cpu power to do copies, no matter what filesystem. > A few years ago I had a disk who used 97% of the CPU when doing a "dd if=/dev/hda of=/dev/null bs=8192". CPU usage dropped to under 20% after enabling DMA. Throughput was nearly trebled. This was a DMA not UDMA disk. JFM From owner-linux-xfs@oss.sgi.com Thu Jan 23 22:05:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Jan 2003 22:05:07 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0O6543v013190 for ; Thu, 23 Jan 2003 22:05:04 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0O5IEKp018766 for ; Thu, 23 Jan 2003 21:18:15 -0800 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA60957; Fri, 24 Jan 2003 17:10:28 +1100 (AEDT) Date: Fri, 24 Jan 2003 17:10:28 +1100 From: Tim Shimmin To: Michel Machado Cc: XFS Subject: Re: ACL / Mode Message-ID: <20030124171028.E1447880@boing.melbourne.sgi.com> References: <009d01c2c2de$392cf0d0$1601070a@mz.digirati.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <009d01c2c2de$392cf0d0$1601070a@mz.digirati.com.br>; from michel@digirati.com.br on Thu, Jan 23, 2003 at 10:51:54AM -0200 X-archive-position: 2418 X-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: 344 Lines: 14 Hi Michel, On Thu, Jan 23, 2003 at 10:51:54AM -0200, Michel Machado wrote: > Hi, > > The XFS shows and edits the mask ACL entry on group mode. Is there a > fashion to disable this feature? With a mount parameter? > Sorry, no, there is no option to disable this. We are just following the Posix ACL std 1003.1e on this one. Ciao, Tim. From owner-linux-xfs@oss.sgi.com Thu Jan 23 23:28:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Jan 2003 23:29:02 -0800 (PST) Received: from mail.qk.com.au (202-44-163-105.nexnet.net.au [202.44.163.105]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0O7Sr3v014076 for ; Thu, 23 Jan 2003 23:28:55 -0800 Received: from amavis by mail.qk.com.au with scanned-ok (Exim 3.35 #1 (Debian)) id 18byNH-0007lB-00 for ; Fri, 24 Jan 2003 18:35:39 +1100 Received: from juno ([10.0.0.79] ident=mail) by mail.qk.com.au with esmtp (Exim 3.35 #1 (Debian)) id 18byNG-0007l2-00 for ; Fri, 24 Jan 2003 18:35:38 +1100 Received: from lbarbuto by juno with local (Exim 3.36 #1 (Debian)) id 18byNF-0002eg-00 for ; Fri, 24 Jan 2003 18:35:37 +1100 Date: Fri, 24 Jan 2003 18:35:37 +1100 From: Lucas Barbuto To: Linux XFS Mailing List Subject: Problems mounting an ext3 filesystem with XFS kernel Message-ID: <20030124073537.GA9136@qk.com.au> Reply-To: Lucas Barbuto Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS perl-11 X-archive-position: 2419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lucas@qk.com.au Precedence: bulk X-list: linux-xfs Content-Length: 1716 Lines: 42 Hi All, I'm getting kernel panics trying to mount my root filesystem on boot: -- EXT3-fs: unable to read superblock EXT2-fs: unable to read superblock iofs_read_super: bread failed, dev=09:01, iso_blknum=16, block=32 XFS: bad magic number XFS: SB validate failed Kernel panic: VFS: Unable to mount root fs on 09:01 -- Which I understand means that my superblock is missing XFS information or is corrupted... trouble is, the filesystem is ext3! It used to be XFS before I realised that I couldn't install LiLo into the superblock along with XFS, so I made an ext3 filesystem on the partition expecting the XFS information to be overwritten and then installed LiLo on the superblock again, same thing. So then I deleted all my partitions and used 'dd if=/dev/zero of=/dev/hde' and 'dd if=/dev/zero of=/dev/hde' to wipe the start of the disks, recreated the partitions, formatted the root partition ext3, reinstalled LiLo, rebooted, same problem. The same kernel successfully boots off another disk (ext3) and can mount the new root partition once the machine is booted as well as any XFS partition I ask it to. All filesystem support that is needed is compiled into the kernel. Can anyone explain what's going on here? I'm completely out of ideas since I thought that the 'dd' was going to give me a completely blank disk I can't imagine what's happening. In case this is relevant (it might be) I'm trying to boot a software raid with the two disks connected to a Promise 20276 controller. The kernel is detecting this and I'm using the controller to access the disks seperately (ie, disabling the hardware raid so the disks become hde and hdg rather than ataraid/d0). Thanks in advance. Regards, Lucas From owner-linux-xfs@oss.sgi.com Fri Jan 24 00:59:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Jan 2003 00:59:08 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0O8x23v016692 for ; Fri, 24 Jan 2003 00:59:03 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0O95jdn061979; Fri, 24 Jan 2003 10:05:50 +0100 (CET) Message-Id: <4.3.2.7.2.20030124095156.04050e50@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Jan 2003 10:05:42 +0100 To: Lucas Barbuto , Linux XFS Mailing List From: Seth Mos Subject: Re: Problems mounting an ext3 filesystem with XFS kernel In-Reply-To: <20030124073537.GA9136@qk.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2420 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1398 Lines: 47 At 18:35 24-1-2003 +1100, Lucas Barbuto wrote: >In case this is relevant (it might be) I'm trying to boot a software >raid with the two disks connected to a Promise 20276 controller. What Raid level are you using? You can only boot a software raid 1 array. What do the first KB of the filesystem show? dd if=/dev/hdeX of=bootblock.bin bs=512 count=4 > The >kernel is detecting this and I'm using the controller to access the >disks seperately (ie, disabling the hardware raid so the disks become >hde and hdg rather than ataraid/d0). The Promise controller is a pseudo raid controller. eg. the driver has the actual raid 1 and 0 logic and not the card. You could even convert the standard Ultra ATA 66 controller to a Fastrak 66 by soldering a resistor to the back. It works, I've tried it. You did actually partition the disk did you? I'm assuming that you are trying to boot from the root disk which would be a raid 1. fdisk /dev/hde create new partition type fd write repeat for /dev/hdg Create a raid 1 set of these 2 disks. Create a filesystem on the corresponding md device. When installing lilo it should print out 2 lines where it installs itself on both disks in the superblock. I personally find this howto useful with respect to this. http://ldp.iserv.nl/HOWTO/Software-RAID-HOWTO-4.html#ss4.14 Good Luck. -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Jan 24 02:18:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Jan 2003 02:18:36 -0800 (PST) Received: from azrael.blades.cxm (ua3d35hel.dial.kolumbus.fi [62.248.233.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0OAIW3v018529 for ; Fri, 24 Jan 2003 02:18:33 -0800 Received: (from blades@localhost) by azrael.blades.cxm (SGI-8.9.3/8.9.3) id MAA38109 for linux-xfs@oss.sgi.com; Fri, 24 Jan 2003 12:25:20 +0200 (EET) X-Authentication-Warning: azrael.blades.cxm: blades set sender to harri.haataja@kolumbus.fi using -f Date: Fri, 24 Jan 2003 12:25:20 +0200 From: Harri Haataja Cc: Linux XFS Mailing List Subject: Re: Problems mounting an ext3 filesystem with XFS kernel Message-ID: <20030124122519.A38111@azrael.blades.cxm> References: <20030124073537.GA9136@qk.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030124073537.GA9136@qk.com.au>; from lucas@qk.com.au on Fri, Jan 24, 2003 at 06:35:37PM +1100 X-archive-position: 2421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: harri.haataja@kolumbus.fi Precedence: bulk X-list: linux-xfs Content-Length: 1328 Lines: 32 On Fri, Jan 24, 2003 at 06:35:37PM +1100, Lucas Barbuto wrote: > I'm getting kernel panics trying to mount my root filesystem on boot: > > -- > EXT3-fs: unable to read superblock > EXT2-fs: unable to read superblock > iofs_read_super: bread failed, dev=09:01, iso_blknum=16, block=32 > XFS: bad magic number > XFS: SB validate failed > Kernel panic: VFS: Unable to mount root fs on 09:01 > -- > > Which I understand means that my superblock is missing XFS information > or is corrupted... trouble is, the filesystem is ext3! It used to be > XFS before I realised that I couldn't install LiLo into the superblock > along with XFS, so I made an ext3 filesystem on the partition > expecting the XFS information to be overwritten and then installed > LiLo on the superblock again, same thing. So then I deleted all my > partitions and used 'dd if=/dev/zero of=/dev/hde' and 'dd if=/dev/zero > of=/dev/hde' to wipe the start of the disks, recreated the partitions, > formatted the root partition ext3, reinstalled LiLo, rebooted, same > problem. A little long shot here, but did you make a new initrd at what points? I'm not sure but I think the actual root filesystem type is mentioned somewhere on the initrd and you have to make a new one if it's changed. IIRC ICBW YMMV etc -- OpenMosix: Because Forking should be Free! From owner-linux-xfs@oss.sgi.com Fri Jan 24 06:09:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Jan 2003 06:09:26 -0800 (PST) Received: from gatekeeper.slim (slimnet.xs4all.nl [194.109.194.192]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0OE9D3v023949 for ; Fri, 24 Jan 2003 06:09:18 -0800 Received: from paragon.slim (paragon.slim [192.168.100.26]) by gatekeeper.slim (8.12.5/8.12.5) with ESMTP id h0ODWgiQ026345 for ; Fri, 24 Jan 2003 14:32:46 +0100 Subject: Problem with CVS trees 2.4 and 2.5 From: Jurgen Kramer To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1043418069.11248.5.camel@paragon.slim> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 (1.2.1-1) Date: 24 Jan 2003 15:21:09 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 2422 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gtm.kramer@inter.nl.net Precedence: bulk X-list: linux-xfs Content-Length: 281 Lines: 19 Hi, There seems to be some trouble with CVS checkout. Both 2.4 and 2.5 trees get stuck while checking out. 2.4: cvs server: Updating linux-2.4-xfs/linux/scripts/usb 2.5 cvs server: Updating linux-2.5-xfs/linux/usr Cheers, Jurgen -- Jurgen Kramer From owner-linux-xfs@oss.sgi.com Fri Jan 24 06:14:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Jan 2003 06:14:29 -0800 (PST) Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0OEEO3v024390 for ; Fri, 24 Jan 2003 06:14:26 -0800 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 18c4hl-0005Ky-00 for ; Fri, 24 Jan 2003 16:21:13 +0200 Date: Fri, 24 Jan 2003 16:21:13 +0200 To: linux-xfs@oss.sgi.com Subject: Re: Problem with CVS trees 2.4 and 2.5 Message-ID: <20030124142113.GA20456@psychedelic.baana.suomi.net> References: <1043418069.11248.5.camel@paragon.slim> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1043418069.11248.5.camel@paragon.slim> User-Agent: Mutt/1.3.28i From: Juha K Kallio X-archive-position: 2423 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunnyh@psychedelic.baana.suomi.net Precedence: bulk X-list: linux-xfs Content-Length: 584 Lines: 27 This is because of some compatibility problem in the cvs server and client. The checkout stops after the last file, you can safely kill it. Or you can disable compression, and it won't get stuck. On Fri, Jan 24, 2003 at 03:21:09PM +0100, Jurgen Kramer wrote: > Hi, > > There seems to be some trouble with CVS checkout. Both 2.4 and 2.5 trees > get stuck while checking out. > > 2.4: > > cvs server: Updating linux-2.4-xfs/linux/scripts/usb > > 2.5 > > cvs server: Updating linux-2.5-xfs/linux/usr > > Cheers, > > Jurgen > -- > Jurgen Kramer > > From owner-linux-xfs@oss.sgi.com Fri Jan 24 12:06:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Jan 2003 12:06:24 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0OK6J3v003919 for ; Fri, 24 Jan 2003 12:06:20 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0OJJZKp005039 for ; Fri, 24 Jan 2003 11:19:35 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA56165 for ; Fri, 24 Jan 2003 14:13:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA32449 for ; Fri, 24 Jan 2003 14:13:04 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h0OKD4S11069; Fri, 24 Jan 2003 14:13:04 -0600 Message-Id: <200301242013.h0OKD4S11069@jen.americas.sgi.com> Date: Fri, 24 Jan 2003 14:13:04 -0600 Subject: TAKE - fix a use after free race in xfs To: linux-xfs@oss.sgi.com X-archive-position: 2424 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1759 Lines: 50 Transaction A is in callback processing unpinning a buffer, Transaction B is in the process of marking the buffer stale. Between transaction A dropping its reference and checking the stale state, transaction B gets a reference and stales the buffer. A ends up freeing the log item and releasing the buffer. End result is we have a reference to free memory and an unlocked buffer. We have never seen this problem on linux, only on Irix under very heavy load, and usually with a large cpu count. Date: Fri Jan 24 12:11:43 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:137748a linux/fs/xfs/xfsidbg.c - 1.213 - decode XFS_LID_BUF_STALE. linux/fs/xfs/xfs_extfree_item.c - 1.53 - deal with extra arg on unpin operation linux/fs/xfs/xfs_buf_item.c - 1.135 - add a new flag to the unpin operation, use this flag being set to indicate that we staled the buffer rather than using the bli_flags which another thread can set while we are in this function. linux/fs/xfs/xfs_inode_item.c - 1.110 linux/fs/xfs/xfs_dquot_item.c - 1.33 - deal with extra arg on unpin operation linux/fs/xfs/xfs_trans.c - 1.138 - when unpining a log item, pass the buffer stale state from the log item descriptor flags into the unpin operation, this tells the function that we are actually the transaction which staled it. linux/fs/xfs/xfs_trans.h - 1.116 - change prototype for unpin operations and IOP_UNPIN, define a new flag for log item descriptors. linux/fs/xfs/xfs_trans_buf.c - 1.110 - when logging a buffer into a transaction, clear XFS_LID_BUF_STALE when staling a buffer in a transaction, set XFS_LID_BUF_STALE. From owner-linux-xfs@oss.sgi.com Fri Jan 24 12:10:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Jan 2003 12:10:25 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0OKAM3v004347 for ; Fri, 24 Jan 2003 12:10:22 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0OJNbKp005404 for ; Fri, 24 Jan 2003 11:23:38 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA27666 for ; Fri, 24 Jan 2003 14:17:05 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA44900 for ; Fri, 24 Jan 2003 14:17:07 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h0OKH7w11506; Fri, 24 Jan 2003 14:17:07 -0600 Message-Id: <200301242017.h0OKH7w11506@jen.americas.sgi.com> Date: Fri, 24 Jan 2003 14:17:07 -0600 Subject: TAKE - remove a potential mechanism for out of order log callbacks To: linux-xfs@oss.sgi.com X-archive-position: 2425 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1208 Lines: 33 Do not release the last iclog of a transaction before we get our callbacks attached to it. Otherwise we can end up executing the callback out of order. This was found by code inspection, not sure it was ever seen in the wild on linux, but it does explain some Irix crashes which have been reported. Date: Fri Jan 24 12:15:45 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:137750a linux/fs/xfs/xfs_log.h - 1.63 - changes in prototypes linux/fs/xfs/xfs_log.c - 1.263 - when writing a commit record into the log, do not release the iclog, but pass it back to the caller so that they can release it after they have attached their callbacks to it. xlog_state_lsn_is_synced goes away because it was used in the path where we were racing between the write of the iclog and the attachment of the callbacks. linux/fs/xfs/xfs_trans.c - 1.139 - when committing a transaction the log code passes us back a handle to the iclog with our commit record in it. We pass this into xfs_log_notify so that we can attach callbacks to it prior to dropping our hold in it. From owner-linux-xfs@oss.sgi.com Fri Jan 24 14:53:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Jan 2003 14:53:20 -0800 (PST) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0OMrA3v014880 for ; Fri, 24 Jan 2003 14:53:11 -0800 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id OAA07207 for ; Fri, 24 Jan 2003 14:59:56 -0800 (PST) Received: from digeo-e2k04.digeo.com ([192.168.2.24]) by digeo-nav01.digeo.com (NAVGW 2.5.2.12) with SMTP id M2003012415030719293 ; Fri, 24 Jan 2003 15:03:07 -0800 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by digeo-e2k04.digeo.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 14:59:56 -0800 Received: from akpm-1 ([172.17.140.233]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 Jan 2003 14:59:54 -0800 Date: Fri, 24 Jan 2003 15:19:01 -0800 From: Andrew Morton To: Juha K Kallio Cc: linux-xfs@oss.sgi.com Subject: Re: Problem with CVS trees 2.4 and 2.5 Message-Id: <20030124151901.0845927e.akpm@digeo.com> In-Reply-To: <20030124142113.GA20456@psychedelic.baana.suomi.net> References: <1043418069.11248.5.camel@paragon.slim> <20030124142113.GA20456@psychedelic.baana.suomi.net> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2003 22:59:54.0919 (UTC) FILETIME=[4F498B70:01C2C3FC] X-archive-position: 2426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: linux-xfs Content-Length: 436 Lines: 13 Juha K Kallio wrote: > > This is because of some compatibility problem in the cvs server and > client. The checkout stops after the last file, you can safely kill > it. Or you can disable compression, and it won't get stuck. > Yes, this started happening to me all over the place when I installed Red Hat 8.0 on the CVS server. Someone broke CVS. Upgrading cvs on all the clients fixed it up. From owner-linux-xfs@oss.sgi.com Sun Jan 26 23:34:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Jan 2003 23:35:02 -0800 (PST) Received: from mail.epost.de ([193.28.100.187]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0R7Yr3v000970 for ; Sun, 26 Jan 2003 23:34:55 -0800 Received: from epost.de (217.110.232.6) by mail.epost.de (6.7.015) (authenticated as rainer.traut@epost.de) id 3E26EB09000F4624 for linux-xfs@oss.sgi.com; Mon, 27 Jan 2003 08:41:54 +0100 Message-ID: <3E34E2C2.4000304@epost.de> Date: Mon, 27 Jan 2003 08:41:54 +0100 From: Rainer Traut User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030123 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Web Site: wrong url for pre5 release Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id h0R7Yt3v000971 X-archive-position: 2427 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rainer.traut@epost.de Precedence: bulk X-list: linux-xfs Content-Length: 157 Lines: 8 Hi, I hope someone reads this, who can change it... The link on http://oss.sgi.com/projects/xfs/ für prerelease5 goes to the wrong ftp url (pre3). Rainer From owner-linux-xfs@oss.sgi.com Sun Jan 26 23:57:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Jan 2003 23:57:22 -0800 (PST) Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0R7vD3v009694 for ; Sun, 26 Jan 2003 23:57:15 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h0R84AKR021400; Mon, 27 Jan 2003 19:04:10 +1100 (EST) Received: from jdc.local (ppp148.dyn134.pacific.net.au [210.23.134.148]) by wisma.pacific.net.au with ESMTP id TAA06912; Mon, 27 Jan 2003 19:04:09 +1100 (EST) Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.3/8.12.3/Debian -4) with ESMTP id h0R848g2003150; Mon, 27 Jan 2003 19:04:08 +1100 Received: (from jason@localhost) by jdc.local (8.12.3/8.12.3/Debian -4) id h0R845mu003136; Mon, 27 Jan 2003 19:04:05 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15924.59381.495296.323106@jdc.local> Date: Mon, 27 Jan 2003 19:04:05 +1100 To: Andrew Morton Cc: Juha K Kallio , linux-xfs@oss.sgi.com Subject: Re: Problem with CVS trees 2.4 and 2.5 In-Reply-To: <20030124151901.0845927e.akpm@digeo.com> References: <1043418069.11248.5.camel@paragon.slim> <20030124142113.GA20456@psychedelic.baana.suomi.net> <20030124151901.0845927e.akpm@digeo.com> X-Mailer: VM 7.07 under Emacs 21.2.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 447 Lines: 12 Andrew Morton writes: > > Yes, this started happening to me all over the place when I installed Red > Hat 8.0 on the CVS server. Someone broke CVS. > > Upgrading cvs on all the clients fixed it up. The recent security vulnerability is another good reason to upgrade any CVS server, and in fact to be safe it might be best to upgrade every installation of CVS, just in case one of the current client machines eventually becomes a server. From owner-linux-xfs@oss.sgi.com Mon Jan 27 00:31:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 00:31:26 -0800 (PST) Received: from web7306.mail.yahoo.co.kr (web7306.mail.yahoo.co.kr [211.119.129.207]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0R8VL3v015090 for ; Mon, 27 Jan 2003 00:31:22 -0800 Message-ID: <20030127083818.84351.qmail@web7306.mail.yahoo.co.kr> Received: from [165.213.1.1] by web7306.mail.yahoo.co.kr via HTTP; Mon, 27 Jan 2003 17:38:18 JST Date: Mon, 27 Jan 2003 17:38:18 +0900 (JST) From: =?euc-kr?q?Kwon=20SoonSon?= Subject: some XFS questions To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit X-archive-position: 2429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksoonson@yahoo.co.kr Precedence: bulk X-list: linux-xfs Content-Length: 1157 Lines: 40 Hello, XFS folks... I am studying the XFS internals and got some questions regarding its detailed design. 1. what is the "uuid" for? I found that XFS has its magic number already. Then why is there "uuid"? 2. in the superblock(xfs_sb), I see "realtime block" and "realtime extent". Can anyone please let me know what the realtime block/extent mean? 3. in xfs_dinode_core, there is di_projid. What is this for? 4. according to the 1993 design document, the inode number of xfs_agi used to be devided into 3 parts but now it is 2 parts. I think this should have some reasoning but don't know the details. Why? 5. is there any plan to support "snapshot" feature in XFS in the near future or any existing one? I actually have not tested XFS myself yet but very interested in using snapshot on it. If anyone please answer me any of the above questions, or link to the appropriate information, that would be very helpful to me. Thanks very much.... _____________________________________________________________________ µðÁöÅ» Ä«¸Þ¶ó¿Í Âû¶± ±ÃÇÕ- ¾ßÈÄ! »çÁø http://kr.photos.yahoo.com/ µ·µÇ´Â Áß°íÂ÷ ¼îÇθô - ¾ßÈÄ! ÀÚµ¿Â÷ http://autos.yahoo.co.kr/autos/ From owner-linux-xfs@oss.sgi.com Mon Jan 27 02:23:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 02:23:18 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RANA3v023084 for ; Mon, 27 Jan 2003 02:23:12 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0RAUCBb068236; Mon, 27 Jan 2003 11:30:12 +0100 (CET) Message-Id: <4.3.2.7.2.20030127111757.043cee60@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Jan 2003 11:30:00 +0100 To: =?euc-kr?q?Kwon=20SoonSon?= , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: some XFS questions In-Reply-To: <20030127083818.84351.qmail@web7306.mail.yahoo.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 531 Lines: 19 At 17:38 27-1-2003 +0900, =?euc-kr?q?Kwon=20SoonSon?= wrote: >Hello, XFS folks... >I am studying the XFS internals and got some questions >regarding its detailed design. > >5. is there any plan to support "snapshot" feature >in XFS in the near future or any existing one? >I actually have not tested XFS myself yet but very >interested >in using snapshot on it. Yes this should be possible using xfs_freeze. You might want to search the archives for any hints. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jan 27 03:56:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 03:56:37 -0800 (PST) Received: from zork.zork.net (mail@zork.zork.net [66.92.188.166]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RBuT3v027874 for ; Mon, 27 Jan 2003 03:56:30 -0800 Received: from sneakums by zork.zork.net with local (Exim 3.35 #1 (Debian)) id 18d7zA-0005sW-00; Mon, 27 Jan 2003 04:03:32 -0800 To: linux-xfs@oss.sgi.com Subject: Re: some XFS questions From: Sean Neakums X-Worst-Pick-Up-Line-Ever: "Hey baby, wanna peer with my leafnode instance?" X-Message-Flag: Message text advisory: ARGUMENTUM AD HOMINEM, TERRORISM/FIREARMS X-Mailer: Norman X-Groin-Mounted-Steering-Wheel: "Arrrr... it's driving me nuts!" X-Alameda: WHY DOESN'T ANYONE KNOW ABOUT ALAMEDA? IT'S RIGHT NEXT TO OAKLAND!!! Organization: The Emadonics Institute Mail-Followup-To: linux-xfs@oss.sgi.com Date: Mon, 27 Jan 2003 12:03:32 +0000 In-Reply-To: <20030127083818.84351.qmail@web7306.mail.yahoo.co.kr> (Kwon SoonSon's message of "Mon, 27 Jan 2003 17:38:18 +0900 (JST)") Message-ID: <6u4r7un6jv.fsf@zork.zork.net> User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 (i386-debian-linux-gnu) References: <20030127083818.84351.qmail@web7306.mail.yahoo.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sneakums@zork.net Precedence: bulk X-list: linux-xfs Content-Length: 448 Lines: 14 commence Kwon SoonSon quotation: > 1. what is the "uuid" for? I found that XFS has its magic number > already. Then why is there "uuid"? The UUID uniquely identifies individual instances of a filesystem, whereas all instances of a filesystem will have the same magic number. -- / | [|] Sean Neakums | Size *does* matter. [|] | That's why I use Emacs. \ | From owner-linux-xfs@oss.sgi.com Mon Jan 27 06:34:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 06:34:19 -0800 (PST) Received: from fwd1.mx.base (p508D6E1E.dip.t-dialin.net [80.141.110.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0REY63v006664 for ; Mon, 27 Jan 2003 06:34:08 -0800 Received: from metze-xp.mx.base (unknown [192.168.0.3]) by fwd1.mx.base (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 4162E73205; Mon, 27 Jan 2003 15:41:02 +0100 (CET) Message-Id: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> X-Sender: lists%metzemix.de@post.webmailer.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 27 Jan 2003 15:41:00 +0100 To: viro@math.psu.edu From: "Stefan (metze) Metzmacher" Subject: default quota limits in linux (via quotactl()) Cc: linux-fsdevel@vger.kernel.org, sct@redhat.com, akpm@zip.com.au, adilger@clusterfs.com, ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_2940037==_" X-archive-position: 2432 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: metze@metzemix.de Precedence: bulk X-list: linux-xfs Content-Length: 9587 Lines: 189 --=====================_2940037==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Alexander and *, I would like linux to handle default quota limits like NTFS 5 do it. So if a new user is added to the system and start to own disk space on a filesystem he should get the default quotas for the specified FS as his own quotas. Now a new user has unlimited disk space until root explicit sets quota limits for this user. I have searched in google to find another unix witch allready implements this feature, but I didn't find any. So I decided to add two (four) new cmd's to quotactl(), Q_SETDEFQUOTA Q_GETDEFQUOTA and for the XFS Quotas Q_XSETDEFQLIM Q_XGETDEFQUOTA this call should take the same paramter's as the Q_GETQUOTA /Q_XGETQUOTA .. cmd's but the uid/gid should be ignored here and the filesystem defaults should be get or set. I think this should be an easy task to be implemented in the filesystems witch allready support quotas. I attach a patch witch modify the quotactl system call for this. the implemetation inside the filesystems, should be done by the maintainers:-) PS: I'm currently using XFS and it would be very cool if the default quota limits could implemented very fast...:-) I hope I will get feedback :) thanks anyway... please cc me: in all replies:-) metze ----------------------------------------------------------------------------- Stefan "metze" Metzmacher --=====================_2940037==_ Content-Type: application/octet-stream; name="2.5.59-defquota.diff"; x-mac-type="42494E41"; x-mac-creator="5843454C" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2.5.59-defquota.diff" ZGlmZiAtTnB1ciAtLWV4Y2x1ZGU9Q1ZTIC0tZXhjbHVkZT0qLmJhayAtLWV4 Y2x1ZGU9Ki5vIC0tZXhjbHVkZT0qLnBvIC0tZXhjbHVkZT0uIyogLS1leGNs dWRlPS4qIGxpbnV4LTIuNS41OS9pbmNsdWRlL2xpbnV4L2RxYmxrX3hmcy5o IGxpbnV4LTIuNS41OS1NWC9pbmNsdWRlL2xpbnV4L2RxYmxrX3hmcy5oCi0t LSBsaW51eC0yLjUuNTkvaW5jbHVkZS9saW51eC9kcWJsa194ZnMuaAlGcmkg SmFuIDE3IDAzOjIyOjI2IDIwMDMKKysrIGxpbnV4LTIuNS41OS1NWC9pbmNs dWRlL2xpbnV4L2RxYmxrX3hmcy5oCVRodSBKYW4gMjMgMTI6NTc6MzEgMjAw MwpAQCAtNDYsNyArNDYsOCBAQAogI2RlZmluZSBRX1hTRVRRTElNCVhRTV9D TUQoMHg0KQkvKiBzZXQgZGlzayBsaW1pdHMgKi8KICNkZWZpbmUgUV9YR0VU UVNUQVQJWFFNX0NNRCgweDUpCS8qIGdldCBxdW90YSBzdWJzeXN0ZW0gc3Rh dHVzICovCiAjZGVmaW5lIFFfWFFVT1RBUk0JWFFNX0NNRCgweDYpCS8qIGZy ZWUgZGlzayBzcGFjZSB1c2VkIGJ5IGRxdW90cyAqLwotCisjZGVmaW5lIFFf WEdFVERFRlFVT1RBCVhRTV9DTUQoMHg3KQkvKiBnZXQgZGVmYXVsdCBkaXNr IGxpbWl0cyBhbmQgdXNhZ2UgKi8KKyNkZWZpbmUgUV9YU0VUREVGUUxJTQlY UU1fQ01EKDB4OCkJLyogc2V0IGRlZmF1bHQgZGlzayBsaW1pdHMgKi8KIC8q CiAgKiBmc19kaXNrX3F1b3RhIHN0cnVjdHVyZToKICAqCmRpZmYgLU5wdXIg LS1leGNsdWRlPUNWUyAtLWV4Y2x1ZGU9Ki5iYWsgLS1leGNsdWRlPSoubyAt LWV4Y2x1ZGU9Ki5wbyAtLWV4Y2x1ZGU9LiMqIC0tZXhjbHVkZT0uKiBsaW51 eC0yLjUuNTkvaW5jbHVkZS9saW51eC9xdW90YS5oIGxpbnV4LTIuNS41OS1N WC9pbmNsdWRlL2xpbnV4L3F1b3RhLmgKLS0tIGxpbnV4LTIuNS41OS9pbmNs dWRlL2xpbnV4L3F1b3RhLmgJRnJpIEphbiAxNyAwMzoyMjoyNSAyMDAzCisr KyBsaW51eC0yLjUuNTktTVgvaW5jbHVkZS9saW51eC9xdW90YS5oCVRodSBK YW4gMjMgMTI6NTY6MjMgMjAwMwpAQCAtODAsMTQgKzgwLDE2IEBAIGV4dGVy biBzcGlubG9ja190IGRxX2RhdGFfbG9jazsKICNkZWZpbmUgU1VCQ01EU0hJ RlQgOAogI2RlZmluZSBRQ01EKGNtZCwgdHlwZSkgICgoKGNtZCkgPDwgU1VC Q01EU0hJRlQpIHwgKCh0eXBlKSAmIFNVQkNNRE1BU0spKQogCi0jZGVmaW5l IFFfU1lOQyAgICAgMHg4MDAwMDEJLyogc3luYyBkaXNrIGNvcHkgb2YgYSBm aWxlc3lzdGVtcyBxdW90YXMgKi8KLSNkZWZpbmUgUV9RVU9UQU9OICAweDgw MDAwMgkvKiB0dXJuIHF1b3RhcyBvbiAqLwotI2RlZmluZSBRX1FVT1RBT0ZG IDB4ODAwMDAzCS8qIHR1cm4gcXVvdGFzIG9mZiAqLwotI2RlZmluZSBRX0dF VEZNVCAgIDB4ODAwMDA0CS8qIGdldCBxdW90YSBmb3JtYXQgdXNlZCBvbiBn aXZlbiBmaWxlc3lzdGVtICovCi0jZGVmaW5lIFFfR0VUSU5GTyAgMHg4MDAw MDUJLyogZ2V0IGluZm9ybWF0aW9uIGFib3V0IHF1b3RhIGZpbGVzICovCi0j ZGVmaW5lIFFfU0VUSU5GTyAgMHg4MDAwMDYJLyogc2V0IGluZm9ybWF0aW9u IGFib3V0IHF1b3RhIGZpbGVzICovCi0jZGVmaW5lIFFfR0VUUVVPVEEgMHg4 MDAwMDcJLyogZ2V0IHVzZXIgcXVvdGEgc3RydWN0dXJlICovCi0jZGVmaW5l IFFfU0VUUVVPVEEgMHg4MDAwMDgJLyogc2V0IHVzZXIgcXVvdGEgc3RydWN0 dXJlICovCisjZGVmaW5lIFFfU1lOQwkJMHg4MDAwMDEJLyogc3luYyBkaXNr IGNvcHkgb2YgYSBmaWxlc3lzdGVtcyBxdW90YXMgKi8KKyNkZWZpbmUgUV9R VU9UQU9OCTB4ODAwMDAyCS8qIHR1cm4gcXVvdGFzIG9uICovCisjZGVmaW5l IFFfUVVPVEFPRkYJMHg4MDAwMDMJLyogdHVybiBxdW90YXMgb2ZmICovCisj ZGVmaW5lIFFfR0VURk1UCTB4ODAwMDA0CS8qIGdldCBxdW90YSBmb3JtYXQg dXNlZCBvbiBnaXZlbiBmaWxlc3lzdGVtICovCisjZGVmaW5lIFFfR0VUSU5G TwkweDgwMDAwNQkvKiBnZXQgaW5mb3JtYXRpb24gYWJvdXQgcXVvdGEgZmls ZXMgKi8KKyNkZWZpbmUgUV9TRVRJTkZPCTB4ODAwMDA2CS8qIHNldCBpbmZv cm1hdGlvbiBhYm91dCBxdW90YSBmaWxlcyAqLworI2RlZmluZSBRX0dFVFFV T1RBCTB4ODAwMDA3CS8qIGdldCB1c2VyIHF1b3RhIHN0cnVjdHVyZSAqLwor I2RlZmluZSBRX1NFVFFVT1RBCTB4ODAwMDA4CS8qIHNldCB1c2VyIHF1b3Rh IHN0cnVjdHVyZSAqLworI2RlZmluZSBRX0dFVERFRlFVT1RBCTB4ODAwMDA5 CS8qIGdldCBkZWZhdWx0IHVzZXIgcXVvdGEgc3RydWN0dXJlICovCisjZGVm aW5lIFFfU0VUREVGUVVPVEEJMHg4MDAwMEEJLyogc2V0IGRlZmF1bHQgdXNl ciBxdW90YSBzdHJ1Y3R1cmUgKi8KIAogLyoKICAqIFF1b3RhIHN0cnVjdHVy ZSB1c2VkIGZvciBjb21tdW5pY2F0aW9uIHdpdGggdXNlcnNwYWNlIHZpYSBx dW90YWN0bApAQCAtMjYxLDEwICsyNjMsMTQgQEAgc3RydWN0IHF1b3RhY3Rs X29wcyB7CiAJaW50ICgqc2V0X2luZm8pKHN0cnVjdCBzdXBlcl9ibG9jayAq LCBpbnQsIHN0cnVjdCBpZl9kcWluZm8gKik7CiAJaW50ICgqZ2V0X2RxYmxr KShzdHJ1Y3Qgc3VwZXJfYmxvY2sgKiwgaW50LCBxaWRfdCwgc3RydWN0IGlm X2RxYmxrICopOwogCWludCAoKnNldF9kcWJsaykoc3RydWN0IHN1cGVyX2Js b2NrICosIGludCwgcWlkX3QsIHN0cnVjdCBpZl9kcWJsayAqKTsKKwlpbnQg KCpnZXRfZGVmZHFibGspKHN0cnVjdCBzdXBlcl9ibG9jayAqLCBpbnQsIHN0 cnVjdCBpZl9kcWJsayAqKTsKKwlpbnQgKCpzZXRfZGVmZHFibGspKHN0cnVj dCBzdXBlcl9ibG9jayAqLCBpbnQsIHN0cnVjdCBpZl9kcWJsayAqKTsKIAlp bnQgKCpnZXRfeHN0YXRlKShzdHJ1Y3Qgc3VwZXJfYmxvY2sgKiwgc3RydWN0 IGZzX3F1b3RhX3N0YXQgKik7CiAJaW50ICgqc2V0X3hzdGF0ZSkoc3RydWN0 IHN1cGVyX2Jsb2NrICosIHVuc2lnbmVkIGludCwgaW50KTsKIAlpbnQgKCpn ZXRfeHF1b3RhKShzdHJ1Y3Qgc3VwZXJfYmxvY2sgKiwgaW50LCBxaWRfdCwg c3RydWN0IGZzX2Rpc2tfcXVvdGEgKik7CiAJaW50ICgqc2V0X3hxdW90YSko c3RydWN0IHN1cGVyX2Jsb2NrICosIGludCwgcWlkX3QsIHN0cnVjdCBmc19k aXNrX3F1b3RhICopOworCWludCAoKmdldF94ZGVmcXVvdGEpKHN0cnVjdCBz dXBlcl9ibG9jayAqLCBpbnQsIHN0cnVjdCBmc19kaXNrX3F1b3RhICopOwor CWludCAoKnNldF94ZGVmcXVvdGEpKHN0cnVjdCBzdXBlcl9ibG9jayAqLCBp bnQsIHN0cnVjdCBmc19kaXNrX3F1b3RhICopOwogfTsKIAogc3RydWN0IHF1 b3RhX2Zvcm1hdF90eXBlIHsKZGlmZiAtTnB1ciAtLWV4Y2x1ZGU9Q1ZTIC0t ZXhjbHVkZT0qLmJhayAtLWV4Y2x1ZGU9Ki5vIC0tZXhjbHVkZT0qLnBvIC0t ZXhjbHVkZT0uIyogLS1leGNsdWRlPS4qIGxpbnV4LTIuNS41OS9mcy9xdW90 YS5jIGxpbnV4LTIuNS41OS1NWC9mcy9xdW90YS5jCi0tLSBsaW51eC0yLjUu NTkvZnMvcXVvdGEuYwlGcmkgSmFuIDE3IDAzOjIyOjQ4IDIwMDMKKysrIGxp bnV4LTIuNS41OS1NWC9mcy9xdW90YS5jCVRodSBKYW4gMjMgMTI6NDM6NDAg MjAwMwpAQCAtNTAsNiArNTAsMTQgQEAgc3RhdGljIGludCBjaGVja19xdW90 YWN0bF92YWxpZChzdHJ1Y3QgcwogCQkJaWYgKCFzYi0+c19xY29wLT5nZXRf ZHFibGspCiAJCQkJcmV0dXJuIC1FTk9TWVM7CiAJCQlicmVhazsKKwkJY2Fz ZSBRX1NFVERFRlFVT1RBOgorCQkJaWYgKCFzYi0+c19xY29wLT5zZXRfZGVm ZHFibGspCisJCQkJcmV0dXJuIC1FTk9TWVM7CisJCQlicmVhazsKKwkJY2Fz ZSBRX0dFVERFRlFVT1RBOgorCQkJaWYgKCFzYi0+c19xY29wLT5nZXRfZGVm ZHFibGspCisJCQkJcmV0dXJuIC1FTk9TWVM7CisJCQlicmVhazsKIAkJY2Fz ZSBRX1NZTkM6CiAJCQlpZiAoIXNiLT5zX3Fjb3AtPnF1b3RhX3N5bmMpCiAJ CQkJcmV0dXJuIC1FTk9TWVM7CkBAIC03Miw2ICs4MCwxNCBAQCBzdGF0aWMg aW50IGNoZWNrX3F1b3RhY3RsX3ZhbGlkKHN0cnVjdCBzCiAJCQlpZiAoIXNi LT5zX3Fjb3AtPmdldF94cXVvdGEpCiAJCQkJcmV0dXJuIC1FTk9TWVM7CiAJ CQlicmVhazsKKwkJY2FzZSBRX1hTRVRERUZRTElNOgorCQkJaWYgKCFzYi0+ c19xY29wLT5zZXRfeGRlZnF1b3RhKQorCQkJCXJldHVybiAtRU5PU1lTOwor CQkJYnJlYWs7CisJCWNhc2UgUV9YR0VUREVGUVVPVEE6CisJCQlpZiAoIXNi LT5zX3Fjb3AtPmdldF94ZGVmcXVvdGEpCisJCQkJcmV0dXJuIC1FTk9TWVM7 CisJCQlicmVhazsKIAkJZGVmYXVsdDoKIAkJCXJldHVybiAtRUlOVkFMOwog CX0KQEAgLTg0LDYgKzEwMCw4IEBAIHN0YXRpYyBpbnQgY2hlY2tfcXVvdGFj dGxfdmFsaWQoc3RydWN0IHMKIAkJY2FzZSBRX1NFVElORk86CiAJCWNhc2Ug UV9TRVRRVU9UQToKIAkJY2FzZSBRX0dFVFFVT1RBOgorCQljYXNlIFFfU0VU REVGUVVPVEE6CisJCWNhc2UgUV9HRVRERUZRVU9UQToKIAkJCS8qIFRoaXMg aXMganVzdCBpbmZvcm1hdGl2ZSB0ZXN0IHNvIHdlIGFyZSBzYXRpc2ZpZWQg d2l0aG91dCBhIGxvY2sgKi8KIAkJCWlmICghc2JfaGFzX3F1b3RhX2VuYWJs ZWQoc2IsIHR5cGUpKQogCQkJCXJldHVybiAtRVNSQ0g7CkBAIC0xNjYsNiAr MTg0LDIyIEBAIHN0YXRpYyBpbnQgZG9fcXVvdGFjdGwoc3RydWN0IHN1cGVy X2Jsb2MKIAkJCQlyZXR1cm4gLUVGQVVMVDsKIAkJCXJldHVybiBzYi0+c19x Y29wLT5zZXRfZHFibGsoc2IsIHR5cGUsIGlkLCAmaWRxKTsKIAkJfQorCQlj YXNlIFFfR0VUREVGUVVPVEE6IHsKKwkJCXN0cnVjdCBpZl9kcWJsayBpZHE7 CisKKwkJCWlmICgocmV0ID0gc2ItPnNfcWNvcC0+Z2V0X2RlZmRxYmxrKHNi LCB0eXBlLCAmaWRxKSkpCisJCQkJcmV0dXJuIHJldDsKKwkJCWlmIChjb3B5 X3RvX3VzZXIoYWRkciwgJmlkcSwgc2l6ZW9mKGlkcSkpKQorCQkJCXJldHVy biAtRUZBVUxUOworCQkJcmV0dXJuIDA7CisJCX0KKwkJY2FzZSBRX1NFVERF RlFVT1RBOiB7CisJCQlzdHJ1Y3QgaWZfZHFibGsgaWRxOworCisJCQlpZiAo Y29weV9mcm9tX3VzZXIoJmlkcSwgYWRkciwgc2l6ZW9mKGlkcSkpKQorCQkJ CXJldHVybiAtRUZBVUxUOworCQkJcmV0dXJuIHNiLT5zX3Fjb3AtPnNldF9k ZWZkcWJsayhzYiwgdHlwZSwgJmlkcSk7CisJCX0KIAkJY2FzZSBRX1NZTkM6 CiAJCQlyZXR1cm4gc2ItPnNfcWNvcC0+cXVvdGFfc3luYyhzYiwgdHlwZSk7 CiAKQEAgLTE5OCw2ICsyMzIsMjIgQEAgc3RhdGljIGludCBkb19xdW90YWN0 bChzdHJ1Y3Qgc3VwZXJfYmxvYwogCQkJc3RydWN0IGZzX2Rpc2tfcXVvdGEg ZmRxOwogCiAJCQlpZiAoKHJldCA9IHNiLT5zX3Fjb3AtPmdldF94cXVvdGEo c2IsIHR5cGUsIGlkLCAmZmRxKSkpCisJCQkJcmV0dXJuIHJldDsKKwkJCWlm IChjb3B5X3RvX3VzZXIoYWRkciwgJmZkcSwgc2l6ZW9mKGZkcSkpKQorCQkJ CXJldHVybiAtRUZBVUxUOworCQkJcmV0dXJuIDA7CisJCX0KKwkJY2FzZSBR X1hTRVRERUZRTElNOiB7CisJCQlzdHJ1Y3QgZnNfZGlza19xdW90YSBmZHE7 CisKKwkJCWlmIChjb3B5X2Zyb21fdXNlcigmZmRxLCBhZGRyLCBzaXplb2Yo ZmRxKSkpCisJCQkJcmV0dXJuIC1FRkFVTFQ7CisJCSAgICAgICByZXR1cm4g c2ItPnNfcWNvcC0+c2V0X3hkZWZxdW90YShzYiwgdHlwZSwgJmZkcSk7CisJ CX0KKwkJY2FzZSBRX1hHRVRERUZRVU9UQTogeworCQkJc3RydWN0IGZzX2Rp c2tfcXVvdGEgZmRxOworCisJCQlpZiAoKHJldCA9IHNiLT5zX3Fjb3AtPmdl dF94ZGVmcXVvdGEoc2IsIHR5cGUsICZmZHEpKSkKIAkJCQlyZXR1cm4gcmV0 OwogCQkJaWYgKGNvcHlfdG9fdXNlcihhZGRyLCAmZmRxLCBzaXplb2YoZmRx KSkpCiAJCQkJcmV0dXJuIC1FRkFVTFQ7Cg== --=====================_2940037==_-- From owner-linux-xfs@oss.sgi.com Mon Jan 27 07:03:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 07:03:25 -0800 (PST) Received: from voyager.st-peter.stw.uni-erlangen.de (postfix@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RF3C3v007432 for ; Mon, 27 Jan 2003 07:03:14 -0800 Received: from localhost (localhost [127.0.0.1]) by voyager.st-peter.stw.uni-erlangen.de (Postfix) with ESMTP id 8E4FE6DF5; Mon, 27 Jan 2003 16:10:13 +0100 (CET) X-Mailbox-Line: From galia@st-peter.stw.uni-erlangen.de Mon Jan 27 16:10:13 2003 Received: by voyager.st-peter.stw.uni-erlangen.de (Postfix, from userid 33) id BAE006DF7; Mon, 27 Jan 2003 16:10:12 +0100 (CET) To: linux-lvm@sistina.com Subject: Re: [linux-lvm] LVM2 for kernels 2.4.20(another problem raid-0) Message-ID: <1043680212.3e354bd4b18c5@secure.st-peter.stw.uni-erlangen.de> Date: Mon, 27 Jan 2003 16:10:12 +0100 (CET) From: Svetoslav Slavtchev Cc: linux-xfs@oss.sgi.com References: <1043622448.3e346a3057b43@secure.st-peter.stw.uni-erlangen.de> <20030127111301.GD1698@tykepenguin.com> <1043666356.3e3515b44e061@secure.st-peter.stw.uni-erlangen.de> <20030127112714.GE1698@tykepenguin.com> <1043667262.3e35193e470c0@secure.st-peter.stw.uni-erlangen.de> <20030127115012.GG1698@tykepenguin.com> <1043669513.3e3522096e53e@secure.st-peter.stw.uni-erlangen.de> <20030127124956.GI1698@tykepenguin.com> <1043676687.3e353e0f8cf19@secure.st-peter.stw.uni-erlangen.de> In-Reply-To: <1043676687.3e353e0f8cf19@secure.st-peter.stw.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 172.17.17.181 X-Virus-Scanned: by AMaViS snapshot-20020222 X-archive-position: 2433 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: galia@st-peter.stw.uni-erlangen.de Precedence: bulk X-list: linux-xfs Content-Length: 1401 Lines: 54 Quoting Svetoslav Slavtchev : > Quoting Patrick Caulfield : > > > On Mon, Jan 27, 2003 at 01:11:53PM +0100, Svetoslav Slavtchev wrote: > > > Quoting Patrick Caulfield : > > > > > > > On Mon, Jan 27, 2003 at 12:34:22PM +0100, Svetoslav Slavtchev > > wrote: > > > > > > > > > > do you think it's only xfs related, > > > > > if i remmember correctly it's not only xfs problem > > > > > > > > I'm fairly sure it was just XFS. It makes (to us) odd > assumptions > > about > > > > the > > > > alignment of the journal or something. > > > > > i'll check later with reiser and jfs > > > no problems at the first check, > transfered ~10Gb to and from the LV useing jfs and reiser > > but with xfs got this: > mkfs.xfs -- > device-mapper: unknown block ioctl 0x6424 > device-mapper: unknown block ioctl 0x6424 > > and with mount again : > > raid0_make_request bug: can't convert block across chunks or bigger than > 16k > 213164570 4 > raid0_make_request bug: can't convert block across chunks or bigger than > 16k > 213164602 4 > > so let's try the patch :( > > svetljo > > > > may be i should try this patch: > > > > > > http://cgi.cse.unsw.edu.au/~neilb/patches/linux-stable/2.4.leading/2003-01-06:00/015RaidSplit > > > after i check reiser and jfs hm the patch doesn't apply clean, no go what now ? svetljo From owner-linux-xfs@oss.sgi.com Mon Jan 27 08:16:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 08:16:44 -0800 (PST) Received: from sisko.scot.redhat.com (80-195-6-186.cable.ubr04.ed.blueyonder.co.uk [80.195.6.186]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RGGZ3v014787 for ; Mon, 27 Jan 2003 08:16:37 -0800 Received: from sisko.scot.redhat.com (localhost [127.0.0.1]) by sisko.scot.redhat.com (8.12.5/8.12.5) with ESMTP id h0RGN8AY012858; Mon, 27 Jan 2003 16:23:08 GMT Received: (from sct@localhost) by sisko.scot.redhat.com (8.12.5/8.12.5/Submit) id h0RGMQcM012850; Mon, 27 Jan 2003 16:22:26 GMT X-Authentication-Warning: sisko.scot.redhat.com: sct set sender to sct@redhat.com using -f Subject: Re: default quota limits in linux (via quotactl()) From: "Stephen C. Tweedie" To: "Stefan (metze) "Metzmacher Cc: viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com In-Reply-To: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11james) Date: 27 Jan 2003 16:22:26 +0000 Message-Id: <1043684546.12781.1.camel@sisko.scot.redhat.com> Mime-Version: 1.0 X-archive-position: 2434 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sct@redhat.com Precedence: bulk X-list: linux-xfs Content-Length: 787 Lines: 25 Hi, On Mon, 2003-01-27 at 14:41, Stefan (metze) Metzmacher wrote: > I would like linux to handle default quota limits like NTFS 5 do it. > > So if a new user is added to the system and start to own disk space on a > filesystem he > should get the default quotas for the specified FS as his own quotas. That's a user-space problem. A new user typically won't have a writable area within /home until the sysadmin has created the new home directory, so it's really up to the sysadmin to make sure that the quota for the home filesystem has been set at the same time. > I have searched in google to find another unix witch allready implements > this feature, > but I didn't find any. The kernel doesn't need it --- just do it in the user-space user config tool. Cheers, Stephen From owner-linux-xfs@oss.sgi.com Mon Jan 27 14:18:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 14:19:01 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RMIt3v003303 for ; Mon, 27 Jan 2003 14:18:56 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0RKQ4G8021886 for ; Mon, 27 Jan 2003 12:26:04 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA18626; Mon, 27 Jan 2003 16:25:54 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA57585; Mon, 27 Jan 2003 16:25:54 -0600 (CST) Subject: Re: some XFS questions From: Eric Sandeen To: Kwon SoonSon Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030127083818.84351.qmail@web7306.mail.yahoo.co.kr> References: <20030127083818.84351.qmail@web7306.mail.yahoo.co.kr> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 27 Jan 2003 16:22:07 -0600 Message-Id: <1043706127.11527.162.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 2435 X-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: 1298 Lines: 37 On Mon, 2003-01-27 at 02:38, Kwon SoonSon wrote: > 2. in the superblock(xfs_sb), I see "realtime block" > and > "realtime extent". Can anyone please let me know > what the realtime block/extent mean? xfs has a "realtime" feature (somewhat misnamed) where data goes to a different partition, and uses a more deterministic allocator - generally allocates in larger chunks. you do an fcntl on the file to designate it as realtime, then do direct I/O to it. This is still buggy on Linux, and is not supported. See the mkfs.xfs man page for how to make an fs w/ a realtime subvolume. > 3. in xfs_dinode_core, there is di_projid. > What is this for? Irix has the concepts of user, group, and project, I believe. Probably not used on Linux, but retained for on-disk compat. > 4. according to the 1993 design document, the inode > number of xfs_agi used to be devided into 3 parts > but now it is 2 parts. I think this should have some > reasoning but don't know the details. Why? That one is probably lost in the mists of time. Perhaps Steve knows. Actually, I thought that the inode number -was- still 3 parts, for ag #, ag block #, and inode # in that block. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Jan 27 15:02:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 15:02:22 -0800 (PST) Received: from K-7.stesmi.com (root@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RN2I3v004425 for ; Mon, 27 Jan 2003 15:02:19 -0800 Received: from stesmi.com (stesmi@as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.4/8.12.4) with ESMTP id h0RN7T4C023257 for ; Tue, 28 Jan 2003 00:07:29 +0100 Message-ID: <3E35BBB1.1000605@stesmi.com> Date: Tue, 28 Jan 2003 00:07:29 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [ANNOUNCE] RedHat 8.0 XFS DVD v0.0.10 Released Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by K-7.stesmi.com id h0RN7T4C023257 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0RN2K3v004426 X-archive-position: 2436 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 2594 Lines: 64 Hi. A new version of the RedHat 8.0 XFS DVD has been released. It can be fetched from ftp://ftp.uninett.no/pub/linux/RH-XFS-DVD/ It should be up within an hour or so. What's on this DVD: * RedHat 8.0 "Psyche" CDs 1-5, including the SRPMS. * All updates that were released up to and including 2003-01-26 at 20:00 GMT. They are installed automatically when the system is installed. The DVD does not contain the old RPMS. * The installer from the XFS 1.2pre1 release from SGI. * All RPMS from the XFS 1.2pre5 release from SGI. Version history: 0.0.1 2002-12-xx Initial version. Not released. Worked fine. I could even verify the DVD with the MD5 function of the installer. Had the bug that made it ask for the XFS CD after verifying MD5. 0.0.2 2002-12-xx Updated version. Contained a few extra RPMS in the contrib directory. Minor tweaks. Not released. Had a fix for the problem above. 0.0.3 2002-12-xx Same as 0.0.2 but this time I didn't forget to implant the MD5 sum into the image (stupid me). Not released. 0.0.4 2002-12-12 Added latest updates. Verified it works from a DVD-RW. Not released. 0.0.5 2002-12-13 Added latest updates: httpd and mod_ssl. Finished my script that I use to build the DVD with. Not released. 0.0.6 2002-12-18 The ethernet and pcmcia on the laptop died and I had the whole build system on there. Took some time to get the relevant info off of it and start building again. SGI also released 1.2pre4 of the kernel so I updated all files to that. Added updated net-snmp. Not released. 0.0.7 2002-12-20 Found out that the kernel from 1.2pre4 is wrong so I waited for the respin to come out and released it when it had. No other changes. First public release. 0.0.8 2003-01-10 Updated a few RPMs. No other changes. Not really released. 0.0.9 2003-01-15 Updated some more RPMs. Switched to 1.2pre5 from SGI. First public release with new mirror. 0.0.10 2003-01-26 Updated lots of RPMs including MySQL, PostgreSQL, the dhcp server and client and CVS. Thanx must go to: (In no particular order) Nicolai Langfeldt Ragnar Kjørstad George Georgalis Ajay Ramaswamy Russel Cattelan Eric Sandeen Nathan Straz and the rest of the XFS team! This DVD wouldn't have existed without you! // Stefan From owner-linux-xfs@oss.sgi.com Mon Jan 27 15:15:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 15:15:26 -0800 (PST) Received: from mail.qk.com.au (202-44-163-105.nexnet.net.au [202.44.163.105]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0RNFK3v005028 for ; Mon, 27 Jan 2003 15:15:22 -0800 Received: from amavis by mail.qk.com.au with scanned-ok (Exim 3.35 #1 (Debian)) id 18dIa6-0002Rb-00 for ; Tue, 28 Jan 2003 10:22:22 +1100 Received: from juno ([10.0.0.79] ident=mail) by mail.qk.com.au with esmtp (Exim 3.35 #1 (Debian)) id 18dIa5-0002RS-00 for ; Tue, 28 Jan 2003 10:22:21 +1100 Received: from lbarbuto by juno with local (Exim 3.36 #1 (Debian)) id 18dIa5-0005bG-00 for ; Tue, 28 Jan 2003 10:22:21 +1100 Date: Tue, 28 Jan 2003 10:22:21 +1100 From: Lucas Barbuto To: Linux XFS Mailing List Subject: Problems mounting an ext3 filesystem with XFS kernel Message-ID: <20030127232221.GA21514@qk.com.au> Reply-To: Lucas Barbuto Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS perl-11 X-archive-position: 2437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lucas@qk.com.au Precedence: bulk X-list: linux-xfs Content-Length: 2360 Lines: 60 Hi Seth and Harri, On Fri, Jan 24, 2003 at 10:05:42AM +0100, Seth Mos wrote: > What Raid level are you using? You can only boot a software raid 1 array. Yes RAID-1. > What do the first KB of the filesystem show? > dd if=/dev/hdeX of=bootblock.bin bs=512 count=4 Oops, don't know, I just zeroed out the whole disk over the weekend. I'll check it out after my next attempt. > You did actually partition the disk did you? Yep. Both exactly the same. I didn't create a seperate /boot though. Could this be a problem? I've never had to do it on any machine I've installed before. I'm going to try it, see if it helps (?). > I'm assuming that you are trying to boot from the root disk which would be > a raid 1. Yes. It's /dev/md1. > When installing lilo it should print out 2 lines where it installs itself > on both disks in the superblock. Yes, that's right, it gives me a warning about using 0x80 for the disk (I don't really get this, but I assume it's not a problem) then it says it's successfully installed in /dev/md1, /dev/hde and /dev/hdg. > I personally find this howto useful with respect to this. > http://ldp.iserv.nl/HOWTO/Software-RAID-HOWTO-4.html#ss4.14 I've read a bunch of RAID howtos (even written my own so I wouldn't forget how to do it again), but this error has got me stumped. Thanks for your help I will keep trying. Harri Haataja wrote: > little long shot here, but did you make a new initrd at what points? > I'm not sure but I think the actual root filesystem type is mentioned > somewhere on the initrd and you have to make a new one if it's > changed. I don't really know much about initrd (my understanding is that it's a minimal kernel image that's loaded onto a ram disk for booting the system so that you can have essential things like file system support compiled as modules). I'm pretty sure I'm not using it though. I rebuilt my new kernel using Debian's kernel-package tool (make-kpkg). I don't think it uses initrd. In any case, the root file system shouldn't have changed, my original install was onto ext2 and the new system is supposed to have an ext3 root partition, should be the same for all intents and purposes, correct? Feel free to correct me here. Do I need to use initrd? I didn't use one for the last system I installed a Boot+Root+Software-RAID on. Thanks again. Regards, Lucas From owner-linux-xfs@oss.sgi.com Mon Jan 27 15:44:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 15:44:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0RNiE3v005671 for ; Mon, 27 Jan 2003 15:44:14 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0RNiEi0005670 for linux-xfs@oss.sgi.com; Mon, 27 Jan 2003 15:44:14 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0RNiB3x005656 for ; Mon, 27 Jan 2003 15:44:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0RNMTwp005535; Mon, 27 Jan 2003 15:22:29 -0800 Date: Mon, 27 Jan 2003 15:22:29 -0800 Message-Id: <200301272322.h0RNMTwp005535@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 212] New: Problem compiling acl-2.0.9: undefined reference to `getxattr' X-Bugzilla-Reason: AssignedTo X-archive-position: 2438 X-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: 1324 Lines: 39 http://oss.sgi.com/bugzilla/show_bug.cgi?id=212 Summary: Problem compiling acl-2.0.9: undefined reference to `getxattr' Product: Linux XFS Version: 1.1.x Platform: IA32 OS/Version: Linux Status: NEW Severity: minor Priority: Low Component: xfsdump AssignedTo: xfs-master@oss.sgi.com ReportedBy: mario@klebsch.de Description of Problem: I have configured attr-2.0.7 and dmapi-2.0.3 to not build a shared library (configure --disble-shared). libattr.a and libdm.a were installed succesfully in /usr/lib. When linking the programs in acl-2.0.9, I get an error, that getxattr is undefined. It turned out, that in acl-2.0.9/chacl/Makefile acl-2.0.9/setfacl/Makefile acl-2.0.9/getfacl/Makefile the reuired libs are given in the wrong order. I had to change the definition of LLDLIBS to look like this. LLDLIBS = $(LIBACL) $(LIBATTR) The libraries are given in the opposite order, but libacl.a depends on libattr.a. It does not matter when linking dynamically, but the static linker does not tie the required modules into the binary, when the order is not Ok. 73, Mario ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 27 20:14:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 20:14:20 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0S4EE3v007779 for ; Mon, 27 Jan 2003 20:14:14 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0S4EEG5007778 for linux-xfs@oss.sgi.com; Mon, 27 Jan 2003 20:14:14 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id h0S4EB3x007762 for ; Mon, 27 Jan 2003 20:14:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.5/Submit) id h0S3qMYF007589; Mon, 27 Jan 2003 19:52:22 -0800 Date: Mon, 27 Jan 2003 19:52:22 -0800 Message-Id: <200301280352.h0S3qMYF007589@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 212] Problem compiling acl-2.0.9: undefined reference to `getxattr' X-Bugzilla-Reason: AssignedTo X-archive-position: 2439 X-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: 692 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=212 ------- Additional Comments From sandeen@sgi.com 2003-01-27 19:52 ------- Can you verify that this is still a problem? You tested 2.0.9, but the latest version is 2.2.2. The Makefiles still have the "wrong" order so it's probably still a problem, but if you could verify, that would help. Also, Nathan (our acl/attr guru) is out for a while, but I'm sure he'll be interested in this when he comes back. I'll let him make the change because I'm not quite sure how we sync up with Andreas on acl changes. -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jan 27 22:36:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 22:36:49 -0800 (PST) Received: from fwd1.mx.base (p508D773A.dip.t-dialin.net [80.141.119.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0S6aW3v013657 for ; Mon, 27 Jan 2003 22:36:33 -0800 Received: from metze-xp.mx.base (unknown [192.168.0.3]) by fwd1.mx.base (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 0E90673205; Tue, 28 Jan 2003 07:43:30 +0100 (CET) Message-Id: <5.2.0.9.2.20030128072705.02186d18@post.webmailer.de> X-Sender: lists%metzemix.de@post.webmailer.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Jan 2003 07:43:30 +0100 To: "Stephen C. Tweedie" From: "Stefan (metze) Metzmacher" Subject: Re: default quota limits in linux (via quotactl()) Cc: viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy In-Reply-To: <1043684546.12781.1.camel@sisko.scot.redhat.com> References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2440 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: metze@metzemix.de Precedence: bulk X-list: linux-xfs Content-Length: 1748 Lines: 50 At 16:22 27.01.2003 +0000, Stephen C. Tweedie wrote: >Hi, > >On Mon, 2003-01-27 at 14:41, Stefan (metze) Metzmacher wrote: > > > I would like linux to handle default quota limits like NTFS 5 do it. > > > > So if a new user is added to the system and start to own disk space on a > > filesystem he > > should get the default quotas for the specified FS as his own quotas. > >That's a user-space problem. A new user typically won't have a writable >area within /home until the sysadmin has created the new home directory, >so it's really up to the sysadmin to make sure that the quota for the >home filesystem has been set at the same time. what is with a filesystem in witch the user has write access because of group memberships. or/and the user's/group's are stored in LDAP: then user are added directly to the LDAP diretory and they maybe available on a large amount of servers and it's a pain to manage the quotas for each filesystem on each server. also it's hard to handle changed group memberships... I think there's a good reason that NTFS 5 support default quota limits. And it would be cool if linux would support them too. it's not hard to implement and it would make thinks much easier to handle in large environments! > > I have searched in google to find another unix witch allready implements > > this feature, > > but I didn't find any. > >The kernel doesn't need it --- just do it in the user-space user config >tool There're many things, witch are not inevitable needed in the kernel, but they all make the life easier. Would it really hurt that much if the kernel would support it? metze ----------------------------------------------------------------------------- Stefan "metze" Metzmacher From owner-linux-xfs@oss.sgi.com Mon Jan 27 22:47:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Jan 2003 22:47:17 -0800 (PST) Received: from fwd1.mx.base (p508D773A.dip.t-dialin.net [80.141.119.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0S6l83v014162 for ; Mon, 27 Jan 2003 22:47:09 -0800 Received: from metze-xp.mx.base (unknown [192.168.0.3]) by fwd1.mx.base (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 28DD973205; Tue, 28 Jan 2003 07:54:08 +0100 (CET) Message-Id: <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> X-Sender: lists%metzemix.de@post.webmailer.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Jan 2003 07:54:08 +0100 To: "Stephen C. Tweedie" , "Stefan (metze) " Metzmacher From: "Stefan (metze) Metzmacher" Subject: Re: default quota limits in linux (via quotactl()) Cc: viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy In-Reply-To: <1043684546.12781.1.camel@sisko.scot.redhat.com> References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2441 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: metze@metzemix.de Precedence: bulk X-list: linux-xfs Content-Length: 1074 Lines: 28 At 16:22 27.01.2003 +0000, Stephen C. Tweedie wrote: >That's a user-space problem. A new user typically won't have a writable >area within /home until the sysadmin has created the new home directory, >so it's really up to the sysadmin to make sure that the quota for the >home filesystem has been set at the same time. What is if we have 500.000 users and 300.000 group in LDAP and set up a new server, witch is intended to store data from ~1000 users 500 group should the admin really run setquota ... for each of the 500.000 users and 300.000 group that's are 800.000 quota entries in the filesystem and only 1500 are really used ans this entries cost disk space too, so if we have two default entries (one for users and one for groups) then only every user witch really uses this filesystem would get a quota entry when he starts to own diskspace on this filesystem and we would have only 1502 quota entries stored on disk! metze ----------------------------------------------------------------------------- Stefan "metze" Metzmacher From owner-linux-xfs@oss.sgi.com Tue Jan 28 00:39:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 00:39:58 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0S8ds3v015495 for ; Tue, 28 Jan 2003 00:39:55 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0S8kmUo095094; Tue, 28 Jan 2003 09:46:59 +0100 (CET) Message-Id: <4.3.2.7.2.20030128092913.03287490@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Jan 2003 09:46:39 +0100 To: Lucas Barbuto , Linux XFS Mailing List From: Seth Mos Subject: Re: Problems mounting an ext3 filesystem with XFS kernel In-Reply-To: <20030127232221.GA21514@qk.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2442 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 3422 Lines: 102 At 10:22 28-1-2003 +1100, Lucas Barbuto wrote: >Hi Seth and Harri, > >Yep. Both exactly the same. I didn't create a seperate /boot though. >Could this be a problem? I've never had to do it on any machine I've >installed before. I'm going to try it, see if it helps (?). That won't matter. >Yes. It's /dev/md1. not /dev/md0 ?? > > When installing lilo it should print out 2 lines where it installs itself > > on both disks in the superblock. > >Yes, that's right, it gives me a warning about using 0x80 for the disk That means that linux detects the disk in a different way then your bios does. You can correct this with a line in your lilo.conf. It might be related to your booting problem. If you say that the boot drive is hda, which would correspond with what the bios thinks. However when the kernel boots the first disk is detected as hde and it can get confused at this point. My lilo.conf contains. boot=/dev/hde map=/boot/map install=/boot/boot.b prompt timeout=50 linear default=2418-rht-1.2 vga=0x430 message=/boot/message image=/boot/vmlinuz-2.4.18-19-xfs-1.2pre5 label=2418-rht-1.2 read-only root=/dev/hde1 This machine has the onboard IDE deactivated as well as your system and thus hda does not exist so I changed the boot line. Subsequent lilo does not give me a line saying it's confused about where the disk should be. >(I don't really get this, but I assume it's not a problem) then it says >it's successfully installed in /dev/md1, /dev/hde and /dev/hdg. >Harri Haataja wrote: > > little long shot here, but did you make a new initrd at what points? > > I'm not sure but I think the actual root filesystem type is mentioned > > somewhere on the initrd and you have to make a new one if it's > > changed. > >I don't really know much about initrd (my understanding is that it's a >minimal kernel image that's loaded onto a ram disk for booting the >system so that you can have essential things like file system support >compiled as modules). I'm pretty sure I'm not using it though. I >rebuilt my new kernel using Debian's kernel-package tool (make-kpkg). You could check either the kernel config or a initrd image file in your /boot/ If that's where debian places the kernels. You can always make one, it doesn't hurt either way. mkinitrd 2.4.18-xfs /boot/initrd-2.4.18-xfs.img IIRC, don't forget to enter a initrd line in your lilo.conf as well! > I >don't think it uses initrd. In any case, the root file system shouldn't >have changed, my original install was onto ext2 and the new system is >supposed to have an ext3 root partition, should be the same for all >intents and purposes, correct? Feel free to correct me here. Do I need >to use initrd? I didn't use one for the last system I installed a >Boot+Root+Software-RAID on. Thanks again. You can always check though. I forgot to compile in the md drivers once and put a box 150Km (~100Miles) away out of service. If you are making a ext3 filesystem on the drive don't forget to make the journal after formatting is as ext2. If I understand what you are trying to do you want to format the / partition with ext3 and leave the rest XFS? If that is so format /dev/md1 with ext2 mkfs.ext2 /dev/md1 Create the ext3 journal ontop of it. tune2fs -j /dev/md1 Now you should be able to mount the / as ext3. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Jan 28 01:26:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 01:26:39 -0800 (PST) Received: from pop3.netroute.cz (ns1.netroute.cz [212.71.168.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0S9QR3v016411 for ; Tue, 28 Jan 2003 01:26:29 -0800 Received: (qmail 2764 invoked from network); 28 Jan 2003 09:33:28 -0000 Received: from unknown (HELO vagabond.cybernet.cz) (212.71.168.94) by ns1.netroute.cz with SMTP; 28 Jan 2003 09:33:28 -0000 Received: from bulb by vagabond.cybernet.cz with local (Exim 3.36 #1 (Debian)) id 18dS6t-0006VP-00; Tue, 28 Jan 2003 10:32:51 +0100 Date: Tue, 28 Jan 2003 10:32:50 +0100 From: Jan Hudec To: "Stefan (metze) Metzmacher" Cc: "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy Subject: Re: default quota limits in linux (via quotactl()) Message-ID: <20030128093250.GM28513@vagabond> Mail-Followup-To: Jan Hudec , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> User-Agent: Mutt/1.4i X-archive-position: 2443 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bulb@ucw.cz Precedence: bulk X-list: linux-xfs Content-Length: 1467 Lines: 32 On Tue, Jan 28, 2003 at 07:54:08AM +0100, Stefan (metze) Metzmacher wrote: > At 16:22 27.01.2003 +0000, Stephen C. Tweedie wrote: > >That's a user-space problem. A new user typically won't have a writable > >area within /home until the sysadmin has created the new home directory, > >so it's really up to the sysadmin to make sure that the quota for the > >home filesystem has been set at the same time. > > What is if we have 500.000 users and 300.000 group in LDAP > > and set up a new server, witch is intended to store data from ~1000 users > 500 group > > should the admin really run setquota ... for each of the 500.000 users and > 300.000 group > > that's are 800.000 quota entries in the filesystem and only 1500 are really > used > > ans this entries cost disk space too, so if we have two default entries > (one for users and one for groups) then only every user witch really uses > this filesystem would get a quota entry when he starts to own diskspace on > this filesystem and we would have only 1502 quota entries stored on disk! It still isn't a kernel problem, but a user-space one. You need to get or write a PAM module, that will check wether quotas are set for user being authenticated and if not, set them. You could even store the qutoas in the LDAP (or some other) database and check them when a user logs in... ------------------------------------------------------------------------------- Jan 'Bulb' Hudec From owner-linux-xfs@oss.sgi.com Tue Jan 28 01:33:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 01:33:16 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0S9X83v016877 for ; Tue, 28 Jan 2003 01:33:10 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 53FFD1855104; Tue, 28 Jan 2003 01:40:14 -0800 (PST) Date: Tue, 28 Jan 2003 01:40:14 -0800 From: Chris Wedgwood To: Jan Hudec , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy Subject: Re: default quota limits in linux (via quotactl()) Message-ID: <20030128094014.GA23257@f00f.org> References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030128093250.GM28513@vagabond> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2444 X-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: 584 Lines: 18 On Tue, Jan 28, 2003 at 10:32:50AM +0100, Jan Hudec wrote: > It still isn't a kernel problem, but a user-space one. You need to > get or write a PAM module, that will check wether quotas are set for > user being authenticated and if not, set them. You could even store > the qutoas in the LDAP (or some other) database and check them when > a user logs in... consider 1 million users where only a small percentage of them will ever write to the fs ... why even store 1 million quota values needlessly at all? surely the argument for a default here isn't a terrible one? --cw From owner-linux-xfs@oss.sgi.com Tue Jan 28 01:39:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 01:39:47 -0800 (PST) Received: from pop3.netroute.cz (ns1.netroute.cz [212.71.168.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0S9dh3v017366 for ; Tue, 28 Jan 2003 01:39:44 -0800 Received: (qmail 2951 invoked from network); 28 Jan 2003 09:46:45 -0000 Received: from unknown (HELO vagabond.cybernet.cz) (212.71.168.94) by ns1.netroute.cz with SMTP; 28 Jan 2003 09:46:45 -0000 Received: from bulb by vagabond.cybernet.cz with local (Exim 3.36 #1 (Debian)) id 18dSJv-0006XX-00; Tue, 28 Jan 2003 10:46:19 +0100 Date: Tue, 28 Jan 2003 10:46:19 +0100 From: Jan Hudec To: Chris Wedgwood Cc: Jan Hudec , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy Subject: Re: default quota limits in linux (via quotactl()) Message-ID: <20030128094619.GO28513@vagabond> Mail-Followup-To: Jan Hudec , Chris Wedgwood , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030128094014.GA23257@f00f.org> User-Agent: Mutt/1.4i X-archive-position: 2445 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bulb@ucw.cz Precedence: bulk X-list: linux-xfs Content-Length: 902 Lines: 22 On Tue, Jan 28, 2003 at 01:40:14AM -0800, Chris Wedgwood wrote: > On Tue, Jan 28, 2003 at 10:32:50AM +0100, Jan Hudec wrote: > > > It still isn't a kernel problem, but a user-space one. You need to > > get or write a PAM module, that will check wether quotas are set for > > user being authenticated and if not, set them. You could even store > > the qutoas in the LDAP (or some other) database and check them when > > a user logs in... > > consider 1 million users where only a small percentage of them will > ever write to the fs ... why even store 1 million quota values > needlessly at all? While all the 1 milion users actualy ever LOG IN that site? And... do they ever log into that site AT THE SAME MOMENT? > surely the argument for a default here isn't a terrible one? ------------------------------------------------------------------------------- Jan 'Bulb' Hudec From owner-linux-xfs@oss.sgi.com Tue Jan 28 01:58:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 01:58:24 -0800 (PST) Received: from silver.digirati.com.br (silver.digirati.com.br [200.185.109.126]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0S9wH3v017967 for ; Tue, 28 Jan 2003 01:58:19 -0800 Received: from wsmichel (RJ227203.user.veloxzone.com.br [200.165.227.203]) (authenticated (0 bits)) by silver.digirati.com.br (8.11.6/8.11.6) with ESMTP id h0SA5LC05117 for ; Tue, 28 Jan 2003 08:05:21 -0200 Message-ID: <005901c2c6b4$c7019da0$1601070a@mz.digirati.com.br> From: "Michel Machado" To: References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> <20030128094619.GO28513@vagabond> Subject: Re: default quota limits in linux (via quotactl()) Date: Tue, 28 Jan 2003 08:05:20 -0200 Organization: Digirati MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 2446 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michel@digirati.com.br Precedence: bulk X-list: linux-xfs Content-Length: 172 Lines: 11 Hi, | While all the 1 milion users actualy ever LOG IN that site? Is the uidNumber e gidNumber unsigned 16 bits? 2^16 = 65536 < 1.000.000 [ ]'s Michel Machado From owner-linux-xfs@oss.sgi.com Tue Jan 28 02:06:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 02:06:06 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SA633v018604 for ; Tue, 28 Jan 2003 02:06:03 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 61F411855132; Tue, 28 Jan 2003 02:13:10 -0800 (PST) Date: Tue, 28 Jan 2003 02:13:10 -0800 From: Chris Wedgwood To: Jan Hudec , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy Subject: Re: default quota limits in linux (via quotactl()) Message-ID: <20030128101310.GA23320@f00f.org> References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> <20030128094619.GO28513@vagabond> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030128094619.GO28513@vagabond> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2447 X-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: 381 Lines: 17 On Tue, Jan 28, 2003 at 10:46:19AM +0100, Jan Hudec wrote: > While all the 1 milion users actualy ever LOG IN that site? what? consider a mail server (or series thereof) and quota for mail... > And... do they ever log into that site AT THE SAME MOMENT? presumably not ... most machines only allow 995,000 simultaneous logins unless you have an extra 2M in your 386 --cw From owner-linux-xfs@oss.sgi.com Tue Jan 28 02:51:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 02:51:14 -0800 (PST) Received: from pop3.netroute.cz (ns1.netroute.cz [212.71.168.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SAp33v021691 for ; Tue, 28 Jan 2003 02:51:06 -0800 Received: (qmail 3784 invoked from network); 28 Jan 2003 10:58:05 -0000 Received: from unknown (HELO vagabond.cybernet.cz) (212.71.168.94) by ns1.netroute.cz with SMTP; 28 Jan 2003 10:58:05 -0000 Received: from bulb by vagabond.cybernet.cz with local (Exim 3.36 #1 (Debian)) id 18dTR5-0006hI-00; Tue, 28 Jan 2003 11:57:47 +0100 Date: Tue, 28 Jan 2003 11:57:47 +0100 From: Jan Hudec To: Chris Wedgwood Cc: Jan Hudec , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy Subject: Re: default quota limits in linux (via quotactl()) Message-ID: <20030128105747.GR28513@vagabond> Mail-Followup-To: Jan Hudec , Chris Wedgwood , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> <20030128094619.GO28513@vagabond> <20030128101310.GA23320@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030128101310.GA23320@f00f.org> User-Agent: Mutt/1.4i X-archive-position: 2448 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bulb@ucw.cz Precedence: bulk X-list: linux-xfs Content-Length: 871 Lines: 25 On Tue, Jan 28, 2003 at 02:13:10AM -0800, Chris Wedgwood wrote: > On Tue, Jan 28, 2003 at 10:46:19AM +0100, Jan Hudec wrote: > > > While all the 1 milion users actualy ever LOG IN that site? > > what? So you can only setquota for the users that actualy log in. > consider a mail server (or series thereof) and quota for mail... Well, it get's complicated, but you still can setquota in the local delivery process... I know it get's a bit complicated... > > And... do they ever log into that site AT THE SAME MOMENT? > > presumably not ... most machines only allow 995,000 simultaneous > logins unless you have an extra 2M in your 386 Because you could remove the quotas again for users, that logged in, but their quota is still the default... ------------------------------------------------------------------------------- Jan 'Bulb' Hudec From owner-linux-xfs@oss.sgi.com Tue Jan 28 03:13:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 03:13:30 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SBDR3v022455 for ; Tue, 28 Jan 2003 03:13:28 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id E0A401855132; Tue, 28 Jan 2003 03:20:34 -0800 (PST) Date: Tue, 28 Jan 2003 03:20:34 -0800 From: Chris Wedgwood To: Jan Hudec , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy Subject: Re: default quota limits in linux (via quotactl()) Message-ID: <20030128112034.GA23731@f00f.org> References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> <20030128094619.GO28513@vagabond> <20030128101310.GA23320@f00f.org> <20030128105747.GR28513@vagabond> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030128105747.GR28513@vagabond> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2449 X-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: 411 Lines: 17 On Tue, Jan 28, 2003 at 11:57:47AM +0100, Jan Hudec wrote: > So you can only setquota for the users that actualy log in the API allows you to set quota for any valid uid/gid > Well, it get's complicated, but you still can setquota in the local > delivery process... I know it get's a bit complicated... sure, this is a perfectly legitimate argument and a fairly reasonable solution to this case --cw From owner-linux-xfs@oss.sgi.com Tue Jan 28 03:15:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 03:15:44 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [202.49.232.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SBFg3v022877 for ; Tue, 28 Jan 2003 03:15:42 -0800 Received: by tapu.f00f.org (Postfix, from userid 10000) id 467401855132; Tue, 28 Jan 2003 03:22:49 -0800 (PST) Date: Tue, 28 Jan 2003 03:22:49 -0800 From: Chris Wedgwood To: Michel Machado Cc: linux-xfs@oss.sgi.com Subject: Re: default quota limits in linux (via quotactl()) Message-ID: <20030128112249.GA23758@f00f.org> References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> <20030128094619.GO28513@vagabond> <005901c2c6b4$c7019da0$1601070a@mz.digirati.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005901c2c6b4$c7019da0$1601070a@mz.digirati.com.br> User-Agent: Mutt/1.3.28i X-No-Archive: Yes X-archive-position: 2450 X-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: 212 Lines: 13 On Tue, Jan 28, 2003 at 08:05:20AM -0200, Michel Machado wrote: > 2^16 = 65536 < 1.000.000 uid/gids are 32-bit now: demo@charon:~$ id uid=20000000(demo) gid=20000000(demo) groups=20000000(demo) --cw From owner-linux-xfs@oss.sgi.com Tue Jan 28 04:30:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 04:30:41 -0800 (PST) Received: from pop3.netroute.cz (ns1.netroute.cz [212.71.168.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SCUV3v000387 for ; Tue, 28 Jan 2003 04:30:33 -0800 Received: (qmail 5020 invoked from network); 28 Jan 2003 12:37:33 -0000 Received: from unknown (HELO vagabond.cybernet.cz) (212.71.168.94) by ns1.netroute.cz with SMTP; 28 Jan 2003 12:37:33 -0000 Received: from bulb by vagabond.cybernet.cz with local (Exim 3.36 #1 (Debian)) id 18dUzO-0006rj-00; Tue, 28 Jan 2003 13:37:18 +0100 Date: Tue, 28 Jan 2003 13:37:18 +0100 From: Jan Hudec To: Chris Wedgwood Cc: Jan Hudec , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy Subject: Re: default quota limits in linux (via quotactl()) Message-ID: <20030128123718.GT28513@vagabond> Mail-Followup-To: Jan Hudec , Chris Wedgwood , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy References: <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> <20030128094619.GO28513@vagabond> <20030128101310.GA23320@f00f.org> <20030128105747.GR28513@vagabond> <20030128112034.GA23731@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030128112034.GA23731@f00f.org> User-Agent: Mutt/1.4i X-archive-position: 2451 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bulb@ucw.cz Precedence: bulk X-list: linux-xfs Content-Length: 1323 Lines: 30 On Tue, Jan 28, 2003 at 03:20:34AM -0800, Chris Wedgwood wrote: > On Tue, Jan 28, 2003 at 11:57:47AM +0100, Jan Hudec wrote: > > > So you can only setquota for the users that actualy log in > > the API allows you to set quota for any valid uid/gid Yes, it does. But since there is many more valid users than those actualy using the system, you don't want to... And a logged in user is sure valid, so no problem there, right? > > Well, it get's complicated, but you still can setquota in the local > > delivery process... I know it get's a bit complicated... > > sure, this is a perfectly legitimate argument and a fairly reasonable > solution to this case If it finaly got too complicated, you could add a simple code to kernel, that would run_usermodehelper and provide a user mode program to fix things up. That might even get a chance of being accepted. (And it would be more flexible since it can get the default quota from LDAP etc...) However as long as it's manageable in userspace, do it in userspace... All services that log in users can use PAM nowadays, so there it is quite easy and all services that can run on behalf of users have some hooks where the fixup command can be run too. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec From owner-linux-xfs@oss.sgi.com Tue Jan 28 05:28:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 05:28:39 -0800 (PST) Received: from fwd1.mx.base (p508D773A.dip.t-dialin.net [80.141.119.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SDSS3v021622 for ; Tue, 28 Jan 2003 05:28:30 -0800 Received: from metze-xp.mx.base (unknown [192.168.0.3]) by fwd1.mx.base (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 21E8371BD5; Tue, 28 Jan 2003 14:35:29 +0100 (CET) Message-Id: <5.2.0.9.2.20030128142729.0218f398@post.webmailer.de> X-Sender: lists%metzemix.de@post.webmailer.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Jan 2003 14:32:30 +0100 To: Jan Hudec , Chris Wedgwood From: "Stefan (metze) Metzmacher" Subject: Re: default quota limits in linux (via quotactl()) Cc: Jan Hudec , "Stefan (metze) Metzmacher" , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy In-Reply-To: <20030128123718.GT28513@vagabond> References: <20030128112034.GA23731@f00f.org> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> <20030128094619.GO28513@vagabond> <20030128101310.GA23320@f00f.org> <20030128105747.GR28513@vagabond> <20030128112034.GA23731@f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2452 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: metze@metzemix.de Precedence: bulk X-list: linux-xfs Content-Length: 1495 Lines: 39 At 13:37 28.01.2003 +0100, Jan Hudec wrote: >On Tue, Jan 28, 2003 at 03:20:34AM -0800, Chris Wedgwood wrote: > > On Tue, Jan 28, 2003 at 11:57:47AM +0100, Jan Hudec wrote: > > > > > So you can only setquota for the users that actualy log in > > > > the API allows you to set quota for any valid uid/gid > >Yes, it does. But since there is many more valid users than those >actualy using the system, you don't want to... And a logged in user is >sure valid, so no problem there, right? > > > > Well, it get's complicated, but you still can setquota in the local > > > delivery process... I know it get's a bit complicated... > > > > sure, this is a perfectly legitimate argument and a fairly reasonable > > solution to this case > >If it finaly got too complicated, you could add a simple code to kernel, >that would run_usermodehelper and provide a user mode program to fix >things up. That might even get a chance of being accepted. (And it would >be more flexible since it can get the default quota from LDAP etc...) is there an example( another place in the kernel where the kernel callback a userspace tool) can you point me to the place (the function) where the quota entry/object will be created for new users, so this should be the location where the userspace tool should be callback... that would be a cool solution, witch I could accept too:-) metze ----------------------------------------------------------------------------- Stefan "metze" Metzmacher From owner-linux-xfs@oss.sgi.com Tue Jan 28 06:28:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 06:28:18 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SES83v025808 for ; Tue, 28 Jan 2003 06:28:08 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0SDfnKp026945 for ; Tue, 28 Jan 2003 05:41:50 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA98709 for ; Tue, 28 Jan 2003 08:35:09 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA46556 for ; Tue, 28 Jan 2003 08:35:08 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h0SLn9N25027 for linux-xfs@oss.sgi.com; Tue, 28 Jan 2003 16:49:09 -0500 Resent-Message-Id: <200301282149.h0SLn9N25027@taclab54.munich.sgi.com> Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA09623 for ; Tue, 28 Jan 2003 08:34:26 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h0SLmQx25020 for hch@sgi.com; Tue, 28 Jan 2003 16:48:26 -0500 Date: Tue, 28 Jan 2003 16:48:26 -0500 From: Christoph Hellwig Message-Id: <200301282148.h0SLmQx25020@taclab54.munich.sgi.com> Subject: TAKE - fix sys_sync() Resent-From: hch@sgi.com Resent-Date: Tue, 28 Jan 2003 16:49:09 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2453 X-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: 415 Lines: 15 This fix is also in 2.5.59-mm6 and needed to survive fsstress load as in cmd/xfstests/013. Date: Tue Jan 28 06:30:17 PST 2003 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:137920a linux/fs/fs-writeback.c - 1.12 - revert a check in __mark_inode_dirty() to the pre-2.5.52 version From owner-linux-xfs@oss.sgi.com Tue Jan 28 07:11:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 07:11:53 -0800 (PST) Received: from waltsathlon.localhost.net (12-229-130-237.client.attbi.com [12.229.130.237]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SFBh3v032528 for ; Tue, 28 Jan 2003 07:11:43 -0800 Received: from comcast.net (localhost.localhost.net [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 5F6671C31BE0; Tue, 28 Jan 2003 07:18:43 -0800 (PST) Message-ID: <3E369F52.7050901@comcast.net> Date: Tue, 28 Jan 2003 07:18:42 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030121 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Stefan (metze) Metzmacher" Cc: Jan Hudec , Chris Wedgwood , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy Subject: Re: default quota limits in linux (via quotactl()) References: <20030128112034.GA23731@f00f.org> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> <20030128094619.GO28513@vagabond> <20030128101310.GA23320@f00f.org> <20030128105747.GR28513@vagabond> <20030128112034.GA23731@f00f.org> <5.2.0.9.2.20030128142729.0218f398@post.webmailer.de> In-Reply-To: <5.2.0.9.2.20030128142729.0218f398@post.webmailer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2454 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: waltabbyh@comcast.net Precedence: bulk X-list: linux-xfs Content-Length: 1832 Lines: 52 I believe that the hotplug stuff does this. When a new hotpluggable pci, usb etc... device is plugged into the system, it triggers /sbin/hotplug to run to look for the appropriate kernel module to provide a driver. -Walt Stefan (metze) Metzmacher wrote: > At 13:37 28.01.2003 +0100, Jan Hudec wrote: > >> On Tue, Jan 28, 2003 at 03:20:34AM -0800, Chris Wedgwood wrote: >> > On Tue, Jan 28, 2003 at 11:57:47AM +0100, Jan Hudec wrote: >> > >> > > So you can only setquota for the users that actualy log in >> > >> > the API allows you to set quota for any valid uid/gid >> >> Yes, it does. But since there is many more valid users than those >> actualy using the system, you don't want to... And a logged in user is >> sure valid, so no problem there, right? >> >> > > Well, it get's complicated, but you still can setquota in the local >> > > delivery process... I know it get's a bit complicated... >> > >> > sure, this is a perfectly legitimate argument and a fairly reasonable >> > solution to this case >> >> If it finaly got too complicated, you could add a simple code to kernel, >> that would run_usermodehelper and provide a user mode program to fix >> things up. That might even get a chance of being accepted. (And it would >> be more flexible since it can get the default quota from LDAP etc...) > > > is there an example( another place in the kernel where the kernel > callback a userspace tool) > > can you point me to the place (the function) where the quota > entry/object will be created for new users, > so this should be the location where the userspace tool should be > callback... > > that would be a cool solution, witch I could accept too:-) > > > > > metze > ----------------------------------------------------------------------------- > > Stefan "metze" Metzmacher > From owner-linux-xfs@oss.sgi.com Tue Jan 28 07:21:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 07:21:03 -0800 (PST) Received: from fwd1.mx.base (p508D773A.dip.t-dialin.net [80.141.119.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SFKt3v000997 for ; Tue, 28 Jan 2003 07:20:57 -0800 Received: from metze-xp.mx.base (unknown [192.168.0.3]) by fwd1.mx.base (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 70A9B71BD5; Tue, 28 Jan 2003 16:27:54 +0100 (CET) Message-Id: <5.2.0.9.2.20030128162412.02186a38@post.webmailer.de> X-Sender: mx%metzemix.de@post.webmailer.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Jan 2003 16:27:56 +0100 To: Walt H From: Stefan Metzmacher Subject: Re: default quota limits in linux (via quotactl()) Cc: Jan Hudec , Chris Wedgwood , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy In-Reply-To: <3E369F52.7050901@comcast.net> References: <5.2.0.9.2.20030128142729.0218f398@post.webmailer.de> <20030128112034.GA23731@f00f.org> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> <20030128094619.GO28513@vagabond> <20030128101310.GA23320@f00f.org> <20030128105747.GR28513@vagabond> <20030128112034.GA23731@f00f.org> <5.2.0.9.2.20030128142729.0218f398@post.webmailer.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2455 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stefan.metzmacher@metzemix.de Precedence: bulk X-list: linux-xfs Content-Length: 1263 Lines: 34 At 07:18 28.01.2003 -0800, Walt H wrote: >I believe that the hotplug stuff does this. When a new hotpluggable pci, >usb etc... device is plugged into the system, it triggers /sbin/hotplug to >run to look for the appropriate kernel module to provide a driver. I'll look at this... is get_empty_dquot() or dqget() the right place to callback the user space tool? >>>If it finaly got too complicated, you could add a simple code to kernel, >>>that would run_usermodehelper and provide a user mode program to fix >>>things up. That might even get a chance of being accepted. (And it would >>>be more flexible since it can get the default quota from LDAP etc...) >> >>is there an example( another place in the kernel where the kernel >>callback a userspace tool) >>can you point me to the place (the function) where the quota entry/object >>will be created for new users, >>so this should be the location where the userspace tool should be callback... >>that would be a cool solution, witch I could accept too:-) >> >> >>metze >>----------------------------------------------------------------------------- >> >>Stefan "metze" Metzmacher ----------------------------------------------- Stefan Metzmacher stefan.metzmacher@metzemix.de From owner-linux-xfs@oss.sgi.com Tue Jan 28 09:19:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 09:20:11 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SHJw3v003917 for ; Tue, 28 Jan 2003 09:19:59 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0SGXeKp007447 for ; Tue, 28 Jan 2003 08:33:40 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA11273 for ; Tue, 28 Jan 2003 11:26:59 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA97613 for ; Tue, 28 Jan 2003 11:26:58 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h0T0ewO26667 for linux-xfs@oss.sgi.com; Tue, 28 Jan 2003 19:40:58 -0500 Resent-Message-Id: <200301290040.h0T0ewO26667@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA05433 for ; Tue, 28 Jan 2003 11:21:09 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h0SHL6dU3006751 for ; Tue, 28 Jan 2003 09:21:07 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h0SHIbTJ023892 for ; Tue, 28 Jan 2003 18:18:37 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h0SHIbhQ023891 for hch@sgi.com; Tue, 28 Jan 2003 18:18:37 +0100 Date: Tue, 28 Jan 2003 18:18:37 +0100 From: Christoph Hellwig Message-Id: <200301281718.h0SHIbhQ023891@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.5.59 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 28 Jan 2003 19:40:57 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2456 X-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: 22281 Lines: 567 Date: Tue Jan 28 09:16:40 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.59-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:137930a linux/crypto/sha512.c - 1.1 linux/arch/ppc/ocp/ocp-probe.c - 1.1 linux/include/video/trident.h - 1.1 linux/arch/ppc/ocp/ocp-driver.c - 1.1 linux/arch/ppc/ocp/Makefile - 1.1 linux/init/vermagic.c - 1.1 linux/drivers/video/riva/nv_driver.c - 1.1 linux/include/linux/eisa.h - 1.1 linux/fs/devfs/internal.h - 1.1 linux/include/asm-x86_64/bug.h - 1.1 linux/arch/ppc64/kernel/module.c - 1.1 linux/fs/proc/task_mmu.c - 1.1 linux/drivers/eisa/eisa.ids - 1.1 linux/arch/alpha/kernel/core_marvel.c - 1.1 linux/include/asm-generic/vmlinux.lds.h - 1.1 linux/include/asm-alpha/gct.h - 1.1 linux/arch/sparc64/kernel/us3_cpufreq.c - 1.1 linux/include/asm-ppc64/bug.h - 1.1 linux/arch/alpha/kernel/err_marvel.c - 1.1 linux/arch/alpha/kernel/err_titan.c - 1.1 linux/arch/alpha/kernel/gct.c - 1.1 linux/include/asm-alpha/core_marvel.h - 1.1 linux/fs/proc/task_nommu.c - 1.1 linux/drivers/eisa/eisa-bus.c - 1.1 linux/arch/alpha/mm/remap.c - 1.1 linux/drivers/eisa/Makefile - 1.1 linux/include/asm-alpha/agp_backend.h - 1.1 linux/include/asm-m68knommu/bug.h - 1.1 linux/drivers/eisa/Kconfig - 1.1 linux/arch/ppc/ocp/ocp.c - 1.1 linux/arch/alpha/kernel/sys_marvel.c - 1.1 linux/net/netsyms.c - 1.58 linux/net/core/rtnetlink.c - 1.13 linux/net/core/dev.c - 1.67 linux/mm/page_alloc.c - 1.103 linux/mm/mmap.c - 1.69 linux/kernel/sched.c - 1.92 linux/kernel/module.c - 1.36 linux/kernel/fork.c - 1.81 linux/kernel/exit.c - 1.62 linux/init/main.c - 1.101 linux/include/video/font.h - 1.6 linux/include/linux/tty_driver.h - 1.6 linux/include/linux/sched.h - 1.96 linux/include/linux/netdevice.h - 1.42 linux/include/linux/module.h - 1.42 linux/include/linux/mm.h - 1.112 linux/include/linux/i2c.h - 1.18 linux/include/linux/fs.h - 1.203 linux/include/linux/fb.h - 1.30 linux/include/asm-ppc/processor.h - 1.40 linux/include/asm-m68k/uaccess.h - 1.7 linux/include/asm-m68k/q40ints.h - 1.4 linux/include/asm-m68k/mmu_context.h - 1.11 linux/include/asm-m68k/machdep.h - 1.9 linux/include/asm-i386/smp.h - 1.27 linux/include/asm-arm/unistd.h - 1.27 linux/include/asm-arm/ide.h - 1.9 linux/include/asm-alpha/system.h - 1.26 linux/include/asm-alpha/smp.h - 1.21 linux/include/asm-alpha/pgtable.h - 1.38 linux/include/asm-alpha/pci.h - 1.16 linux/include/asm-alpha/machvec.h - 1.16 linux/include/asm-alpha/irq.h - 1.7 linux/include/asm-alpha/io.h - 1.20 linux/include/asm-alpha/ide.h - 1.13 linux/include/asm-alpha/hwrpb.h - 1.8 linux/include/asm-alpha/hardirq.h - 1.17 linux/include/asm-alpha/console.h - 1.5 linux/fs/proc/inode.c - 1.29 linux/fs/proc/base.c - 1.47 linux/fs/proc/array.c - 1.55 linux/fs/proc/Makefile - 1.13 linux/fs/exec.c - 1.76 linux/fs/devpts/inode.c - 1.21 linux/fs/block_dev.c - 1.72 linux/drivers/video/fbmem.c - 1.58 linux/drivers/video/acornfb.c - 1.28 linux/drivers/video/Makefile - 1.49 linux/drivers/scsi/scsi_debug.c - 1.29 linux/drivers/scsi/mac_scsi.h - 1.6 linux/drivers/scsi/mac_scsi.c - 1.12 linux/drivers/net/via-rhine.c - 1.39 linux/drivers/net/smc9194.c - 1.24 linux/drivers/net/seeq8005.c - 1.18 linux/drivers/net/ptifddi.c - 1.9 linux/drivers/net/pcnet32.c - 1.39 linux/drivers/net/myri_sbus.c - 1.18 linux/drivers/net/Space.c - 1.39 linux/drivers/net/3c59x.c - 1.44 linux/drivers/net/3c527.c - 1.22 linux/drivers/net/3c515.c - 1.27 linux/drivers/net/3c509.c - 1.40 linux/drivers/net/3c501.c - 1.24 linux/drivers/isdn/hisax/config.c - 1.36 linux/drivers/char/tty_io.c - 1.60 linux/drivers/char/synclink.c - 1.32 linux/drivers/acorn/block/fd1772.c - 1.30 linux/drivers/Makefile - 1.41 linux/arch/sparc64/kernel/sys_sparc32.c - 1.67 linux/arch/sparc64/kernel/setup.c - 1.37 linux/arch/sparc64/kernel/Makefile - 1.28 linux/arch/sparc64/defconfig - 1.86 linux/arch/ppc/kernel/traps.c - 1.29 linux/arch/ppc/kernel/smp.c - 1.47 linux/arch/ppc/kernel/ptrace.c - 1.18 linux/arch/ppc/kernel/head.S - 1.40 linux/arch/ppc/Makefile - 1.36 linux/arch/m68k/q40/q40ints.c - 1.9 linux/arch/m68k/q40/config.c - 1.18 linux/arch/m68k/mm/fault.c - 1.11 linux/arch/m68k/mm/extable.c - 1.4 linux/arch/m68k/kernel/setup.c - 1.21 linux/arch/m68k/kernel/m68k_ksyms.c - 1.15 linux/arch/m68k/kernel/m68k_defs.c - 1.9 linux/arch/m68k/atari/stram.c - 1.24 linux/arch/i386/kernel/smp.c - 1.53 linux/arch/i386/kernel/io_apic.c - 1.51 linux/arch/i386/kernel/entry.S - 1.72 linux/arch/i386/defconfig - 1.118 linux/arch/i386/Makefile - 1.45 linux/arch/arm/kernel/process.c - 1.35 linux/arch/arm/kernel/calls.S - 1.22 linux/arch/alpha/mm/Makefile - 1.6 linux/arch/alpha/kernel/traps.c - 1.28 linux/arch/alpha/kernel/smp.c - 1.41 linux/arch/alpha/kernel/setup.c - 1.34 linux/arch/alpha/kernel/proto.h - 1.21 linux/arch/alpha/kernel/osf_sys.c - 1.38 linux/arch/alpha/kernel/irq.c - 1.28 linux/arch/alpha/kernel/core_tsunami.c - 1.23 linux/arch/alpha/kernel/alpha_ksyms.c - 1.40 linux/arch/alpha/kernel/Makefile - 1.29 linux/arch/alpha/boot/Makefile - 1.15 linux/arch/alpha/Makefile - 1.27 linux/Makefile - 1.237 linux/MAINTAINERS - 1.130 linux/Documentation/Changes - 1.62 linux/drivers/net/sk_mca.c - 1.15 linux/arch/i386/vmlinux.lds.S - 1.16 linux/fs/partitions/sgi.c - 1.8 linux/drivers/atm/nicstar.c - 1.20 linux/net/atm/mpc.c - 1.12 linux/arch/ppc/kernel/entry.S - 1.33 linux/arch/arm/vmlinux-armv.lds.in - 1.24 linux/arch/arm/vmlinux-armo.lds.in - 1.22 linux/arch/arm/kernel/bios32.c - 1.34 linux/arch/alpha/kernel/pci_impl.h - 1.12 linux/arch/alpha/kernel/pci.c - 1.28 linux/arch/alpha/kernel/machvec_impl.h - 1.9 linux/arch/sh/vmlinux.lds.S - 1.17 linux/drivers/pcmcia/cardbus.c - 1.25 linux/arch/m68k/vmlinux-sun3.lds - 1.14 linux/arch/i386/kernel/smpboot.c - 1.56 linux/drivers/net/wan/sbni.c - 1.20 linux/drivers/video/tdfxfb.c - 1.27 linux/fs/proc/proc_misc.c - 1.52 linux/include/asm-alpha/pgalloc.h - 1.17 linux/drivers/video/fbmon.c - 1.4 linux/arch/ppc/kernel/head_4xx.S - 1.12 linux/include/linux/mmzone.h - 1.35 linux/drivers/char/agp/agp.h - 1.32 linux/arch/i386/kernel/acpi.c - 1.32 linux/arch/i386/kernel/mpparse.c - 1.32 linux/include/asm-i386/mpspec.h - 1.14 linux/include/asm-i386/apicdef.h - 1.10 linux/arch/ia64/vmlinux.lds.S - 1.21 linux/arch/ia64/defconfig - 1.25 linux/arch/alpha/kernel/pci_iommu.c - 1.21 linux/include/linux/devfs_fs_kernel.h - 1.17 linux/drivers/scsi/pcmcia/qlogic_stub.c - 1.10 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.10 linux/fs/devfs/util.c - 1.17 linux/fs/devfs/base.c - 1.50 linux/drivers/scsi/pcmcia/aha152x_stub.c - 1.11 linux/fs/devfs/Makefile - 1.6 linux/arch/mips64/ld.script.elf64 - 1.7 linux/drivers/video/riva/riva_hw.c - 1.6 linux/drivers/video/riva/fbdev.c - 1.21 linux/drivers/video/riva/Makefile - 1.6 linux/drivers/net/appletalk/cops.c - 1.16 linux/include/linux/usb.h - 1.52 linux/drivers/usb/serial/usb-serial.c - 1.12 linux/drivers/block/elevator.c - 1.29 linux/kernel/kallsyms.c - 1.18 linux/arch/alpha/kernel/core_titan.c - 1.8 linux/arch/alpha/kernel/core_wildfire.c - 1.4 linux/drivers/usb/storage/scsiglue.c - 1.29 linux/arch/alpha/kernel/sys_titan.c - 1.8 linux/arch/alpha/kernel/sys_wildfire.c - 1.7 linux/arch/alpha/lib/callback_srm.S - 1.2 linux/include/asm-alpha/core_titan.h - 1.5 linux/drivers/sbus/char/display7seg.c - 1.8 linux/drivers/media/video/cpia_usb.c - 1.18 linux/drivers/media/video/cpia_pp.c - 1.9 linux/drivers/media/video/cpia.h - 1.8 linux/arch/arm/tools/mach-types - 1.22 linux/drivers/net/hamachi.c - 1.20 linux/drivers/net/sundance.c - 1.22 linux/drivers/net/isa-skeleton.c - 1.10 linux/include/asm-i386/module.h - 1.4 linux/drivers/video/stifb.c - 1.8 linux/arch/parisc/defconfig - 1.10 linux/arch/s390x/kernel/signal32.c - 1.9 linux/drivers/video/riva/rivafb.h - 1.5 linux/arch/s390x/kernel/linux32.h - 1.6 linux/arch/s390x/kernel/linux32.c - 1.22 linux/drivers/s390/net/netiucv.c - 1.14 linux/drivers/s390/net/ctcmain.c - 1.12 linux/arch/s390x/kernel/entry.S - 1.19 linux/arch/s390x/kernel/wrapper32.S - 1.11 linux/include/asm-arm/arch-integrator/memory.h - 1.5 linux/include/asm-alpha/mmzone.h - 1.6 linux/arch/alpha/mm/numa.c - 1.8 linux/arch/ppc/boot/common/misc-common.c - 1.8 linux/include/asm-m68k/rtc.h - 1.4 linux/drivers/video/aty/atyfb.h - 1.5 linux/drivers/video/aty/atyfb_base.c - 1.16 linux/drivers/video/aty/mach64_accel.c - 1.6 linux/drivers/video/sa1100fb.h - 1.7 linux/arch/arm/mach-integrator/cpu.c - 1.11 linux/arch/arm/mach-sa1100/cpu-sa1100.c - 1.10 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.12 linux/drivers/video/sstfb.h - 1.5 linux/drivers/video/sstfb.c - 1.11 linux/fs/quota.c - 1.18 linux/drivers/char/i8k.c - 1.5 linux/fs/ext3/ialloc.c - 1.21 linux/fs/ext3/inode.c - 1.31 linux/fs/ext3/namei.c - 1.17 linux/include/linux/jbd.h - 1.12 linux/fs/intermezzo/vfs.c - 1.13 linux/include/linux/ext3_jbd.h - 1.7 linux/include/linux/ext3_fs.h - 1.15 linux/fs/jbd/transaction.c - 1.14 linux/fs/jbd/commit.c - 1.9 linux/fs/jbd/checkpoint.c - 1.6 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.11 linux/arch/ppc/boot/common/util.S - 1.3 linux/arch/ppc/boot/ld.script - 1.4 linux/arch/ppc/boot/simple/Makefile - 1.11 linux/arch/ppc/boot/simple/gt64260_tty.c - 1.3 linux/arch/ppc/boot/simple/head.S - 1.3 linux/arch/ppc/boot/simple/misc-ev64260.S - 1.2 linux/arch/ppc/boot/simple/misc-spruce.c - 1.4 linux/arch/ppc/boot/utils/mkbugboot.c - 1.2 linux/sound/oss/soundcard.c - 1.7 linux/arch/ppc/platforms/ev64260.h - 1.2 linux/arch/ppc/platforms/ev64260_setup.c - 1.4 linux/arch/ppc/platforms/k2.h - 1.2 linux/arch/ppc/platforms/k2_pci.c - 1.4 linux/arch/ppc/platforms/k2_setup.c - 1.6 linux/arch/ppc/platforms/lopec_pci.c - 1.3 linux/arch/ppc/platforms/lopec_serial.h - 1.2 linux/arch/ppc/platforms/lopec_setup.c - 1.10 linux/arch/ppc/platforms/mcpn765.h - 1.2 linux/arch/ppc/platforms/mcpn765_pci.c - 1.2 linux/arch/ppc/platforms/mcpn765_serial.h - 1.2 linux/arch/ppc/platforms/mcpn765_setup.c - 1.7 linux/arch/ppc/platforms/menf1.h - 1.2 linux/arch/ppc/platforms/menf1_pci.c - 1.2 linux/arch/ppc/platforms/menf1_setup.c - 1.6 linux/arch/ppc/platforms/mvme5100.h - 1.2 linux/arch/ppc/platforms/mvme5100_pci.c - 1.2 linux/arch/ppc/platforms/mvme5100_serial.h - 1.2 linux/arch/ppc/platforms/mvme5100_setup.c - 1.4 linux/arch/ppc/platforms/pcore.h - 1.2 linux/arch/ppc/platforms/pcore_pci.c - 1.2 linux/arch/ppc/platforms/pcore_setup.c - 1.5 linux/arch/ppc/platforms/powerpmc250.c - 1.5 linux/arch/ppc/platforms/powerpmc250.h - 1.2 linux/arch/ppc/platforms/powerpmc250_serial.h - 1.2 linux/arch/ppc/platforms/pplus_pci.c - 1.2 linux/arch/ppc/platforms/pplus_setup.c - 1.10 linux/arch/ppc/platforms/prpmc750_pci.c - 1.2 linux/arch/ppc/platforms/prpmc750_serial.h - 1.2 linux/arch/ppc/platforms/prpmc750_setup.c - 1.5 linux/arch/ppc/platforms/prpmc800.h - 1.2 linux/arch/ppc/platforms/prpmc800_pci.c - 1.2 linux/arch/ppc/platforms/prpmc800_serial.h - 1.2 linux/arch/ppc/platforms/prpmc800_setup.c - 1.5 linux/arch/ppc/platforms/sandpoint.h - 1.2 linux/arch/ppc/platforms/sandpoint_pci.c - 1.2 linux/arch/ppc/platforms/sandpoint_serial.h - 1.2 linux/arch/ppc/platforms/sandpoint_setup.c - 1.8 linux/arch/ppc/platforms/spruce.h - 1.3 linux/arch/ppc/platforms/spruce_pci.c - 1.3 linux/arch/ppc/platforms/spruce_serial.h - 1.2 linux/arch/ppc/platforms/spruce_setup.c - 1.8 linux/arch/ppc/platforms/zx4500.h - 1.2 linux/arch/ppc/platforms/zx4500_pci.c - 1.2 linux/arch/ppc/platforms/zx4500_serial.h - 1.2 linux/arch/ppc/platforms/zx4500_setup.c - 1.4 linux/arch/x86_64/Makefile - 1.13 linux/arch/x86_64/boot/Makefile - 1.11 linux/arch/x86_64/boot/compressed/Makefile - 1.6 linux/arch/x86_64/defconfig - 1.14 linux/arch/x86_64/ia32/ia32_signal.c - 1.8 linux/arch/x86_64/ia32/ia32entry.S - 1.8 linux/arch/x86_64/ia32/sys_ia32.c - 1.13 linux/arch/x86_64/kernel/Makefile - 1.12 linux/arch/x86_64/kernel/apic.c - 1.8 linux/arch/x86_64/kernel/entry.S - 1.8 linux/arch/x86_64/kernel/head.S - 1.8 linux/arch/x86_64/kernel/process.c - 1.13 linux/arch/x86_64/kernel/ptrace.c - 1.8 linux/arch/x86_64/kernel/setup64.c - 1.8 linux/arch/x86_64/kernel/smpboot.c - 1.10 linux/arch/x86_64/kernel/traps.c - 1.12 linux/arch/x86_64/lib/Makefile - 1.9 linux/arch/x86_64/lib/usercopy.c - 1.5 linux/arch/x86_64/mm/Makefile - 1.6 linux/arch/x86_64/mm/init.c - 1.12 linux/include/asm-x86_64/segment.h - 1.5 linux/include/asm-x86_64/ptrace.h - 1.6 linux/include/asm-x86_64/page.h - 1.7 linux/include/asm-x86_64/mmu_context.h - 1.9 linux/include/asm-x86_64/ia32.h - 1.7 linux/include/asm-ppc/todc.h - 1.3 linux/include/asm-ppc/pplus.h - 1.2 linux/include/asm-ppc/ppc405_dma.h - 1.2 linux/include/asm-ppc/mpc10x.h - 1.4 linux/include/asm-ppc/ibm403.h - 1.3 linux/include/asm-x86_64/uaccess.h - 1.5 linux/include/asm-ppc/gt64260.h - 1.2 linux/include/asm-ppc/gt64260_defs.h - 1.2 linux/include/asm-ppc/harrier.h - 1.2 linux/arch/ppc64/boot/zImage.lds - 1.2 linux/arch/ppc64/kernel/Makefile - 1.12 linux/arch/ppc64/kernel/entry.S - 1.12 linux/arch/ppc64/kernel/ioctl32.c - 1.14 linux/arch/ppc64/kernel/misc.S - 1.13 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.9 linux/arch/ppc64/kernel/process.c - 1.11 linux/arch/ppc64/kernel/signal.c - 1.12 linux/arch/ppc64/kernel/signal32.c - 1.12 linux/arch/ppc64/kernel/sys32.S - 1.6 linux/arch/ppc64/kernel/sys_ppc32.c - 1.14 linux/arch/ppc64/mm/extable.c - 1.5 linux/include/asm-ppc64/module.h - 1.2 linux/include/asm-ppc64/page.h - 1.11 linux/drivers/net/tulip/winbond-840.c - 1.8 linux/drivers/net/tc35815.c - 1.7 linux/drivers/usb/class/bluetty.c - 1.14 linux/drivers/usb/class/cdc-acm.c - 1.13 linux/drivers/usb/core/hcd.c - 1.17 linux/drivers/usb/core/hcd.h - 1.12 linux/drivers/usb/core/usb.c - 1.26 linux/mm/readahead.c - 1.15 linux/arch/x86_64/ia32/fpu32.c - 1.3 linux/arch/x86_64/mm/modutil.c - 1.4 linux/drivers/char/synclinkmp.c - 1.6 linux/drivers/char/pcmcia/synclink_cs.c - 1.7 linux/init/Makefile - 1.13 linux/drivers/video/cfbcopyarea.c - 1.6 linux/drivers/base/bus.c - 1.12 linux/drivers/video/cfbfillrect.c - 1.5 linux/drivers/video/cfbimgblt.c - 1.6 linux/drivers/video/tridentfb.c - 1.4 linux/drivers/video/tridentfb.h - 1.2 linux/drivers/s390/cio/chsc.c - 1.5 linux/arch/i386/kernel/cpu/proc.c - 1.6 linux/arch/i386/kernel/cpu/amd.c - 1.8 linux/arch/x86_64/pci/Makefile - 1.4 linux/include/asm-alpha/agp.h - 1.2 linux/drivers/input/keyboard/amikbd.c - 1.7 linux/drivers/input/serio/q40kbd.c - 1.5 linux/drivers/char/agp/ali-agp.c - 1.5 linux/drivers/char/agp/sis-agp.c - 1.5 linux/drivers/char/agp/frontend.c - 1.5 linux/drivers/char/agp/hp-agp.c - 1.5 linux/drivers/char/agp/i460-agp.c - 1.5 linux/drivers/char/agp/sworks-agp.c - 1.5 linux/drivers/char/agp/via-agp.c - 1.5 linux/drivers/serial/sunsab.c - 1.5 linux/drivers/usb/misc/speedtouch.c - 1.9 linux/arch/alpha/vmlinux.lds.S - 1.7 linux/include/asm-ppc/rtc.h - 1.2 linux/arch/mips64/vmlinux.lds.S - 1.2 linux/arch/m68k/vmlinux-std.lds - 1.5 linux/arch/ppc64/vmlinux.lds.S - 1.5 linux/arch/x86_64/vmlinux.lds.S - 1.6 linux/arch/sparc64/vmlinux.lds.S - 1.7 linux/arch/sparc/vmlinux.lds.S - 1.8 linux/arch/s390x/vmlinux.lds.S - 1.7 linux/arch/cris/vmlinux.lds.S - 1.3 linux/arch/ppc/vmlinux.lds.S - 1.7 linux/arch/s390/vmlinux.lds.S - 1.7 linux/arch/mips/vmlinux.lds.S - 1.3 linux/arch/parisc/vmlinux.lds.S - 1.6 linux/Documentation/driver-model/bus.txt - 1.3 linux/Documentation/driver-model/driver.txt - 1.3 linux/Documentation/driver-model/overview.txt - 1.3 linux/arch/ppc/boot/include/mpc10x.h - 1.3 linux/arch/ppc/boot/common/mpc10x_memory.c - 1.2 linux/include/asm-alpha/numnodes.h - 1.2 linux/arch/ppc/boot/common/cpc700_memory.c - 1.2 linux/include/asm-alpha/topology.h - 1.3 linux/include/asm-generic/topology.h - 1.2 linux/include/asm-i386/topology.h - 1.3 linux/include/asm-ia64/topology.h - 1.4 linux/include/asm-ppc64/topology.h - 1.3 linux/arch/um/uml.lds.S - 1.5 linux/include/linux/cpufreq.h - 1.8 linux/arch/ppc/platforms/4xx/walnut.h - 1.4 linux/include/asm-ppc/ibm405.h - 1.3 linux/arch/ppc/kernel/asm-offsets.c - 1.4 linux/arch/ppc/platforms/4xx/ash.c - 1.3 linux/arch/ppc/platforms/4xx/ash.h - 1.4 linux/arch/ppc/platforms/4xx/cedar.c - 1.3 linux/arch/ppc/platforms/4xx/cedar.h - 1.4 linux/arch/ppc/platforms/4xx/ep405.c - 1.4 linux/arch/ppc/platforms/4xx/ep405.h - 1.4 linux/arch/ppc/platforms/4xx/ibm405gp.c - 1.4 linux/arch/ppc/platforms/4xx/ibm405gp.h - 1.4 linux/arch/ppc/platforms/4xx/ibmnp405h.c - 1.4 linux/arch/ppc/platforms/4xx/ibmnp405h.h - 1.4 linux/arch/ppc/platforms/4xx/ibmnp405l.c - 1.4 linux/arch/ppc/platforms/4xx/ibmnp405l.h - 1.4 linux/arch/ppc/platforms/4xx/ibmstb3.c - 1.4 linux/arch/ppc/platforms/4xx/ibmstb3.h - 1.4 linux/arch/ppc/platforms/4xx/ibmstb4.c - 1.4 linux/arch/ppc/platforms/4xx/ibmstb4.h - 1.4 linux/arch/ppc/platforms/4xx/redwood.c - 1.3 linux/arch/ppc/platforms/4xx/redwood.h - 1.4 linux/arch/ppc/platforms/4xx/redwood5.c - 1.3 linux/arch/ppc/platforms/4xx/redwood5.h - 1.3 linux/arch/ppc/platforms/4xx/walnut.c - 1.4 linux/include/asm-x86_64/proto.h - 1.5 linux/arch/ppc/boot/simple/misc.c - 1.4 linux/Documentation/filesystems/sysfs.txt - 1.3 linux/arch/ppc/boot/simple/relocate.S - 1.2 linux/drivers/isdn/i4l/isdn_ppp_ccp.c - 1.4 linux/arch/ppc/platforms/pal4.h - 1.2 linux/arch/ppc/platforms/pal4_pci.c - 1.3 linux/arch/ppc/platforms/pal4_serial.h - 1.2 linux/arch/ppc/platforms/pal4_setup.c - 1.3 linux/include/linux/kobject.h - 1.6 linux/Documentation/crypto/api-intro.txt - 1.5 linux/arch/alpha/Kconfig - 1.6 linux/sound/Kconfig - 1.2 linux/arch/i386/Kconfig - 1.9 linux/scripts/Makefile.build - 1.5 linux/drivers/char/Kconfig - 1.4 linux/arch/m68k/Kconfig - 1.7 linux/drivers/hotplug/acpiphp_glue.c - 1.4 linux/arch/sparc64/Kconfig - 1.5 linux/drivers/ide/Kconfig - 1.4 linux/arch/x86_64/Kconfig - 1.7 linux/lib/kobject.c - 1.5 linux/crypto/Kconfig - 1.5 linux/crypto/Makefile - 1.5 linux/crypto/des.c - 1.4 linux/crypto/tcrypt.c - 1.5 linux/crypto/tcrypt.h - 1.5 linux/drivers/video/Kconfig - 1.5 linux/init/Kconfig - 1.5 linux/fs/hugetlbfs/inode.c - 1.6 linux/arch/alpha/kernel/err_impl.h - 1.3 linux/include/asm-m68knommu/entry.h - 1.2 linux/drivers/parisc/Kconfig - 1.4 linux/include/asm-m68knommu/page.h - 1.2 linux/drivers/base/node.c - 1.4 linux/arch/v850/vmlinux.lds.S - 1.5 linux/arch/m68knommu/kernel/Makefile - 1.3 linux/arch/m68knommu/platform/5307/entry.S - 1.2 linux/arch/m68knommu/platform/68328/entry.S - 1.2 linux/arch/m68knommu/platform/68360/entry.S - 1.2 linux/arch/m68knommu/platform/68EZ328/ucsimm/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/68VZ328/de2/himem.ld - 1.2 linux/arch/m68knommu/platform/68VZ328/ucdimm/crt0_ram.S - 1.2 linux/arch/m68knommu/vmlinux.lds.S - 1.3 linux/arch/ppc/syslib/pplus_common.c - 1.2 linux/arch/ppc/syslib/todc_time.c - 1.4 linux/arch/ppc/syslib/ppc4xx_serial.c - 1.2 linux/arch/ppc/syslib/ppc4xx_pm.c - 1.2 linux/arch/ppc/syslib/ppc405_pci.c - 1.3 linux/arch/ppc/syslib/pci_auto.c - 1.2 linux/arch/ppc/syslib/mpc10x_common.c - 1.3 linux/arch/ppc/syslib/harrier.c - 1.2 linux/arch/ppc/syslib/gt64260_pic.c - 1.2 linux/arch/ppc/syslib/gt64260_common.c - 1.2 linux/arch/ppc/syslib/cpc710.h - 1.3 linux/arch/ppc/syslib/cpc700_pic.c - 1.2 linux/arch/ppc/syslib/cpc700.h - 1.2 linux/drivers/s390/net/cu3088.c - 1.2 linux/scripts/per-cpu-check.awk - 1.2 linux/include/linux/compat.h - 1.3 linux/scripts/kallsyms.c - 1.4 linux/drivers/usb/serial/bus.c - 1.4 linux/drivers/video/console/Kconfig - 1.3 linux/drivers/video/console/fbcon.c - 1.3 linux/drivers/video/console/sticon.c - 1.3 linux/drivers/video/console/sticore.c - 1.3 linux/drivers/char/agp/amd-k7-agp.c - 1.4 linux/drivers/char/agp/amd-k8-agp.c - 1.4 linux/drivers/char/agp/backend.c - 1.4 linux/drivers/char/agp/generic.c - 1.4 linux/drivers/video/sticore.h - 1.3 linux/drivers/char/agp/intel-agp.c - 1.4 linux/drivers/char/watchdog/acquirewdt.c - 1.3 linux/drivers/char/watchdog/advantechwdt.c - 1.3 linux/drivers/char/watchdog/eurotechwdt.c - 1.3 linux/drivers/char/watchdog/i810-tco.c - 1.3 linux/kernel/compat.c - 1.3 linux/drivers/char/watchdog/ib700wdt.c - 1.3 linux/drivers/char/watchdog/machzwd.c - 1.3 linux/drivers/char/watchdog/mixcomwd.c - 1.3 linux/drivers/char/watchdog/pcwd.c - 1.3 linux/drivers/char/watchdog/sbc60xxwdt.c - 1.3 linux/drivers/char/watchdog/wdt977.c - 1.3 linux/drivers/char/watchdog/wdt_pci.c - 1.3 linux/drivers/char/watchdog/shwdt.c - 1.3 linux/drivers/char/watchdog/scx200_wdt.c - 1.2 linux/drivers/char/watchdog/softdog.c - 1.3 linux/drivers/char/watchdog/wdt285.c - 1.2 linux/drivers/char/watchdog/wdt.c - 1.3 linux/drivers/char/watchdog/w83877f_wdt.c - 1.3 linux/arch/x86_64/ia32/syscall32.c - 1.2 linux/arch/x86_64/kernel/module.c - 1.4 linux/include/linux/font.h - 1.2 linux/drivers/char/agp/i7x05-agp.c - 1.3 linux/include/asm-x86_64/compat.h - 1.3 linux/include/asm-s390x/compat.h - 1.3 linux/include/asm-i386/mach-summit/mach_mpparse.h - 1.2 linux/include/asm-i386/mach-summit/mach_apic.h - 1.3 linux/include/asm-i386/mach-numaq/mach_mpparse.h - 1.2 linux/include/asm-i386/mach-numaq/mach_apic.h - 1.3 linux/include/asm-i386/mach-default/mach_mpparse.h - 1.2 linux/include/asm-i386/mach-default/mach_apic.h - 1.3 linux/drivers/video/i810/i810.h - 1.2 linux/drivers/video/i810/i810_accel.c - 1.2 linux/drivers/video/i810/i810_dvt.c - 1.2 linux/drivers/video/i810/i810_main.c - 1.2 linux/drivers/video/i810/i810_main.h - 1.2 linux/include/asm-ppc/ibm_ocp_pci.h - 1.2 linux/drivers/char/watchdog/alim7101_wdt.c - 1.2 linux/arch/ppc/platforms/4xx/ibm405gpr.c - 1.2 linux/arch/ppc/platforms/4xx/ibm405gpr.h - 1.2 linux/drivers/char/agp/via-kt400.c - 1.2 linux/drivers/char/watchdog/wafer5823wdt.c - 1.2 linux/arch/ppc/platforms/4xx/ibmnp4gs.c - 1.2 linux/drivers/char/watchdog/indydog.c - 1.2 linux/drivers/char/watchdog/sa1100_wdt.c - 1.2 linux/drivers/char/watchdog/sc1200wdt.c - 1.2 linux/drivers/char/watchdog/sc520_wdt.c - 1.2 linux/arch/ppc/platforms/4xx/ibmnp4gs.h - 1.2 linux/arch/ppc/syslib/ppc4xx_dma.c - 1.2 linux/arch/ppc/platforms/4xx/ibmstbx25.c - 1.2 linux/arch/ppc/platforms/4xx/ibmstbx25.h - 1.2 linux/arch/ppc/platforms/4xx/sycamore.c - 1.2 linux/arch/ppc/platforms/4xx/sycamore.h - 1.2 linux/arch/ppc/platforms/4xx/redwood6.h - 1.2 linux/arch/ppc/platforms/4xx/redwood6.c - 1.2 linux/net/sunrpc/rpc_pipe.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c - 1.2 linux/include/asm-i386/mach-bigsmp/mach_apic.h - 1.2 linux/include/asm-sparc64/bug.h - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jan 28 14:47:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 14:47:43 -0800 (PST) Received: from mail.qk.com.au (202-44-163-105.nexnet.net.au [202.44.163.105]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0SMlX3v016547 for ; Tue, 28 Jan 2003 14:47:34 -0800 Received: from amavis by mail.qk.com.au with scanned-ok (Exim 3.35 #1 (Debian)) id 18decp-0003Ln-00 for ; Wed, 29 Jan 2003 09:54:39 +1100 Received: from juno ([10.0.0.79] ident=mail) by mail.qk.com.au with esmtp (Exim 3.35 #1 (Debian)) id 18deco-0003Le-00 for ; Wed, 29 Jan 2003 09:54:38 +1100 Received: from lbarbuto by juno with local (Exim 3.36 #1 (Debian)) id 18decn-00070i-00 for ; Wed, 29 Jan 2003 09:54:37 +1100 Date: Wed, 29 Jan 2003 09:54:37 +1100 From: Lucas Barbuto To: Linux XFS Mailing List Subject: Re: Problems mounting an ext3 filesystem with XFS kernel Message-ID: <20030128225437.GA26920@qk.com.au> Reply-To: Lucas Barbuto References: <20030127232221.GA21514@qk.com.au> <4.3.2.7.2.20030128092913.03287490@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030128092913.03287490@pop.xs4all.nl> User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS perl-11 X-archive-position: 2457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lucas@qk.com.au Precedence: bulk X-list: linux-xfs Content-Length: 3086 Lines: 94 Hi Seth, On Tue, Jan 28, 2003 at 09:46:39AM +0100, Seth Mos wrote: > At 10:22 28-1-2003 +1100, Lucas Barbuto wrote: > > Yes. It's /dev/md1. > > not /dev/md0 ?? No, I named my RAID devices after the underlying partitions they consist of, ie, hde1 and hdg1 map to md1, to avoid confusing myself. > That means that linux detects the disk in a different way then your bios > does. You can correct this with a line in your lilo.conf. > > It might be related to your booting problem. If you say that the boot drive > is hda, which would correspond with what the bios thinks. However when the > kernel boots the first disk is detected as hde and it can get confused at > this point. The boot device (as specified in LiLo) is /dev/md1. I have started a similar thread on linux-raid as I've realised that this is a RAID problem rather than an XFS problem. There I received the advice that the kernel is booting off /dev/hde1 or /dev/hdg1 and not actually off the RAID device and that the RAID is not being constructed before the kernel tries to mount the root device (md2), hence crashing ensues. This makes sense to me, I haven't been able to fix it though. > My lilo.conf contains. > boot=/dev/hde > map=/boot/map > install=/boot/boot.b > prompt > timeout=50 > linear > default=2418-rht-1.2 > vga=0x430 > message=/boot/message > > image=/boot/vmlinuz-2.4.18-19-xfs-1.2pre5 > label=2418-rht-1.2 > read-only > root=/dev/hde1 > > This machine has the onboard IDE deactivated as well as your system and > thus hda does not exist so I changed the boot line. > > Subsequent lilo does not give me a line saying it's confused about where > the disk should be. Yeah, that's similar to what mine was, but I was still getting the warning message. > You could check either the kernel config or a initrd image file in your > /boot/ If that's where debian places the kernels. I checked, not using initrd. > You can always check though. I forgot to compile in the md drivers once and > put a box 150Km (~100Miles) away out of service. Hmm, well this box is under my desk at the moment, but it's headed for a data centre so I need to get it right :). > If I understand what you are trying to do you want to format the / > partition with ext3 and leave the rest XFS? > If that is so format /dev/md1 with ext2 > mkfs.ext2 /dev/md1 > Create the ext3 journal ontop of it. > tune2fs -j /dev/md1 > Now you should be able to mount the / as ext3. Yeah, that's right, I used 'mke2fs -j /dev/md1' to create an ext3, I think this does the same thing you suggested, but in one line. Anyhow, I've since given up on the onboard RAID controller and I've put my system disks back in the primary and secondary IDE slots because I've done it that way before and it's worked. I'll just use the onboard RAID for an extra data disk or two. Problem is, now I'm trying to get the system to boot with the root RAID in degraded mode with a boot disk but it's telling me: Invalid compressed format (err=1) -- System halted *BIGSIGH* Thanks for your help. Regards, Lucas From owner-linux-xfs@oss.sgi.com Tue Jan 28 19:13:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 19:13:29 -0800 (PST) Received: from smtp3.cbn.net.id (smtp3.cbn.net.id [202.158.3.28]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0T3DM3v018760 for ; Tue, 28 Jan 2003 19:13:24 -0800 Received: from navajo.int.cbn.net.id (cheyenne.cbn.net.id [202.158.50.84]) by smtp3.cbn.net.id (Postfix) with ESMTP id CDFAF432F9 for ; Wed, 29 Jan 2003 10:20:25 +0700 (WIT) Content-Type: text/plain; charset="us-ascii" From: Kisanak Organization: Allahu Ghaayatunaa Rasuulu Qudwatunna To: linux-xfs@oss.sgi.com Subject: How To Unsubscribe? Date: Wed, 29 Jan 2003 10:20:24 +0700 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200301291020.24101.kisanak@cbn.net.id> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0T3DP3v018762 X-archive-position: 2458 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kisanak@cbn.net.id Precedence: bulk X-list: linux-xfs Content-Length: 86 Lines: 5 I didn't find any information from: http://www.oss.sgi.com/newsgroups.html Thanks. From owner-linux-xfs@oss.sgi.com Tue Jan 28 19:21:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Jan 2003 19:21:06 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0T3L43v019206 for ; Tue, 28 Jan 2003 19:21:04 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0T1SIG8005063 for ; Tue, 28 Jan 2003 17:28:18 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA18579; Tue, 28 Jan 2003 21:28:07 -0600 (CST) Received: from chuckle.americas.sgi.com (PSEOmJrYl2K/aqaFac+Fqk8MFwxRLXmi@chuckle.americas.sgi.com [128.162.241.66]) by poppy-e236.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id VAA66191; Tue, 28 Jan 2003 21:28:08 -0600 (CST) Date: Tue, 28 Jan 2003 21:28:08 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@chuckle.americas.sgi.com To: Kisanak cc: linux-xfs@oss.sgi.com Subject: Re: How To Unsubscribe? In-Reply-To: <200301291020.24101.kisanak@cbn.net.id> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2459 X-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: 363 Lines: 17 Send "unsubscribe linux-xfs your@email.address" to majordomo@oss.sgi.com It's actually an ecartis list but I think it still speaks majordomo. This info was probably in your welcome letter when you subscribed, too :) -Eric On Wed, 29 Jan 2003, Kisanak wrote: > I didn't find any information from: > http://www.oss.sgi.com/newsgroups.html > > Thanks. > > From owner-linux-xfs@oss.sgi.com Wed Jan 29 03:19:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jan 2003 03:19:08 -0800 (PST) Received: from voyager.st-peter.stw.uni-erlangen.de (postfix@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0TBIx3v003674 for ; Wed, 29 Jan 2003 03:19:00 -0800 Received: from localhost (localhost [127.0.0.1]) by voyager.st-peter.stw.uni-erlangen.de (Postfix) with ESMTP id CEEBF6DF7; Wed, 29 Jan 2003 12:26:08 +0100 (CET) X-Mailbox-Line: From galia@st-peter.stw.uni-erlangen.de Wed Jan 29 12:26:08 2003 Received: by voyager.st-peter.stw.uni-erlangen.de (Postfix, from userid 33) id EEB386DF8; Wed, 29 Jan 2003 12:26:07 +0100 (CET) To: linux-xfs@oss.sgi.com Subject: 2.4.20 + xfs +lvm2 = raid0_make_request bug Message-ID: <1043839567.3e37ba4fd327e@secure.st-peter.stw.uni-erlangen.de> Date: Wed, 29 Jan 2003 12:26:07 +0100 (CET) From: Svetoslav Slavtchev Cc: linux-lvm@sistina.com, linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 172.17.17.181 X-Virus-Scanned: by AMaViS snapshot-20020222 X-archive-position: 2460 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: galia@st-peter.stw.uni-erlangen.de Precedence: bulk X-list: linux-xfs Content-Length: 1039 Lines: 37 Hi, a kind of repost useing lvm2(with lvm1 everything is working perfect for the last 6 months) when i try to mount a xfs filesystem wich is on lv over soft raid-0, i'm getting just like in 2.5.2x - 2.5.4x (i didn't try later kernels) : ############################ raid0_make_request bug: can't convert block across chunks or bigger than 16k 25181311 4 raid0_make_request bug: can't convert block across chunks or bigger than 16k 25181343 4 ############################ is this know problem, is it fixed ? i thought that the problem exist only in 2.5 kernel everything works with reiserfs and jfs ( well not really sure but i could transfer ~10Gb to and from the LV, mkfs ..) but with xfs got this: mkfs.xfs -- device-mapper: unknown block ioctl 0x6424 device-mapper: unknown block ioctl 0x6424 and with mount again : raid0_make_request bug: can't convert block across chunks or bigger than 16k 213164570 4 raid0_make_request bug: can't convert block across chunks or bigger than 16k 213164602 4 any hints? regards, svetljo From owner-linux-xfs@oss.sgi.com Wed Jan 29 03:34:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jan 2003 03:34:47 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0TBYc3v004197 for ; Wed, 29 Jan 2003 03:34:39 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0TAmPKp009722 for ; Wed, 29 Jan 2003 02:48:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id FAA53050 for ; Wed, 29 Jan 2003 05:41:43 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id FAA50576 for ; Wed, 29 Jan 2003 05:41:42 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id h0TItfa28331 for linux-xfs@oss.sgi.com; Wed, 29 Jan 2003 13:55:41 -0500 Resent-Message-Id: <200301291855.h0TItfa28331@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id FAA05926 for ; Wed, 29 Jan 2003 05:17:56 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id h0TBHsdU3308087 for ; Wed, 29 Jan 2003 03:17:55 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id h0TBFODK002253 for ; Wed, 29 Jan 2003 12:15:24 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id h0TBFOAu002252 for hch@sgi.com; Wed, 29 Jan 2003 12:15:24 +0100 Date: Wed, 29 Jan 2003 12:15:24 +0100 From: Christoph Hellwig Message-Id: <200301291115.h0TBFOAu002252@lab343.munich.sgi.com> Subject: TAKE - remove a dead codepath in xfs_syncsub To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Wed, 29 Jan 2003 13:55:40 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 2461 X-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: 329 Lines: 11 Date: Wed Jan 29 03:16:55 PST 2003 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:138037a linux/fs/xfs/xfs_vfsops.c - 1.406 - in XFS/Linux VOP_SYNC is not used to periodically flush delalloc space From owner-linux-xfs@oss.sgi.com Wed Jan 29 08:27:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jan 2003 08:27:23 -0800 (PST) Received: from trasno.mitica (cm19173.red.mundo-r.com [213.60.19.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0TGR83v017209 for ; Wed, 29 Jan 2003 08:27:09 -0800 Received: by trasno.mitica (Postfix, from userid 1001) id EF53ABF00; Wed, 29 Jan 2003 17:34:18 +0100 (CET) To: "Stefan (metze) Metzmacher" Cc: Jan Hudec , Chris Wedgwood , "Stephen C. Tweedie" , viro@math.psu.edu, linux-fsdevel@vger.kernel.org, akpm@zip.com.au, Andreas Dilger , ext2-devel@lists.sourceforge.net, jfs-discussion@www-124.southbury.usf.ibm.com, linux-xfs@oss.sgi.com, Alexander Bokovoy Subject: Re: default quota limits in linux (via quotactl()) X-Url: http://people.mandrakesoft.com/~quintela From: Juan Quintela In-Reply-To: <5.2.0.9.2.20030128142729.0218f398@post.webmailer.de> ("Stefan's message of "Tue, 28 Jan 2003 14:32:30 +0100") References: <20030128112034.GA23731@f00f.org> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030127150905.0217e170@post.strato.de> <5.2.0.9.2.20030128074810.0218c4f8@post.webmailer.de> <20030128093250.GM28513@vagabond> <20030128094014.GA23257@f00f.org> <20030128094619.GO28513@vagabond> <20030128101310.GA23320@f00f.org> <20030128105747.GR28513@vagabond> <20030128112034.GA23731@f00f.org> <5.2.0.9.2.20030128142729.0218f398@post.webmailer.de> Date: Wed, 29 Jan 2003 17:34:18 +0100 Message-ID: <861y2vvrsl.fsf@trasno.mitica> User-Agent: Gnus/5.090012 (Oort Gnus v0.12) Emacs/21.2.92 (i386-mandrake-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2462 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: quintela@mandrakesoft.com Precedence: bulk X-list: linux-xfs Content-Length: 1386 Lines: 38 >>>>> "stefan" == Stefan (metze) Metzmacher writes: stefan> At 13:37 28.01.2003 +0100, Jan Hudec wrote: >> On Tue, Jan 28, 2003 at 03:20:34AM -0800, Chris Wedgwood wrote: >> > On Tue, Jan 28, 2003 at 11:57:47AM +0100, Jan Hudec wrote: >> > >> > > So you can only setquota for the users that actualy log in >> > >> > the API allows you to set quota for any valid uid/gid >> >> Yes, it does. But since there is many more valid users than those >> actualy using the system, you don't want to... And a logged in user is >> sure valid, so no problem there, right? >> >> > > Well, it get's complicated, but you still can setquota in the local >> > > delivery process... I know it get's a bit complicated... >> > >> > sure, this is a perfectly legitimate argument and a fairly reasonable >> > solution to this case >> >> If it finaly got too complicated, you could add a simple code to kernel, >> that would run_usermodehelper and provide a user mode program to fix >> things up. That might even get a chance of being accepted. (And it would >> be more flexible since it can get the default quota from LDAP etc...) stefan> is there an example( another place in the kernel where the kernel stefan> callback a userspace tool) devfsd <-> devfs /me runs Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From owner-linux-xfs@oss.sgi.com Wed Jan 29 11:56:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jan 2003 11:56:30 -0800 (PST) Received: from fed1mtao07.cox.net (fed1mtao07.cox.net [68.6.19.124]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0TJuM3v019621 for ; Wed, 29 Jan 2003 11:56:23 -0800 Received: from Lydian ([68.104.225.216]) by fed1mtao07.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030129200329.NBWT3373.fed1mtao07.cox.net@Lydian> for ; Wed, 29 Jan 2003 15:03:29 -0500 Content-Type: text/plain; charset="us-ascii" From: Josh Helmer To: linux-xfs@oss.sgi.com Subject: DMAPI questions... Date: Wed, 29 Jan 2003 13:03:39 -0700 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200301291303.39958.joshhelmer@cox.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0TJuN3v019622 X-archive-position: 2463 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joshhelmer@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 2447 Lines: 46 Hey folks... Perhaps this is not the appropriate place to ask this... If not, please forgive me, but this looks like just about the best place to get the feedback I am looking for. I am in the early design stages of some backup/HSM software. At this point I am just researching my options and I was hoping someone could help me out with some questions I have about DMAPI in general (since XFS seems to be the only place where anyone is working in this area under linux - at least since the OpenXDSM project died) and about the XFS implementation of DMAPI. One of our requirements is near-real-time backup. Basically what we need to be able to do is duplicate changes to secondary storage as soon as possible, and then after a file has aged we will go back and poke holes as necessary. When a file is accessed we would fill in the holes again. Unfortunately our secondary storage is SIGNIFICANTLY slower than a hard drive (writes at between 1.0 and 1.5Mb/s). Rather than trying to duplicate every write, we were thinking about just adding files to a backup queue when the file is closed. Unfortunately, the easist way that I can see for handling this is to handle the debut event (initialize the event list for a file) and the close event(schedule the file for backup). We understand that this method will not ensure EVERY change to a file is backed up, but for our application, files will not change often enough to make this a big concern. Of course, this will only work if XFS adds support for the debut and close events. Are there any plans to implement these events in XFS? If so, is there an estimate on when this will be available? If not, is there any other way of handling this that I have not considered yet. I have also considered creating a separate write queue. In this implementation I would basically try to consolidate writes (a non-trivial operation with questionable advantages - may just forget about trying that) and then after no write events have appeared after a pre-determined amount of time, flush all writes to the secondary storage. As I stated earlier I am still in the VERY early stages of design and I have probably overlooked some issues (locking and file consistency... ugh... LOTS of work to do there...) with this approach too. Anyhow, any input would be appreciated. Maybe I would be better off just going with the standard NFS-server solution? Thanks, Josh From owner-linux-xfs@oss.sgi.com Wed Jan 29 12:42:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Jan 2003 12:42:54 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0TKgh3v020428 for ; Wed, 29 Jan 2003 12:42:44 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0TJuXKp025749 for ; Wed, 29 Jan 2003 11:56:33 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA66289 for ; Wed, 29 Jan 2003 14:49:50 -0600 (CST) Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA12710 for ; Wed, 29 Jan 2003 14:49:50 -0600 (CST) Received: from chewtoy.americas.sgi.com by chewtoy.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id OAA47358; Wed, 29 Jan 2003 14:49:50 -0600 (CST) Message-Id: <200301292049.OAA47358@chewtoy.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: DMAPI questions... Date: Wed, 29 Jan 2003 14:49:49 -0600 From: Dean Roehrich X-archive-position: 2464 X-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: 3218 Lines: 65 >From: Josh Helmer >Hey folks... > >Perhaps this is not the appropriate place to ask this... If not, please >forgive me, but this looks like just about the best place to get the feedback >I am looking for. > >I am in the early design stages of some backup/HSM software. At this point I > >am just researching my options and I was hoping someone could help me out >with some questions I have about DMAPI in general (since XFS seems to be the >only place where anyone is working in this area under linux - at least since >the OpenXDSM project died) and about the XFS implementation of DMAPI. > >One of our requirements is near-real-time backup. Basically what we need to >be able to do is duplicate changes to secondary storage as soon as possible, >and then after a file has aged we will go back and poke holes as necessary. >When a file is accessed we would fill in the holes again. Unfortunately our >secondary storage is SIGNIFICANTLY slower than a hard drive (writes at >between 1.0 and 1.5Mb/s). Rather than trying to duplicate every write, we >were thinking about just adding files to a backup queue when the file is >closed. Unfortunately, the easist way that I can see for handling this is to >handle the debut event (initialize the event list for a file) and the close >event(schedule the file for backup). We understand that this method will not >ensure EVERY change to a file is backed up, but for our application, files >will not change often enough to make this a big concern. > >Of course, this will only work if XFS adds support for the debut and close >events. Are there any plans to implement these events in XFS? If so, is >there an estimate on when this will be available? If not, is there any other >way of handling this that I have not considered yet. DEBUT is for use on filesystems that don't allow some form of persistent dmattrs. We have persistent dmattrs. We're not going to implement this event ourselves. CLOSE has never been on our to-do list. >I have also considered creating a separate write queue. In this >implementation I would basically try to consolidate writes (a non-trivial >operation with questionable advantages - may just forget about trying that) >and then after no write events have appeared after a pre-determined amount of >time, flush all writes to the secondary storage. As I stated earlier I am >still in the VERY early stages of design and I have probably overlooked some >issues (locking and file consistency... ugh... LOTS of work to do there...) >with this approach too. Anyhow, any input would be appreciated. > >Maybe I would be better off just going with the standard NFS-server solution? Have you spent any time researching existing HSMs? Can we speak in terms of that experience? You speak about wanting near-realtime backup, but say you can't write to the backup device fast enough to do this--which means you're trying for something else. So do you really need to have it appear on the backup device at the same time it appears on the primary device, or do you just need to make sure that the primary device always appears "bottomless" and that writes to it never block? Dean From owner-linux-xfs@oss.sgi.com Thu Jan 30 03:49:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 03:50:02 -0800 (PST) Received: from silver.digirati.com.br (silver.digirati.com.br [200.185.109.126]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UBnv3v005531 for ; Thu, 30 Jan 2003 03:49:59 -0800 Received: from wsmichel (RJ227059.user.veloxzone.com.br [200.165.227.59]) (authenticated (0 bits)) by silver.digirati.com.br (8.11.6/8.11.6) with ESMTP id h0UBvBC32730 for ; Thu, 30 Jan 2003 09:57:12 -0200 Message-ID: <015a01c2c856$bac63610$1601070a@mz.digirati.com.br> From: "Michel Machado" To: References: <200301291303.39958.joshhelmer@cox.net> Subject: Lots of files Date: Thu, 30 Jan 2003 09:57:13 -0200 Organization: Digirati MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 2465 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michel@digirati.com.br Precedence: bulk X-list: linux-xfs Content-Length: 1803 Lines: 53 Hi, Book "Postfix", ISBN 0-672-32114-9, page 46, item "Modified active, bounce, and deferred Queues": ======================== One item of contention for busy mail servers is the message queues. As new messages are received, they are placed in separate files in the message queues. As more files are stores in the message queues, file handling performance decreases. It is a well-known fact on Unix systems that accesing files in a directory containig lots of files is slower than accessing fewer files in muitiple subdirectories. Using this information, Venema has modified the crucial message queue directories (active, bounce, and deferred), subdividing them into new subdirectories. Each of the three main queue directories is split into two levels of subdirectories. Each message is placed into a subdirectory based on the first two characters of its filename. Figure 2.5 demonstrates this layout: /var/spool/postfix/active/ 0/0/ 0023A55F2 00A3CF9D3 0/2/ A/1/ A/B/ ABC343CC2 AB224CD21 As new messages are received in the message queues, corresponding subdirectories are created. As files are retrieved from directories, other message use the subdirectories. Although this structure appears more complicated, it clearly outperforms the old structure in time required to retrieve messages from the message queue. ======================== Is this well-known fact on Unix systems true on XFS? Why? Does the XFS hash algorithm solve this? Is the solution used by Venema good? Why? On XFS? How many files are necessary to produce this effect? 100, 1000, 10000, 100000, 1000000? Book on Amazon: http://www.amazon.com/exec/obidos/ASIN/0672321149/ [ ]'s Michel Machado From owner-linux-xfs@oss.sgi.com Thu Jan 30 04:58:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 04:58:34 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UCwQ3v006964 for ; Thu, 30 Jan 2003 04:58:27 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZBLDBW2T; Thu, 30 Jan 2003 08:05:58 -0500 Received: from wgate.com (localhost.localdomain [127.0.0.1]) by sinz.eng.tvol.net (8.12.5/8.12.5) with ESMTP id h0UD4UPd003646; Thu, 30 Jan 2003 08:04:30 -0500 Message-ID: <3E3922DE.3010606@wgate.com> Date: Thu, 30 Jan 2003 08:04:30 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Machado CC: linux-xfs@oss.sgi.com Subject: Re: Lots of files References: <200301291303.39958.joshhelmer@cox.net> <015a01c2c856$bac63610$1601070a@mz.digirati.com.br> In-Reply-To: <015a01c2c856$bac63610$1601070a@mz.digirati.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2466 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Content-Length: 6169 Lines: 133 Michel Machado wrote: > Hi, > > Book "Postfix", ISBN 0-672-32114-9, page 46, item "Modified active, > bounce, and deferred Queues": > > ======================== [...] > It is a well-known fact on Unix systems that accesing files in a > directory containig lots of files is slower than accessing fewer files in > muitiple subdirectories. Using this information, Venema has modified the > crucial message queue directories (active, bounce, and deferred), > subdividing them into new subdirectories. > > Each of the three main queue directories is split into two levels of > subdirectories. Each message is placed into a subdirectory based on the > first two characters of its filename. > > Figure 2.5 demonstrates this layout: > > /var/spool/postfix/active/ > 0/0/ > 0023A55F2 > 00A3CF9D3 > 0/2/ > A/1/ > A/B/ > ABC343CC2 > AB224CD21 [...] > ======================== > > Is this well-known fact on Unix systems true on XFS? Why? Does the XFS > hash algorithm solve this? While I do not have a system that is *very* large, our tests on somewhat large systems shows that XFS does not have the access problem that linear directory entry filesystems have (such as BSD's filesystem or Linux/EXT2 or MS-DOS FAT(12/16/32)) What this technique basically describes is a hashing mechanism that the application implements due to performance problems within the operating system and filesystem. Depending on what the code does and how it was "tuned" to the behavior patterns of the filesystem(s) it was built on, XFS may or may not be impacted by this. For example, if you do not have the performance problem of many files within a directory, doing the pseudo-hash within the application actually slows things down relative to not doing it. Even ignoring the extra code overhead within the application, you have the fact that opening a file with the name "foobar" will be one directory lookup while opening up the file with "f/o/foobar" will be three directory lookups. When directory lookups are O(n) (UFS/EXT2/etc) then an application hash can drop the time by doing something like the above with something like 3*O(n/(36*36)) (well, assuming you have a nice hash that is 36 (0-9,A-Z) for the first and second character of the name and that the names are evenly distributed) That is a big win. However, if the lookup is more like O(log2 n) (btree) the 3x factor starts to become the primary factor. (Especially since there is some fixed overhead in any directory lookup which is being "ignored" in the O(n) case for large n as the O(n) is significantly greater than the fixed overhead. Once you get to O(log2 n) the fixed overhead becomes a more significant factor) How close a filesystem can get to O(log2 n) is still a complex question due to performance considerations during file creation and deletion. (Those operations become more expensive as you try to keep b-tree structures balanced vs simple linear lists or hash lists) There are other reasons applications may wish to implement a form of "hash" themselves. For example, a mail server needs to "scan" the mail queue to find work it needs to do. In the simplistic case this could significantly impact either memory performance or system throughput due to cache thrash if you scan a single very large directory or do the scan in parts. This is, to some extent, outside the direct details of the filesystem except for what the cost is of enumerating the files within a directory. For example, the Amiga FFS filesystem had a physical disk block per directory entry. Thus, the directory itself was one block and any entries in that directory were their own blocks. This made file access very deterministic and very fast (a very good hashing mechanism helped, along with caches) but caused extra disk operations in order to list all of the files in a directory. (You had to read a block for each file just to get the file names) Thus, you could have a directory such as a "/bin" that had thousands of files in it and have no noticable impact on the speed of command execution but enumerating (ls /bin) such a large directory was significantly slower than on filesystems that have linear access. Thus, the tradeoff that was used was that access to files was seen more important (most common case?) than enumeration of the files. (This was later addressed by adding directory cache that contained the information needed for the enumeration, thus giving linear directory performance for enumeration while still providing full speed file access at the cost of slightly slower create and delete performance) > Is the solution used by Venema good? Why? On XFS? I have not studied the code to see what the performance considerations would be. However, I would say that the mechanism described can be a significant win with many files on any traditional filesystem. (thousands of files level). The point at which more advanced filesystems such as XFS or JFS may show significant gains depends on the behavior of the code. From my tests of XFS scaling performance (this was with many home directories), XFS scales to at least two orders of magnitude more entries than UFS (did not have large enough systems to try more) but in very few entries, the slightly higher overhead of XFS showed UFS slightly faster. (However, in the low numbers case, both were faster than the system needed or even could handle as far as delivering data to the clients - the only cases that we cared about were when performance became an issue and XFS scaled much better than UFS - and not just in directory entried) > How many files are necessary to produce this effect? 100, 1000, 10000, > 100000, 1000000? Sounds like an interesting test should be made of this. I should compile a kernel with as many R/W filesystems as possible and see if I can do some benchmarks to compare them for this type of access pattern. (Or maybe someone has?) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Thu Jan 30 06:20:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 06:20:27 -0800 (PST) Received: from mail-gw.farmexim.ro (mail-gw.farmexim.ro [217.156.6.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UEKD3v008600 for ; Thu, 30 Jan 2003 06:20:13 -0800 Received: from 127.0.0.1 (localhost [127.0.0.1]) by email.farmexim.ro (Postfix) with SMTP id 212FA17ACE for ; Thu, 30 Jan 2003 16:12:23 +0200 (EET) Received: from localhost.localdomain (busybox.farmexim.intern [192.168.1.60]) by mail-gw.farmexim.ro (Postfix) with ESMTP id D142B17AC5 for ; Thu, 30 Jan 2003 16:12:22 +0200 (EET) Subject: su,sw suboptions clarification on fs creation From: Dragos Delcea To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 30 Jan 2003 16:12:22 +0200 Message-Id: <1043935942.6121.32.camel@busybox> Mime-Version: 1.0 X-archive-position: 2467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dragos.delcea@farmexim.ro Precedence: bulk X-list: linux-xfs Content-Length: 703 Lines: 25 Hello, given a recent linux distribution (SuSE 8.1) and a raid 0 logical disk (hardware raid with stripe=16k) with 3 scsi disks, what are the right parameters used at fs creation? I used: #mkfs.xfs -l logdev=/dev/sda3,size=32768b -d \ su=16384,sw=49152,unwritten=0 /dev/sdb1 -f; but I have doubts about sw suboption, in the man page of mkfs.xfs the explanation seemd clear at first, but (I'm not an native english speaker) the more I stare at it, the more confused I get. Should it be sw=(su*number_of_disks)=49152, or sw=number_of_disks=3? also, does "unwritten=0" helps performance? the fs will be used for some datafiles of an oracle test instance (few files, but big ones). thanks, dragos From owner-linux-xfs@oss.sgi.com Thu Jan 30 06:58:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 06:58:13 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UEw63v010338 for ; Thu, 30 Jan 2003 06:58:07 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h0UF5JF16990; Thu, 30 Jan 2003 10:05:19 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 30 Jan 2003 10:05:19 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Dragos Delcea cc: linux-xfs@oss.sgi.com Subject: Re: su,sw suboptions clarification on fs creation In-Reply-To: <1043935942.6121.32.camel@busybox> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2468 X-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: 956 Lines: 27 On 30 Jan 2003 at 4:12pm, Dragos Delcea wrote > given a recent linux distribution (SuSE 8.1) and a raid 0 logical disk > (hardware raid with stripe=16k) with 3 scsi disks, what are the right > parameters used at fs creation? > I used: > > #mkfs.xfs -l logdev=/dev/sda3,size=32768b -d \ > su=16384,sw=49152,unwritten=0 /dev/sdb1 -f; > > but I have doubts about sw suboption, in the man page of mkfs.xfs the > explanation seemd clear at first, but (I'm not an native english > speaker) the more I stare at it, the more confused I get. Should it be > sw=(su*number_of_disks)=49152, or sw=number_of_disks=3? Given my reading of the man page, I think you are correct that sw should be 3. Your other option is to use sunit and swidth switches, which are alternatives to su and sw. These are specified in 512-byte units, and for your setup would be sunit=32768,swidth=98304. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Jan 30 08:05:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 08:05:50 -0800 (PST) Received: from mail-gw.farmexim.ro (mail-gw.farmexim.ro [217.156.6.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UG5V3v011528 for ; Thu, 30 Jan 2003 08:05:31 -0800 Received: from 127.0.0.1 (localhost [127.0.0.1]) by email.farmexim.ro (Postfix) with SMTP id 79FF217ACE; Thu, 30 Jan 2003 17:31:29 +0200 (EET) Received: from localhost.localdomain (busybox.farmexim.intern [192.168.1.60]) by mail-gw.farmexim.ro (Postfix) with ESMTP id 398FF17AC5; Thu, 30 Jan 2003 17:31:29 +0200 (EET) Subject: Re: su,sw suboptions clarification on fs creation From: Dragos Delcea To: Joshua Baker-LePain Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 30 Jan 2003 17:31:29 +0200 Message-Id: <1043940689.6125.42.camel@busybox> Mime-Version: 1.0 X-archive-position: 2469 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dragos.delcea@farmexim.ro Precedence: bulk X-list: linux-xfs Content-Length: 1315 Lines: 44 On Thu, 2003-01-30 at 17:05, Joshua Baker-LePain wrote: > On 30 Jan 2003 at 4:12pm, Dragos Delcea wrote > > > given a recent linux distribution (SuSE 8.1) and a raid 0 logical disk > > (hardware raid with stripe=16k) with 3 scsi disks, what are the right > > parameters used at fs creation? > > I used: > > > > #mkfs.xfs -l logdev=/dev/sda3,size=32768b -d \ > > su=16384,sw=49152,unwritten=0 /dev/sdb1 -f; > > > > but I have doubts about sw suboption, in the man page of mkfs.xfs the > > explanation seemd clear at first, but (I'm not an native english > > speaker) the more I stare at it, the more confused I get. Should it be > > sw=(su*number_of_disks)=49152, or sw=number_of_disks=3? > > Given my reading of the man page, I think you are correct that sw should > be 3. You are right; I wasn't paying attention. At fs creation, it told me: ... sunit=4 swidth=12 blks, unwritten=0 ... which answers my question. I'll do some (write intensive) tests to see if it behaves better than ext2.. cheers, dragos > > Your other option is to use sunit and swidth switches, which are > alternatives to su and sw. These are specified in 512-byte units, and for > your setup would be sunit=32768,swidth=98304. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University > > > From owner-linux-xfs@oss.sgi.com Thu Jan 30 08:12:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 08:12:54 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UGCp3v012034 for ; Thu, 30 Jan 2003 08:12:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0UFQkKp011648 for ; Thu, 30 Jan 2003 07:26:47 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA48288; Thu, 30 Jan 2003 10:20:00 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA67549; Thu, 30 Jan 2003 10:19:55 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h0UGJt711839; Thu, 30 Jan 2003 10:19:55 -0600 Subject: Re: su,sw suboptions clarification on fs creation From: Steve Lord To: Dragos Delcea Cc: linux-xfs@oss.sgi.com In-Reply-To: <1043935942.6121.32.camel@busybox> References: <1043935942.6121.32.camel@busybox> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1043943594.8593.47.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 30 Jan 2003 10:19:55 -0600 X-archive-position: 2470 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 620 Lines: 20 On Thu, 2003-01-30 at 08:12, Dragos Delcea wrote: > > also, does "unwritten=0" helps performance? > the fs will be used for some datafiles of an oracle test instance (few > files, but big ones). > Your other question appears to have been answered, as to this one, for the moment, unwritten=0 is the default on linux and also the only supported configuration. Unwritten extent support is a work in progress still. In general, unwritten=0 will be a little faster. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 30 08:22:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 08:22:37 -0800 (PST) Received: from imf35bis.bellsouth.net (mail341.mail.bellsouth.net [205.152.58.219]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UGMV3v013064 for ; Thu, 30 Jan 2003 08:22:32 -0800 Received: from marsha ([66.156.0.56]) by imf35bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with SMTP id <20030130163140.KLAI8797.imf35bis.bellsouth.net@marsha> for ; Thu, 30 Jan 2003 11:31:40 -0500 Date: Thu, 30 Jan 2003 11:27:44 -0500 From: Greg Freemyer Subject: 3ware - Itanium compatible drivers? To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20030130163140.KLAI8797.imf35bis.bellsouth.net@marsha> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0UGMX3v013069 X-archive-position: 2471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 389 Lines: 17 My company is building up an Itanium based Redhat box that needs 1 TB of storage. They have asked me what the choices are. I have been very impressed with 3ware cards in Pentium systems. Does anyone know if the 3ware x86 drivers work at all in an Itanium? Or have any thoughts about a pure software Raid? I know the md driver can do Raid 1, can it do Raid 5? Thanks Greg Freemyer From owner-linux-xfs@oss.sgi.com Thu Jan 30 08:28:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 08:29:05 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UGSw3v014032 for ; Thu, 30 Jan 2003 08:28:59 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 51FC0AC57; Thu, 30 Jan 2003 17:43:40 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 1F1B3190D5; Thu, 30 Jan 2003 17:43:40 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 2F62E30881D; Thu, 30 Jan 2003 17:36:12 +0100 (CET) Message-ID: <3E39547B.721E16A0@ch.sauter-bc.com> Date: Thu, 30 Jan 2003 17:36:11 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.3 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Greg Freemyer Cc: xfs mailing list Subject: Re: 3ware - Itanium compatible drivers? References: <20030130163140.KLAI8797.imf35bis.bellsouth.net@marsha> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 730 Lines: 25 Greg Freemyer schrieb: > > My company is building up an Itanium based Redhat box that needs 1 TB of storage. > > They have asked me what the choices are. > > I have been very impressed with 3ware cards in Pentium systems. > > Does anyone know if the 3ware x86 drivers work at all in an Itanium? > > Or have any thoughts about a pure software Raid? > > I know the md driver can do Raid 1, can it do Raid 5? It does RAID5 and it does it very well. The only problem with older XFS versions was that performance was bad with internal log. An external log on RAID1 on the same disks was the solution for me. It looks like recent XFS versions work much better on RAID5 with internal log too. Simon > > Thanks > Greg Freemyer From owner-linux-xfs@oss.sgi.com Thu Jan 30 08:31:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 08:31:34 -0800 (PST) Received: from waltsathlon.localhost.net (12-229-130-237.client.attbi.com [12.229.130.237]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UGVU3v014468 for ; Thu, 30 Jan 2003 08:31:31 -0800 Received: from comcast.net (localhost.localhost.net [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 1C06D1C31BE0; Thu, 30 Jan 2003 08:38:42 -0800 (PST) Message-ID: <3E395511.4040505@comcast.net> Date: Thu, 30 Jan 2003 08:38:41 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030121 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Freemyer Cc: xfs mailing list Subject: Re: 3ware - Itanium compatible drivers? References: <20030130163140.KLAI8797.imf35bis.bellsouth.net@marsha> In-Reply-To: <20030130163140.KLAI8797.imf35bis.bellsouth.net@marsha> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: waltabbyh@comcast.net Precedence: bulk X-list: linux-xfs Content-Length: 882 Lines: 29 I have a server at work that uses a six disk software raid 5 setup. I use version 2 logging and it's worked pretty well so far. Reads and writes are excellent, with creates/deletes lagging somewhat (as expected). If I would have used an external log, I'm sure delete performance would be fine, but for our intended use of the server it's more than adequate as-is. From my experience, software md raid with XFS works great. -Walt Greg Freemyer wrote: > My company is building up an Itanium based Redhat box that needs 1 TB of storage. > > They have asked me what the choices are. > > I have been very impressed with 3ware cards in Pentium systems. > > Does anyone know if the 3ware x86 drivers work at all in an Itanium? > > Or have any thoughts about a pure software Raid? > > I know the md driver can do Raid 1, can it do Raid 5? > > Thanks > Greg Freemyer > > > From owner-linux-xfs@oss.sgi.com Thu Jan 30 08:33:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 08:33:59 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UGXu3v014903 for ; Thu, 30 Jan 2003 08:33:57 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id h0UGaBK17130; Thu, 30 Jan 2003 11:36:11 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 30 Jan 2003 11:36:11 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Greg Freemyer cc: xfs mailing list Subject: Re: 3ware - Itanium compatible drivers? In-Reply-To: <20030130163140.KLAI8797.imf35bis.bellsouth.net@marsha> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2474 X-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: 570 Lines: 21 On Thu, 30 Jan 2003 at 11:27am, Greg Freemyer wrote > Does anyone know if the 3ware x86 drivers work at all in an Itanium? That seems to be a question for 3ware. Their latest driver set (7.5.3 for the 7000 series cards) claims support for 64-bit architectures, but doesn't mention IA64 specifically. > Or have any thoughts about a pure software Raid? It generally gets very good reviews, if you have the cycles to spare. > I know the md driver can do Raid 1, can it do Raid 5? Yes. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Jan 30 09:21:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 09:22:00 -0800 (PST) Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UHLd3v016206; Thu, 30 Jan 2003 09:21:40 -0800 Received: from smtpscan-nl4.philips.com (smtpscan-nl4.philips.com [130.139.36.24]) by gw-nl4.philips.com (Postfix) with ESMTP id EE436A3A5E; Thu, 30 Jan 2003 17:57:56 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA20001; Thu, 30 Jan 2003 17:57:56 +0100 (MET) From: darren.miller@philips.com Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA26081; Thu, 30 Jan 2003 17:57:56 +0100 (MET) To: Greg Freemyer Cc: xfs mailing list , linux-xfs-bounce@oss.sgi.com Subject: Re: 3ware - Itanium compatible drivers? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 30 Jan 2003 16:55:39 +0000 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 30/01/2003 17:58:57, Serialize complete at 30/01/2003 17:58:57 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 2475 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: darren.miller@philips.com Precedence: bulk X-list: linux-xfs Content-Length: 1408 Lines: 66 Try compiling the sources on an IA64 system, just a thought. I do however use the 3Ware 7500-8 on Slackware and have compiled the sources which come with 7.5.3 driver package for redhat and that works fine, infact the driver actually comes as part of the 2.4.18 and above kernel so I would hope so. ;-) Daz ============================================================================== Darren Miller Senior Systems Support Engineer Microsoft Certified Professional SCO Advanced Certified Engineer Infomation Systems Department (Core Server Support) Philips Semiconductors,Milbrook Industrial Estate,Southampton,SO15 0DJ,England Direct Dial In: (02380) 312681 Greg Freemyer Sent by: linux-xfs-bounce@oss.sgi.com 30/01/2003 16:27 To: xfs mailing list cc: (bcc: Darren Miller/SOU/SC/PHILIPS) Subject: 3ware - Itanium compatible drivers? Classification: My company is building up an Itanium based Redhat box that needs 1 TB of storage. They have asked me what the choices are. I have been very impressed with 3ware cards in Pentium systems. Does anyone know if the 3ware x86 drivers work at all in an Itanium? Or have any thoughts about a pure software Raid? I know the md driver can do Raid 1, can it do Raid 5? Thanks Greg Freemyer [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jan 30 10:02:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 10:02:41 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UI2V3v016968 for ; Thu, 30 Jan 2003 10:02:32 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0UI9W9R020901; Thu, 30 Jan 2003 19:09:33 +0100 (CET) Message-Id: <4.3.2.7.2.20030130185641.041601d0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Jan 2003 19:09:22 +0100 To: Greg Freemyer , xfs mailing list From: Seth Mos Subject: Re: 3ware - Itanium compatible drivers? In-Reply-To: <20030130163140.KLAI8797.imf35bis.bellsouth.net@marsha> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1136 Lines: 31 At 11:27 30-1-2003 -0500, Greg Freemyer wrote: >Or have any thoughts about a pure software Raid? I like software raid, good value for the price. It's fast too. >I know the md driver can do Raid 1, can it do Raid 5? Yes, for the best performance you should at least use the version 2 log(journal) with a md raid5 or even better, use a external logdevice. A raid 1 system disk would be a good candidate. Note that putting the external logdevice on a different drive _can_ result in a performance bottleneck when you have more concurrent metadata throughput (not data!) then the external logdevice can shove. My suggestion, put 2 15K rpm scsi disks in a raid 1 config (may be software raid) for the root and boot drive and put the external logdevice on here as well. Then use the rest of the disks for a software raid 5 container with about 4-5 disks per scsi channel (if you use scsi). The faster logdevice disks can do a lot of IO per second which will help a busy filesystem. If 3ware does deliver cards for IA64 the external log device issue is moot. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jan 30 11:04:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 11:04:27 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UJ4L3v018131 for ; Thu, 30 Jan 2003 11:04:21 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0UJK0kq017893 for ; Thu, 30 Jan 2003 13:20:00 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA74417 for ; Thu, 30 Jan 2003 13:11:31 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA37582 for ; Thu, 30 Jan 2003 13:11:31 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h0UJBV214839; Thu, 30 Jan 2003 13:11:31 -0600 Message-Id: <200301301911.h0UJBV214839@jen.americas.sgi.com> Date: Thu, 30 Jan 2003 13:11:31 -0600 Subject: TAKE - fix some bio intialization code To: linux-xfs@oss.sgi.com X-archive-position: 2477 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 371 Lines: 16 fix initialization of bio in end case where we are dealing with sub page sized requests. Date: Thu Jan 30 11:10:35 PST 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:138201a linux/fs/xfs/pagebuf/page_buf.c - 1.92 - fix some bio init code From owner-linux-xfs@oss.sgi.com Thu Jan 30 11:21:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Jan 2003 11:21:44 -0800 (PST) Received: from imf23bis.bellsouth.net (mail223.mail.bellsouth.net [205.152.58.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0UJLf3v018672 for ; Thu, 30 Jan 2003 11:21:41 -0800 Received: from marsha ([66.156.0.56]) by imf23bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with SMTP id <20030130193048.KXDY3112.imf23bis.bellsouth.net@marsha>; Thu, 30 Jan 2003 14:30:48 -0500 Date: Thu, 30 Jan 2003 14:26:51 -0500 From: Greg Freemyer Subject: re[2]: 3ware - Itanium compatible drivers? To: Seth Mos , xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20030130193048.KXDY3112.imf23bis.bellsouth.net@marsha> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0UJLg3v018673 X-archive-position: 2478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 683 Lines: 25 >> At 11:27 30-1-2003 -0500, Greg Freemyer wrote: >> >Or have any thoughts about a pure software Raid? >> I like software raid, good value for the price. It's fast too. Seth, Thanks for the info. BTW: I believe a 3ware based 1TB FS will be cheaper than a software RAID using SCSI. i.e. RAID 5 = 8 port 3ware controller + 6 * 200 Gig IDE drives (7200 RPM) = $400 + 6 * $300 = $2200 And it could fit into a single large tower. (I don't know if they want a tower or a rack mount for this project.) And if you don't know the 3ware card eliminates the single tasking nature of ide, so it should be as fast as a 6 drive (7200 RPM) scsi array. Greg Freemyer From owner-linux-xfs@oss.sgi.com Fri Jan 31 09:56:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Jan 2003 09:56:20 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c6e90c22-CM014280010574.cpe.net.cable.rogers.com [24.43.161.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0VHuE3v026913 for ; Fri, 31 Jan 2003 09:56:15 -0800 Received: from contact.skynet.coplanar.net (contact.skynet.coplanar.net [192.168.7.125]) by stargate.coplanar.net (8.11.6/8.11.6) with ESMTP id h0VI3We02882; Fri, 31 Jan 2003 13:03:32 -0500 Subject: Re: some XFS questions From: Jeremy Jackson To: Kwon SoonSon Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030127083818.84351.qmail@web7306.mail.yahoo.co.kr> References: <20030127083818.84351.qmail@web7306.mail.yahoo.co.kr> Content-Type: text/plain Organization: Message-Id: <1044035930.7609.3.camel@contact.skynet.coplanar.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 31 Jan 2003 12:58:50 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 900 Lines: 26 On Mon, 2003-01-27 at 03:38, Kwon SoonSon wrote: > Hello, XFS folks... > I am studying the XFS internals and got some questions > regarding its detailed design. > > 1. what is the "uuid" for? I found that XFS has its > magic > number already. Then why is there "uuid"? It used among other things by the backup utility to uniquely identify a filesystem, even if the mount point and/or physical device it resides on changes (ie scsi id changes) > 5. is there any plan to support "snapshot" feature > in XFS in the near future or any existing one? > I actually have not tested XFS myself yet but very > interested > in using snapshot on it. http://evms.sourceforge.net I am using EVMS with XFS and the snapshots are very easy to use. You just have to apply 1 extra xfs-vfs-lock patch when installing EVMS into your kernel source tree, then it can be used easily by the GUI or command line tools. From owner-linux-xfs@oss.sgi.com Fri Jan 31 11:48:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Jan 2003 11:48:36 -0800 (PST) Received: from imf48bis.bellsouth.net (mail137.mail.bellsouth.net [205.152.58.97]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0VJmO3v028611 for ; Fri, 31 Jan 2003 11:48:27 -0800 Received: from marsha ([66.156.1.73]) by imf48bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with SMTP id <20030131195738.TNEK10199.imf48bis.bellsouth.net@marsha>; Fri, 31 Jan 2003 14:57:38 -0500 Date: Fri, 31 Jan 2003 14:53:43 -0500 From: Greg Freemyer Subject: re[2]: some XFS questions To: Jeremy Jackson , Kwon SoonSon cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20030131195738.TNEK10199.imf48bis.bellsouth.net@marsha> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h0VJmR3v028612 X-archive-position: 2484 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1027 Lines: 26 >> > 5. is there any plan to support "snapshot" feature >> > in XFS in the near future or any existing one? >> > I actually have not tested XFS myself yet but very >> > interested >> > in using snapshot on it. >> http://evms.sourceforge.net >> I am using EVMS with XFS and the snapshots are very easy to use. >> You just have to apply 1 extra xfs-vfs-lock patch when installing >> EVMS into your kernel source tree, then it can be used easily by the >> GUI or command line tools. EVMS is going through some pretty radical restructuring right now. If you are not already using it, I would wait a few months for it to settle down. FYI: With the new structure, Device Mapper (dm) from Sistina is providing the kernel APIs and a lot of functionality. Then EVMS will be providing dm plug-ins for any unique kernel features they need. The user land parts of EVMS are not being drastically changed, except now they talk to dm (and md??) instead of talking to a dedicated EVMS kernel api. Greg Freemyer From owner-linux-xfs@oss.sgi.com Fri Jan 31 14:24:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Jan 2003 14:24:14 -0800 (PST) Received: from ohsmtp01.ogw.rr.com (ohsmtp01.ogw.rr.com [65.24.7.36]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0VMO53v031076 for ; Fri, 31 Jan 2003 14:24:06 -0800 Received: from dynamix-ltd.com (dhcp024-208-191-088.columbus.rr.com [24.208.191.88]) by ohsmtp01.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h0VMVLXc013866 for ; Fri, 31 Jan 2003 17:31:26 -0500 (EST) Message-ID: <3E3B0517.1090008@dynamix-ltd.com> Date: Fri, 31 Jan 2003 18:21:59 -0500 From: Andy Skunza User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: dumb mkfs question Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: askunza@dynamix-ltd.com Precedence: bulk X-list: linux-xfs Content-Length: 241 Lines: 6 Is it possible to retrieve the data on an xfs partition after it was mkfs'ed (with -t xfs) for a second time? In this case, the partition was quickly unmounted and hasn't been used since. I'm using linux 2.4.18, xfs 1.1, xfs tools 2.0.3 From owner-linux-xfs@oss.sgi.com Fri Jan 31 14:50:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Jan 2003 14:50:16 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h0VMo73v031700 for ; Fri, 31 Jan 2003 14:50:08 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id h0VMvRHK015523; Fri, 31 Jan 2003 23:57:27 +0100 (CET) Message-Id: <4.3.2.7.2.20030131230850.043eb348@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Jan 2003 23:47:12 +0100 To: jakob@unthought.net, DCox@SnapServer.com, linux-xfs@oss.sgi.com, linux-raid@vger.rutgers.edu From: Seth Mos Subject: Growing a Software Raid 5 array with XFS on it. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 3843 Lines: 106 Hi, This is the log of a semi succesful conversion of a software raid 5 array with raidreconf from a 3 disk array to a 4 disk array. raidreconf is a utility to add disks to a existing raid 0 or 5 array. In this case it involved a 3 disk raid 5 array with XFS (version 1 log) on it. The operating system was Red Hat Linux 7.3 Raidreconf was version 0.1.2. The partitions were about 40GB each. The raid was about 77GB netto. The filesystem contained about 39GB of data. The old raidtab entry looked like this: # md0 is the /data raid array raiddev /dev/md0 raid-level 5 nr-raid-disks 3 chunk-size 128 parity-algorithm left-symmetric # Spare disks for hot reconstruction nr-spare-disks 0 persistent-superblock 1 # Define 1st RAID disk device /dev/hde1 raid-disk 0 # Define 2nd RAID disk device /dev/hdg1 raid-disk 1 # Define 3rd RAID disk device /dev/hdb1 raid-disk 2 The new one looked like this: # md0 is the /data raid array raiddev /dev/md0 raid-level 5 nr-raid-disks 4 chunk-size 128 parity-algorithm left-symmetric # Spare disks for hot reconstruction nr-spare-disks 0 persistent-superblock 1 # Define 1st RAID disk device /dev/hde1 raid-disk 0 # Define 2nd RAID disk device /dev/hdg1 raid-disk 1 # Define 3rd RAID disk device /dev/hdb1 raid-disk 2 # Define 4th RAID disk device /dev/hdc9 raid-disk 3 The partition tables looked something like this. /dev/hde1 1 77207 38912296+ fd Linux raid autodetect /dev/hdg1 1 77207 38912296+ fd Linux raid autodetect /dev/hdb1 1 4972 39937558+ fd Linux raid autodetect /dev/hdc9 52014 131252 39936424+ fd Linux raid autodetect And yes I am very aware that putting 2 7200RPM IDE disks on one UDMA33 channel is not the fastest thing to do. New ide controller for two more ports arriving soon. The procedure involves stopping the /dev/md0 raid array and start the conversion with: raidreconf -o /etc/raidtab.old -n /etc/raidtab.new -m /dev/md0 All this went reasonably well but on the last few percent of the reconstruction raidreconf barfed. I don't have the exact error but it reached this error (by grepping the source): rrc_raid5.c.backup: fprintf "raid5_map_global_to_local: disk %d block out of range: %lu (%lu) gblock = %lu\n" in this case the error was on block 60500 out of 61500 something. The disk was number 1. Because this happened with just one hash mark to go I ad some hope that the filesystem would be mostly intact. The process already ran for about 2 hours. I recreated the /dev/md0 array with the new raidtab and it started resyncing. I checked the filesystem with xfs-repair -n and it reported a few directory entries and one which it would move to lost and found. I ran xfs_repair and mounted the filesystem, and sure enough just one dierctory with about 10 files in it was damaged. The next step was growing the filesystem to it's new size. This was easily done and without error using xfs_growfs. The /data raid 5 is now 4 disks of 40GB each and the netto space is 111GB. The growing is only and was done with the raid array still resyncing. This took about 10 seconds. I got really lucky I guess. At least I don't have to restore a lot of data from backup. AND YES YOU DO NEED BACKUPS. It's good that the manual for raidreconf explicitly states this and every webpage that mentions raidreconf. It's all working now but this is one for the archives. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Jan 31 17:56:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Jan 2003 17:56:42 -0800 (PST) Received: from dea.linux-mips.net (p508B6159.dip.t-dialin.net [80.139.97.89]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id h111uW3v003721 for ; Fri, 31 Jan 2003 17:56:33 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id h1123u907871; Sat, 1 Feb 2003 03:03:56 +0100 Date: Sat, 1 Feb 2003 03:03:56 +0100 From: Ralf Baechle To: linux-xfs@oss.sgi.com Subject: [ADMIN] Virus killers running amok Message-ID: <20030201030356.E5321@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 2487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ralf@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1264 Lines: 23 Due to today's email virus incident this as a reminder for mail admins - an automatic system should never reply to mail with "Precedence: bulk" or "Precedence: list" header. It's dangerous because such automatic mails may potencially result in mail loops. Anway, bulk or list precende means the sender doesn't care anyway. - In sense of RFC2821 the reply is an error message because of non-delivery. An error message should only be sent to the envelope sender, linux-xfs-bounce@oss.sgi.com in this particular case. Sending to the To: and Cc: addresses is completly broken. - Your software is setup to use just "Administrator" as the sender address. A RFC compliant mailer such as on oss.sgi.com will canonicalize the address of the received mail that is add it's own hostname which results in your mails showing up as if they were from Administrator@oss.sgi.com. - It's annoying for the nearly 1,000 list subscribers. Most are running Linux or UNIX or have their own virus killers so don't care the least bit about that notification. Automatic systems So fix your systems. You only have one chance - and that's your LAST change - before you endup in mail filters around the world so use it. Ralf (BOFH on duty ...)