From owner-linux-xfs@oss.sgi.com Thu Feb 1 00:58:03 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 00:57:44 -0800 Received: from drone5-svc-skyt.qsi.net.nz ([202.89.128.5]:34572 "HELO drone5.qsi.net.nz") by oss.sgi.com with SMTP id ; Thu, 1 Feb 2001 00:57:22 -0800 Received: (qmail 79007 invoked by uid 0); 1 Feb 2001 08:57:19 -0000 Received: from unknown (HELO adam) ([202.89.144.19]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 1 Feb 2001 08:57:19 -0000 From: "Adam Warner" To: Subject: RE: xfs installer (SGI Pre-Release ISO) Date: Thu, 1 Feb 2001 21:57:45 +1200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A78DDE2.C7C36D0C@sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi Eric, Well I gave it my best shot--twice. The advice was really helpful. In this end this is how I distilled the commands: cd /tmp mknod hde1 (b 3 didn't work because I had to provide a major AND minor number) mount -t xfs /mnt/A chroot /mnt/A And volia! The partition is mounted at / There was nothing wrong with lilo.conf. And it was parsed by lilo fine. I also tried booting with the non-smp kernel. Unfortunately with my particular hardware configuration I couldn't get it to boot. Not even a solitary boot message. I'm sure I could get it to work by removing my hard disk from the third ide controller (hde, first HPT366 controller) and putting it on the first standard IDE controller (hda). But I'm not prepared to do that at the moment. Anyway, thanks for your assistance. I've learned some new recovery techniques, even if they weren't successful this time. Does anyone know if SGI is talking with Redhat about including the XFS file system in Redhat's next release? Regards, Adam -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On Behalf Of Eric Sandeen Sent: Thursday, 1 February 2001 3:54 p.m. To: Adam Warner Cc: linux-xfs@oss.sgi.com Subject: Re: xfs installer (SGI Pre-Release ISO) Adam Warner wrote: > Thanks. Knowing how to create my own devices is beyond me at this stage. I > was not able to properly mount /dev/hde1 and received this error message: > mount failed: block device required. See the installer caveats at http://oss.sgi.com/projects/xfs/pr_installer.html for hints on making devices... It's not too bad. Use "linux rescue" off the installer CD. Check /proc/devices to make sure you have IDE support at all (you should see "hd" or "ide" - I'm not sure...). Insert modules as necessary (ide-mod, ide-disk, ide-cd...). You can make devices as follows: cd /tmp mknod hda b 3 (i.e. mknod hda1 b 3) mknod hda b 3 (if you have /boot) mount hda /mnt/A mount hda /mnt/A/boot chroot /mnt/A Now you should be able to do some lilo work... if you need to recreate the initial ramdisk: /sbin/mkinitrd /boot/initrd-2.4.0-SGI_XFS_PR.img 2.4.0-SGI_XFS_PR vi /etc/lilo.conf add to the correct kernel entry: initrd=/boot/initrd-2.4.0-SGI_XFS_PR.img /sbin/lilo -v When you're done: exit (out of chrooted shell) umount /mnt/A/boot umount /mnt/A From owner-linux-xfs@oss.sgi.com Thu Feb 1 02:50:54 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 02:50:35 -0800 Received: from [212.184.85.82] ([212.184.85.82]:50441 "EHLO lulu.kehl.dalim.de") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 02:50:09 -0800 Received: from horace.kehl.dalim.de (horace.kehl.dalim.de [192.168.111.70]) by lulu.kehl.dalim.de (8.9.3/8.8.7) with SMTP id MAA32135 for <@lulu.kehl.dalim.de:linux-xfs@oss.sgi.com>; Thu, 1 Feb 2001 12:46:21 +0100 Received: from dalim.de by horace.kehl.dalim.de via ESMTP (940816.SGI.8.6.9/940406.SGI) for id LAA13700; Thu, 1 Feb 2001 11:46:58 +0100 Message-ID: <3A793EA1.CEDB61DD@dalim.de> Date: Thu, 01 Feb 2001 11:46:57 +0100 From: Stephane KLEIN X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: ide-cd not loaded on boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi have tested the ISO image installation with two servers: SGI 1200 and HP LH2000. Both had the same problems: I was not able to put an XFS partition on the root filesystem because the system is not able to mount it during the first reboot. This is probably due to the fact that the /etc/hosts file uses a label "/" for the root fs and XFS does not seems to have any label on its partitions. The other problem is with devfs and some devices like the mouse and the cd. During the boot the ide-cd module is not loaded and the device nodes for the cd are not created. I can fix this by modifying the init scripts but I would like to know the real solution. For the mouse the problem is that XFree86 is trying to use /dev/mouse which does not exist. We are currently investigating to find a Linux distribution/hardware that could handle big server config like 4CPU, >2Gb ram, 500G raid. Could you please tell me how to fix these problems ? From owner-linux-xfs@oss.sgi.com Thu Feb 1 04:30:14 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 04:30:04 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:15370 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Thu, 1 Feb 2001 04:29:56 -0800 Received: (qmail 23093 invoked from network); 1 Feb 2001 12:29:50 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 1 Feb 2001 12:29:50 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Adam Warner" cc: linux-xfs@oss.sgi.com Subject: Re: xfs installer (SGI Pre-Release ISO) In-reply-to: Your message of "Thu, 01 Feb 2001 21:57:45 +1200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 2001 23:29:50 +1100 Message-ID: <16141.981030590@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 1 Feb 2001 21:57:45 +1200, "Adam Warner" wrote: >I'm sure I could get it to work by removing my hard disk from the third ide >controller (hde, first HPT366 controller) and putting it on the first >standard IDE controller (hda). But I'm not prepared to do that at the >moment. Try booting with command line option "ide=reverse". That should scan ide 3/4 before 1/2. Another possibility is adding these lines to lilo.conf. disk=/dev/hde bios=0x80 From owner-linux-xfs@oss.sgi.com Thu Feb 1 05:10:34 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 05:10:14 -0800 Received: from dollar.ecetra.com ([193.164.224.209]:43683 "EHLO msg.ecetra.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 05:09:59 -0800 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id OAA10381 for ; Thu, 1 Feb 2001 14:09:51 +0100 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.9.3/8.9.3) with ESMTP id OAA05923 for ; Thu, 1 Feb 2001 14:09:56 +0100 Date: Thu, 1 Feb 2001 14:09:56 +0100 (CET) From: CioccarelliA To: Subject: XFS on Slackware Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I was just wondering if anybody else on the mailing list is running xfs with slackware. If so does anyone have it running on the root partition? I am after any tips I can get before converting the root partition to xfs. Although I am not expecting any problems as I have been running xfs for about 3 months now on my /opt partition where I have my home directory, most of my software, vmware and an oracle database! Adam From owner-linux-xfs@oss.sgi.com Thu Feb 1 07:25:14 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 07:25:05 -0800 Received: from hermes.mixx.net ([212.84.196.2]:23825 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 1 Feb 2001 07:24:58 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 0E2D0F80E for ; Thu, 1 Feb 2001 16:24:56 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id BA2CA2CA6F; Thu, 1 Feb 2001 16:24:55 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs_mount manpage Date: 1 Feb 2001 15:24:55 GMT Organization: innominate AG, Berlin, Germany Lines: 11 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 981041095 30988 10.0.0.31 (1 Feb 2001 15:24:55 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing wasn't there a manpage describing the xfs mount-options? - looks it got lost in the xfs-cmds restructuring ... (but maybe i only did not find it :-) t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Thu Feb 1 07:33:14 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 07:33:05 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:49940 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 07:32:52 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA09431 for ; Thu, 1 Feb 2001 07:32:51 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA668675; Thu, 1 Feb 2001 09:30:17 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA88053; Thu, 1 Feb 2001 09:30:17 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f11FUuH30066; Thu, 1 Feb 2001 09:30:56 -0600 Message-Id: <200102011530.f11FUuH30066@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Thomas Graichen , thomas.graichen@innominate.com cc: linux-xfs@oss.sgi.com Subject: Re: xfs_mount manpage In-Reply-To: Message from Thomas Graichen of "01 Feb 2001 15:24:55 GMT." Date: Thu, 01 Feb 2001 09:30:56 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > wasn't there a manpage describing the xfs mount-options? - looks it > got lost in the xfs-cmds restructuring ... (but maybe i only did > not find it :-) I asked this question myself the other day. Some mount options are described here: Documentation/filesystems/xfs.txt this does not currently mention kio and kiocluster. I think a patch was submitted to the mount maintainer containing man page updates for xfs options - but I may be mis-remembering that. Steve > > t > > -- > thomas.graichen@innominate.com > innominate AG > the linux architects > tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Thu Feb 1 08:10:25 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 08:10:15 -0800 Received: from mail11.jump.net ([206.196.91.11]:17321 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 08:09:58 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f11G9ki29542; Thu, 1 Feb 2001 10:09:46 -0600 (CST) Message-ID: <3A7901A5.22DD96C5@sgi.com> Date: Thu, 01 Feb 2001 00:26:45 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephane KLEIN CC: linux-xfs@oss.sgi.com Subject: Re: ide-cd not loaded on boot References: <3A793EA1.CEDB61DD@dalim.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Stephane KLEIN wrote: > I was not able to put an XFS partition on the root filesystem because > the system is not able to mount it during the first reboot. This is > probably due to the fact that the /etc/hosts file uses a label "/" for > the root fs and XFS does not seems to have any label on its partitions. (/etc/hosts? I assume you mean /etc/fstab?) I have not seen label problems like this before... the booting problems I've seen so far have been either lilo-related, or some people have seen the installer de-select formatting the root FS by default. You might try using the CD in rescue mode ("boot: linux rescue") and poke around to see what the format the / filesystem really is - there's a chance that it's ext2, but /etc/fstab says "xfs". > The other problem is with devfs and some devices like the mouse and the > cd. During the boot the ide-cd module is not loaded and the device nodes > for the cd are not created. I can fix this by modifying the init scripts > but I would like to know the real solution. For the mouse the problem is > that XFree86 is trying to use /dev/mouse which does not exist. This is on the caveats list. The installer does not configure mouse devices correctly, and/or devfsd is not configured to provide the devices that Red Hat expects. (You can look at it either way). You can work around this by either modifying your /etc/fstab, /etc/X11/XF86Config, etc. for the new devices devfs provides, or by configuring /etc/devfsd.conf to provide the devices that Red Hat expects. One of the problems with automatic module loading is that /etc/modules.devfs is missing from the devfsd RPM - this file helps devfsd auto-load modules as necessary. See this and other caveats at http://oss.sgi.com/projects/xfs/installcavs.html -Eric From owner-linux-xfs@oss.sgi.com Thu Feb 1 08:17:45 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 08:17:35 -0800 Received: from mail15.jump.net ([206.196.91.15]:6125 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 08:17:32 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f11GHJ104866; Thu, 1 Feb 2001 10:17:19 -0600 (CST) Message-ID: <3A798C0E.180B526@sgi.com> Date: Thu, 01 Feb 2001 10:17:18 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Adam Warner CC: linux-xfs@oss.sgi.com Subject: Re: xfs installer (SGI Pre-Release ISO) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Adam Warner wrote: > > Hi Eric, > > Well I gave it my best shot--twice. > > The advice was really helpful. In this end this is how I distilled the > commands: > > cd /tmp > mknod hde1 (b 3 didn't work because I had to provide a major AND minor > number) > mount -t xfs /mnt/A > chroot /mnt/A Oh, I'm sorry... there was a typo on our help page, and I was reading from it on autopilot... should be: cd /tmp mknod hda b 3 (i.e. mknod hda1 b 3 1) mknod hda b 3 (if you have /boot) mount hda /mnt/A mount hda /mnt/A/boot chroot /mnt/A (that's checked in for the web page now). I'll bet that one of Keith's suggestions fixes your problem - you have to tell Lilo where to look for the drive in your system. -Eric From owner-linux-xfs@oss.sgi.com Thu Feb 1 09:11:05 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 09:10:55 -0800 Received: from smtp5.xs4all.nl ([194.109.6.49]:34766 "EHLO smtp5.xs4all.nl") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 09:10:50 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA25291 for ; Thu, 1 Feb 2001 18:10:36 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA10530 for ; Thu, 1 Feb 2001 18:10:36 +0100 (CET) Date: Thu, 1 Feb 2001 18:10:36 +0100 (CET) From: Seth Mos To: linux-xfs@oss.sgi.com Subject: Slashdot announcement (OT) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, The XFS Prerelease announcement got posted to slashdot. Just for your information, the fire is spreading. I know it's offtopic. But hey it's kinda cool. Bye Seth From owner-linux-xfs@oss.sgi.com Thu Feb 1 09:15:35 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 09:15:27 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:45391 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 09:15:08 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08094 for ; Thu, 1 Feb 2001 09:15:04 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA669831 for ; Thu, 1 Feb 2001 11:12:33 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA29932 for ; Thu, 1 Feb 2001 11:12:33 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f11HDB423696; Thu, 1 Feb 2001 11:13:11 -0600 Message-Id: <200102011713.f11HDB423696@jen.americas.sgi.com> Date: Thu, 1 Feb 2001 11:13:11 -0600 Subject: TAKE - Bump xfs development tree to 2.4.1 base To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Merge XFS tree upto 2.4.1, should trickle out to cvs in the next few hours. Date: Thu Feb 1 09:10:24 PST 2001 Workarea: jen.americas.sgi.com:/src/lord/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:84663a linux/fs/reiserfs/stree.c - 1.1 linux/fs/reiserfs/super.c - 1.1 linux/fs/reiserfs/tail_conversion.c - 1.1 linux/fs/reiserfs/version.c - 1.1 linux/include/asm-ppc/parport.h - 1.1 linux/drivers/acpi/acpi_ksyms.c - 1.1 linux/fs/reiserfs/resize.c - 1.1 linux/fs/reiserfs/prints.c - 1.1 linux/drivers/char/drm/radeon_bufs.c - 1.1 linux/drivers/char/drm/radeon_context.c - 1.1 linux/drivers/char/drm/radeon_cp.c - 1.1 linux/drivers/char/drm/radeon_drm.h - 1.1 linux/drivers/char/drm/radeon_drv.c - 1.1 linux/drivers/char/drm/radeon_drv.h - 1.1 linux/drivers/char/drm/radeon_state.c - 1.1 linux/fs/reiserfs/objectid.c - 1.1 linux/drivers/acpi/hardware/hwsleep.c - 1.1 linux/drivers/acpi/hardware/hwtimer.c - 1.1 linux/fs/reiserfs/namei.c - 1.1 linux/fs/reiserfs/lbalance.c - 1.1 linux/arch/sparc64/kernel/pci_schizo.c - 1.1 linux/fs/reiserfs/journal.c - 1.1 linux/fs/reiserfs/item_ops.c - 1.1 linux/fs/reiserfs/ioctl.c - 1.1 linux/fs/reiserfs/inode.c - 1.1 linux/fs/reiserfs/ibalance.c - 1.1 linux/fs/reiserfs/hashes.c - 1.1 linux/fs/reiserfs/fix_node.c - 1.1 linux/drivers/md/lvm-snap.h - 1.1 linux/fs/reiserfs/file.c - 1.1 linux/fs/reiserfs/do_balan.c - 1.1 linux/fs/reiserfs/dir.c - 1.1 linux/fs/reiserfs/buffer2.c - 1.1 linux/include/asm-sparc64/watchdog.h - 1.1 linux/include/linux/reiserfs_fs.h - 1.1 linux/include/linux/reiserfs_fs_i.h - 1.1 linux/include/linux/reiserfs_fs_sb.h - 1.1 linux/fs/reiserfs/bitmap.c - 1.1 linux/fs/reiserfs/README - 1.1 linux/fs/reiserfs/Makefile - 1.1 linux/arch/ppc/kernel/proc_rtas.c - 1.1 linux/drivers/usb/storage/unusual_devs.h - 1.1 linux/drivers/acpi/interpreter/amconvrt.c - 1.1 linux/arch/ppc/kernel/open_pic_defs.h - 1.1 linux/arch/ppc/kernel/error_log.h - 1.1 linux/arch/ppc/kernel/error_log.c - 1.1 linux/drivers/sbus/char/cpwatchdog.c - 1.1 linux/arch/ppc/configs/power3_defconfig - 1.1 linux/net/ipv6/netfilter/ip6table_mangle.c - 1.1 linux/arch/ppc/configs/ibmchrp_defconfig - 1.1 linux/scripts/checkconfig.pl - 1.4 linux/net/x25/x25_timer.c - 1.4 linux/net/x25/x25_subr.c - 1.4 linux/net/x25/x25_route.c - 1.6 linux/net/x25/x25_out.c - 1.5 linux/net/x25/x25_link.c - 1.8 linux/net/x25/x25_in.c - 1.7 linux/net/x25/x25_facilities.c - 1.4 linux/net/x25/x25_dev.c - 1.8 linux/net/x25/af_x25.c - 1.19 linux/net/x25/Makefile - 1.4 linux/net/unix/sysctl_net_unix.c - 1.6 linux/net/unix/af_unix.c - 1.25 linux/net/unix/Makefile - 1.4 linux/net/sysctl_net.c - 1.5 linux/net/sunrpc/sunrpc_syms.c - 1.7 linux/net/sunrpc/auth.c - 1.7 linux/net/sched/cls_u32.c - 1.4 linux/net/irda/af_irda.c - 1.17 linux/net/ipx/af_ipx.c - 1.16 linux/net/ipv4/tcp_input.c - 1.22 linux/net/ipv4/tcp.c - 1.24 linux/net/ipv4/igmp.c - 1.12 linux/net/appletalk/ddp.c - 1.15 linux/net/appletalk/aarp.c - 1.10 linux/mm/vmscan.c - 1.47 linux/mm/vmalloc.c - 1.26 linux/mm/swap.c - 1.8 linux/mm/slab.c - 1.22 linux/mm/page_alloc.c - 1.37 linux/mm/mmap.c - 1.32 linux/mm/memory.c - 1.43 linux/mm/filemap.c - 1.65 linux/kernel/sched.c - 1.31 linux/kernel/ksyms.c - 1.72 linux/kernel/fork.c - 1.28 linux/ipc/shm.c - 1.45 linux/include/net/x25.h - 1.9 linux/include/net/ipx.h - 1.6 linux/include/linux/vt_kern.h - 1.4 linux/include/linux/swap.h - 1.24 linux/include/linux/sched.h - 1.36 linux/include/linux/pagemap.h - 1.22 linux/include/linux/mm.h - 1.46 linux/include/linux/fs.h - 1.77 linux/include/linux/blkdev.h - 1.28 linux/include/linux/blk.h - 1.19 linux/include/asm-sparc64/pbm.h - 1.9 linux/include/asm-sparc64/mostek.h - 1.4 linux/include/asm-sparc/mostek.h - 1.5 linux/include/asm-ppc/unistd.h - 1.14 linux/include/asm-ppc/termios.h - 1.5 linux/include/asm-ppc/smplock.h - 1.6 linux/include/asm-ppc/smp.h - 1.11 linux/include/asm-ppc/serial.h - 1.8 linux/include/asm-ppc/segment.h - 1.3 linux/include/asm-ppc/raven.h - 1.4 linux/include/asm-ppc/prom.h - 1.9 linux/include/asm-ppc/processor.h - 1.22 linux/include/asm-ppc/prep_nvram.h - 1.4 linux/include/asm-ppc/pgtable.h - 1.24 linux/include/asm-ppc/pci-bridge.h - 1.7 linux/include/asm-ppc/mmu_context.h - 1.8 linux/include/asm-ppc/mmu.h - 1.7 linux/include/asm-ppc/mman.h - 1.5 linux/include/asm-ppc/machdep.h - 1.14 linux/include/asm-ppc/linux_logo.h - 1.6 linux/include/asm-ppc/irq.h - 1.12 linux/include/asm-ppc/ioctls.h - 1.3 linux/include/asm-ppc/io.h - 1.12 linux/include/asm-ppc/ide.h - 1.10 linux/include/asm-ppc/hardirq.h - 1.11 linux/include/asm-ppc/feature.h - 1.9 linux/include/asm-ppc/elf.h - 1.8 linux/include/asm-ppc/dma.h - 1.7 linux/include/asm-ppc/delay.h - 1.4 linux/include/asm-i386/system.h - 1.15 linux/include/asm-i386/pgtable.h - 1.25 linux/include/asm-i386/errno.h - 1.3 linux/include/asm-i386/bugs.h - 1.14 linux/include/asm-alpha/unistd.h - 1.14 linux/include/asm-alpha/errno.h - 1.3 linux/fs/super.c - 1.41 linux/fs/ncpfs/sock.c - 1.9 linux/fs/ncpfs/dir.c - 1.23 linux/fs/inode.c - 1.35 linux/fs/fat/cache.c - 1.9 linux/fs/exec.c - 1.38 linux/fs/coda/cnode.c - 1.9 linux/fs/buffer.c - 1.55 linux/fs/Makefile - 1.27 linux/fs/Config.in - 1.53 linux/drivers/video/vfb.c - 1.8 linux/drivers/video/sbusfb.c - 1.14 linux/drivers/sound/trix.c - 1.10 linux/drivers/sound/Makefile - 1.26 linux/drivers/sound/Config.in - 1.20 linux/drivers/scsi/sr.c - 1.23 linux/drivers/scsi/sg.c - 1.18 linux/drivers/scsi/ppa.c - 1.9 linux/drivers/scsi/megaraid.c - 1.20 linux/drivers/scsi/ibmmca.c - 1.12 linux/drivers/scsi/constants.c - 1.6 linux/drivers/sbus/sbus.c - 1.10 linux/drivers/sbus/char/vfc_dev.c - 1.10 linux/drivers/sbus/char/sunmouse.c - 1.13 linux/drivers/sbus/char/sunkbd.c - 1.15 linux/drivers/sbus/char/rtc.c - 1.8 linux/drivers/sbus/char/pcikbd.c - 1.14 linux/drivers/sbus/char/flash.c - 1.10 linux/drivers/sbus/char/bpp.c - 1.15 linux/drivers/sbus/char/Makefile - 1.8 linux/drivers/sbus/audio/dbri.c - 1.10 linux/drivers/sbus/audio/amd7930.c - 1.6 linux/drivers/sbus/audio/Config.in - 1.5 linux/drivers/net/sunbmac.c - 1.15 linux/drivers/net/pcnet32.c - 1.20 linux/drivers/net/myri_sbus.c - 1.10 linux/drivers/net/hamradio/scc.c - 1.14 linux/drivers/net/hamradio/mkiss.c - 1.10 linux/drivers/net/eepro100.c - 1.26 linux/drivers/net/depca.c - 1.11 linux/drivers/net/Makefile - 1.39 linux/drivers/net/3c59x.c - 1.22 linux/drivers/isdn/isdn_v110.c - 1.6 linux/drivers/isdn/isdn_ppp.c - 1.11 linux/drivers/isdn/isdn_net.c - 1.16 linux/drivers/isdn/isdn_common.c - 1.20 linux/drivers/isdn/hisax/isdnl3.c - 1.9 linux/drivers/isdn/hisax/config.c - 1.15 linux/drivers/isdn/hisax/Makefile - 1.9 linux/drivers/char/n_tty.c - 1.10 linux/drivers/char/misc.c - 1.21 linux/drivers/cdrom/cdrom.c - 1.28 linux/drivers/block/paride/pf.c - 1.11 linux/drivers/block/paride/pd.c - 1.12 linux/drivers/block/ll_rw_blk.c - 1.60 linux/arch/sparc64/kernel/time.c - 1.11 linux/arch/sparc64/kernel/sys_sunos32.c - 1.26 linux/arch/sparc64/kernel/sys_sparc32.c - 1.32 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.25 linux/arch/sparc64/kernel/smp.c - 1.21 linux/arch/sparc64/kernel/signal32.c - 1.15 linux/arch/sparc64/kernel/signal.c - 1.14 linux/arch/sparc64/kernel/ioctl32.c - 1.29 linux/arch/sparc64/defconfig - 1.32 linux/arch/sparc64/config.in - 1.34 linux/arch/sparc/kernel/time.c - 1.13 linux/arch/sparc/kernel/sys_sunos.c - 1.25 linux/arch/sparc/kernel/sparc_ksyms.c - 1.24 linux/arch/sparc/kernel/signal.c - 1.18 linux/arch/sparc/kernel/pcic.c - 1.15 linux/arch/sparc/kernel/entry.S - 1.10 linux/arch/sparc/defconfig - 1.20 linux/arch/sparc/config.in - 1.26 linux/arch/ppc/mm/init.c - 1.31 linux/arch/ppc/mm/fault.c - 1.13 linux/arch/ppc/lib/locks.c - 1.6 linux/arch/ppc/lib/Makefile - 1.6 linux/arch/ppc/kernel/traps.c - 1.15 linux/arch/ppc/kernel/time.c - 1.11 linux/arch/ppc/kernel/smp.c - 1.22 linux/arch/ppc/kernel/signal.c - 1.11 linux/arch/ppc/kernel/setup.c - 1.28 linux/arch/ppc/kernel/prom.c - 1.18 linux/arch/ppc/kernel/process.c - 1.25 linux/arch/ppc/kernel/prep_setup.c - 1.15 linux/arch/ppc/kernel/prep_pci.c - 1.7 linux/arch/ppc/kernel/prep_nvram.c - 1.5 linux/arch/ppc/kernel/ppc_ksyms.c - 1.27 linux/arch/ppc/kernel/ppc_htab.c - 1.11 linux/arch/ppc/kernel/pmac_time.c - 1.10 linux/arch/ppc/kernel/pmac_setup.c - 1.18 linux/arch/ppc/kernel/pmac_pic.c - 1.16 linux/arch/ppc/kernel/pmac_pci.c - 1.11 linux/arch/ppc/kernel/pci.h - 1.4 linux/arch/ppc/kernel/pci.c - 1.17 linux/arch/ppc/kernel/open_pic.h - 1.7 linux/arch/ppc/kernel/open_pic.c - 1.16 linux/arch/ppc/kernel/misc.S - 1.25 linux/arch/ppc/kernel/local_irq.h - 1.8 linux/arch/ppc/kernel/irq.c - 1.24 linux/arch/ppc/kernel/indirect_pci.c - 1.4 linux/arch/ppc/kernel/idle.c - 1.14 linux/arch/ppc/kernel/i8259.c - 1.6 linux/arch/ppc/kernel/head.S - 1.23 linux/arch/ppc/kernel/feature.c - 1.10 linux/arch/ppc/kernel/chrp_setup.c - 1.17 linux/arch/ppc/kernel/chrp_pci.c - 1.14 linux/arch/ppc/kernel/apus_setup.c - 1.14 linux/arch/ppc/kernel/Makefile - 1.18 linux/arch/ppc/defconfig - 1.27 linux/arch/ppc/config.in - 1.32 linux/arch/ppc/coffboot/main.c - 1.6 linux/arch/ppc/coffboot/Makefile - 1.11 linux/arch/ppc/chrpboot/Makefile - 1.11 linux/arch/ppc/boot/vreset.c - 1.3 linux/arch/ppc/boot/Makefile - 1.13 linux/arch/ppc/Makefile - 1.17 linux/arch/ppc/8xx_io/fec.c - 1.10 linux/arch/ppc/8xx_io/enet.c - 1.10 linux/arch/mips/kernel/signal.c - 1.11 linux/arch/mips/kernel/irixsig.c - 1.9 linux/arch/m68k/kernel/signal.c - 1.13 linux/arch/i386/mm/init.c - 1.27 linux/arch/i386/kernel/traps.c - 1.34 linux/arch/i386/kernel/signal.c - 1.15 linux/arch/i386/kernel/setup.c - 1.42 linux/arch/i386/kernel/io_apic.c - 1.24 linux/arch/i386/defconfig - 1.51 linux/arch/i386/config.in - 1.54 linux/arch/i386/boot/bootsect.S - 1.12 linux/arch/i386/Makefile - 1.21 linux/arch/arm/kernel/signal.c - 1.14 linux/arch/alpha/kernel/sys_cabriolet.c - 1.11 linux/arch/alpha/kernel/signal.c - 1.10 linux/arch/alpha/kernel/osf_sys.c - 1.21 linux/arch/alpha/kernel/Makefile - 1.16 linux/Makefile - 1.80 linux/MAINTAINERS - 1.52 linux/Documentation/Configure.help - 1.73 linux/Documentation/Changes - 1.31 linux/CREDITS - 1.48 linux/net/decnet/dn_timer.c - 1.6 linux/net/decnet/dn_route.c - 1.17 linux/net/decnet/dn_nsp_out.c - 1.9 linux/net/decnet/dn_nsp_in.c - 1.13 linux/net/decnet/dn_neigh.c - 1.10 linux/net/decnet/dn_fib.c - 1.9 linux/net/decnet/dn_dev.c - 1.11 linux/net/decnet/af_decnet.c - 1.20 linux/net/decnet/TODO - 1.8 linux/net/decnet/Makefile - 1.7 linux/include/net/dn_nsp.h - 1.4 linux/include/net/dn.h - 1.6 linux/include/linux/dn.h - 1.3 linux/fs/hpfs/inode.c - 1.12 linux/drivers/isdn/hisax/md5sums.asc - 1.10 linux/drivers/i2o/i2o_block.c - 1.20 linux/arch/ppc/xmon/xmon.c - 1.13 linux/arch/ppc/xmon/start.c - 1.14 linux/drivers/block/cpqarray.c - 1.19 linux/drivers/net/ppp_async.c - 1.9 linux/fs/partitions/msdos.c - 1.12 linux/drivers/pnp/isapnp_proc.c - 1.13 linux/drivers/atm/Makefile - 1.11 linux/net/core/netfilter.c - 1.12 linux/net/atm/lec.h - 1.5 linux/net/atm/lec.c - 1.11 linux/arch/ppc/kernel/ppc_asm.h - 1.5 linux/arch/ppc/kernel/hashtable.S - 1.9 linux/arch/ppc/kernel/gemini_setup.c - 1.16 linux/arch/ppc/kernel/gemini_prom.S - 1.5 linux/arch/ppc/kernel/gemini_pci.c - 1.6 linux/arch/ppc/kernel/entry.S - 1.17 linux/drivers/block/DAC960.c - 1.23 linux/arch/sparc64/kernel/pci_sabre.c - 1.15 linux/arch/sparc64/kernel/pci_psycho.c - 1.13 linux/arch/sparc64/kernel/pci_iommu.c - 1.8 linux/arch/sparc64/kernel/pci.c - 1.16 linux/arch/sparc/kernel/semaphore.c - 1.6 linux/arch/sh/lib/delay.c - 1.3 linux/arch/sh/kernel/traps.c - 1.9 linux/arch/sh/kernel/signal.c - 1.11 linux/arch/sh/kernel/sh_ksyms.c - 1.6 linux/arch/sh/kernel/setup.c - 1.12 linux/arch/sh/kernel/process.c - 1.11 linux/arch/sh/kernel/irq.c - 1.9 linux/arch/sh/kernel/head.S - 1.8 linux/arch/sh/kernel/entry.S - 1.16 linux/include/asm-sh/system.h - 1.10 linux/include/asm-sh/pgtable.h - 1.16 linux/include/asm-sh/current.h - 1.4 linux/include/asm-ppc/gemini_serial.h - 1.6 linux/include/asm-ppc/gemini.h - 1.4 linux/fs/udf/file.c - 1.22 linux/fs/udf/inode.c - 1.19 linux/include/asm-ppc/pci.h - 1.9 linux/drivers/char/drm/drm.h - 1.7 linux/drivers/char/drm/Makefile - 1.8 linux/include/linux/acpi.h - 1.19 linux/drivers/net/dmfe.c - 1.10 linux/arch/ppc/kernel/m8xx_setup.c - 1.8 linux/arch/i386/lib/mmx.c - 1.4 linux/drivers/net/wan/sdla.c - 1.9 linux/drivers/net/wan/lapbether.c - 1.6 linux/arch/sh/mm/cache.c - 1.9 linux/arch/sh/lib/checksum.S - 1.6 linux/fs/proc/kcore.c - 1.10 linux/arch/ppc/configs/walnut_defconfig - 1.8 linux/arch/ppc/configs/oak_defconfig - 1.8 linux/arch/ppc/configs/mbx_defconfig - 1.3 linux/arch/ppc/configs/gemini_defconfig - 1.10 linux/arch/ppc/configs/common_defconfig - 1.15 linux/arch/ppc/configs/apus_defconfig - 1.4 linux/arch/ppc/coffboot/coffmain.c - 1.3 linux/drivers/scsi/scsi_merge.c - 1.23 linux/drivers/scsi/scsi_lib.c - 1.26 linux/drivers/char/agp/agpgart_be.c - 1.14 linux/drivers/sbus/char/jsflash.c - 1.7 linux/include/asm-ppc/hw_irq.h - 1.5 linux/Documentation/usb/usb-serial.txt - 1.13 linux/net/sched/sch_gred.c - 1.5 linux/net/sched/sch_dsmark.c - 1.4 linux/net/decnet/dn_table.c - 1.5 linux/net/decnet/dn_rules.c - 1.2 linux/arch/ia64/ia32/sys_ia32.c - 1.12 linux/arch/ppc/kernel/galaxy_pci.c - 1.2 linux/drivers/sound/via82cxxx_audio.c - 1.11 linux/include/linux/rtc.h - 1.5 linux/include/linux/raid/md_u.h - 1.5 linux/include/linux/lvm.h - 1.5 linux/net/bridge/br_private.h - 1.4 linux/drivers/net/tulip/tulip_core.c - 1.17 linux/drivers/net/tulip/media.c - 1.5 linux/drivers/net/tulip/eeprom.c - 1.7 linux/arch/mips64/kernel/signal32.c - 1.7 linux/arch/mips64/kernel/signal.c - 1.6 linux/arch/mips64/kernel/linux32.c - 1.7 linux/drivers/usb/rio500.c - 1.8 linux/arch/sh/kernel/irq_imask.c - 1.6 linux/arch/sh/kernel/fpu.c - 1.4 linux/drivers/ide/via82cxxx.c - 1.12 linux/drivers/ide/ide-probe.c - 1.12 linux/drivers/ide/ide-dma.c - 1.9 linux/drivers/ide/ide-cd.c - 1.11 linux/drivers/ide/hpt366.c - 1.7 linux/drivers/block/elevator.c - 1.6 linux/include/linux/elevator.h - 1.5 linux/net/ipv4/netfilter/iptable_mangle.c - 1.5 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.8 linux/net/ipv4/netfilter/ipt_MASQUERADE.c - 1.6 linux/net/ipv4/netfilter/ip_nat_core.c - 1.4 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.7 linux/net/ipv4/netfilter/Makefile - 1.6 linux/net/ipv4/netfilter/Config.in - 1.3 linux/fs/nfs/flushd.c - 1.6 linux/arch/i386/kernel/pci-irq.c - 1.11 linux/include/linux/nfs_xdr.h - 1.5 linux/fs/ramfs/inode.c - 1.11 linux/drivers/usb/serial/usbserial.c - 1.11 linux/drivers/usb/serial/visor.c - 1.11 linux/drivers/sound/emu10k1/audio.c - 1.5 linux/drivers/net/wan/lmc/lmc_proto.h - 1.2 linux/drivers/net/wan/lmc/lmc_prot.h - 1.2 linux/drivers/net/wan/lmc/lmc_media.h - 1.2 linux/drivers/net/wan/lmc/lmc.h - 1.2 linux/drivers/net/pppoe.c - 1.9 linux/arch/ppc/kernel/m8260_setup.c - 1.4 linux/arch/ppc/8260_io/enet.c - 1.5 linux/drivers/s390/block/dasd.c - 1.3 linux/arch/s390/kernel/signal.c - 1.3 linux/net/ipv6/netfilter/ip6t_mark.c - 1.2 linux/net/ipv6/netfilter/ip6t_MARK.c - 1.2 linux/net/ipv6/netfilter/ip6_tables.c - 1.4 linux/net/ipv6/netfilter/Makefile - 1.4 linux/arch/ppc/mbxboot/vmlinux.lds - 1.2 linux/fs/pagebuf/page_buf_io.c - 1.48 linux/drivers/usb/storage/usb.h - 1.6 linux/drivers/usb/storage/usb.c - 1.8 linux/drivers/usb/storage/scsiglue.c - 1.8 linux/drivers/char/drm/Config.in - 1.3 linux/drivers/usb/storage/debug.h - 1.5 linux/include/asm-i386/i387.h - 1.4 linux/include/asm-sh/sh_bios.h - 1.2 linux/drivers/acpi/tables/tbxface.c - 1.4 linux/drivers/acpi/tables/tbutils.c - 1.4 linux/drivers/acpi/tables/tbinstal.c - 1.4 linux/drivers/acpi/tables/tbget.c - 1.4 linux/drivers/acpi/sys.c - 1.5 linux/drivers/acpi/resources/rsxface.c - 1.4 linux/drivers/acpi/resources/rsutils.c - 1.4 linux/drivers/acpi/resources/rsmisc.c - 1.4 linux/drivers/acpi/resources/rsmemory.c - 1.4 linux/drivers/acpi/resources/rslist.c - 1.4 linux/drivers/acpi/resources/rsirq.c - 1.4 linux/drivers/acpi/resources/rsio.c - 1.4 linux/drivers/acpi/resources/rsdump.c - 1.4 linux/drivers/acpi/resources/rscreate.c - 1.4 linux/drivers/acpi/resources/rscalc.c - 1.4 linux/drivers/acpi/resources/rsaddr.c - 1.4 linux/drivers/acpi/parser/psxface.c - 1.4 linux/drivers/acpi/parser/pswalk.c - 1.4 linux/drivers/acpi/parser/psutils.c - 1.4 linux/drivers/acpi/parser/pstree.c - 1.4 linux/drivers/acpi/parser/psscope.c - 1.4 linux/drivers/acpi/parser/psparse.c - 1.5 linux/drivers/acpi/parser/psopcode.c - 1.4 linux/drivers/acpi/parser/psargs.c - 1.5 linux/drivers/acpi/os.c - 1.4 linux/drivers/acpi/namespace/nsxfobj.c - 1.5 linux/drivers/acpi/namespace/nsxfname.c - 1.4 linux/drivers/acpi/namespace/nswalk.c - 1.3 linux/drivers/acpi/namespace/nsutils.c - 1.4 linux/drivers/acpi/namespace/nssearch.c - 1.5 linux/drivers/acpi/namespace/nsobject.c - 1.4 linux/drivers/acpi/namespace/nsnames.c - 1.4 linux/drivers/acpi/namespace/nsload.c - 1.4 linux/drivers/acpi/namespace/nseval.c - 1.4 linux/drivers/acpi/namespace/nsalloc.c - 1.4 linux/drivers/acpi/namespace/nsaccess.c - 1.5 linux/drivers/acpi/interpreter/amxface.c - 1.3 linux/drivers/acpi/interpreter/amutils.c - 1.5 linux/drivers/acpi/interpreter/amsystem.c - 1.4 linux/drivers/acpi/interpreter/amstorob.c - 1.4 linux/drivers/acpi/interpreter/amstoren.c - 1.4 linux/drivers/acpi/interpreter/amstore.c - 1.4 linux/drivers/acpi/interpreter/amresop.c - 1.4 linux/drivers/acpi/interpreter/amresolv.c - 1.4 linux/drivers/acpi/interpreter/amresnte.c - 1.4 linux/drivers/acpi/interpreter/amregion.c - 1.4 linux/drivers/acpi/interpreter/amprep.c - 1.5 linux/drivers/acpi/interpreter/amnames.c - 1.4 linux/drivers/acpi/interpreter/ammonad.c - 1.5 linux/drivers/acpi/interpreter/ammisc.c - 1.4 linux/drivers/acpi/interpreter/amfldio.c - 1.4 linux/drivers/acpi/interpreter/amfield.c - 1.4 linux/drivers/acpi/interpreter/amdyadic.c - 1.4 linux/drivers/acpi/interpreter/amcreate.c - 1.4 linux/drivers/acpi/interpreter/amconfig.c - 1.4 linux/arch/i386/kernel/i387.c - 1.4 linux/drivers/acpi/include/amlcode.h - 1.4 linux/drivers/acpi/include/actypes.h - 1.5 linux/drivers/acpi/include/actables.h - 1.4 linux/drivers/acpi/include/acpixf.h - 1.5 linux/drivers/acpi/include/acpiosxf.h - 1.5 linux/drivers/acpi/include/acpi.h - 1.3 linux/drivers/acpi/include/acobject.h - 1.4 linux/drivers/acpi/include/acexcep.h - 1.4 linux/drivers/acpi/include/acenv.h - 1.4 linux/drivers/acpi/hardware/hwxface.c - 1.4 linux/drivers/acpi/hardware/hwregs.c - 1.5 linux/drivers/acpi/hardware/hwgpe.c - 1.4 linux/drivers/acpi/hardware/hwcpu32.c - 1.5 linux/drivers/acpi/hardware/hwacpi.c - 1.5 linux/drivers/acpi/events/evxfregn.c - 1.5 linux/drivers/acpi/events/evxfevnt.c - 1.4 linux/drivers/acpi/events/evxface.c - 1.4 linux/drivers/acpi/events/evsci.c - 1.4 linux/drivers/acpi/events/evrgnini.c - 1.4 linux/drivers/acpi/events/evregion.c - 1.5 linux/drivers/acpi/events/evmisc.c - 1.4 linux/drivers/acpi/events/evevent.c - 1.5 linux/drivers/acpi/ec.c - 1.5 linux/drivers/acpi/driver.c - 1.7 linux/drivers/acpi/dispatcher/dswstate.c - 1.5 linux/drivers/acpi/dispatcher/dswscope.c - 1.4 linux/drivers/acpi/dispatcher/dswload.c - 1.4 linux/drivers/acpi/dispatcher/dswexec.c - 1.4 linux/drivers/acpi/dispatcher/dsutils.c - 1.4 linux/drivers/acpi/dispatcher/dsopcode.c - 1.4 linux/drivers/acpi/dispatcher/dsobject.c - 1.4 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.4 linux/drivers/acpi/dispatcher/dsmethod.c - 1.4 linux/drivers/acpi/dispatcher/dsfield.c - 1.3 linux/drivers/acpi/cpu.c - 1.4 linux/drivers/acpi/common/cmxface.c - 1.4 linux/drivers/acpi/common/cmutils.c - 1.4 linux/drivers/acpi/common/cmobject.c - 1.5 linux/drivers/acpi/common/cminit.c - 1.5 linux/drivers/acpi/common/cmglobal.c - 1.4 linux/drivers/acpi/common/cmeval.c - 1.4 linux/drivers/acpi/common/cmdelete.c - 1.4 linux/drivers/acpi/common/cmdebug.c - 1.4 linux/drivers/acpi/common/cmcopy.c - 1.5 linux/drivers/acpi/common/cmalloc.c - 1.4 linux/drivers/acpi/Makefile - 1.5 linux/arch/sh/kernel/sh_bios.c - 1.4 linux/arch/sh/boot/compressed/head.S - 1.4 linux/arch/ppc/configs/rpxlite_defconfig - 1.3 linux/arch/ppc/configs/rpxcllf_defconfig - 1.4 linux/arch/ppc/configs/est8260_defconfig - 1.4 linux/arch/ppc/configs/bseip_defconfig - 1.3 linux/Documentation/cachetlb.txt - 1.5 linux/drivers/md/lvm.c - 1.6 linux/drivers/md/raid5.c - 1.8 linux/arch/ppc/8260_io/fcc_enet.c - 1.2 linux/drivers/acpi/common/cmclib.c - 1.3 linux/drivers/acpi/include/accommon.h - 1.3 linux/drivers/acpi/include/acconfig.h - 1.3 linux/drivers/acpi/include/acdebug.h - 1.3 linux/drivers/acpi/include/acdispat.h - 1.3 linux/drivers/acpi/include/acevents.h - 1.4 linux/drivers/acpi/include/acglobal.h - 1.3 linux/drivers/acpi/include/achware.h - 1.3 linux/drivers/acpi/include/acinterp.h - 1.3 linux/drivers/acpi/include/aclocal.h - 1.4 linux/drivers/acpi/include/acmacros.h - 1.4 linux/drivers/acpi/include/acnamesp.h - 1.4 linux/drivers/acpi/include/acoutput.h - 1.3 linux/drivers/acpi/include/acparser.h - 1.3 linux/drivers/acpi/include/acresrc.h - 1.2 linux/drivers/acpi/include/actbl.h - 1.3 linux/drivers/acpi/table.c - 1.3 linux/drivers/block/cciss.c - 1.4 linux/drivers/md/Config.in - 1.2 linux/drivers/md/lvm-snap.c - 1.3 linux/drivers/md/md.c - 1.5 linux/drivers/md/xor.c - 1.4 linux/include/asm-ppc/keylargo.h - 1.2 linux/fs/xfs/support/mrlock.h - 1.3 linux/fs/xfs/support/mrlock.c - 1.4 linux/drivers/net/tulip/ChangeLog - 1.3 linux/Documentation/usb/hotplug.txt - 1.2 linux/kernel/context.c - 1.3 linux/drivers/usb/serial/Config.in - 1.2 linux/drivers/sound/ymfpci.h - 1.2 linux/drivers/sound/ymfpci.c - 1.2 linux/drivers/acpi/tables/tbconvrt.c - 1.2 linux/drivers/acpi/tables/tbxfroot.c - 1.2 linux/drivers/acpi/namespace/nsinit.c - 1.2 linux/drivers/acpi/ksyms.c - 1.3 linux/drivers/acpi/include/actbl71.h - 1.2 linux/drivers/acpi/include/actbl2.h - 1.2 linux/drivers/acpi/include/actbl1.h - 1.2 linux/drivers/acpi/include/aclinux.h - 1.3 linux/drivers/acpi/include/acgcc.h - 1.2 linux/drivers/acpi/cmbatt.c - 1.3 linux/mm/shmem.c - 1.3 linux/Documentation/filesystems/xfs.txt - 1.3 linux/drivers/acpi/power.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Feb 1 10:19:16 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 10:18:56 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:41076 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 10:18:39 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA08570 for ; Thu, 1 Feb 2001 10:18:38 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA34748; Thu, 1 Feb 2001 10:17:20 -0800 (PST) Date: Thu, 1 Feb 2001 10:18:17 -0800 (PST) From: Tom Duffy To: cc: Subject: re: vmware under pre-release 0.9 In-Reply-To: <200102010609.BAA16225@mclean.mail.mindspring.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 1 Feb 2001 jtrostel@mindspring.com wrote: > Which build of vmware are you using? Vmware works for me with an > SGI-XFS kernel from Monday of this week. I am using build 7(?)99 of > Vmware (the most recent one available from their web site) it is 2.0.3, build 799. did you have to do anything special to get the stuff to build? did you install XFS kernel as an rpm? -tduffy From owner-linux-xfs@oss.sgi.com Thu Feb 1 11:29:06 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 11:28:57 -0800 Received: from tisch.mail.mindspring.net ([207.69.200.157]:28434 "EHLO tisch.mail.mindspring.net") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 11:28:32 -0800 Received: from jtsdell (user-37ka9ak.dialup.mindspring.com [207.69.37.84]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA00800; Thu, 1 Feb 2001 14:28:23 -0500 (EST) Message-ID: X-Mailer: XFMail 1.4.7 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 01 Feb 2001 14:26:27 -0500 (EST) Reply-To: jtrostel@mindspring.com Organization: Connex From: John Trostel To: Tom Duffy Subject: re: vmware under pre-release 0.9 Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Mine is 2.0.3 build 799 also. I am using the 2.4.? kernel sources from the SGI-XFS CVS tree now, but I think they are just the stock kernel sources which are then patched. So, I installed XFS by recompiling the kernel and then doing a make on the /cmd directory of the XFS tree also. What version of the kernel is in the rpm version? On 01-Feb-2001 Tom Duffy wrote: > On Thu, 1 Feb 2001 jtrostel@mindspring.com wrote: > >> Which build of vmware are you using? Vmware works for me with an >> SGI-XFS kernel from Monday of this week. I am using build 7(?)99 of >> Vmware (the most recent one available from their web site) > > it is 2.0.3, build 799. did you have to do anything special to get the > stuff to build? did you install XFS kernel as an rpm? > > -tduffy -- John M. Trostel Linux OS Engineer Connex jtrostel@connex.com From owner-linux-xfs@oss.sgi.com Thu Feb 1 12:30:05 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 12:29:56 -0800 Received: from garnet.sover.net ([209.198.87.53]:53744 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 12:29:40 -0800 Received: from [192.168.1.3] (arc7a8.bf.sover.net [209.198.117.137]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id PAA08568 for ; Thu, 1 Feb 2001 15:29:37 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from arc7a8.bf.sover.net [209.198.117.137] 209.198.117.137 Thu, 1 Feb 2001 15:29:37 -0500 (EST) Date: Thu, 1 Feb 2001 15:28:26 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: SGI XFS Mailing List Subject: Simple question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ok, I hate to be the one to ask the stupid questions, but I read the posting that you guys moved up to 2.4.1. I did a cvs update and it updated things...'make menuconfig' says it's indeed 2.4.1, I also did a make mrproper before that. the thing is make dep pukes, unable to find linux/fs/reiserfs directory. indeed it is not there. the option for reiserfs exists in configuration though. What am I missing? I am sure it's something dumb..thanks guys RegEx From owner-linux-xfs@oss.sgi.com Thu Feb 1 12:38:25 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 12:38:07 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:32331 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 12:37:58 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA08157 for ; Thu, 1 Feb 2001 12:37:57 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA672493; Thu, 1 Feb 2001 14:35:25 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA99777; Thu, 1 Feb 2001 14:35:25 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f11Ka2320307; Thu, 1 Feb 2001 14:36:02 -0600 Message-Id: <200102012036.f11Ka2320307@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jason Walker cc: SGI XFS Mailing List Subject: Re: Simple question In-Reply-To: Message from Jason Walker of "Thu, 01 Feb 2001 15:28:26 EST." Date: Thu, 01 Feb 2001 14:36:02 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > ok, I hate to be the one to ask the stupid questions, but I read the > posting that you guys moved up to 2.4.1. I did a cvs update and it updated > things...'make menuconfig' says it's indeed 2.4.1, I also did a make > mrproper before that. the thing is make dep pukes, unable to find > linux/fs/reiserfs directory. indeed it is not there. the option for > reiserfs exists in configuration though. What am I missing? I am sure > it's something dumb..thanks guys > > RegEx > OK, I suspect you are not being stupid, reiserfs is a new directory which could well be the problem. I don't know the details of how the tree on oss gets created - except for the fact that they are very convoluted. The guy who maintains this is at Linux World this week, and getting this fixed in the correct manner would involve his help. Can you try pulling in the reiserfs directory from a vanilla 2.4.1 tree, we did not change it. Steve From owner-linux-xfs@oss.sgi.com Thu Feb 1 12:57:06 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 12:56:56 -0800 Received: from Cantor.suse.de ([213.95.15.193]:17162 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Thu, 1 Feb 2001 12:56:43 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 3D5F71E0F3; Thu, 1 Feb 2001 21:56:41 +0100 (MET) Date: Thu, 1 Feb 2001 21:56:33 +0100 From: Andi Kleen To: Jason Walker Cc: SGI XFS Mailing List Subject: Re: Simple question Message-ID: <20010201215633.A29723@gruyere.muc.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from unseen@sover.net on Thu, Feb 01, 2001 at 03:28:26PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, Feb 01, 2001 at 03:28:26PM -0500, Jason Walker wrote: > > ok, I hate to be the one to ask the stupid questions, but I read the > posting that you guys moved up to 2.4.1. I did a cvs update and it updated > things...'make menuconfig' says it's indeed 2.4.1, I also did a make > mrproper before that. the thing is make dep pukes, unable to find > linux/fs/reiserfs directory. indeed it is not there. the option for > reiserfs exists in configuration though. What am I missing? I am sure > it's something dumb..thanks guys Try giving the -d option to cvs update Without it cvs won't fetch new directories. -Andi From owner-linux-xfs@oss.sgi.com Thu Feb 1 12:58:05 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 12:57:56 -0800 Received: from pike.sover.net ([209.198.87.34]:6909 "EHLO pike.sover.net") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 12:57:40 -0800 Received: from [192.168.1.3] (arc7a8.bf.sover.net [209.198.117.137]) by pike.sover.net (8.9.3/8.9.3) with ESMTP id PAA21459; Thu, 1 Feb 2001 15:57:18 -0500 (EST) Comments: SoVerNet Verification (on pike.sover.net) [192.168.1.3] from arc7a8.bf.sover.net [209.198.117.137] 209.198.117.137 Thu, 1 Feb 2001 15:57:18 -0500 (EST) Date: Thu, 1 Feb 2001 15:56:10 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Steve Lord cc: SGI XFS Mailing List Subject: Re: Simple question In-Reply-To: <200102012036.f11Ka2320307@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 1 Feb 2001, Steve Lord wrote: > OK, I suspect you are not being stupid, reiserfs is a new directory which could > well be the problem. I don't know the details of how the tree on oss gets > created - except for the fact that they are very convoluted. The guy who > maintains this is at Linux World this week, and getting this fixed in the > correct manner would involve his help. Can you try pulling in the reiserfs > directory from a vanilla 2.4.1 tree, we did not change it. > > Steve Sure, I will do that. A friend of mine got it working without a hitch. The impression I got was he pulled down the entire CVS tree fresh. I could be wrong, and I will ask him what he did. when I find out, I will post what he did to see if that helps you guys pin down the problem. In the mean time, I will get vanilla 2.4.1 and copy the reiser tree over. thanks! RegEx From owner-linux-xfs@oss.sgi.com Thu Feb 1 13:01:55 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 13:01:36 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:47191 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 13:01:20 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA07169 for ; Thu, 1 Feb 2001 13:01:19 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA673040; Thu, 1 Feb 2001 14:59:52 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA94148; Thu, 1 Feb 2001 14:59:52 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f11L0T621135; Thu, 1 Feb 2001 15:00:29 -0600 Message-Id: <200102012100.f11L0T621135@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen cc: Jason Walker , SGI XFS Mailing List Subject: Re: Simple question In-Reply-To: Message from Andi Kleen of "Thu, 01 Feb 2001 21:56:33 +0100." <20010201215633.A29723@gruyere.muc.suse.de> Date: Thu, 01 Feb 2001 15:00:29 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Thu, Feb 01, 2001 at 03:28:26PM -0500, Jason Walker wrote: > > > > ok, I hate to be the one to ask the stupid questions, but I read the > > posting that you guys moved up to 2.4.1. I did a cvs update and it updated > > things...'make menuconfig' says it's indeed 2.4.1, I also did a make > > mrproper before that. the thing is make dep pukes, unable to find > > linux/fs/reiserfs directory. indeed it is not there. the option for > > reiserfs exists in configuration though. What am I missing? I am sure > > it's something dumb..thanks guys > > Try giving the -d option to cvs update > Without it cvs won't fetch new directories. Duh! I forgot about that one! Steve From owner-linux-xfs@oss.sgi.com Thu Feb 1 13:21:25 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 13:21:16 -0800 Received: from [134.6.36.170] ([134.6.36.170]:23812 "EHLO Maxtor.Com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 13:20:57 -0800 Received: from pacbell.net (localhost [127.0.0.1]) by localhost (8.11.1/8.9.3) with ESMTP id f11AmgT10500 for ; Thu, 1 Feb 2001 02:48:43 -0800 Message-ID: <3A793F0A.C1EFBBFA@pacbell.net> Date: Thu, 01 Feb 2001 10:48:42 +0000 From: "Joseph I. Davida" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kgcc and ATTRIBUTE_UNUSED directive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Compiling on Redhat 7.0 - Kgcc cannot parse this directive. I have resorted to commenting it out or just deleting it in order to compile the disassembler i386-dis.c in /usr/src/linux-2.4-xfs-beta/linux/arch/i386/kdb. Is there a better suggestion? Cheers, Joe From owner-linux-xfs@oss.sgi.com Thu Feb 1 13:30:16 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 13:29:56 -0800 Received: from garnet.sover.net ([209.198.87.53]:61903 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 13:29:51 -0800 Received: from [192.168.1.3] (arc7a8.bf.sover.net [209.198.117.137]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id QAA20213; Thu, 1 Feb 2001 16:29:08 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from arc7a8.bf.sover.net [209.198.117.137] 209.198.117.137 Thu, 1 Feb 2001 16:29:08 -0500 (EST) Date: Thu, 1 Feb 2001 16:27:59 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Andi Kleen cc: SGI XFS Mailing List Subject: Re: Simple question In-Reply-To: <20010201215633.A29723@gruyere.muc.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 1 Feb 2001, Andi Kleen wrote: > On Thu, Feb 01, 2001 at 03:28:26PM -0500, Jason Walker wrote: > > > > ok, I hate to be the one to ask the stupid questions, but I read the > > posting that you guys moved up to 2.4.1. I did a cvs update and it updated > > things...'make menuconfig' says it's indeed 2.4.1, I also did a make > > mrproper before that. the thing is make dep pukes, unable to find > > linux/fs/reiserfs directory. indeed it is not there. the option for > > reiserfs exists in configuration though. What am I missing? I am sure > > it's something dumb..thanks guys > > Try giving the -d option to cvs update > Without it cvs won't fetch new directories. > > > -Andi > doh! I knew it was something stupid...what did I tell ya? ;) thanks Andi :) RegEx From owner-linux-xfs@oss.sgi.com Thu Feb 1 13:33:56 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 13:33:46 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:39783 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 13:33:27 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05580 for ; Thu, 1 Feb 2001 13:33:24 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA674008; Thu, 1 Feb 2001 15:32:07 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA40303; Thu, 1 Feb 2001 15:32:07 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f11LWhx22899; Thu, 1 Feb 2001 15:32:44 -0600 Message-Id: <200102012132.f11LWhx22899@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Joseph I. Davida" cc: linux-xfs@oss.sgi.com Subject: Re: kgcc and ATTRIBUTE_UNUSED directive In-Reply-To: Message from "Joseph I. Davida" of "Thu, 01 Feb 2001 10:48:42 GMT." <3A793F0A.C1EFBBFA@pacbell.net> Date: Thu, 01 Feb 2001 15:32:43 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Compiling on Redhat 7.0 - > Kgcc cannot parse this directive. > I have resorted to commenting it out > or just deleting it in order to compile > the disassembler i386-dis.c in > /usr/src/linux-2.4-xfs-beta/linux/arch/i386/kdb. > Is there a better suggestion? > > Cheers, > > Joe Hmm, are you really running redhat 7? This is the platform I am doing all of my builds on without any problems. You might want to check you have a more recent modutils though (this is a guess), I have modutils-2.4.2-1 on my system. Steve From owner-linux-xfs@oss.sgi.com Thu Feb 1 15:08:37 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 15:08:17 -0800 Received: from hermes.mixx.net ([212.84.196.2]:25105 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 1 Feb 2001 15:08:00 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 5BF62F823 for ; Fri, 2 Feb 2001 00:07:58 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 39BED2CA70; Fri, 2 Feb 2001 00:07:58 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: quota Date: 1 Feb 2001 23:07:58 GMT Organization: innominate AG, Berlin, Germany Lines: 46 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 981068878 6542 10.0.0.31 (1 Feb 2001 23:07:58 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing i am a bit confused about quota on XFS ... all started by getting messages like user enforcement is already disabled etc. from the quotaoff -a in the normal redhat shutdown scripts - this brought me to look at the quota stuff - ok i tried to enable quota now but for me it does not work like described in the quotaon man-page (the XFS quota man page) rootfs -> quotaon -v / and reboot but after rebooting root did not have quota ... i also added ",usrquota" to the fstab entries for the non / partitions but some- how it did not work (but i have to check that in more detail - so maybe ignore this one for now) ... ok - but now the quotaon on bootup complains about "quotas have to be enabled on mount" ... ok - while trying all this i found out that somehow the grpquota stuff does not work at all for now (i think i remember something like grpquotas not working from the lists) - right? so - before i try further - can anyone please say some words about the status of the quota stuff: is the quotaon/quotaoff output on bootup/shutdown normal for now (or am i doing something wrong)? what is the state of the grpquota stuff? and how one really enables quota on XFS filesystems? (my idea would be quotaon -v / for the rootfs + reboot and an ... defaults,usrquota entry in the fstab for all the other XFS fs + reboot (or remount) - right or anything wrong on this idea? a lot of thanks in advance t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Thu Feb 1 15:10:07 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 15:09:57 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:4874 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 15:09:50 -0800 Received: from thebarn.com ([64.244.37.248]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f11N9i283549; Thu, 1 Feb 2001 17:09:44 -0600 (CST) Message-ID: <3A79ED06.CAB6AD44@thebarn.com> Date: Thu, 01 Feb 2001 17:11:02 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Jason Walker , SGI XFS Mailing List Subject: Re: Simple question References: <200102012036.f11Ka2320307@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > > > > > ok, I hate to be the one to ask the stupid questions, but I read the > > posting that you guys moved up to 2.4.1. I did a cvs update and it updated > > things...'make menuconfig' says it's indeed 2.4.1, I also did a make > > mrproper before that. the thing is make dep pukes, unable to find > > linux/fs/reiserfs directory. indeed it is not there. the option for > > reiserfs exists in configuration though. What am I missing? I am sure > > it's something dumb..thanks guys > > > > RegEx > > > > OK, I suspect you are not being stupid, reiserfs is a new directory which could > well be the problem. I don't know the details of how the tree on oss gets > created - except for the fact that they are very convoluted. The guy who > maintains this is at Linux World this week, and getting this fixed in the > correct manner would involve his help. Can you try pulling in the reiserfs > directory from a vanilla 2.4.1 tree, we did not change it. > > Steve Use cvs update -d the -d says pull new directoryuied From owner-linux-xfs@oss.sgi.com Thu Feb 1 15:43:07 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 15:42:48 -0800 Received: from hermes.mixx.net ([212.84.196.2]:15890 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 1 Feb 2001 15:42:37 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id B6BF0F817 for ; Fri, 2 Feb 2001 00:42:35 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 947CF2CA6F; Fri, 2 Feb 2001 00:42:35 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: quota Date: 1 Feb 2001 23:42:35 GMT Organization: innominate AG, Berlin, Germany Lines: 77 Distribution: local Message-ID: References: Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 981070955 25296 10.0.0.31 (1 Feb 2001 23:42:35 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing little update after more testing: the usrquota in fstab for non root fs seems to work (but still with message and thus bad exit code from quotaon on bootup) but rootfs is still /dev/ide/host0/bus0/target0/lun0/part3 (/): ------------------------------------------- Status user quota accounting : off user quota limit enforcement : off group quota accounting : off group quota limit enforcement: off Quota Storage user quota inode: none group quota inode: none after a quotaon -v / and reboot - ok - enough for today - good night :-) t Thomas Graichen wrote: > i am a bit confused about quota on XFS ... all started by getting > messages like > user enforcement is already disabled > etc. from the quotaoff -a in the normal redhat shutdown scripts - this > brought me to look at the quota stuff - ok i tried to enable quota now > but for me it does not work like described in the quotaon man-page > (the XFS quota man page) > rootfs -> quotaon -v / and reboot > but after rebooting root did not have quota ... i also added > ",usrquota" to the fstab entries for the non / partitions but some- > how it did not work (but i have to check that in more detail - so > maybe ignore this one for now) ... ok - but now the quotaon on > bootup complains about "quotas have to be enabled on mount" ... > ok - while trying all this i found out that somehow the grpquota > stuff does not work at all for now (i think i remember something > like grpquotas not working from the lists) - right? > so - before i try further - can anyone please say some words > about the status of the quota stuff: is the quotaon/quotaoff > output on bootup/shutdown normal for now (or am i doing something > wrong)? what is the state of the grpquota stuff? and how one > really enables quota on XFS filesystems? (my idea would be > quotaon -v / > for the rootfs + reboot and an > ... defaults,usrquota > entry in the fstab for all the other XFS fs + reboot (or remount) > - right or anything wrong on this idea? > a lot of thanks in advance > t > -- > thomas.graichen@innominate.com > innominate AG > the linux architects > tel: +49-30-308806-13 fax: -77 http://www.innominate.com -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Thu Feb 1 15:47:37 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 15:47:17 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16939 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 15:47:08 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id PAA00029 for ; Thu, 1 Feb 2001 15:56:14 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18796; Fri, 2 Feb 2001 10:45:52 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA88395; Fri, 2 Feb 2001 10:44:33 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102021044.ZM67176@wobbly.melbourne.sgi.com> Date: Fri, 2 Feb 2001 10:44:30 -0400 In-Reply-To: Thomas Graichen "quota" (Feb 1, 11:07pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Thomas Graichen , thomas.graichen@innominate.com, linux-xfs@oss.sgi.com Subject: Re: quota Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Thomas, On Feb 1, 11:07pm, Thomas Graichen wrote: > Subject: quota > i am a bit confused about quota on XFS ... all started by getting > messages like > > user enforcement is already disabled > sounds like a logic error in quotaoff - I'll have a look, thanks. > etc. from the quotaoff -a in the normal redhat shutdown scripts - this > brought me to look at the quota stuff - ok i tried to enable quota now > but for me it does not work like described in the quotaon man-page > (the XFS quota man page) > > rootfs -> quotaon -v / and reboot > this is probably the one situation I haven't got round to trying out yet ;) - quota on root are a special case in XFS, so theres possibly a bug lurking in there. > but after rebooting root did not have quota ... i also added how did you check that? (repquota -s?) > ",usrquota" to the fstab entries for the non / partitions but some- > how it did not work (but i have to check that in more detail - so this should definately work, I run many filesystems in this mode all the time. in what way did it not work? > maybe ignore this one for now) ... ok - but now the quotaon on > bootup complains about "quotas have to be enabled on mount" ... this is probably related to the root fs issue somehow (probably a related error to above since quotaon==quotaoff). > > ok - while trying all this i found out that somehow the grpquota > stuff does not work at all for now (i think i remember something > like grpquotas not working from the lists) - right? > yes, thats right. > so - before i try further - can anyone please say some words > about the status of the quota stuff: is the quotaon/quotaoff > output on bootup/shutdown normal for now (or am i doing something > wrong)? what is the state of the grpquota stuff? and how one > really enables quota on XFS filesystems? (my idea would be > > quotaon -v / > in theory, yes. i'll need to do some work to test out this case though. status of group quota is: IRIX has a "projects" concept which is similar to groups but used for accounting purposed rather than security. the IRIX version of XFS implements project quota instead of group quota. since Linux has no notion of projects, I need to come up with a plan B (on my todo list) and its not as simple as "just use gids instead of projids", obviously. this'll take awhile... > for the rootfs + reboot and an > > ... defaults,usrquota > > entry in the fstab for all the other XFS fs + reboot (or remount) > - right or anything wrong on this idea? no reboot is required for non-root filesystems. unmount & then mount is all thats required. a remount would be nice but I haven't had a chance to look into that mechanism yet. switching quota on for / is really fiddly in IRIX (needs a reboot), so this may be a much cleaner way for doing root quota in Linux... I'll use that as my excuse for not testing quota on / yet. ;-) to date, I have just been concentrating on porting from IRIX and getting the basic functionality in place. > > a lot of thanks in advance > no worries - thanks for the bug report. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 1 16:12:07 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 16:11:57 -0800 Received: from 653229hfc163.tampabay.rr.com ([65.32.29.163]:5371 "EHLO zorak.illusionary.lan") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 16:11:37 -0800 Received: from illusionary.com (wraith [192.168.10.100]) by zorak.illusionary.lan (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id TAA00891 for ; Thu, 1 Feb 2001 19:11:34 -0500 X-Authentication-Warning: zorak.illusionary.lan: Host wraith [192.168.10.100] claimed to be illusionary.com Message-ID: <3A79FB34.7406CB7C@illusionary.com> Date: Thu, 01 Feb 2001 19:11:32 -0500 From: Derek Glidden X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_shrinkfs ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing First off, many kudos to the SGI folks et al for the amazing work at getting XFS ported and running so quickly and well on Linux! Thanks! Now the question: I've got a big XFS LVM volume on my file server and I'm just curious if there is a utility that can shrink an XFS filesystem, if I decide for whatever reason to shrink the LVM volume the filesystem happens to be on. I'm busy backing up the partition right now to test this directly, but it'd be nice to hear for certain. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- With Microsoft products, failure is not an option -- it's a standard component. Choose your life. Choose your future. Derek Glidden Choose Linux. http://www.illusionary.com/ From owner-linux-xfs@oss.sgi.com Thu Feb 1 16:33:07 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 16:32:57 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:52543 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 16:32:33 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA03874 for ; Thu, 1 Feb 2001 16:32:20 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA19153; Fri, 2 Feb 2001 11:31:05 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA92257; Fri, 2 Feb 2001 11:31:03 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102021131.ZM92281@wobbly.melbourne.sgi.com> Date: Fri, 2 Feb 2001 11:31:00 -0400 In-Reply-To: Steve Lord "Re: xfs_mount manpage" (Feb 1, 9:30am) References: <200102011530.f11FUuH30066@jen.americas.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Steve Lord , Thomas Graichen , thomas.graichen@innominate.com Subject: Re: xfs_mount manpage Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Feb 1, 9:30am, Steve Lord wrote: > Subject: Re: xfs_mount manpage > > wasn't there a manpage describing the xfs mount-options? - looks it yes, it was xfs_fstab.5 (aka the IRIX fstab(4) man page). > > got lost in the xfs-cmds restructuring ... (but maybe i only did > > not find it :-) > not lost - it got reworked a little to remove all the IRIX specific words, added missing words about some options, and rearranged into a mount.8 patch and the xfs.txt file Steve mentioned. > I asked this question myself the other day. Some mount options are described > here: > > Documentation/filesystems/xfs.txt > > this does not currently mention kio and kiocluster. > I had a short discussion with Ananth about this at the time & it wasn't clear whether these would become the default & go away or not, so I ommitted these from the patch - I'll add some words to the xfs.txt file though since we can more easily change that if need be. > I think a patch was submitted to the mount maintainer containing man > page updates for xfs options - but I may be mis-remembering that. > yes, that did happen late last year. I heard back from Andries just last night that this has now been applied to his tree (so I'd expect it in mount.8 in util-linux 2.10t). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 1 16:39:37 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 16:39:27 -0800 Received: from tux.mkp.net ([130.225.60.11]:34822 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 16:39:07 -0800 Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 14OUEn-0006AT-00; Fri, 02 Feb 2001 01:38:06 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id TAA17761; Thu, 1 Feb 2001 19:38:48 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Derek Glidden Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_shrinkfs ? References: <3A79FB34.7406CB7C@illusionary.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 01 Feb 2001 19:38:48 -0500 In-Reply-To: <3A79FB34.7406CB7C@illusionary.com> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Derek" == Derek Glidden writes: Derek> Now the question: I've got a big XFS LVM volume on my file Derek> server and I'm just curious if there is a utility that can Derek> shrink an XFS filesystem, if I decide for whatever reason to Derek> shrink the LVM volume the filesystem happens to be on. Unfortunately, no. XFS does not support shrinking. Only growing the filesystem is supported. Technically, I guess it would be possible to write something which would migrate data to the first allocation groups of the fs and chop off/truncate the allocation group(s) at the end. It's just that nobody has done it yet :) -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Thu Feb 1 17:52:07 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 17:51:58 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:58886 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 17:51:41 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id XAA23036; Thu, 1 Feb 2001 23:51:30 -0200 Date: Thu, 1 Feb 2001 22:02:28 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: PF_MEMALLOC in wakeup_bdflush() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve, I'm looking into the 2.4.1 XFS tree and I noticed you're setting the PF_MEMALLOC bit in the task flags before calling flush_dirty_buffers(), inside wakeup_bdflush(). Have you actually seen any oom deadlock caused by flush_dirty_buffers() or you just added the bit there to be safe? From owner-linux-xfs@oss.sgi.com Thu Feb 1 18:36:18 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 18:35:59 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:47473 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 18:35:45 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA02974 for ; Thu, 1 Feb 2001 18:34:45 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA676642; Thu, 1 Feb 2001 20:34:27 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA14172; Thu, 1 Feb 2001 20:34:27 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f122Z1C02234; Thu, 1 Feb 2001 20:35:01 -0600 Message-Id: <200102020235.f122Z1C02234@jen.americas.sgi.com> To: Marcelo Tosatti cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: PF_MEMALLOC in wakeup_bdflush() References: Comments: In-reply-to Marcelo Tosatti message dated "Thu, 01 Feb 2001 22:02:28 -0200." Date: Thu, 01 Feb 2001 20:35:01 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Steve, > > I'm looking into the 2.4.1 XFS tree and I noticed you're setting the > PF_MEMALLOC bit in the task flags before calling flush_dirty_buffers(), > inside wakeup_bdflush(). > > Have you actually seen any oom deadlock caused by flush_dirty_buffers() or > you just added the bit there to be safe? > I am? Not in the code I am looking at here: void wakeup_bdflush(int block) { if (current != bdflush_tsk) { wake_up_process(bdflush_tsk); if (block) flush_dirty_buffers(0); } } The code in the cvs tree I have does not do that either, you either have a modified tree, or I am misinterpreting where you mean in the code. The only PF_MEMALLOC I messed with was in page_buf_io.c out of the writepage method. Steve From owner-linux-xfs@oss.sgi.com Thu Feb 1 18:40:48 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 18:40:29 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:1287 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 18:40:23 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id AAA23519; Fri, 2 Feb 2001 00:40:10 -0200 Date: Thu, 1 Feb 2001 22:51:09 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: PF_MEMALLOC in wakeup_bdflush() In-Reply-To: <200102020235.f122Z1C02234@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 1 Feb 2001, Steve Lord wrote: > > > > Steve, > > > > I'm looking into the 2.4.1 XFS tree and I noticed you're setting the > > PF_MEMALLOC bit in the task flags before calling flush_dirty_buffers(), > > inside wakeup_bdflush(). > > > > Have you actually seen any oom deadlock caused by flush_dirty_buffers() or > > you just added the bit there to be safe? > > > > I am? Not in the code I am looking at here: > > void wakeup_bdflush(int block) > { > if (current != bdflush_tsk) { > wake_up_process(bdflush_tsk); > > if (block) > flush_dirty_buffers(0); > } > } > > The code in the cvs tree I have does not do that either, you either > have a modified tree, or I am misinterpreting where you mean in > the code. The only PF_MEMALLOC I messed with was in page_buf_io.c > out of the writepage method. I'm stupid. Those were my modifications in my local XFS tree. Marcelo runs. From owner-linux-xfs@oss.sgi.com Thu Feb 1 19:04:19 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 19:04:00 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:32632 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 19:03:37 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA07284 for ; Thu, 1 Feb 2001 19:03:33 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA677259; Thu, 1 Feb 2001 20:59:41 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA52873; Thu, 1 Feb 2001 20:59:41 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1230E903798; Thu, 1 Feb 2001 21:00:15 -0600 Message-Id: <200102020300.f1230E903798@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Derek Glidden cc: linux-xfs@oss.sgi.com Subject: Re: xfs_shrinkfs ? In-Reply-To: Message from Derek Glidden of "Thu, 01 Feb 2001 19:11:32 EST." <3A79FB34.7406CB7C@illusionary.com> Date: Thu, 01 Feb 2001 21:00:14 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > First off, many kudos to the SGI folks et al for the amazing work at > getting XFS ported and running so quickly and well on Linux! Thanks! > > Now the question: I've got a big XFS LVM volume on my file server and > I'm just curious if there is a utility that can shrink an XFS > filesystem, if I decide for whatever reason to shrink the LVM volume the > filesystem happens to be on. I'm busy backing up the partition right > now to test this directly, but it'd be nice to hear for certain. > Martin already answered this, there is unfortunately no such beast. Growing the filesystem is easy, you just tag some space on the end and fix up some counters, oh and because we do it live it is safe against crashes since we journal it. Shrinking is much harder, you almost certainly want the same journaling protection, which means you need to do more than just migrate structures around the disk, you need to cope with new ongoing activity. OK, you could do the offline version with less work, but you need to find all the inodes, directory blocks, data blocks, etc within the allocation groups to be removed (we would have to do whole allocation groups I think). Doing this would require a complete scan of all inodes in the filesystem to find the ones affected. The allocator would need modification to be able to prevent new allocations into these areas. Then it is just a matter of moving all the files and directories one by one, the files part is easy, the directories would be harder, but not impossible. It would not be possible to keep inode numbers constant - since these encode a disk location. Probably about 3 months work for an expert - any volunteers? Steve From owner-linux-xfs@oss.sgi.com Thu Feb 1 20:30:49 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 20:30:41 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:25626 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 20:30:23 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA00187 for ; Thu, 1 Feb 2001 20:30:21 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA74783 for linux-xfs@oss.sgi.com; Fri, 2 Feb 2001 15:29:06 +1100 (EST) Date: Fri, 2 Feb 2001 15:29:06 +1100 (EST) From: Nathan Scott Message-Id: <200102020429.PAA74783@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Feb 1 20:28:58 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/quota-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:84741a linux/fs/dquot.c - 1.22 - fix a permission problem for non-root users using quota tools. linux/fs/xfs/dmapi/Makefile - 1.8 - pseudo-inc is gone. From owner-linux-xfs@oss.sgi.com Thu Feb 1 23:10:31 2001 Received: by oss.sgi.com id ; Thu, 1 Feb 2001 23:10:12 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:8994 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Feb 2001 23:09:45 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA25350 for ; Thu, 1 Feb 2001 23:08:44 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA75591 for linux-xfs@oss.sgi.com; Fri, 2 Feb 2001 18:08:01 +1100 (EST) Date: Fri, 2 Feb 2001 18:08:01 +1100 (EST) From: Nathan Scott Message-Id: <200102020708.SAA75591@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Couple of changes Marco requested. Date: Thu Feb 1 23:06:44 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:84744a cmd/quota/Makefile.in - 1.7 - reinstate ALT_FORMAT as a build-time option. cmd/quota/README.xfs - 1.6 - update status wrt NFS mounts and ALT_FORMAT. cmd/quota/edquota.c - 1.5 cmd/quota/quotaops.c - 1.8 cmd/quota/quotaops.h - 1.4 - reinstate ALT_FORMAT as a build-time option. fix a bug in the timer handling which could cause a segv. cmd/quota/rquota.h - 1.2 cmd/quota/rquota.x - 1.2 cmd/quota/rquota_clnt.c - 1.2 cmd/quota/rquota_xdr.c - 1.2 - fix up some build warnings. cmd/quota/rquota_server.c - 1.3 - alot of work to get NFS mounted xfs filesystems with quota enabled correctly reported by the quota tools. some work still to be done, but this is functional & works quite nicely for linux->linux case. From owner-linux-xfs@oss.sgi.com Fri Feb 2 01:56:53 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 01:56:34 -0800 Received: from drone4-svc-skyt.qsi.net.nz ([202.89.128.4]:19978 "HELO drone4.qsi.net.nz") by oss.sgi.com with SMTP id ; Fri, 2 Feb 2001 01:56:10 -0800 Received: (qmail 6062 invoked by uid 0); 2 Feb 2001 09:56:07 -0000 Received: from unknown (HELO adam) ([202.89.144.70]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 2 Feb 2001 09:56:07 -0000 From: "Adam Warner" To: Subject: RE: xfs installer (SGI Pre-Release ISO)--SUCCESS Date: Fri, 2 Feb 2001 22:56:33 +1200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A798C0E.180B526@sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi Eric and all, >From previous experience of booting Linux on the HPT366 I was aware that neither of Keith's welcome suggestions were necessary. What I did was: Had another go at reinstalling the OS, following the installation instructions for the original Redhat 7 disks to the letter. But it still wouldn't boot. Played with a number of settings. Then remembered to add "lba32" to lilo.conf. Decided to let linux take control of the MBR instead of just the partition (Linux is now my boot manager). And it worked! Kernel 2.4.0-SGI_XFS_PRsmp on a 2-processor i686. So thanks for all your persistence. I'm so glad I got it to work. A documentation suggestion for your rescue procedure. You state: mount hda /mnt/A mount hda /mnt/A/boot Ideally this should be: mount -t xfs /dev/hda /mnt/A mount -t xfs /dev/hda /mnt/A/boot Regards, Adam -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On Behalf Of Eric Sandeen Sent: Friday, 2 February 2001 4:17 a.m. To: Adam Warner Cc: linux-xfs@oss.sgi.com Subject: Re: xfs installer (SGI Pre-Release ISO) Adam Warner wrote: > > Hi Eric, > > Well I gave it my best shot--twice. > > The advice was really helpful. In this end this is how I distilled the > commands: > > cd /tmp > mknod hde1 (b 3 didn't work because I had to provide a major AND minor > number) > mount -t xfs /mnt/A > chroot /mnt/A Oh, I'm sorry... there was a typo on our help page, and I was reading from it on autopilot... should be: cd /tmp mknod hda b 3 (i.e. mknod hda1 b 3 1) mknod hda b 3 (if you have /boot) mount hda /mnt/A mount hda /mnt/A/boot chroot /mnt/A (that's checked in for the web page now). I'll bet that one of Keith's suggestions fixes your problem - you have to tell Lilo where to look for the drive in your system. -Eric From owner-linux-xfs@oss.sgi.com Fri Feb 2 06:56:05 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 06:55:56 -0800 Received: from hm32.locaweb.com.br ([200.246.179.102]:3775 "HELO hm32.locaweb.com.br") by oss.sgi.com with SMTP id ; Fri, 2 Feb 2001 06:55:50 -0800 Received: (qmail 25669 invoked by uid 811); 2 Feb 2001 14:55:37 -0000 Date: 2 Feb 2001 14:55:37 -0000 Message-ID: <20010202145537.25668.qmail@hm32.locaweb.com.br> From: =?ISO-8859-1?Q? "Jo=E3o?= Paulo Legat" To: linux-xfs@oss.sgi.com Subject: Can't start X, console ownership References: In-Reply-To: X-IPAddress: 200.177.200.169 X-Sender: jp@404notfound.com.br Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I got the SGI-XFS-PR and installed from the ISO. Everything worked fine, except that I'm unable to run X with other user but root. The error says: Authentication failed - cannot start X server. > Perhaps you do not have console > ownership? Any help is appreciated. Regards, JP From owner-linux-xfs@oss.sgi.com Fri Feb 2 07:43:44 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 07:43:26 -0800 Received: from mail11.jump.net ([206.196.91.11]:47245 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 07:43:09 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f12Fh5T01268; Fri, 2 Feb 2001 09:43:05 -0600 (CST) Message-ID: <3A7AD597.6F662EE2@sgi.com> Date: Fri, 02 Feb 2001 09:43:19 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?Jo=E3o?= Paulo Legat CC: linux-xfs@oss.sgi.com Subject: Re: Can't start X, console ownership References: <20010202145537.25668.qmail@hm32.locaweb.com.br> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a known issue with XFree86 and devfs - please see our caveats list at http://oss.sgi.com/projects/xfs/installcavs.html for this and other problems you may experience. The fix for your problem below is to edit /etc/security/console.perms Change # file classes -- these are regular expressions =tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9] to # file classes -- these are regular expressions =tty[0-9][0-9]* vc\/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] to add the vc/* devices to the access list. Good luck, - Eric Sandeen SGI, Inc. XFS for Linux João Paulo Legat wrote: > > Hi, > > I got the SGI-XFS-PR and installed from the ISO. Everything worked fine, > except that I'm unable to run X with other user but root. > > The error says: > > Authentication failed - cannot start X server. > > Perhaps you do not have console > > ownership? > > Any help is appreciated. > > Regards, > > JP From owner-linux-xfs@oss.sgi.com Fri Feb 2 09:31:38 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 09:31:18 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:49707 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 09:30:57 -0800 Received: from trantor.americas.sgi.com (root@trantor.americas.sgi.com [128.162.211.23]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA24914 for ; Fri, 2 Feb 2001 09:29:57 -0800 (PST) mail_from (mann@trantor.americas.sgi.com) Received: (from mann@localhost) by trantor.americas.sgi.com (8.11.0/8.11.0) id f12HWr402840 for linux-xfs@oss.sgi.com; Fri, 2 Feb 2001 11:32:53 -0600 Date: Fri, 2 Feb 2001 11:32:53 -0600 From: Mark Nordstrand Message-Id: <200102021732.f12HWr402840@trantor.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Feb 2 09:31:04 PST 2001 Workarea: 128.162.211.23:/usr/home/man/work2 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:84764a linux/include/linux/xfs_fs.h - 1.20 - Make INDUCE_IO_ERROR easily accessable. cmd/xfstests/src/fsstress.c - 1.2 - linux/xfs_fs.h Turn off ERROR_INJECT_DISABLE (or turn on error injection). From owner-linux-xfs@oss.sgi.com Fri Feb 2 10:40:09 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 10:40:00 -0800 Received: from cloven.nks.net ([216.139.201.15]:12816 "EHLO homer.mkintl.com") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 10:39:40 -0800 Received: from illusionary.com (two.nks.net [192.168.1.22]) by homer.mkintl.com (8.9.3/8.9.3) with ESMTP id NAA04039; Fri, 2 Feb 2001 13:39:15 -0500 Message-ID: <3A7AFED3.C48E2DC0@illusionary.com> Date: Fri, 02 Feb 2001 13:39:15 -0500 From: Derek Glidden X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: xfs_shrinkfs ? References: <200102020300.f1230E903798@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > > Martin already answered this, there is unfortunately no such beast. Growing > the filesystem is easy, you just tag some space on the end and fix up some > counters, oh and because we do it live it is safe against crashes since we > journal it. That makes sense. I kinda figured the filesystem structure would allow for something like that, but I hadn't thought about journaling the action as well. > Shrinking is much harder, you almost certainly want the same journaling > protection, which means you need to do more than just migrate structures > around the disk, you need to cope with new ongoing activity. OK, you could > do the offline version with less work, but you need to find all the inodes, > directory blocks, data blocks, etc within the allocation groups to be > removed (we would have to do whole allocation groups I think). Doing this > would require a complete scan of all inodes in the filesystem to find > the ones affected. The allocator would need modification to be able to > prevent new allocations into these areas. Then it is just a matter of > moving all the files and directories one by one, the files part is easy, > the directories would be harder, but not impossible. It would not be > possible to keep inode numbers constant - since these encode a disk > location. > > Probably about 3 months work for an expert - any volunteers? Good lord... I think the amount of extra work it would require to create such a beast would way way way outweigh the amount of extra work involved in "backup, shrink volume, recreate filesystem, restore" that the very, very few people who would want such a thing would have to go through due to it not existing. Unless there's some huge unvoiced contingent of people who really want it, I'd personally rather any experts who thought about putting time into such a utility would work on the XFS core instead. Now I'm kind of embarrassed I brought it up... :) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- With Microsoft products, failure is not Derek Glidden an option - it's a standard component. http://3dlinux.org/ Choose your life. Choose your http://www.tbcpc.org/ future. Choose Linux. http://www.illusionary.com/ From owner-linux-xfs@oss.sgi.com Fri Feb 2 11:00:59 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 11:00:50 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:2635 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 11:00:28 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA03458 for ; Fri, 2 Feb 2001 11:00:17 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA681039; Fri, 2 Feb 2001 12:56:29 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA55080; Fri, 2 Feb 2001 12:56:29 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f12IuuN13481; Fri, 2 Feb 2001 12:56:56 -0600 Message-Id: <200102021856.f12IuuN13481@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Derek Glidden cc: linux-xfs@oss.sgi.com Subject: Re: xfs_shrinkfs ? In-Reply-To: Message from Derek Glidden of "Fri, 02 Feb 2001 13:39:15 EST." <3A7AFED3.C48E2DC0@illusionary.com> Date: Fri, 02 Feb 2001 12:56:56 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > > > Martin already answered this, there is unfortunately no such beast. Growing > > the filesystem is easy, you just tag some space on the end and fix up some > > counters, oh and because we do it live it is safe against crashes since we > > journal it. > > That makes sense. I kinda figured the filesystem structure would allow > for something like that, but I hadn't thought about journaling the > action as well. > > > Shrinking is much harder, you almost certainly want the same journaling > > protection, which means you need to do more than just migrate structures > > around the disk, you need to cope with new ongoing activity. OK, you could > > do the offline version with less work, but you need to find all the inodes, > > directory blocks, data blocks, etc within the allocation groups to be > > removed (we would have to do whole allocation groups I think). Doing this > > would require a complete scan of all inodes in the filesystem to find > > the ones affected. The allocator would need modification to be able to > > prevent new allocations into these areas. Then it is just a matter of > > moving all the files and directories one by one, the files part is easy, > > the directories would be harder, but not impossible. It would not be > > possible to keep inode numbers constant - since these encode a disk > > location. > > > > Probably about 3 months work for an expert - any volunteers? > > Good lord... I think the amount of extra work it would require to > create such a beast would way way way outweigh the amount of extra work > involved in "backup, shrink volume, recreate filesystem, restore" that > the very, very few people who would want such a thing would have to go > through due to it not existing. > > Unless there's some huge unvoiced contingent of people who really want > it, I'd personally rather any experts who thought about putting time > into such a utility would work on the XFS core instead. > > Now I'm kind of embarrassed I brought it up... :) > No question should be embarrassing. This is one of those features which you really have to design in from day one. As you point out, it is now one of those things where the cost of implementing it probably outweighs the amount of gain to the people who might use it. Now that ext2 to xfs converter though ..... ;-) Steve From owner-linux-xfs@oss.sgi.com Fri Feb 2 12:43:49 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 12:43:30 -0800 Received: from PIERRE.MIT.EDU ([18.77.0.109]:18436 "EHLO pierre.mit.edu") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 12:43:20 -0800 Received: from localhost (gelinas@localhost) by pierre.mit.edu (8.9.3/8.9.3) with ESMTP id PAA01252 for ; Fri, 2 Feb 2001 15:43:13 -0500 (EST) X-Authentication-Warning: pierre.mit.edu: gelinas owned process doing -bs Date: Fri, 2 Feb 2001 15:43:12 -0500 (EST) From: "J. Maynard Gelinas" X-Sender: To: Subject: CVS 2.4.1-XFS module support broken? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello folks, I CVS'd down the source to your XFS 2.4.1 kernel last night and built a kernel and tools under RH-6.2 for a RAID that I'm setting up to export home directories. The system isn't production -- yet -- so I'm willing to experiment for the moment. However, I've run into a few problems: a) The kernel build environment demands kgcc. Simple fix. b) The tools build fails at the end with an error to the effect that one needs linux-2.4.1.tar.bz2 in /SOURCES ... adding the tarball doesn't fix the error. Fortunately, it appears that critical tools such as mkfs.xfs et all are already installed by that point. c) With modutils-2.4.2 installed I'm getting: [root@ctpraid1 /etc]# insmod autofs Using /lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o /lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o: unresolved symbol dput /lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o: unresolved symbol [...] /lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o: unresolved symbol printk /lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o: unresolved symbol follow_down [root@ctpraid1 /etc]# uname -a Linux ctpraid1 2.4.1-XFS #3 Fri Feb 2 12:11:17 EST 2001 i686 unknown root@ctpraid1 /etc]# rpm -qa | grep modutils modutils-2.4.2-1 [root@ctpraid1 /etc]# Module and versioning support is compiled into the kernel. Finally, a question: I know that reiserfs has had problems in the past with file corruption on NFS exported volumes. Should I expect similar issues with XFS? (Hope not!). Thanks, --Maynard From owner-linux-xfs@oss.sgi.com Fri Feb 2 13:57:20 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 13:57:00 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:17414 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 13:56:51 -0800 Received: from godzilla.melbourne.sgi.com (godzilla.melbourne.sgi.com [134.14.55.188]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA05599 for ; Fri, 2 Feb 2001 13:55:50 -0800 (PST) mail_from (mg@godzilla.melbourne.sgi.com) Received: from localhost (mg@localhost) by godzilla.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id IAA39918; Sat, 3 Feb 2001 08:55:24 +1100 (EST) Date: Sat, 3 Feb 2001 08:55:23 +1100 From: Mike Gigante To: Derek Glidden cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: xfs_shrinkfs ? In-Reply-To: <3A7AFED3.C48E2DC0@illusionary.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing xfs_fsr already exists right? It would appear that it could be modified without too much pain so that all the free space was contiguous at the end of the device. You'd also have to move the inodes from the back-end of the device (and hence change the inode numbers) but it would probably be a good start. ----------------------------------------------------------------------- Michael Gigante R&D Software Engineer mg@melbourne.sgi.com SGI Performance Tools Group, +61 3 9834 8233 Melbourne Australia V-Net: 524-8233 From owner-linux-xfs@oss.sgi.com Fri Feb 2 14:02:00 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 14:01:50 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:56861 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 14:01:36 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA03530 for ; Fri, 2 Feb 2001 14:01:17 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA687170; Fri, 2 Feb 2001 15:58:14 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA08534; Fri, 2 Feb 2001 15:58:14 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f12LweO16536; Fri, 2 Feb 2001 15:58:40 -0600 Message-Id: <200102022158.f12LweO16536@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mike Gigante cc: Derek Glidden , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: xfs_shrinkfs ? In-Reply-To: Message from Mike Gigante of "Sat, 03 Feb 2001 08:55:23 +1100." Date: Fri, 02 Feb 2001 15:58:40 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > xfs_fsr already exists right? It would appear that it could be modified > without too much pain so that all the free space was contiguous at the > end of the device. You'd also have to move the inodes from the back-end > of the device (and hence change the inode numbers) but it would probably > be a good start. > xfs_fsr just moves extents in a file, all it does is ask the kernel to create some new extents, and hopes they are more contiguous than the old ones. This does not give us the control to say 'don't use the end of the disk'. It also does not deal with directories. Steve From owner-linux-xfs@oss.sgi.com Fri Feb 2 14:12:20 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 14:12:00 -0800 Received: from hm32.locaweb.com.br ([200.246.179.102]:10452 "HELO hm32.locaweb.com.br") by oss.sgi.com with SMTP id ; Fri, 2 Feb 2001 14:11:49 -0800 Received: (qmail 11293 invoked by uid 811); 2 Feb 2001 22:11:43 -0000 Date: 2 Feb 2001 22:11:43 -0000 Message-ID: <20010202221143.11292.qmail@hm32.locaweb.com.br> From: =?ISO-8859-1?Q? "Jo=E3o?= Paulo Legat" To: Eric Sandeen , =?iso-8859-1?Q?Jo=E3o?= Paulo Legat , linux-xfs@oss.sgi.com Subject: Re: Can't start X, console ownership References: <> In-Reply-To: <> X-IPAddress: 200.177.202.83 X-Sender: jp@404notfound.com.br Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing It's true, it's in the caveats... Anyway, it's working perfectly now. Much appreciated. Best regards, JP On Fri, 02 Feb 2001 09:43:19 -0600, Eric Sandeen wrote : > This is a known issue with XFree86 and devfs - please see our caveats > list at > > http://oss.sgi.com/projects/xfs/installcavs.html > > for this and other problems you may experience. > > The fix for your problem below is to edit /etc/security/console.perms > > Change > > # file classes -- these are regular expressions > =tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9] > > to > > # file classes -- these are regular expressions > =tty[0-9][0-9]* vc\/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] > > to add the vc/* devices to the access list. > > Good luck, > > - Eric Sandeen > SGI, Inc. > XFS for Linux > > João Paulo Legat wrote: > > > > > Hi, > > > > I got the SGI-XFS-PR and installed from the ISO. Everything worked fine, > > except that I'm unable to run X with other user but root. > > > > The error says: > > > > Authentication failed - cannot start X server. > > > Perhaps you do not have console > > > ownership? > > > > Any help is appreciated. > > > > Regards, > > > > JP > > > From owner-linux-xfs@oss.sgi.com Fri Feb 2 14:30:19 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 14:30:00 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:48644 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Fri, 2 Feb 2001 14:29:42 -0800 Received: (qmail 8031 invoked from network); 2 Feb 2001 22:29:35 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Feb 2001 22:29:35 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "J. Maynard Gelinas" cc: linux-xfs@oss.sgi.com Subject: Re: CVS 2.4.1-XFS module support broken? In-reply-to: Your message of "Fri, 02 Feb 2001 15:43:12 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Feb 2001 09:29:35 +1100 Message-ID: <9811.981152975@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 2 Feb 2001 15:43:12 -0500 (EST), "J. Maynard Gelinas" wrote: >[root@ctpraid1 /etc]# insmod autofs >Using /lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o >/lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o: unresolved symbol printk >[root@ctpraid1 /etc]# uname -a >Linux ctpraid1 2.4.1-XFS #3 Fri Feb 2 12:11:17 EST 2001 i686 unknown >Module and versioning support is compiled into the kernel. I need the output from grep printk /proc/ksyms strings -a /lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o | grep printk grep printk 2.4.1-XFS/include/linux/modversions.h point that last command at the 2.4.1-XFS source tree. From owner-linux-xfs@oss.sgi.com Fri Feb 2 17:08:14 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 17:08:05 -0800 Received: from PIERRE.MIT.EDU ([18.77.0.109]:63239 "EHLO pierre.mit.edu") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 17:07:47 -0800 Received: from localhost (gelinas@localhost) by pierre.mit.edu (8.9.3/8.9.3) with ESMTP id UAA24123; Fri, 2 Feb 2001 20:07:11 -0500 (EST) X-Authentication-Warning: pierre.mit.edu: gelinas owned process doing -bs Date: Fri, 2 Feb 2001 20:07:11 -0500 (EST) From: "J. Maynard Gelinas" X-Sender: To: Keith Owens cc: Subject: Re: CVS 2.4.1-XFS module support broken? In-Reply-To: <9811.981152975@ocs3.ocs-net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing OK, will do: Last login: Fri Feb 2 17:03:57 2001 from ctpjaguar.mit.edu [root@ctpraid1 /root]# grep printk /proc/ksyms c011446c printk_R__ver_printk [root@ctpraid1 /root]# strings -a /lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o | grep printk printk [root@ctpraid1 /root]# grep printk /usr/src/linux/include/linux/modversions.h [root@ctpraid1 /root]# [root@ctpraid1 /root]# ls -al /usr/src/linux lrwxrwxrwx 1 root root 19 Feb 1 19:35 /usr/src/linux -> linux-2.4-xfs/linux ls -al /usr/include/asm lrwxrwxrwx 1 root root 26 Feb 1 19:27 /usr/include/asm -> /usr/src/linux/include/asm [root@ctpraid1 /root]# ls -al /usr/include/linux lrwxrwxrwx 1 root root 28 Feb 1 19:27 /usr/include/linux -> /usr/src/linux/include/linux It looks like I've got my include symlinks right, and the /usr/src/linux link goes straight into the kernel source. Cheers, --Maynard On Sat, 3 Feb 2001, Keith Owens wrote: > On Fri, 2 Feb 2001 15:43:12 -0500 (EST), > "J. Maynard Gelinas" wrote: > >[root@ctpraid1 /etc]# insmod autofs > >Using /lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o > >/lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o: unresolved symbol printk > >[root@ctpraid1 /etc]# uname -a > >Linux ctpraid1 2.4.1-XFS #3 Fri Feb 2 12:11:17 EST 2001 i686 unknown > >Module and versioning support is compiled into the kernel. > > I need the output from > > grep printk /proc/ksyms > strings -a /lib/modules/2.4.1-XFS/kernel/fs/autofs/autofs.o | grep printk > grep printk 2.4.1-XFS/include/linux/modversions.h > > point that last command at the 2.4.1-XFS source tree. > > From owner-linux-xfs@oss.sgi.com Fri Feb 2 18:02:25 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 18:02:15 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:47621 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Fri, 2 Feb 2001 18:01:57 -0800 Received: (qmail 9730 invoked from network); 3 Feb 2001 02:01:51 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 3 Feb 2001 02:01:51 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "J. Maynard Gelinas" cc: linux-xfs@oss.sgi.com Subject: Re: CVS 2.4.1-XFS module support broken? In-reply-to: Your message of "Fri, 02 Feb 2001 20:07:11 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Feb 2001 13:01:49 +1100 Message-ID: <12041.981165709@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 2 Feb 2001 20:07:11 -0500 (EST), "J. Maynard Gelinas" wrote: >Last login: Fri Feb 2 17:03:57 2001 from ctpjaguar.mit.edu >[root@ctpraid1 /root]# grep printk /proc/ksyms >c011446c printk_R__ver_printk You have been bitten by the broken kernel makefiles. This is not an XFS problem, it is a generic kernel bug. http://www.tux.org/lkml/#s8-8 From owner-linux-xfs@oss.sgi.com Fri Feb 2 22:21:26 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 22:21:15 -0800 Received: from mail11.jump.net ([206.196.91.11]:5831 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 22:20:55 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f136KnV10530; Sat, 3 Feb 2001 00:20:49 -0600 (CST) Message-ID: <3A7BA355.86692AEE@sgi.com> Date: Sat, 03 Feb 2001 00:21:09 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: "J. Maynard Gelinas" CC: linux-xfs@oss.sgi.com Subject: Re: CVS 2.4.1-XFS module support broken? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "J. Maynard Gelinas" wrote: > > Hello folks, > b) The tools build fails at the end with an error to the effect that one > needs linux-2.4.1.tar.bz2 in /SOURCES ... adding the tarball > doesn't fix the error. Fortunately, it appears that critical tools such as > mkfs.xfs et all are already installed by that point. Hm, this may be part of a different build process, RPM kernel packaging and such... Is this from the top-level Makefile (above SCRIPTS, SOURCES, SPECS, etc)? You should be able to go into cmd/xfsprogs and build (make / make install) the tools there, I believe. "make dist" in cmd/xfsprogs/build will make you a tarball and RPMS as well. -Eric From owner-linux-xfs@oss.sgi.com Sat Feb 3 06:57:38 2001 Received: by oss.sgi.com id ; Sat, 3 Feb 2001 06:57:28 -0800 Received: from vie-cs0.ebnewcom.at ([193.83.118.218]:58633 "EHLO vie-ms01.office.ecetra.com") by oss.sgi.com with ESMTP id ; Sat, 3 Feb 2001 06:57:12 -0800 Received: by vie-ms01.office.ecetra.com with Internet Mail Service (5.5.2653.19) id ; Sat, 3 Feb 2001 15:57:05 +0100 Message-ID: <6528DABD42A2E945B4B0E984494233DB580C82@vie-ms01.office.ecetra.com> From: "Cioccarelli, Adam" To: 'Keith Owens' , "J. Maynard Gelinas" Cc: linux-xfs@oss.sgi.com Subject: RE: CVS 2.4.1-XFS module support broken? Date: Sat, 3 Feb 2001 15:57:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08DF1.9009F3E0" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing 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_001_01C08DF1.9009F3E0 Content-Type: text/plain; charset="iso-8859-1" I had exactly the same problem with modules, then I started again using make mrproper first (which I forgot to do the first time) and everything worked fine... -----Original Message----- From: Keith Owens [mailto:kaos@melbourne.sgi.com] Sent: Saturday, 3 February 2001 3:02 AM To: J. Maynard Gelinas Cc: linux-xfs@oss.sgi.com Subject: Re: CVS 2.4.1-XFS module support broken? On Fri, 2 Feb 2001 20:07:11 -0500 (EST), "J. Maynard Gelinas" wrote: >Last login: Fri Feb 2 17:03:57 2001 from ctpjaguar.mit.edu >[root@ctpraid1 /root]# grep printk /proc/ksyms >c011446c printk_R__ver_printk You have been bitten by the broken kernel makefiles. This is not an XFS problem, it is a generic kernel bug. http://www.tux.org/lkml/#s8-8 ------_=_NextPart_001_01C08DF1.9009F3E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: CVS 2.4.1-XFS module support broken?

I had exactly the same problem with modules, then I = started again using make mrproper first (which I forgot to do the first = time) and everything worked fine...

-----Original Message-----
From: Keith Owens [mailto:kaos@melbourne.sgi.com= ]
Sent: Saturday, 3 February 2001 3:02 AM
To: J. Maynard Gelinas
Cc: linux-xfs@oss.sgi.com
Subject: Re: CVS 2.4.1-XFS module support broken? =


On Fri, 2 Feb 2001 20:07:11 -0500 (EST),
"J. Maynard Gelinas" = <gelinas@lns.mit.edu> wrote:
>Last login: Fri Feb  2 17:03:57 2001 from = ctpjaguar.mit.edu
>[root@ctpraid1 /root]# grep printk = /proc/ksyms
>c011446c printk_R__ver_printk

You have been bitten by the broken kernel = makefiles.  This is not an
XFS problem, it is a generic kernel bug.

http://www.tux.org/lkml/#s8-8

------_=_NextPart_001_01C08DF1.9009F3E0-- From owner-linux-xfs@oss.sgi.com Sat Feb 3 11:41:39 2001 Received: by oss.sgi.com id ; Sat, 3 Feb 2001 11:41:19 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:26912 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sat, 3 Feb 2001 11:40:54 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA06954 for ; Sat, 3 Feb 2001 11:40:36 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA39850; Sat, 3 Feb 2001 11:39:18 -0800 (PST) Date: Sat, 3 Feb 2001 11:40:10 -0800 (PST) From: Tom Duffy To: "J. Maynard Gelinas" cc: Subject: Re: CVS 2.4.1-XFS module support broken? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Hello folks, > > b) The tools build fails at the end with an error to the effect that one > needs linux-2.4.1.tar.bz2 in /SOURCES ... adding the tarball > doesn't fix the error. Fortunately, it appears that critical tools such as > mkfs.xfs et all are already installed by that point. this can be fixed by setting the environment variable WORKAREA to your top level directory. (under SOURCES) -tduffy From owner-linux-xfs@oss.sgi.com Sat Feb 3 14:12:01 2001 Received: by oss.sgi.com id ; Sat, 3 Feb 2001 14:11:41 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:24327 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Sat, 3 Feb 2001 14:11:09 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id XAA13746 for linux-xfs@oss.sgi.com; Sat, 3 Feb 2001 23:10:25 +0100 Date: Sat, 3 Feb 2001 23:10:25 +0100 From: sooo lame To: linux-xfs@oss.sgi.com Subject: 2.4.1-ac2 merge ? Message-ID: <20010203231025.A12482@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I noticed one issue on my 2.4-XFS kernels... It was fixed in Alan's series - 2.4.1-ac2 What i have in mind is: o Fix datagram hang on shutdown (Alexey Kuznetsov) It is very important for me, so , will CVS XFS tree be merged with -ac kernel ? or maybe until 2.4.2 comes ? - Krzysztof From owner-linux-xfs@oss.sgi.com Sat Feb 3 15:26:21 2001 Received: by oss.sgi.com id ; Sat, 3 Feb 2001 15:26:11 -0800 Received: from smtp5.xs4all.nl ([194.109.6.49]:60631 "EHLO smtp5.xs4all.nl") by oss.sgi.com with ESMTP id ; Sat, 3 Feb 2001 15:25:49 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA03572 for ; Sun, 4 Feb 2001 00:25:39 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA08975 for ; Sun, 4 Feb 2001 00:25:39 +0100 (CET) Date: Sun, 4 Feb 2001 00:25:38 +0100 (CET) From: Seth Mos To: linux-xfs@oss.sgi.com Subject: MD ioctls in mkfs.xfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing When trying to create a md volume on 2 ide disks in a raid0 md volume the sytem complains that an older ioctl is being used. The sytem is running redhat 6.2 with updates with a recent 2.4.1 cvs tree. mkfs.xfs(pid 9939) is using onsolete MD ioctl, upgrade your software to use new ioctls. mkfs.xfs: waning - can not set block size on block device /dev/md0 invalid argument. Any other hints except that I should use the newer raid tools? It still complains about the block size. More news when I upgrade my raidtools. Bye Seth From owner-linux-xfs@oss.sgi.com Sat Feb 3 16:09:52 2001 Received: by oss.sgi.com id ; Sat, 3 Feb 2001 16:09:31 -0800 Received: from [65.100.85.35] ([65.100.85.35]:8087 "EHLO localhost.localdomain") by oss.sgi.com with ESMTP id ; Sat, 3 Feb 2001 16:09:08 -0800 Received: from localhost (IDENT:ringram@gargoyle [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id RAA17530 for ; Sat, 3 Feb 2001 17:11:58 -0700 Date: Sat, 3 Feb 2001 17:11:58 -0700 (MST) From: Russ Ingram X-Sender: ringram@localhost.localdomain To: linux-xfs@oss.sgi.com Subject: Mouse detection with graphic installer Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I've been trying to install the XFS version of RH7 from the RH7.0-SGI-XFS_PR.iso CD and keep running into a mouse problem that I hope someone has some way around. My problem is that the PS2 mouse port on my system doesn't work but it is still detected by the kernel and by the graphical installer as the default mouse type. I want it to use the mouse that is connected to the serial port instead. Anyone have a workaround for this? Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Sat Feb 3 16:12:21 2001 Received: by oss.sgi.com id ; Sat, 3 Feb 2001 16:12:02 -0800 Received: from tux.mkp.net ([130.225.60.11]:17937 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Sat, 3 Feb 2001 16:11:58 -0800 Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 14PClN-00014U-00; Sun, 04 Feb 2001 01:10:42 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id TAA18429; Sat, 3 Feb 2001 19:11:22 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: sooo lame Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.1-ac2 merge ? References: <20010203231025.A12482@main.braxis.co.uk> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 03 Feb 2001 19:11:22 -0500 In-Reply-To: <20010203231025.A12482@main.braxis.co.uk> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Krzysztof" == sooo lame writes: Krzysztof> I noticed one issue on my 2.4-XFS kernels... It was fixed Krzysztof> in Alan's series - 2.4.1-ac2 Krzysztof> What i have in mind is: Krzysztof> o Fix datagram hang on shutdown (Alexey Kuznetsov) Krzysztof> It is very important for me, so , will CVS XFS tree be Krzysztof> merged with -ac kernel ? Unlikely. Merging is an extremely cumbersome process, and we can't possibly keep up with every release out there. I suggest you extract the appropriate bits from Alan's patch and apply them yourself. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Sat Feb 3 16:15:32 2001 Received: by oss.sgi.com id ; Sat, 3 Feb 2001 16:15:21 -0800 Received: from tux.mkp.net ([130.225.60.11]:19729 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Sat, 3 Feb 2001 16:15:04 -0800 Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 14PCoX-00014i-00; Sun, 04 Feb 2001 01:13:58 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id TAA18443; Sat, 3 Feb 2001 19:14:39 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: MD ioctls in mkfs.xfs References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 03 Feb 2001 19:14:39 -0500 In-Reply-To: Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --=-=-= >>>>> "Seth" == Seth Mos writes: Seth> When trying to create a md volume on 2 ide disks in a raid0 md Seth> volume the sytem complains that an older ioctl is being used. Seth> mkfs.xfs(pid 9939) is using onsolete MD ioctl, upgrade your Seth> software to use new ioctls. mkfs.xfs: waning - can not set Seth> block size on block device /dev/md0 invalid argument. I just committed a fix to CVS. Tiny patch attached below. Please note that we're still having several corruption issues with RAID5. These are being worked on... -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=md-blksetsize.diff diff -urN slinx-pristine/linux/drivers/md/md.c slinx-md/linux/drivers/md/md.c --- slinx-pristine/linux/drivers/md/md.c Sat Feb 3 18:58:15 2001 +++ slinx-md/linux/drivers/md/md.c Sat Feb 3 19:00:59 2001 @@ -2710,6 +2710,10 @@ err = do_md_stop (mddev, 1); goto done_unlock; + case BLKSETSIZE: + set_blocksize (mddev, (int *) arg); + goto done_unlock; + /* * We have a problem here : there is no easy way to give a CHS * virtual geometry. We currently pretend that we have a 2 heads --=-=-=-- From owner-linux-xfs@oss.sgi.com Sat Feb 3 16:16:41 2001 Received: by oss.sgi.com id ; Sat, 3 Feb 2001 16:16:22 -0800 Received: from tux.mkp.net ([130.225.60.11]:21521 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Sat, 3 Feb 2001 16:16:12 -0800 Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 14PCpe-00014w-00; Sun, 04 Feb 2001 01:15:07 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id TAA18446; Sat, 3 Feb 2001 19:15:49 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: linux-xfs@oss.sgi.com Subject: TAKE - BLKSETSIZE fixes From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 03 Feb 2001 19:15:49 -0500 Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Sat Feb 3 16:09:40 PST 2001 Workarea: sshgate.corp.sgi.com:/home/mkp/XFS/slinx-md The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:84856a linux/arch/mips64/kernel/ioctl32.c - 1.4 - Added BLKSETSIZE to MIPS64 ioctl mapper linux/drivers/md/md.c - 1.6 - Added BLKSETSIZE to MD -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Sun Feb 4 09:26:41 2001 Received: by oss.sgi.com id ; Sun, 4 Feb 2001 09:26:21 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:50261 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sun, 4 Feb 2001 09:25:56 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA04952 for ; Sun, 4 Feb 2001 09:25:54 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA701340; Sun, 4 Feb 2001 11:22:58 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA96509; Sun, 4 Feb 2001 11:22:58 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f14HN6a08323; Sun, 4 Feb 2001 11:23:06 -0600 Message-Id: <200102041723.f14HN6a08323@jen.americas.sgi.com> To: "Martin K. Petersen" cc: sooo lame , linux-xfs@oss.sgi.com Subject: Re: 2.4.1-ac2 merge ? References: <20010203231025.A12482@main.braxis.co.uk> Comments: In-reply-to "Martin K. Petersen" message dated "03 Feb 2001 19:11:22 -0500." Date: Sun, 04 Feb 2001 11:23:06 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing If this is the fix which is in 2.4.2-pre1 then that might be the easier thing to apply, it is pretty small, there are some serial console changes which may land on top of kdb code in the xfs tree though (but I would like those because my kdb serial line is running at 9600 because of flow control issues). I may merge this stuff in, but I will have to ask around internally first - other people are using our tree. Steve > >>>>> "Krzysztof" == sooo lame writes: > > Krzysztof> I noticed one issue on my 2.4-XFS kernels... It was fixed > Krzysztof> in Alan's series - 2.4.1-ac2 > > Krzysztof> What i have in mind is: > Krzysztof> o Fix datagram hang on shutdown (Alexey Kuznetsov) > > Krzysztof> It is very important for me, so , will CVS XFS tree be > Krzysztof> merged with -ac kernel ? > > Unlikely. Merging is an extremely cumbersome process, and we can't > possibly keep up with every release out there. > > I suggest you extract the appropriate bits from Alan's patch and apply > them yourself. > > -- > Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. > mkp@linuxcare.com, http://www.linuxcare.com/ > SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Sun Feb 4 12:58:32 2001 Received: by oss.sgi.com id ; Sun, 4 Feb 2001 12:58:23 -0800 Received: from [65.100.85.34] ([65.100.85.34]:25472 "EHLO roujin.gargoylecc.com") by oss.sgi.com with ESMTP id ; Sun, 4 Feb 2001 12:58:08 -0800 Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [65.100.85.34]) by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id FAA30949 for ; Mon, 5 Feb 2001 05:08:40 -0700 Date: Mon, 5 Feb 2001 05:08:40 -0700 (MST) From: Russel Ingram To: linux-xfs@oss.sgi.com Subject: Re: non-root X (was: Mouse detection with graphic installer) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I almost forgot, I also ran into another problem once I did get the installation done. I know what causes this but haven't found a way to fix it yet. Once the system is installed the only person that can start X is the root user. Its a permissions problem that stems from having a different device name for the console than what XF86 is expecting. I had the same problem when I was compiling 2.4.0-test? kernels for my systems and finally just stopped compiling in the new devfs. -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com On Sat, 3 Feb 2001, Eric Sandeen wrote: > Date: Sat, 03 Feb 2001 19:25:45 -0600 > From: Eric Sandeen > To: Russ Ingram > Subject: Re: Mouse detection with graphic installer > > Russ - I don't yet see any easy way to tell anaconda not to use the ps/2 > mouse - it's using kudzu, I guess, and it reports the first thing it > tries. I was hoping there was a boot time parameter to turn off the > ps/2 mouse in the kernel, but I don't see that... > > Any chance you can turn it off in your bios? > > If not, can you use the keyboard until the mouse selection screen, and > then tell it serial? Or maybe it just configures it that way, but > continues using the first mouse it thinks it "found..." > > -Eric > From owner-linux-xfs@oss.sgi.com Sun Feb 4 13:08:52 2001 Received: by oss.sgi.com id ; Sun, 4 Feb 2001 13:08:42 -0800 Received: from [65.100.85.35] ([65.100.85.35]:48546 "EHLO localhost.localdomain") by oss.sgi.com with ESMTP id ; Sun, 4 Feb 2001 13:08:13 -0800 Received: from localhost (IDENT:ringram@gargoyle [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id OAA31483 for ; Sun, 4 Feb 2001 14:10:55 -0700 Date: Sun, 4 Feb 2001 14:10:54 -0700 (MST) From: Russ Ingram X-Sender: ringram@localhost.localdomain To: linux-xfs@oss.sgi.com Subject: Igonre my last message -- oops Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Sorry about the last post about the console problem with X. I thought I was subscribed to the list and didn't look at the archives before posting. Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Sun Feb 4 15:11:12 2001 Received: by oss.sgi.com id ; Sun, 4 Feb 2001 15:11:02 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:61820 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 4 Feb 2001 15:10:48 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA08007 for ; Sun, 4 Feb 2001 15:09:46 -0800 (PST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id KAA27403; Mon, 5 Feb 2001 10:09:19 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Steve Lord cc: "Martin K. Petersen" , sooo lame , linux-xfs@oss.sgi.com Subject: Re: 2.4.1-ac2 merge ? In-reply-to: Your message of "Sun, 04 Feb 2001 11:23:06 MDT." <200102041723.f14HN6a08323@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Feb 2001 10:09:18 +1100 Message-ID: <25660.981328158@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, 04 Feb 2001 11:23:06 -0600, Steve Lord wrote: >If this is the fix which is in 2.4.2-pre1 then that might be the >easier thing to apply, it is pretty small, there are some serial >console changes which may land on top of kdb code in the xfs tree >though (but I would like those because my kdb serial line is running >at 9600 because of flow control issues). Just merged kdb v1.7 for ix86 up to 2.4.2-pre1 and put it on oss.sgi.com. The serial console changes in 2.4.2-pre1 do not directly affect kdb. They may or may not solve Steve Lord's problem, it depends a lot on the receiving machine. I still see lost characters in 2.4.2-pre1 with a serial console running at 38400, but I suspect the problem is the old terminal server that the other end of the null modem is plugged into. From owner-linux-xfs@oss.sgi.com Mon Feb 5 01:44:14 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 01:44:04 -0800 Received: from studsv07.studserv.uni-stuttgart.de ([129.69.21.37]:18446 "EHLO studsv07.studserv.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 01:43:44 -0800 Received: from ysabell [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.05) id A5CCE301D0; Mon, 05 Feb 2001 10:43:40 +0100 Received: from marcelo by ysabell with local (Exim 3.22 #1 (Debian)) id 14PiBG-0000Id-00 for ; Mon, 05 Feb 2001 10:43:30 +0100 Date: Mon, 5 Feb 2001 10:43:30 +0100 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: stress test failures Message-ID: <20010205104330.A1108@ysabell.wh.vaih> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.3.12i X-Operating-System: Linux ysabell 2.4.1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I got a failure on test 020, short version: 020 - output mismatch (see 020.out.bad) 65a66,68 > 0001520 e5 79 0d 00 03 00 00 00 c0 79 0d 00 00 00 00 00 > 0001540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > * 020.out.bad attached. 051 also fails: 051 - output mismatch (see 051.out.bad) 24c24 < sh: ./file1: Permission denied --- > Test was executed 29c29 < sh: ./file1: Permission denied --- > Test was executed 35c35 < sh: ./file1: Permission denied --- > Test was executed 40c40 < sh: ./file1: Permission denied --- > Test was executed 42c42 < sh: ./file1: Permission denied --- > Test was executed 44c44 < sh: ./file1: Permission denied --- > Test was executed 56c56 < file1 [u::---,g::---,o::---,u:1002:r-x,m::rwx] --- > file1 [u::---,g::---,o::---,u:simvis:r-x,m::rwx] 59c59 < sh: ./file1: Permission denied --- > Test was executed 65,66c65,66 < file1 [u::---,g::---,o::---,u:1002:r-x,m::rwx] < file1 [u::---,g::---,o::---,g:1002:r-x,m::rwx] --- > file1 [u::---,g::---,o::---,u:simvis:r-x,m::rwx] > file1 [u::---,g::---,o::---,g:xxxxxx:r-x,m::rwx] 72c72 < sh: ./file1: Permission denied --- > Test was executed 75c75 < file1 [u::---,g::---,o::---,g:1002:r-x,m::-wx] --- > file1 [u::---,g::---,o::---,g:xxxxxx:r-x,m::-wx] 77c77 < ./file1: ./file1: Permission denied --- > Test was executed 79c79 < ./file1: ./file1: Permission denied --- > Test was executed 85c85 < sh: ./file1: Permission denied --- > Test was executed "xxxxxxx" is the name of the group with gid 1002 (someone arround here could get uneasy if I disclose it). I guess chacl needs a "numeric" flag. -- Marcelo --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="020.out.bad" QA output created by 020 *** list non-existant file *** print attributes attr_list: No such file or directory Could not list attributes for !!! error return *** list non-xfs file (in /proc) *** print attributes attr_list: Invalid argument Could not list attributes for !!! error return *** list empty file *** print attributes *** 0 attribute(s) *** query non-existant attribute attr_get: No data available Could not get "nonexistant" for *** one attribute Attribute "fish" set to a 5 byte value for : fish *** print attributes *** 1 attribute(s) *** field: fish length: 5 ::: fish ::: *** replace attribute Attribute "fish" set to a 6 byte value for : fish3 *** print attributes *** 1 attribute(s) *** field: fish length: 6 ::: fish3 ::: *** add attribute Attribute "snrub" set to a 6 byte value for : fish2 *** print attributes *** 2 attribute(s) *** field: fish length: 6 ::: fish3 ::: *** field: snrub length: 6 ::: fish2 ::: *** remove attribute *** print attributes *** 1 attribute(s) *** field: snrub length: 6 ::: fish2 ::: *** add lots of attributes *** check *** 1001 attribute(s) *** remove lots of attributes *** print attributes *** 1 attribute(s) *** field: snrub length: 6 ::: fish2 ::: *** really long value 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0001520 e5 79 0d 00 03 00 00 00 c0 79 0d 00 00 00 00 00 0001540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0200000 0a 0200001 *** set/get/remove really long names (expect failure) attr_set: Bad address Could not set "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" for attr_get: Bad address Could not get "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" for attr_remove: Bad address Could not remove "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" for *** check final *** print attributes *** 1 attribute(s) *** field: snrub length: 6 ::: fish2 ::: *** delete --lrZ03NoBR/3+SXJZ-- From owner-linux-xfs@oss.sgi.com Mon Feb 5 07:45:14 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 07:44:55 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:6429 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 07:44:35 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA26272 for ; Mon, 5 Feb 2001 07:43:35 -0800 (PST) mail_from (mann@trantor.americas.sgi.com) Received: from trantor.americas.sgi.com (root@[128.162.211.23]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA47601 for ; Mon, 5 Feb 2001 07:44:04 -0800 (PST) Received: (from mann@localhost) by trantor.americas.sgi.com (8.11.0/8.11.0) id f15FkMI08221 for linux-xfs@oss.sgi.com; Mon, 5 Feb 2001 09:46:22 -0600 Date: Mon, 5 Feb 2001 09:46:22 -0600 From: Mark Nordstrand Message-Id: <200102051546.f15FkMI08221@trantor.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Feb 5 07:44:01 PST 2001 Workarea: 128.162.211.23:/usr/home/man/work2 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:84890a cmd/xfsprogs/include/xfs_fs.h - 1.2 - Sync with linux/include/linux/xfs_fs.h From owner-linux-xfs@oss.sgi.com Mon Feb 5 08:03:24 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 08:03:15 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:2830 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 08:02:53 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08741 for ; Mon, 5 Feb 2001 08:02:14 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA707447 for ; Mon, 5 Feb 2001 09:59:38 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA49749 for ; Mon, 5 Feb 2001 09:59:38 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f15FxaX23217; Mon, 5 Feb 2001 09:59:36 -0600 Message-Id: <200102051559.f15FxaX23217@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Re: stress test failures In-Reply-To: Message from "Marcelo E. Magallon" of "Mon, 05 Feb 2001 10:43:30 +0100." <20010205104330.A1108@ysabell.wh.vaih> Date: Mon, 05 Feb 2001 09:59:36 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing For test 51 to run you need a kernel with the acl code built in, there is a posix_acl config option near the top of filesystems config. Also, for both tests do you have the latest version of the acl and attribute commands installed? These have been broken out into seperate directories under the cmd tree. The latest and complete set of rpm files for the commands is this: attr-1.0.1-0.i386.rpm attr-devel-1.0.1-0.i386.rpm acl-1.0.1-0.i386.rpm acl-devel-1.0.1-0.i386.rpm xfsprogs-1.1.1-0.i386.rpm xfsprogs-devel-1.1.1-0.i386.rpm xfsdump-1.0.1-0.i386.rpm Steve > --lrZ03NoBR/3+SXJZ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > Hi, > > I got a failure on test 020, short version: > > 020 - output mismatch (see 020.out.bad) > 65a66,68 > > 0001520 e5 79 0d 00 03 00 00 00 c0 79 0d 00 00 00 00 00 > > 0001540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > * > > 020.out.bad attached. > > 051 also fails: > > 051 - output mismatch (see 051.out.bad) > 24c24 > < sh: ./file1: Permission denied > --- > > Test was executed > 29c29 > < sh: ./file1: Permission denied > --- > > Test was executed > 35c35 > < sh: ./file1: Permission denied > --- > > Test was executed > 40c40 > < sh: ./file1: Permission denied > --- > > Test was executed > 42c42 > < sh: ./file1: Permission denied > --- > > Test was executed > 44c44 > < sh: ./file1: Permission denied > --- > > Test was executed > 56c56 > < file1 [u::---,g::---,o::---,u:1002:r-x,m::rwx] > --- > > file1 [u::---,g::---,o::---,u:simvis:r-x,m::rwx] > 59c59 > < sh: ./file1: Permission denied > --- > > Test was executed > 65,66c65,66 > < file1 [u::---,g::---,o::---,u:1002:r-x,m::rwx] > < file1 [u::---,g::---,o::---,g:1002:r-x,m::rwx] > --- > > file1 [u::---,g::---,o::---,u:simvis:r-x,m::rwx] > > file1 [u::---,g::---,o::---,g:xxxxxx:r-x,m::rwx] > 72c72 > < sh: ./file1: Permission denied > --- > > Test was executed > 75c75 > < file1 [u::---,g::---,o::---,g:1002:r-x,m::-wx] > --- > > file1 [u::---,g::---,o::---,g:xxxxxx:r-x,m::-wx] > 77c77 > < ./file1: ./file1: Permission denied > --- > > Test was executed > 79c79 > < ./file1: ./file1: Permission denied > --- > > Test was executed > 85c85 > < sh: ./file1: Permission denied > --- > > Test was executed > > "xxxxxxx" is the name of the group with gid 1002 (someone arround here > could get uneasy if I disclose it). I guess chacl needs a "numeric" > flag. > > -- > Marcelo > > --lrZ03NoBR/3+SXJZ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="020.out.bad" > > QA output created by 020 > *** list non-existant file > *** print attributes > attr_list: No such file or directory > Could not list attributes for > !!! error return > *** list non-xfs file (in /proc) > *** print attributes > attr_list: Invalid argument > Could not list attributes for > !!! error return > *** list empty file > *** print attributes > *** 0 attribute(s) > *** query non-existant attribute > attr_get: No data available > Could not get "nonexistant" for > *** one attribute > Attribute "fish" set to a 5 byte value for : > fish > > *** print attributes > *** 1 attribute(s) > *** field: fish length: 5 > ::: fish > ::: > *** replace attribute > Attribute "fish" set to a 6 byte value for : > fish3 > > *** print attributes > *** 1 attribute(s) > *** field: fish length: 6 > ::: fish3 > ::: > *** add attribute > Attribute "snrub" set to a 6 byte value for : > fish2 > > *** print attributes > *** 2 attribute(s) > *** field: fish length: 6 > ::: fish3 > ::: > *** field: snrub length: 6 > ::: fish2 > ::: > *** remove attribute > *** print attributes > *** 1 attribute(s) > *** field: snrub length: 6 > ::: fish2 > ::: > *** add lots of attributes > *** check > *** 1001 attribute(s) > *** remove lots of attributes > *** print attributes > *** 1 attribute(s) > *** field: snrub length: 6 > ::: fish2 > ::: > *** really long value > 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > * > 0001520 e5 79 0d 00 03 00 00 00 c0 79 0d 00 00 00 00 00 > 0001540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > * > 0200000 0a > 0200001 > *** set/get/remove really long names (expect failure) > attr_set: Bad address > Could not set "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXX" for > attr_get: Bad address > Could not get "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXX" for > attr_remove: Bad address > Could not remove "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXX" for > *** check final > *** print attributes > *** 1 attribute(s) > *** field: snrub length: 6 > ::: fish2 > ::: > *** delete > > --lrZ03NoBR/3+SXJZ-- From owner-linux-xfs@oss.sgi.com Mon Feb 5 08:30:54 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 08:30:44 -0800 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:27089 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 08:30:26 -0800 Received: from techno.informatik.uni-stuttgart.de (techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id RAA09801 for ; Mon, 5 Feb 2001 17:28:25 +0100 (MET) Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.11.0/2.2) id f15GUJk21730 for linux-xfs@oss.sgi.com; Mon, 5 Feb 2001 17:30:19 +0100 Date: Mon, 5 Feb 2001 17:30:19 +0100 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: stress test failures Message-ID: <20010205173019.A21651@techno.informatik.uni-stuttgart.de> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200102051559.f15FxaX23217@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i In-Reply-To: <200102051559.f15FxaX23217@jen.americas.sgi.com>; from lord@sgi.com on Mon, Feb 05, 2001 at 09:59:36AM -0600 X-Operating-System: Linux techno 2.4.1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >> Steve Lord writes: > For test 51 to run you need a kernel with the acl code built in CONFIG_FS_POSIX_ACL=y > there is a posix_acl config option near the top of filesystems > config. Also, for both tests do you have the latest version of the > acl and attribute commands installed? --- snip! --- == dist, log is Logs/dist Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/attr/build/tar/attr-1.0.1.tar.gz Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/attr/build/rpm/attr-1.0.1-0.src.rpm Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/attr/build/rpm/attr-1.0.1-0.i386.rpm Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/attr/build/rpm/attr-devel-1.0.1-0.i386.rpm attr-1.0.1-0 attr-devel-1.0.1-0 --- snip! --- --- snip! --- == dist, log is Logs/dist Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/acl/build/tar/acl-1.0.1.tar.gz Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/acl/build/rpm/acl-1.0.1-0.src.rpm Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/acl/build/rpm/acl-1.0.1-0.i386.rpm Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/acl/build/rpm/acl-devel-1.0.1-0.i386.rpm acl-1.0.1-0 acl-devel-1.0.1-0 --- snip! --- I compile xfsprogs and xfsprogs-devel, install both, compile attr, attr-devel, install both, compile acl and acl-devel and install both. The two log file snippets above correspond to the compilation and installation of these two packages. The code is checked out arround 3:00 GMT (this particular case would be arround 2001-02-05 03:00 GMT) > These have been broken out into seperate directories under the cmd > tree. Yeah, I didn't notice before because my compilation/installation script broke because of the reorganization. > xfsdump-1.0.1-0.i386.rpm Also installed. -- Marcelo From owner-linux-xfs@oss.sgi.com Mon Feb 5 08:31:54 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 08:31:44 -0800 Received: from hm32.locaweb.com.br ([200.246.179.102]:7904 "HELO hm32.locaweb.com.br") by oss.sgi.com with SMTP id ; Mon, 5 Feb 2001 08:31:25 -0800 Received: (qmail 13610 invoked by uid 811); 5 Feb 2001 16:31:17 -0000 Date: 5 Feb 2001 16:31:17 -0000 Message-ID: <20010205163117.13609.qmail@hm32.locaweb.com.br> From: =?ISO-8859-1?Q? "Jo=E3o?= Paulo Legat" To: linux-xfs@oss.sgi.com Subject: Can't find some devices like ATAPI ZIP and CD-ROM on /dev after installation References: In-Reply-To: X-IPAddress: 200.207.14.159 X-Sender: jp@404notfound.com.br Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I did a fresh install w/o problems and after booting I noticed that the ATAPI ZIP 100 and the IDE cd-rom were not listed in /dev. What I did: 1- gone to /usr/src/linux-2.4.0/scripts and executed MAKEDEV.devfs 2- lodaded the respective modules for the cd and zip - ide-floppy, ide-cd, cdrom by hand. 3- It worked : ) After that I rebooted and found that the entries for the cd-rom and the zip drive unit disappeared again... Questions: 1- Is there a way to make these entries in /dev permanent ? 2- Does it have something to do with the devfs scheme ? 3- Why the correct modules were not lodaded automatically ? Note: I'm totally new to devfs.... Best regards, JP From owner-linux-xfs@oss.sgi.com Mon Feb 5 08:46:55 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 08:46:45 -0800 Received: from mail11.jump.net ([206.196.91.11]:45475 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 08:46:37 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f15GkPd03210; Mon, 5 Feb 2001 10:46:25 -0600 (CST) Message-ID: <3A7ED8F2.52AA157A@sgi.com> Date: Mon, 05 Feb 2001 10:46:42 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?Jo=E3o?= Paulo Legat CC: linux-xfs@oss.sgi.com Subject: Re: Can't find some devices like ATAPI ZIP and CD-ROM on /dev after installation References: <20010205163117.13609.qmail@hm32.locaweb.com.br> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing IDE CD-Roms will be at /dev/cdroms/cdrom0 (/dev/cdroms/cdrom1, etc...) only _after_ you load the cd-rom module (ide-cd.o) Same goes for the zip (although it may treat it as a normal scsi disk, and not make a /dev/zip entry - I'm not sure) You can support module auto-loading by putting modules.devfs in /etc (see the installer caveats page). I agree, devfs is tricky when you're new to it. I'd suggest doing some reading on devfs configuration. Good luck, -Eric João Paulo Legat wrote: > > Hi, > > I did a fresh install w/o problems and after booting I noticed that the > ATAPI ZIP 100 and the IDE cd-rom were not listed in /dev. > > What I did: > 1- gone to /usr/src/linux-2.4.0/scripts and executed MAKEDEV.devfs > 2- lodaded the respective modules for the cd and zip - ide-floppy, ide-cd, > cdrom by hand. > 3- It worked : ) > > After that I rebooted and found that the entries for the cd-rom and the zip > drive unit disappeared again... > > Questions: > > 1- Is there a way to make these entries in /dev permanent ? > 2- Does it have something to do with the devfs scheme ? > 3- Why the correct modules were not lodaded automatically ? > > Note: I'm totally new to devfs.... > > Best regards, > > JP From owner-linux-xfs@oss.sgi.com Mon Feb 5 11:09:27 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 11:09:07 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:51551 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 11:08:53 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA00499 for ; Mon, 5 Feb 2001 11:08:47 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA712588 for ; Mon, 5 Feb 2001 13:06:15 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA31198 for ; Mon, 5 Feb 2001 13:06:15 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f15J6Dn23533; Mon, 5 Feb 2001 13:06:13 -0600 Message-Id: <200102051906.f15J6Dn23533@jen.americas.sgi.com> Date: Mon, 5 Feb 2001 13:06:13 -0600 Subject: TAKE - fix reference count leaks To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is probably a path you do not hit unless you try really hard. Date: Mon Feb 5 11:06:00 PST 2001 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:84915a linux/fs/xfs/linux/xfs_ioctl.c - 1.27 - Fix a couple of inode leaks in error paths in the open by handle code From owner-linux-xfs@oss.sgi.com Mon Feb 5 11:35:57 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 11:35:48 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:49004 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 11:35:22 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA03286 for ; Mon, 5 Feb 2001 11:35:00 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA713451 for ; Mon, 5 Feb 2001 13:33:39 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA99253 for ; Mon, 5 Feb 2001 13:33:39 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f15JXam23777; Mon, 5 Feb 2001 13:33:36 -0600 Message-Id: <200102051933.f15JXam23777@jen.americas.sgi.com> Date: Mon, 5 Feb 2001 13:33:36 -0600 Subject: TAKE - pagebuf delalloc page cleaning changes To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This changes how we convert delalloc pages into real pages, the page cleaner now scans the inactive_dirty list looking for candidates rather than the page table. The kiobuf and buffer_head paths now behave in similar manners, they both do clustered writes on delalloc conversion. This means that the kiocluster mount option is not really needed, for now it will still be parsed and interpreted as the same as the kio option, clustering is independent of kiobufs now. truncate_inode_pages is reverted to its original argument list, the toss/no toss option is removed. This was a) not implemented correctly, and b) not actually used anymore. Finally, the pagebuf_flush function was cleaned up to do more optimal memory allocations, and less dropping and obtaining of spinlocks. There still remains more performance work to be done on how we trigger the page cleaner. Date: Mon Feb 5 11:29:03 PST 2001 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:84918a linux/mm/memory.c - 1.44 - revert truncate_inode_pages call to its original arguments linux/mm/filemap.c - 1.66 - call toss_page instead of convertpage when a delalloc page is found in the truncate_inode_pages path. Revert truncate_inode_pages to it's original specification. linux/include/linux/mm.h - 1.47 - revert truncate_inode_pages call to its original arguments linux/include/linux/fs.h - 1.78 - remove MS_KIOCLUSTER and IS_KIOCLUSTER, rename the converpage address space method to toss_page linux/fs/inode.c - 1.36 - Remove extra parameter from truncate_inode_pages, go back to the original Linux version. linux/fs/xfs/linux/xfs_lrw.c - 1.75 - revert truncate_inode_pages call to its original arguments linux/fs/xfs/linux/xfs_super.c - 1.108 - revert truncate_inode_pages call to its original arguments. Make the kiocluster mount option the same as the kio option for now, clustering happens all the time now. linux/fs/xfs/linux/xfs_iops.c - 1.93 - Change the convertpage method to a toss_page method. linux/include/linux/page_buf.h - 1.72 - replace pagebuf_convert_page with pagebuf_toss_page linux/fs/pagebuf/page_buf.c - 1.51 - Change to page locking for doing dealloc clustered writes using buffer heads. linux/fs/pagebuf/page_buf_io.c - 1.49 - Make the pagebuf cleaner operate by scanning the inactive dirty list of pages rather than the page table. This makes the page cleaner more deterministic. Change clustering code to operate even if we are not using kiobufs for the I/O path. Change the pagebuf convert function into a pagebuf_toss_page function which removes delalloc state from a page. Cleanup the pagebuf_flush code to be more efficient. From owner-linux-xfs@oss.sgi.com Mon Feb 5 12:51:16 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 12:51:07 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:19220 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 12:50:45 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA04571 for ; Mon, 5 Feb 2001 12:50:37 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA698536 for ; Mon, 5 Feb 2001 14:48:02 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA27365 for ; Mon, 5 Feb 2001 14:48:02 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f15Klw523880; Mon, 5 Feb 2001 14:47:58 -0600 Message-Id: <200102052047.f15Klw523880@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Re: stress test failures In-Reply-To: Message from "Marcelo E. Magallon" of "Mon, 05 Feb 2001 17:30:19 +0100." <20010205173019.A21651@techno.informatik.uni-stuttgart.de> Date: Mon, 05 Feb 2001 14:47:57 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Does this mean you were already running with the latest version of everything when you saw the problem? If so, I have to leave this up to the capable folks in the Melbourne office. Steve > >> Steve Lord writes: > > > For test 51 to run you need a kernel with the acl code built in > > CONFIG_FS_POSIX_ACL=y > > > there is a posix_acl config option near the top of filesystems > > config. Also, for both tests do you have the latest version of the > > acl and attribute commands installed? > > --- snip! --- > == dist, log is Logs/dist > Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/attr/build/tar/attr-1.0.1.t > ar.gz > Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/attr/build/rpm/attr-1.0.1-0 > .src.rpm > Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/attr/build/rpm/attr-1.0.1-0 > .i386.rpm > Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/attr/build/rpm/attr-devel-1 > .0.1-0.i386.rpm > attr-1.0.1-0 > attr-devel-1.0.1-0 > --- snip! --- > > --- snip! --- > == dist, log is Logs/dist > Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/acl/build/tar/acl-1.0.1.tar > .gz > Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/acl/build/rpm/acl-1.0.1-0.s > rc.rpm > Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/acl/build/rpm/acl-1.0.1-0.i > 386.rpm > Wrote: /v/techno/fs1/proj/marcelo/xfs/user-space/acl/build/rpm/acl-devel-1.0 > .1-0.i386.rpm > acl-1.0.1-0 > acl-devel-1.0.1-0 > --- snip! --- > > I compile xfsprogs and xfsprogs-devel, install both, compile attr, > attr-devel, install both, compile acl and acl-devel and install both. > The two log file snippets above correspond to the compilation and > installation of these two packages. The code is checked out arround > 3:00 GMT (this particular case would be arround 2001-02-05 03:00 GMT) > > > These have been broken out into seperate directories under the cmd > > tree. > > Yeah, I didn't notice before because my compilation/installation script > broke because of the reorganization. > > > xfsdump-1.0.1-0.i386.rpm > > Also installed. > > -- > Marcelo From owner-linux-xfs@oss.sgi.com Mon Feb 5 13:44:17 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 13:44:07 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:44841 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 13:43:56 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA07186 for ; Mon, 5 Feb 2001 13:43:53 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA714558 for ; Mon, 5 Feb 2001 15:41:21 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA99841 for ; Mon, 5 Feb 2001 15:41:21 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f15LfH810086; Mon, 5 Feb 2001 15:41:17 -0600 Message-Id: <200102052141.f15LfH810086@jen.americas.sgi.com> Date: Mon, 5 Feb 2001 15:41:17 -0600 Subject: TAKE - fix mount output message To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing We said the same thing twice after my last checkin: XFS (dev: 8/5) mounting with KIOBUFIO (kiobuf I/O) clean this up. Date: Mon Feb 5 13:40:16 PST 2001 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:84954a linux/fs/xfs/linux/xfs_super.c - 1.109 - Fix up mount message for kiobuf based I/O, it was a bit verbose. From owner-linux-xfs@oss.sgi.com Mon Feb 5 14:15:47 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 14:15:37 -0800 Received: from plato.arts.usyd.edu.au ([129.78.16.1]:23566 "EHLO plato.arts.usyd.edu.au") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 14:15:16 -0800 Received: from arts.usyd.edu.au (IDENT:matthew@whitestar.arts.usyd.edu.au [129.78.16.20]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id JAA15959; Tue, 6 Feb 2001 09:14:32 +1100 (EST) Message-ID: <3A7F26D1.B3A8D1A0@arts.usyd.edu.au> Date: Tue, 06 Feb 2001 09:18:57 +1100 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Eric Sandeen CC: =?iso-8859-1?Q?Jo=E3o?= Paulo Legat , linux-xfs@oss.sgi.com Subject: Re: Can't find some devices like ATAPI ZIP and CD-ROM on /dev after installation References: <20010205163117.13609.qmail@hm32.locaweb.com.br> <3A7ED8F2.52AA157A@sgi.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEA06C3EFCC8B9C7A89DB12F8" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a cryptographically signed message in MIME format. --------------msEA06C3EFCC8B9C7A89DB12F8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric Sandeen wrote: > > IDE CD-Roms will be at /dev/cdroms/cdrom0 (/dev/cdroms/cdrom1, etc...) > only _after_ you load the cd-rom module (ide-cd.o) > > Same goes for the zip (although it may treat it as a normal scsi disk, > and not make a /dev/zip entry - I'm not sure) > > You can support module auto-loading by putting modules.devfs in /etc > (see the installer caveats page). > > I agree, devfs is tricky when you're new to it. I'd suggest doing some > reading on devfs configuration. > devfs and the PCMCIA utilities appear to dislike one another as well. I was getting a hard machine lockup when I inserted a CF card on my Dell laptop (2.4.1-XFS). Tried all sorts of things and then disabled DevFS (now that device nodes work I could do that!:-) and the Card Services now works and I can read my CF cards with out instant death. -- Matthew Geier matthew@arts.usyd.edu.au Arts IT Unit +61 2 9351 4713 Sydney University --------------msEA06C3EFCC8B9C7A89DB12F8 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH4AYJKoZIhvcNAQcCoIIH0TCCB80CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BckwggKtMIICFqADAgECAgMC8UswDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyMTAyNDAzNFoXDTAxMDcyMTAyNDAz NFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYY bWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR gAKbBhCplgqyhkR0Ykn4XOW0Py1G40orbP+B2KkACTMx4GxhHNg2h3nPiNC/P/9BZETw6NA+ dp/mxtN7XHmvRounnCL+9pjG3yWpw/ONNEpObjRSfujGe/jJvUF2vrAfecI/J5DKQ0/5gZMv 5fqfl4spYSPl+9vc2hKG7uvjgQIDAQABo1YwVDAjBgNVHREEHDAagRhtYXR0aGV3QGFydHMu dXN5ZC5lZHUuYXUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORYx0YdwGG9 I9fDjDANBgkqhkiG9w0BAQQFAAOBgQBjjvY9P9hSktFnCJrkQSTKjh9ZBG9a58a0Hi+GvmyD t9e29sRgxHN+Nwtsu2yUs8+xv1BemYzCnri+y91uJsfRTrm4+1oc/TV+lDGWqBud68wf4x29 /xaj1oQ2vWMy1Y64KZSWyxjt+vcU5/nyNF3DGz9XtXlxTI8dntzEWkyq/DCCAxQwggJ9oAMC AQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxs ZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn /XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESw iy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL3Vx1b8aR kMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6syg1vcnpn LGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAd8wggHbAgEBMIGcMIGUMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UE ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAvFLMAkGBSsOAwIaBQCggZkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMjA1MjIxODU4WjAjBgkq hkiG9w0BCQQxFgQUkfmIEKN9YO40lcuHxlUEjhLKg74wOgYJKoZIhvcNAQkPMS0wKzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwDQYJKoZIhvcNAQEBBQAE gYB1mYE8P2s75ZhdkDel7j5D3eV7z0sXisJLQ3YgEsMtuSZbYx6hCw7erKDr3eLPMZnejsh+ 0ocAgd/LXtiA1jEO0kj+6S2ciDvduq7urBzpUJ9iKd4hTbseMro2jIk9I3OJMui3yP3CU14i k/jCRJ5/+7N8rqL+Z11jQhoXEH1pWA== --------------msEA06C3EFCC8B9C7A89DB12F8-- From owner-linux-xfs@oss.sgi.com Mon Feb 5 15:30:37 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 15:30:28 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:60758 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 15:30:11 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA02240 for ; Mon, 5 Feb 2001 15:30:10 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA73756 for ; Mon, 5 Feb 2001 17:27:39 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f15NQde11261 for ; Mon, 5 Feb 2001 17:26:39 -0600 Message-ID: <3A7F36AE.61A68006@thebarn.com> Date: Mon, 05 Feb 2001 17:26:38 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: RPM build "stuff" in the CVS tree Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Quite a few people commented on the large download size the XFS cvs tree. Much of this has to do with the inclusion of the SOURCES directory, which is only relevant to rpm builds. Since rpm builds have very little to do with with development it is probably best this directory be dropped. This will significantly reduce the patch size and reduce cvs update times. If anybody actually wants this stuff let me know and I will export it via a different mechanism, otherwise expect these following directories to be dropped from the cvs trees. SCRIPTS/ SOURCES/ SPECS/ and the top level Makefile. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Feb 5 17:32:48 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 17:32:29 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:63085 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 17:32:06 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA02986 for ; Mon, 5 Feb 2001 17:31:03 -0800 (PST) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA19711 for linux-xfs@oss.sgi.com; Tue, 6 Feb 2001 12:30:44 +1100 (EST) Date: Tue, 6 Feb 2001 12:30:44 +1100 (EST) From: Daniel Moore Message-Id: <200102060130.MAA19711@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix pagebuf as module Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Feb 5 17:30:21 PST 2001 Workarea: snort.melbourne.sgi.com:/home/dxm/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:84982a linux/kernel/ksyms.c - 1.73 - add symbols required to use pagebuf as module From owner-linux-xfs@oss.sgi.com Mon Feb 5 17:56:18 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 17:55:59 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:51058 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 17:55:31 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA05429 for ; Mon, 5 Feb 2001 17:54:30 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id RAA07392; Mon, 5 Feb 2001 17:54:11 -0800 (PST) Date: Mon, 5 Feb 2001 17:54:58 -0800 (PST) From: Tom Duffy To: Matthew Geier cc: Subject: Re: Can't find some devices like ATAPI ZIP and CD-ROM on /dev aft er installation In-Reply-To: <3A7F26D1.B3A8D1A0@arts.usyd.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > devfs and the PCMCIA utilities appear to dislike one another as well. I > was getting a hard machine lockup when I inserted a CF card on my Dell > laptop (2.4.1-XFS). Tried all sorts of things and then disabled DevFS > (now that device nodes work I could do that!:-) and the Card Services > now works and I can read my CF cards with out instant death. I am seeing a similar problem: when I insert and remove pcmcia cards on my dell laptop, the machine locks up hard (can't even get into kdb). I just tried rebooting the kernel with devfs=nomount option to disable devfs on bootup and I am *still* having the problem with pcmcia. (i am using 2.4.0+xfs -- would love to upgrade to 2.4.1 but can't access network becasue of lack of pcmcia support :( ). so unless having devfs compiled into the kernel (but no used) kills pcmcia (doubtful), it should not be devfs. -tduffy From owner-linux-xfs@oss.sgi.com Mon Feb 5 18:02:29 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 18:02:19 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49690 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 18:02:09 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA02693 for ; Mon, 5 Feb 2001 18:11:20 -0800 (PST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA32442; Tue, 6 Feb 2001 13:00:42 +1100 (EDT) From: Timothy Shimmin Message-Id: <200102060200.NAA32442@boing.melbourne.sgi.com> Subject: Re: stress test failures To: marcelo.magallon@bigfoot.com (Marcelo E. Magallon) Date: Tue, 6 Feb 2001 13:00:42 +1100 (EDT) Cc: linux-xfs@oss.sgi.com In-Reply-To: <20010205104330.A1108@ysabell.wh.vaih> from "Marcelo E. Magallon" at Feb 05, 2001 10:43:30 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi Marcelo, You wrote: > I got a failure on test 020, short version: > > 020 - output mismatch (see 020.out.bad) > 65a66,68 > > 0001520 e5 79 0d 00 03 00 00 00 c0 79 0d 00 00 00 00 00 > > 0001540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > * > Looking at 020, the test is testing setting a long value for the extended attribute. It does this by trying to set a value of 100K worth of zeroes. The attr(1) code truncates this to ATTR_MAX_VALUELEN (64K). (I will have to update the man page for this - it says 256K). So it is quite concerning that when we extract back the 64K value we get some non-zero values. I will have to look at the code and see where we can trace what is going wrong. > 051 also fails: > > 051 - output mismatch (see 051.out.bad) > 24c24 > < sh: ./file1: Permission denied > --- > > Test was executed ... It seems that ALL the tests which verified that access would be denied did not happen - access was granted in each case. Even the first permissions test case failed which actually had the DAC with no access permissions other than for the owner. I use a small program, xfstests/src/runas, to set up the effective uid, e-gid, and supplementary groups for a process. Could you do the following as root to verify it is working: [root@sagan src]# runas -u 10001 -g 10002 -s 10003 -s 10004 id uid=0(root) gid=0(root) euid=10001 egid=10002 groups=10003,10004 > > Test was executed > 56c56 > < file1 [u::---,g::---,o::---,u:1002:r-x,m::rwx] > --- > > file1 [u::---,g::---,o::---,u:simvis:r-x,m::rwx] > 65,66c65,66 > < file1 [u::---,g::---,o::---,u:1002:r-x,m::rwx] > < file1 [u::---,g::---,o::---,g:1002:r-x,m::rwx] > --- > > file1 [u::---,g::---,o::---,u:simvis:r-x,m::rwx] > > file1 [u::---,g::---,o::---,g:xxxxxx:r-x,m::rwx] > > "xxxxxxx" is the name of the group with gid 1002 (someone arround here > could get uneasy if I disclose it). I guess chacl needs a "numeric" > flag. Ok, this is a problem with the qa test - oops. I can't really change the text output of the acl cmd because it uses acl_to_short_text() which is an acl posix function. I will fix up the qa test to do some filtering/mapping. BTW, test 051, will not run (and will output a msg to that effect) if the chacl(1) command isn't there or if the ACL syscall is not turned on in the kernel. Thanks, Tim. From owner-linux-xfs@oss.sgi.com Mon Feb 5 18:59:09 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 18:58:49 -0800 Received: from plato.arts.usyd.edu.au ([129.78.16.1]:20998 "EHLO plato.arts.usyd.edu.au") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 18:58:20 -0800 Received: from arts.usyd.edu.au (IDENT:matthew@whitestar.arts.usyd.edu.au [129.78.16.20]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id NAA19691; Tue, 6 Feb 2001 13:58:11 +1100 (EST) Message-ID: <3A7F694C.CCC00516@arts.usyd.edu.au> Date: Tue, 06 Feb 2001 14:02:36 +1100 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Tom Duffy CC: linux-xfs@oss.sgi.com Subject: Re: Can't find some devices like ATAPI ZIP and CD-ROM on /dev after installation References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD2ABE3E4FE903384A93F3132" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a cryptographically signed message in MIME format. --------------msD2ABE3E4FE903384A93F3132 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom Duffy wrote: > > > devfs and the PCMCIA utilities appear to dislike one another as well. I > > was getting a hard machine lockup when I inserted a CF card on my Dell > > laptop (2.4.1-XFS). Tried all sorts of things and then disabled DevFS > > (now that device nodes work I could do that!:-) and the Card Services > > now works and I can read my CF cards with out instant death. > > I am seeing a similar problem: when I insert and remove pcmcia cards on my > dell laptop, the machine locks up hard (can't even get into kdb). I just > tried rebooting the kernel with devfs=nomount option to disable devfs on > bootup and I am *still* having the problem with pcmcia. (i am using > 2.4.0+xfs -- would love to upgrade to 2.4.1 but can't access network > becasue of lack of pcmcia support :( ). I just put the devfs nomount flag in the lilo append options. Didn't recompile the kernel. I did however earlier download and compile the latest pcmcia utils, but still had lockups. I have not tried the orginal RH7 utils without devfs. -- Matthew Geier matthew@arts.usyd.edu.au Arts IT Unit +61 2 9351 4713 Sydney University --------------msD2ABE3E4FE903384A93F3132 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH4AYJKoZIhvcNAQcCoIIH0TCCB80CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BckwggKtMIICFqADAgECAgMC8UswDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyMTAyNDAzNFoXDTAxMDcyMTAyNDAz NFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYY bWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR gAKbBhCplgqyhkR0Ykn4XOW0Py1G40orbP+B2KkACTMx4GxhHNg2h3nPiNC/P/9BZETw6NA+ dp/mxtN7XHmvRounnCL+9pjG3yWpw/ONNEpObjRSfujGe/jJvUF2vrAfecI/J5DKQ0/5gZMv 5fqfl4spYSPl+9vc2hKG7uvjgQIDAQABo1YwVDAjBgNVHREEHDAagRhtYXR0aGV3QGFydHMu dXN5ZC5lZHUuYXUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORYx0YdwGG9 I9fDjDANBgkqhkiG9w0BAQQFAAOBgQBjjvY9P9hSktFnCJrkQSTKjh9ZBG9a58a0Hi+GvmyD t9e29sRgxHN+Nwtsu2yUs8+xv1BemYzCnri+y91uJsfRTrm4+1oc/TV+lDGWqBud68wf4x29 /xaj1oQ2vWMy1Y64KZSWyxjt+vcU5/nyNF3DGz9XtXlxTI8dntzEWkyq/DCCAxQwggJ9oAMC AQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxs ZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn /XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESw iy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL3Vx1b8aR kMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6syg1vcnpn LGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAd8wggHbAgEBMIGcMIGUMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UE ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAvFLMAkGBSsOAwIaBQCggZkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMjA2MDMwMjM3WjAjBgkq hkiG9w0BCQQxFgQU9JZUDDzW0g+FjGOQ0JCx8wwl9c8wOgYJKoZIhvcNAQkPMS0wKzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwDQYJKoZIhvcNAQEBBQAE gYC70sx9OjT3Ay9dD/6jQAZd+eE+dsUL+h/ord83ICpsN78x0YbN7+r7Ia4JdhQ4iRaLbfj6 ///H0uvHnzULYKeMYT5nlAXT7atmOSkc2kTxuV2o5HiRy2gQw0Cmdp4g0XodxUmr0cGFurod zLjZDbXgBAFKhP0jrOgkUcWw7IjZNA== --------------msD2ABE3E4FE903384A93F3132-- From owner-linux-xfs@oss.sgi.com Mon Feb 5 21:44:30 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 21:44:12 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:55653 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 21:43:45 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA09330 for ; Mon, 5 Feb 2001 21:43:42 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA16819 for linux-xfs@oss.sgi.com; Tue, 6 Feb 2001 16:42:24 +1100 (EST) Date: Tue, 6 Feb 2001 16:42:24 +1100 (EST) From: Timothy Shimmin Message-Id: <200102060542.QAA16819@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfstests/051 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing See if this helps a bit, Marcelo. Date: Mon Feb 5 21:41:13 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:84995a cmd/xfstests/051.out - 1.2 cmd/xfstests/051 - 1.3 - Choose new uid/gid and filter them appropriately. From owner-linux-xfs@oss.sgi.com Mon Feb 5 23:32:20 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 23:32:01 -0800 Received: from edge.coltex.nl ([194.151.97.115]:27398 "EHLO mail.coltex.nl") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 23:31:37 -0800 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f167VOL20659; Tue, 6 Feb 2001 08:31:25 +0100 Message-Id: <4.3.2.7.2.20010206082545.03727ce8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Feb 2001 08:29:07 +0100 To: Russell Cattelan , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: RPM build "stuff" in the CVS tree In-Reply-To: <3A7F36AE.61A68006@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 17:26 5-2-2001 -0600, Russell Cattelan wrote: >Quite a few people commented on the large download size the XFS > >cvs tree. > >Much of this has to do with the inclusion of the SOURCES directory, > >which is only relevant to rpm builds. > >Since rpm builds have very little to do with with development > >it is probably best this directory be dropped. > >This will significantly reduce the patch size and reduce cvs > >update times. > >If anybody actually wants this stuff let me know and >I will export it via a different mechanism, otherwise rsync anyone? it supports incremental transfer, multiple login procedures and compression. It's free and available on most samba mirrors. It also works great for updating websites (a large website I may note) If only a time stamp changes, it would not result in downloading the entire file. >expect these following directories to be dropped from > >the cvs trees. > >SCRIPTS/ > >SOURCES/ > >SPECS/ > >and the top level Makefile. Bye -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Tue Feb 6 05:00:03 2001 Received: by oss.sgi.com id ; Tue, 6 Feb 2001 04:59:54 -0800 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:47766 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Tue, 6 Feb 2001 04:59:36 -0800 Received: from techno.informatik.uni-stuttgart.de (techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id NAA06817; Tue, 6 Feb 2001 13:57:38 +0100 (MET) Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.11.0/2.2) id f16CxWW28305; Tue, 6 Feb 2001 13:59:32 +0100 Date: Tue, 6 Feb 2001 13:59:32 +0100 From: "Marcelo E. Magallon" To: Timothy Shimmin Cc: linux-xfs@oss.sgi.com Subject: Re: stress test failures Message-ID: <20010206135932.A27553@techno.informatik.uni-stuttgart.de> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010205104330.A1108@ysabell.wh.vaih> <200102060200.NAA32442@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.1.14i In-Reply-To: <200102060200.NAA32442@boing.melbourne.sgi.com>; from tes@boing.melbourne.sgi.com on Tue, Feb 06, 2001 at 01:00:42PM +1100 X-Operating-System: Linux techno 2.4.1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline >> Timothy Shimmin writes: > I use a small program, xfstests/src/runas, to set up the > effective uid, e-gid, and supplementary groups for a process. > Could you do the following as root to verify it is working: > [root@sagan src]# runas -u 10001 -g 10002 -s 10003 -s 10004 id > uid=0(root) gid=0(root) euid=10001 egid=10002 groups=10003,10004 I'm not getting that. The problem is runas uses system. It eventually executes /bin/sh, which is a symlink to bash, which in turn will reset privileges on start up (a patched bash might not do this if called as "sh", but the one installed here does). The attached runas.c solves this: # ./runas -u 10001 -g 10002 -s 10003 -s 10004 /usr/bin/id uid=0(root) gid=0(root) euid=10001 egid=10002 groups=10003,10004 (I'm using execv, replace with execvp if you want things to be searched in the PATH) -- Marcelo --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="runas.c" /* * Copyright (c) 2000 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as * published by the Free Software Foundation. * * This program is distributed in the hope that it would be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * * Further, this software is distributed without any warranty that it is * free of the rightful claim of any third person regarding infringement * or the like. Any license provided herein, whether implied or * otherwise, applies only to this software file. Patent licenses, if * any, provided herein do not apply to combinations of this program with * other software, or any other product whatsoever. * * You should have received a copy of the GNU General Public License along * with this program; if not, write the Free Software Foundation, Inc., 59 * Temple Place - Suite 330, Boston MA 02111-1307, USA. * * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, * Mountain View, CA 94043, or: * * http://www.sgi.com * * For further information regarding this notice, see: * * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ */ /* * Run a command with a particular * - effective user id * - effective group id * - supplementary group list */ #include "global.h" #include char *prog; void usage(void) { fprintf(stderr, "usage: %s [-u uid] [-g gid] [-s gid] cmd\n" "flags:\n" " -u - effective user-id\n" " -g - effective group-id\n" " -s - supplementary group-id\n", prog); } #define SUP_MAX 20 int main(int argc, char **argv) { int c; uid_t uid = -1; gid_t gid = -1; int pid; char **cmd; gid_t sgids[SUP_MAX]; int sup_cnt = 0; int status; prog = basename(argv[0]); while ((c = getopt(argc, argv, "u:g:s:")) != -1) { switch (c) { case 'u': uid = atoi(optarg); break; case 'g': gid = atoi(optarg); break; case 's': if (sup_cnt+1 > SUP_MAX) { fprintf(stderr, "%s: too many sup groups\n", prog); exit(1); } sgids[sup_cnt++] = atoi(optarg); break; case '?': usage(); exit(1); } } /* build up the cmd */ if (optind == argc) { usage(); exit(1); } else { char **p; p = cmd = (char **)malloc(sizeof(char *) * (argc - optind + 1)); for ( ; optind < argc; optind++, p++) { *p = strdup(argv[optind]); } *p = NULL; } if (gid != -1) { if (setegid(gid) == -1) { fprintf(stderr, "%s: setegid(%d) failed: %s\n", prog, gid, strerror(errno)); exit(1); } } if (sup_cnt > 0) { if (setgroups(sup_cnt, sgids) == -1) { fprintf(stderr, "%s: setgroups() failed: %s\n", prog, strerror(errno)); exit(1); } } if (uid != -1) { if (seteuid(uid) == -1) { fprintf(stderr, "%s: seteuid(%d) failed: %s\n", prog, uid, strerror(errno)); exit(1); } } pid = fork(); if (pid == -1) { fprintf(stderr, "%s: fork failed: %s\n", prog, strerror(errno)); exit(1); } if (pid == 0) { execv(cmd[0], cmd); exit(127); } wait(&status); if (WIFSIGNALED(status)) { fprintf(stderr, "%s: command terminated with signal %d\n", prog, WTERMSIG(status)); exit(1); } else if (WIFEXITED(status)) { exit(WEXITSTATUS(status)); } else { fprintf(stderr, "%s: command bizarre wait status 0x%x\n", prog, status); exit(1); } exit(0); /* NOTREACHED */ } --HlL+5n6rz5pIUxbD-- From owner-linux-xfs@oss.sgi.com Tue Feb 6 05:26:54 2001 Received: by oss.sgi.com id ; Tue, 6 Feb 2001 05:26:34 -0800 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:16283 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Tue, 6 Feb 2001 05:26:13 -0800 Received: from techno.informatik.uni-stuttgart.de (techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id OAA07514; Tue, 6 Feb 2001 14:24:16 +0100 (MET) Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.11.0/2.2) id f16DQAc28581; Tue, 6 Feb 2001 14:26:10 +0100 Date: Tue, 6 Feb 2001 14:26:10 +0100 From: "Marcelo E. Magallon" To: Timothy Shimmin Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - xfstests/051 Message-ID: <20010206142610.B27553@techno.informatik.uni-stuttgart.de> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200102060542.QAA16819@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i In-Reply-To: <200102060542.QAA16819@snort.melbourne.sgi.com>; from tes@snort.melbourne.sgi.com on Tue, Feb 06, 2001 at 04:42:24PM +1100 X-Operating-System: Linux techno 2.4.1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >> Timothy Shimmin writes: > See if this helps a bit, Marcelo. Only a small typo: Index: 051 =================================================================== RCS file: /cvs/linux-2.4-xfs/cmd/xfstests/051,v retrieving revision 1.3 diff -u -r1.3 051 --- 051 2001/02/06 05:41:13 1.3 +++ 051 2001/02/06 13:22:05 @@ -95,7 +95,7 @@ -e "s/g:$acl3/g:id3/" \ -e "s/ $acl1 / id1 /" \ -e "s/ $acl2 / id2 /" \ - -e "s/ $acl3 / id3 /" \ + -e "s/ $acl3 / id3 /" } # ----- bash (aka, /bin/sh here) doesn't seem to like \ before } -- Marcelo From owner-linux-xfs@oss.sgi.com Tue Feb 6 07:20:17 2001 Received: by oss.sgi.com id ; Tue, 6 Feb 2001 07:20:07 -0800 Received: from mta09-acc.tin.it ([212.216.176.40]:152 "EHLO fep09-svc.tin.it") by oss.sgi.com with ESMTP id ; Tue, 6 Feb 2001 07:19:44 -0800 Received: from tin.it ([212.171.40.17]) by fep09-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with ESMTP id <20010206151936.SABH27359.fep09-svc.tin.it@tin.it> for ; Tue, 6 Feb 2001 16:19:36 +0100 Message-ID: <3A801837.6B5F466A@tin.it> Date: Tue, 06 Feb 2001 16:28:55 +0100 From: Giuseppe Zompatori X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-SGI_XFS.0 i586) X-Accept-Language: it, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: offtopic question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, Well, I know this is somehow offtopic but I couldn't resist... What do you guys at SGI think about the 5Dwm(http://www.5Dwm.org) project? also check out an interview with the authour at: http://www.linuxworld.com/linuxworld/lw-2001-01/lw-01-indigo.html This is a hot question from the interview: "LinuxWorld.com: As we conduct this interview, SGI shares are trading at around $3, and the future of the company seems uncertain. What do you see as the future of SGI?" "Erik Masson: Well, that's a tough call. But I would say that SGI should focus more on Linux as the next great Irix platform rather than just providing a patch-level CD for Linux. No doubt that SGI is and has been a great contributor to Linux, but now it's time to do more ... for its customers. I can easily see SGI offering its own implementation of Linux as the choice for professional users. People wouldn't mind paying a little more than they do for Red Hat and turning a midrange PC into a killer workstation powered by SGI's leading-edge technology. There is a market for that, and a huge one." I agree with him and I might be on of those people. cheers, gz From owner-linux-xfs@oss.sgi.com Tue Feb 6 21:18:02 2001 Received: by oss.sgi.com id ; Tue, 6 Feb 2001 21:17:52 -0800 Received: from aurora.bus.olemiss.edu ([130.74.189.31]:50308 "EHLO aurora.bus.olemiss.edu") by oss.sgi.com with ESMTP id ; Tue, 6 Feb 2001 21:17:33 -0800 Received: from localhost (smounico@localhost) by aurora.bus.olemiss.edu (8.11.0/8.11.0) with ESMTP id f175lCJ14274 for ; Tue, 6 Feb 2001 23:47:12 -0600 Date: Tue, 6 Feb 2001 23:47:11 -0600 (CST) From: smounico@olemiss.edu X-Sender: smounico@aurora.bus.olemiss.edu To: linux-xfs@oss.sgi.com Subject: xfs growth? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I apologize for the newbie question but I've parsed the mailing list and I can't seem to find an answer. If xfs continuously grows (more space taken per file) due to the journaling, and there is no xfs_shrink ( I saw the posts on the list), will my filesystem continue to fill so much so that eventually, I will run out of space? Is the only way around this to perform an xfs_dump and restore? Thanks Sonny From owner-linux-xfs@oss.sgi.com Tue Feb 6 21:28:33 2001 Received: by oss.sgi.com id ; Tue, 6 Feb 2001 21:28:13 -0800 Received: from perilith.com ([207.198.250.232]:11014 "HELO easywayout.perilith.com") by oss.sgi.com with SMTP id ; Tue, 6 Feb 2001 21:27:49 -0800 Received: by easywayout.perilith.com (Postfix, from userid 1034) id 42D213E018; Wed, 7 Feb 2001 00:27:47 -0500 (EST) Date: Tue, 6 Feb 2001 21:27:47 -0800 From: Drew Bloechl To: linux-xfs@oss.sgi.com Subject: Re: xfs growth? Message-ID: <20010206212746.C24260@perilith.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from smounico@olemiss.edu on Tue, Feb 06, 2001 at 11:47:11PM -0600 X-PGP-Fingerprint: B8B4 8A05 A58B 5252 FFC5 E455 D831 31A3 3385 5516 X-PGP-Public-Key: http://cesspool.net/drew.pubkey.txt Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Feb 06, 2001 at 11:47:11PM -0600, smounico@olemiss.edu wrote: > I apologize for the newbie question but I've parsed the mailing list and I > can't seem to find an answer. If xfs continuously grows (more space > taken per file) due to the journaling, and there is no xfs_shrink ( I saw > the posts on the list), will my filesystem continue to fill so much so > that eventually, I will run out of space? Is the only way around this to > perform an xfs_dump and restore? What gave you the idea the filesystem continuously grows? The journal gets reused and it will never take more space than you've allocated for it. -- Drew Bloechl drew@cesspool.net PGP key ID: 33855516 From owner-linux-xfs@oss.sgi.com Tue Feb 6 21:36:43 2001 Received: by oss.sgi.com id ; Tue, 6 Feb 2001 21:36:33 -0800 Received: from drone1-svc-skyt.qsi.net.nz ([202.89.128.1]:37137 "HELO drone1.qsi.net.nz") by oss.sgi.com with SMTP id ; Tue, 6 Feb 2001 21:36:19 -0800 Received: (qmail 39914 invoked by uid 0); 7 Feb 2001 05:36:16 -0000 Received: from unknown (HELO adam) ([202.89.144.53]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 7 Feb 2001 05:36:16 -0000 From: "Adam Warner" To: Subject: RE: xfs growth? Date: Wed, 7 Feb 2001 18:36:44 +1200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi Sonny, A small portion of the hard disk is used for the journal. In the event of a crash the journal can be accessed to undo partial changes and put the partition back to a clean state. All these technologies are designed for data security and so that you no longer have to worry about file system maintenance. Space reserved for the journal would not keep growing until you ran out of space. If you are a newbie to Linux my advice would be to stay as close to a standard install as possible and start using journaling when it becomes supported by your favourite distribution. Regards, Adam -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On Behalf Of smounico@olemiss.edu Sent: Wednesday, 7 February 2001 5:47 p.m. To: linux-xfs@oss.sgi.com Subject: xfs growth? I apologize for the newbie question but I've parsed the mailing list and I can't seem to find an answer. If xfs continuously grows (more space taken per file) due to the journaling, and there is no xfs_shrink ( I saw the posts on the list), will my filesystem continue to fill so much so that eventually, I will run out of space? Is the only way around this to perform an xfs_dump and restore? Thanks Sonny From owner-linux-xfs@oss.sgi.com Tue Feb 6 21:42:02 2001 Received: by oss.sgi.com id ; Tue, 6 Feb 2001 21:41:44 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:58629 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 6 Feb 2001 21:41:38 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id VAA00366 for ; Tue, 6 Feb 2001 21:41:31 -0800 (PST) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA00379; Wed, 7 Feb 2001 16:40:14 +1100 Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA83465; Wed, 7 Feb 2001 16:40:12 +1100 (EST) Message-Id: <200102070540.QAA83465@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Drew Bloechl cc: linux-xfs@oss.sgi.com Subject: Re: xfs growth? In-reply-to: Your message of "Tue, 06 Feb 2001 21:27:47 -0800." <20010206212746.C24260@perilith.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Feb 2001 16:40:12 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Drew Bloechl writes: => On Tue, Feb 06, 2001 at 11:47:11PM -0600, smounico@olemiss.edu wrote: => > I apologize for the newbie question but I've parsed the mailing list and => I => > can't seem to find an answer. If xfs continuously grows (more space => > taken per file) due to the journaling, and there is no xfs_shrink ( I saw => > the posts on the list), will my filesystem continue to fill so much so => > that eventually, I will run out of space? Is the only way around this to => > perform an xfs_dump and restore? => => What gave you the idea the filesystem continuously grows? The journal => gets reused and it will never take more space than you've allocated for => it. There was a discussion on this list last week regarding xfs_growfs. What xfs_growfs does is grow a filesystem ie if you created a 1Gb XFS filesystem on a 2Gb disk and then wanted to use up the remaining 1Gb, you could use xfs_growfs to grow the existing filesystem out to fill the available space. There is no xfs_shrinkfs, because making a filesystem smaller (non-destructively) is much harder. I think that discussion must have been what confused Sonny - we were talking about changing the size of the filesystem, not anything relating to the log. The log is allocated when you generate the filesystem, and is used for journalling all meta-data changes. As Drew points out, it doesn't change size, instead it is continually reused. Hope that clears it up a little... ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Feb 7 00:42:13 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 00:42:04 -0800 Received: from hermes.mixx.net ([212.84.196.2]:20236 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 7 Feb 2001 00:41:50 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 9578DF80D for ; Wed, 7 Feb 2001 09:41:47 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 013C92CA6F; Wed, 7 Feb 2001 09:41:46 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: new XFS on ppc tarball Date: 7 Feb 2001 08:41:46 GMT Organization: innominate AG, Berlin, Germany Lines: 20 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 981535306 28975 10.0.0.31 (7 Feb 2001 08:41:46 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing if anybody is interested - i have just put together a new tarball to use XFS on ppc machines at http://innominate.org/~graichen/projects/xfs/ppc/ i hope the supplied README.xfs-ppc gives enough instructions on how to use it (otherwise send me a mail) ... also keep in mind that to my experience it works stable on ppc but i won't guaratee for your data :-) ... also this tarball only had minimal testing last night (but it should work fine) good luck t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Wed Feb 7 02:00:33 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 02:00:13 -0800 Received: from studsv07.studserv.uni-stuttgart.de ([129.69.21.37]:7174 "EHLO studsv07.studserv.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Wed, 7 Feb 2001 02:00:05 -0800 Received: from ysabell [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP (SMTPD32-6.05) id ACA312110118; Wed, 07 Feb 2001 11:00:03 +0100 Received: from marcelo by ysabell with local (Exim 3.22 #1 (Debian)) id 14QROF-0000Ju-00 for ; Wed, 07 Feb 2001 10:59:55 +0100 Date: Wed, 7 Feb 2001 10:59:55 +0100 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: stress test failures Message-ID: <20010207105955.A1094@ysabell.wh.vaih> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20010205104330.A1108@ysabell.wh.vaih> <200102060200.NAA32442@boing.melbourne.sgi.com> <20010206135932.A27553@techno.informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20010206135932.A27553@techno.informatik.uni-stuttgart.de>; from marcelo.magallon@bigfoot.com on Tue, Feb 06, 2001 at 01:59:32PM +0100 X-Operating-System: Linux ysabell 2.4.1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline >> "Marcelo E. Magallon" writes: > "sh", but the one installed here does). The attached runas.c solves > this: Just a follow up. With these version of runas 051 succeeds, more or less. Using system(3) you are calling the shell which outputs something along the lines of: sh: ./file1: Permission denied I didn't realize that. This would fix it: if (pid == 0) { execvp(cmd[0], cmd); fprintf(stderr, "%s: %s\n", cmd[0], strerror(errno)); exit(127); } Attached is a patch against current CVS. 051.out needs to be regenerated for this to work. -- Marcelo --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="runas.c.diff" Index: runas.c =================================================================== RCS file: /cvs/linux-2.4-xfs/cmd/xfstests/src/runas.c,v retrieving revision 1.1 diff -u -u -r1.1 runas.c --- runas.c 2001/01/15 05:01:19 1.1 +++ runas.c 2001/02/07 09:57:51 @@ -62,7 +62,8 @@ int c; uid_t uid = -1; gid_t gid = -1; - char *cmd=NULL; + int pid; + char **cmd; gid_t sgids[SUP_MAX]; int sup_cnt = 0; int status; @@ -91,13 +92,18 @@ } /* build up the cmd */ - for ( ; optind < argc; optind++) { - cmd = realloc(cmd, (cmd==NULL?0:strlen(cmd)) + - strlen(argv[optind]) + 4); - strcat(cmd, " "); - strcat(cmd, argv[optind]); - } - + if (optind == argc) { + usage(); + exit(1); + } + else { + char **p; + p = cmd = (char **)malloc(sizeof(char *) * (argc - optind + 1)); + for ( ; optind < argc; optind++, p++) { + *p = strdup(argv[optind]); + } + *p = NULL; + } if (gid != -1) { if (setegid(gid) == -1) { @@ -122,9 +128,19 @@ exit(1); } } - - status = system(cmd); + pid = fork(); + if (pid == -1) { + fprintf(stderr, "%s: fork failed: %s\n", + prog, strerror(errno)); + exit(1); + } + if (pid == 0) { + execvp(cmd[0], cmd); + fprintf(stderr, "%s: %s\n", cmd[0], strerror(errno)); + exit(127); + } + wait(&status); if (WIFSIGNALED(status)) { fprintf(stderr, "%s: command terminated with signal %d\n", prog, WTERMSIG(status)); --wRRV7LY7NUeQGEoC-- From owner-linux-xfs@oss.sgi.com Wed Feb 7 11:06:05 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 11:05:56 -0800 Received: from cr768314-a.rchrd1.on.wave.home.com ([24.43.43.134]:131 "HELO snake-fist.gulag.glub.org") by oss.sgi.com with SMTP id ; Wed, 7 Feb 2001 11:05:42 -0800 Received: (qmail 11259 invoked by uid 2); 7 Feb 2001 18:53:16 -0000 Received: from snake-fist.gulag.glub.org (hhp@192.168.7.5) by snake-fist.gulag.glub.org with SMTP; 7 Feb 2001 18:53:16 -0000 Date: Wed, 7 Feb 2001 13:53:16 -0500 (EST) From: "Hong H. Pham" X-X-Sender: Reply-To: To: Subject: GCC 2.95.x and stalled processes [PATCH] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I have tracked down the probable cause for processes hanging when acting on an XFS filesystem, running on a system with a kernel compiled with GCC 2.95.x. I have included a patch that seems to correct this problem. The first mention of this bug was in the following thread: http://oss.sgi.com/projects/linux-xfs/indexed/msg01455.html This bug can be easily observed by untaring a large tarball on to the XFS mount. For testing, I used the Debian base2_2.tgz tarball; it has a good mix of large and many small files (eg. the /dev/* files). ftp://ftp.us.debian.org:/debian/dists/potato/main/disks-i386/current/base2_2.tgz This bug is only triggered when compiling a kernel using GCC 2.95.x with the -march=i686 optimization flag enabled. Using -march=i386, -march=i486, or -march=i586 will produce a working kernel. In xfs_trans_ail.c, xfs_trans_push_ail() line 141, GCC 2.95.x generates incorrect code for the following line: while (((restarts < XFS_TRANS_PUSH_AIL_RESTARTS) && (XFS_LSN_CMP(lip->li_lsn, threshold_lsn) < 0))) { More specifically, XFS_LSN_CMP(), really a macro wrapper for the static inline function _lsn_cmp(), defined in xfs_log.h, is inlined incorrectly by the i686 optimizer. The resulting code causes the condition in the while() statement to always be false. Consequently the body of the while() statement never executes. Making _lsm_cmp() into a non-inlined function is a quick fix for the problem. I don't know specifically what triggers this bug, so I can't offer any suggestions for an elegant work around for an inlined _lsm_cmp(). Cheers, ..h ---- Patch Starts ---- diff -urN linux.orig/Makefile linux/Makefile --- linux.orig/Makefile Thu Feb 1 12:10:24 2001 +++ linux/Makefile Wed Feb 7 13:39:22 2001 @@ -29,7 +29,7 @@ #comment out this line if compiling on RH 7.0 #CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 # AND uncomment the following line -CC = $(CROSS_COMPILE)kgcc +CC = $(CROSS_COMPILE)gcc CPP = $(CC) -E AR = $(CROSS_COMPILE)ar NM = $(CROSS_COMPILE)nm diff -urN linux.orig/fs/xfs/xfs_log.h linux/fs/xfs/xfs_log.h --- linux.orig/fs/xfs/xfs_log.h Tue Nov 14 18:40:34 2000 +++ linux/fs/xfs/xfs_log.h Wed Feb 7 13:30:17 2001 @@ -50,7 +50,8 @@ * By comparing each compnent, we don't have to worry about extra * endian issues in treating two 32 bit numbers as one 64 bit number */ -static inline xfs_lsn_t _lsn_cmp(xfs_lsn_t lsn1, xfs_lsn_t lsn2, xfs_arch_t arch) + +static inline xfs_lsn_t _lsn_cmp_inline(xfs_lsn_t lsn1, xfs_lsn_t lsn2, xfs_arch_t arch) { if (CYCLE_LSN(lsn1, arch) != CYCLE_LSN(lsn2, arch)) return (CYCLE_LSN(lsn1, arch); Wed, 7 Feb 2001 12:58:56 -0800 Received: from relay02.sportsline.com ([63.72.118.49]:47122 "HELO relay02.sportsline.com") by oss.sgi.com with SMTP id ; Wed, 7 Feb 2001 12:58:47 -0800 Received: (qmail 21298 invoked from network); 7 Feb 2001 20:58:45 -0000 Received: from chipsworld.llamas.net (63.77.33.226) by relay02.sportsline.com with SMTP; 7 Feb 2001 20:58:45 -0000 Received: from localhost (chipper@localhost) by chipsworld.llamas.net (8.11.0/8.11.0) with ESMTP id f17Kwik06492 for ; Wed, 7 Feb 2001 15:58:44 -0500 Date: Wed, 7 Feb 2001 15:58:44 -0500 (EST) From: "Chris 'Chipper' Chiapusio" To: Subject: Unresolved Symbols problem w/ 2.4.1-XFS cvs Message-ID: X-Files: Resist or serve MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1296032289-1045275365-981579524=:20195" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1296032289-1045275365-981579524=:20195 Content-Type: TEXT/PLAIN; charset=US-ASCII I've been trying to get this going for days now. I've read the list archives, checked Documentation/Changes and ensured that all my tools are up to date. I've done cp .config ..;make mrproper;cp ../.config .;make oldconfig; make dep && make clean && make bzlilo && make modules && make modules_install I've updated my cvs tree repeatedly and I still cannot build a kernel that doesn have Unresolved symbols. My system is the RH7-XFS install, I've changed /usr/include/{asm,include,pcmcia} to point to the appropriate directories in my source tree (symlinked ala /usr/src/linux) and the last thing I can think of that I changed in an effort to make it all work is: [root@fury linux]# grep gcc Makefile HOSTCC = kgcc #CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 CC = $(CROSS_COMPILE)kgcc [root@fury linux]# the kernel builds and is even bootable, but no modules work. what in the world have I missed? I've even nuked my source tree and re-downloaded from CVS, reconfigured from scratch. just on the off chance that I'm configuring something foolishly I've attached my .config file for examination. Thanks in advance, Chipper PS. this is on a Toshiba Laptop. ------ Please encrypt anything important. PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D --1296032289-1045275365-981579524=:20195 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=241 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=241 Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBieSBtYWtlIG1lbnVjb25m aWc6IGRvbid0IGVkaXQNCiMNCkNPTkZJR19YODY9eQ0KQ09ORklHX0lTQT15 DQojIENPTkZJR19TQlVTIGlzIG5vdCBzZXQNCkNPTkZJR19VSUQxNj15DQoN CiMNCiMgQ29kZSBtYXR1cml0eSBsZXZlbCBvcHRpb25zDQojDQpDT05GSUdf RVhQRVJJTUVOVEFMPXkNCg0KIw0KIyBMb2FkYWJsZSBtb2R1bGUgc3VwcG9y dA0KIw0KQ09ORklHX01PRFVMRVM9eQ0KQ09ORklHX01PRFZFUlNJT05TPXkN CkNPTkZJR19LTU9EPXkNCg0KIw0KIyBQcm9jZXNzb3IgdHlwZSBhbmQgZmVh dHVyZXMNCiMNCiMgQ09ORklHX00zODYgaXMgbm90IHNldA0KIyBDT05GSUdf TTQ4NiBpcyBub3Qgc2V0DQojIENPTkZJR19NNTg2IGlzIG5vdCBzZXQNCiMg Q09ORklHX001ODZUU0MgaXMgbm90IHNldA0KIyBDT05GSUdfTTU4Nk1NWCBp cyBub3Qgc2V0DQojIENPTkZJR19NNjg2IGlzIG5vdCBzZXQNCkNPTkZJR19N UEVOVElVTUlJST15DQojIENPTkZJR19NUEVOVElVTTQgaXMgbm90IHNldA0K IyBDT05GSUdfTUs2IGlzIG5vdCBzZXQNCiMgQ09ORklHX01LNyBpcyBub3Qg c2V0DQojIENPTkZJR19NQ1JVU09FIGlzIG5vdCBzZXQNCiMgQ09ORklHX01X SU5DSElQQzYgaXMgbm90IHNldA0KIyBDT05GSUdfTVdJTkNISVAyIGlzIG5v dCBzZXQNCiMgQ09ORklHX01XSU5DSElQM0QgaXMgbm90IHNldA0KQ09ORklH X1g4Nl9XUF9XT1JLU19PSz15DQpDT05GSUdfWDg2X0lOVkxQRz15DQpDT05G SUdfWDg2X0NNUFhDSEc9eQ0KQ09ORklHX1g4Nl9CU1dBUD15DQpDT05GSUdf WDg2X1BPUEFEX09LPXkNCkNPTkZJR19YODZfTDFfQ0FDSEVfU0hJRlQ9NQ0K Q09ORklHX1g4Nl9UU0M9eQ0KQ09ORklHX1g4Nl9HT09EX0FQSUM9eQ0KQ09O RklHX1g4Nl9QR0U9eQ0KQ09ORklHX1g4Nl9VU0VfUFBST19DSEVDS1NVTT15 DQpDT05GSUdfVE9TSElCQT15DQojIENPTkZJR19NSUNST0NPREUgaXMgbm90 IHNldA0KIyBDT05GSUdfWDg2X01TUiBpcyBub3Qgc2V0DQojIENPTkZJR19Y ODZfQ1BVSUQgaXMgbm90IHNldA0KQ09ORklHX05PSElHSE1FTT15DQojIENP TkZJR19ISUdITUVNNEcgaXMgbm90IHNldA0KIyBDT05GSUdfSElHSE1FTTY0 RyBpcyBub3Qgc2V0DQojIENPTkZJR19NQVRIX0VNVUxBVElPTiBpcyBub3Qg c2V0DQpDT05GSUdfTVRSUj15DQojIENPTkZJR19TTVAgaXMgbm90IHNldA0K IyBDT05GSUdfWDg2X1VQX0lPQVBJQyBpcyBub3Qgc2V0DQoNCiMNCiMgR2Vu ZXJhbCBzZXR1cA0KIw0KQ09ORklHX05FVD15DQojIENPTkZJR19WSVNXUyBp cyBub3Qgc2V0DQpDT05GSUdfUENJPXkNCiMgQ09ORklHX1BDSV9HT0JJT1Mg aXMgbm90IHNldA0KIyBDT05GSUdfUENJX0dPRElSRUNUIGlzIG5vdCBzZXQN CkNPTkZJR19QQ0lfR09BTlk9eQ0KQ09ORklHX1BDSV9CSU9TPXkNCkNPTkZJ R19QQ0lfRElSRUNUPXkNCkNPTkZJR19QQ0lfTkFNRVM9eQ0KIyBDT05GSUdf RUlTQSBpcyBub3Qgc2V0DQojIENPTkZJR19NQ0EgaXMgbm90IHNldA0KQ09O RklHX0hPVFBMVUc9eQ0KDQojDQojIFBDTUNJQS9DYXJkQnVzIHN1cHBvcnQN CiMNCkNPTkZJR19QQ01DSUE9eQ0KQ09ORklHX0NBUkRCVVM9eQ0KQ09ORklH X0k4MjM2NT15DQojIENPTkZJR19UQ0lDIGlzIG5vdCBzZXQNCkNPTkZJR19T WVNWSVBDPXkNCiMgQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1QgaXMgbm90IHNl dA0KQ09ORklHX1NZU0NUTD15DQpDT05GSUdfS0NPUkVfRUxGPXkNCiMgQ09O RklHX0tDT1JFX0FPVVQgaXMgbm90IHNldA0KQ09ORklHX0JJTkZNVF9BT1VU PW0NCkNPTkZJR19CSU5GTVRfRUxGPXkNCkNPTkZJR19CSU5GTVRfTUlTQz1t DQpDT05GSUdfUE09eQ0KIyBDT05GSUdfQUNQSSBpcyBub3Qgc2V0DQpDT05G SUdfQVBNPXkNCkNPTkZJR19BUE1fSUdOT1JFX1VTRVJfU1VTUEVORD15DQpD T05GSUdfQVBNX0RPX0VOQUJMRT15DQpDT05GSUdfQVBNX0NQVV9JRExFPXkN CkNPTkZJR19BUE1fRElTUExBWV9CTEFOSz15DQpDT05GSUdfQVBNX1JUQ19J U19HTVQ9eQ0KIyBDT05GSUdfQVBNX0FMTE9XX0lOVFMgaXMgbm90IHNldA0K IyBDT05GSUdfQVBNX1JFQUxfTU9ERV9QT1dFUl9PRkYgaXMgbm90IHNldA0K DQojDQojIE1lbW9yeSBUZWNobm9sb2d5IERldmljZXMgKE1URCkNCiMNCiMg Q09ORklHX01URCBpcyBub3Qgc2V0DQoNCiMNCiMgUGFyYWxsZWwgcG9ydCBz dXBwb3J0DQojDQojIENPTkZJR19QQVJQT1JUIGlzIG5vdCBzZXQNCg0KIw0K IyBQbHVnIGFuZCBQbGF5IGNvbmZpZ3VyYXRpb24NCiMNCkNPTkZJR19QTlA9 eQ0KQ09ORklHX0lTQVBOUD15DQoNCiMNCiMgQmxvY2sgZGV2aWNlcw0KIw0K Q09ORklHX0JMS19ERVZfRkQ9eQ0KIyBDT05GSUdfQkxLX0RFVl9YRCBpcyBu b3Qgc2V0DQojIENPTkZJR19QQVJJREUgaXMgbm90IHNldA0KIyBDT05GSUdf QkxLX0NQUV9EQSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfQ1BRX0NJU1Nf REEgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9EQUM5NjAgaXMgbm90 IHNldA0KQ09ORklHX0JMS19ERVZfTE9PUD1tDQojIENPTkZJR19CTEtfREVW X05CRCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9SQU09bQ0KQ09ORklH X0JMS19ERVZfUkFNX1NJWkU9NDA5Ng0KIyBDT05GSUdfQkxLX0RFVl9JTklU UkQgaXMgbm90IHNldA0KDQojDQojIE11bHRpLWRldmljZSBzdXBwb3J0IChS QUlEIGFuZCBMVk0pDQojDQojIENPTkZJR19NRCBpcyBub3Qgc2V0DQojIENP TkZJR19CTEtfREVWX01EIGlzIG5vdCBzZXQNCiMgQ09ORklHX01EX0xJTkVB UiBpcyBub3Qgc2V0DQojIENPTkZJR19NRF9SQUlEMCBpcyBub3Qgc2V0DQoj IENPTkZJR19NRF9SQUlEMSBpcyBub3Qgc2V0DQojIENPTkZJR19NRF9SQUlE NSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0xWTSBpcyBub3Qgc2V0 DQoNCiMNCiMgTmV0d29ya2luZyBvcHRpb25zDQojDQpDT05GSUdfUEFDS0VU PXkNCkNPTkZJR19QQUNLRVRfTU1BUD15DQojIENPTkZJR19ORVRMSU5LIGlz IG5vdCBzZXQNCiMgQ09ORklHX05FVEZJTFRFUiBpcyBub3Qgc2V0DQpDT05G SUdfRklMVEVSPXkNCkNPTkZJR19VTklYPXkNCkNPTkZJR19JTkVUPXkNCkNP TkZJR19JUF9NVUxUSUNBU1Q9eQ0KIyBDT05GSUdfSVBfQURWQU5DRURfUk9V VEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX1BOUCBpcyBub3Qgc2V0DQoj IENPTkZJR19ORVRfSVBJUCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfSVBH UkUgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfTVJPVVRFIGlzIG5vdCBzZXQN CkNPTkZJR19JTkVUX0VDTj15DQpDT05GSUdfU1lOX0NPT0tJRVM9eQ0KIyBD T05GSUdfSVBWNiBpcyBub3Qgc2V0DQojIENPTkZJR19LSFRUUEQgaXMgbm90 IHNldA0KIyBDT05GSUdfQVRNIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQWCBp cyBub3Qgc2V0DQojIENPTkZJR19BVEFMSyBpcyBub3Qgc2V0DQojIENPTkZJ R19ERUNORVQgaXMgbm90IHNldA0KIyBDT05GSUdfQlJJREdFIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0DQojIENPTkZJR19MQVBCIGlz IG5vdCBzZXQNCiMgQ09ORklHX0xMQyBpcyBub3Qgc2V0DQojIENPTkZJR19O RVRfRElWRVJUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VDT05FVCBpcyBub3Qg c2V0DQojIENPTkZJR19XQU5fUk9VVEVSIGlzIG5vdCBzZXQNCiMgQ09ORklH X05FVF9GQVNUUk9VVEUgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX0hXX0ZM T1dDT05UUk9MIGlzIG5vdCBzZXQNCg0KIw0KIyBRb1MgYW5kL29yIGZhaXIg cXVldWVpbmcNCiMNCiMgQ09ORklHX05FVF9TQ0hFRCBpcyBub3Qgc2V0DQoN CiMNCiMgVGVsZXBob255IFN1cHBvcnQNCiMNCiMgQ09ORklHX1BIT05FIGlz IG5vdCBzZXQNCiMgQ09ORklHX1BIT05FX0lYSiBpcyBub3Qgc2V0DQoNCiMN CiMgQVRBL0lERS9NRk0vUkxMIHN1cHBvcnQNCiMNCkNPTkZJR19JREU9eQ0K DQojDQojIElERSwgQVRBIGFuZCBBVEFQSSBCbG9jayBkZXZpY2VzDQojDQpD T05GSUdfQkxLX0RFVl9JREU9eQ0KIyBDT05GSUdfQkxLX0RFVl9IRF9JREUg aXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9IRCBpcyBub3Qgc2V0DQpD T05GSUdfQkxLX0RFVl9JREVESVNLPXkNCkNPTkZJR19JREVESVNLX01VTFRJ X01PREU9eQ0KIyBDT05GSUdfQkxLX0RFVl9JREVESVNLX1ZFTkRPUiBpcyBu b3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0lERURJU0tfRlVKSVRTVSBpcyBu b3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0lERURJU0tfSUJNIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0JMS19ERVZfSURFRElTS19NQVhUT1IgaXMgbm90IHNl dA0KIyBDT05GSUdfQkxLX0RFVl9JREVESVNLX1FVQU5UVU0gaXMgbm90IHNl dA0KIyBDT05GSUdfQkxLX0RFVl9JREVESVNLX1NFQUdBVEUgaXMgbm90IHNl dA0KIyBDT05GSUdfQkxLX0RFVl9JREVESVNLX1dEIGlzIG5vdCBzZXQNCiMg Q09ORklHX0JMS19ERVZfQ09NTUVSSUFMIGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfVElWTyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0lE RUNTIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERUNEPXkNCiMgQ09O RklHX0JMS19ERVZfSURFVEFQRSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX0lERUZMT1BQWSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0lE RVNDU0kgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9DTUQ2NDAgaXMg bm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9DTUQ2NDBfRU5IQU5DRUQgaXMg bm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JU0FQTlAgaXMgbm90IHNldA0K IyBDT05GSUdfQkxLX0RFVl9SWjEwMDAgaXMgbm90IHNldA0KQ09ORklHX0JM S19ERVZfSURFUENJPXkNCkNPTkZJR19JREVQQ0lfU0hBUkVfSVJRPXkNCkNP TkZJR19CTEtfREVWX0lERURNQV9QQ0k9eQ0KIyBDT05GSUdfQkxLX0RFVl9P RkZCT0FSRCBpcyBub3Qgc2V0DQpDT05GSUdfSURFRE1BX1BDSV9BVVRPPXkN CkNPTkZJR19CTEtfREVWX0lERURNQT15DQojIENPTkZJR19JREVETUFfUENJ X1dJUCBpcyBub3Qgc2V0DQojIENPTkZJR19JREVETUFfTkVXX0RSSVZFX0xJ U1RJTkdTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQUVDNjJYWCBp cyBub3Qgc2V0DQojIENPTkZJR19BRUM2MlhYX1RVTklORyBpcyBub3Qgc2V0 DQojIENPTkZJR19CTEtfREVWX0FMSTE1WDMgaXMgbm90IHNldA0KIyBDT05G SUdfV0RDX0FMSTE1WDMgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9B TUQ3NDA5IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FNRDc0MDlfT1ZFUlJJREUg aXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9DTUQ2NFggaXMgbm90IHNl dA0KIyBDT05GSUdfQkxLX0RFVl9DWTgyQzY5MyBpcyBub3Qgc2V0DQojIENP TkZJR19CTEtfREVWX0NTNTUzMCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX0hQVDM0WCBpcyBub3Qgc2V0DQojIENPTkZJR19IUFQzNFhfQVVUT0RN QSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0hQVDM2NiBpcyBub3Qg c2V0DQpDT05GSUdfQkxLX0RFVl9QSUlYPXkNCkNPTkZJR19QSUlYX1RVTklO Rz15DQojIENPTkZJR19CTEtfREVWX05TODc0MTUgaXMgbm90IHNldA0KIyBD T05GSUdfQkxLX0RFVl9PUFRJNjIxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM S19ERVZfUERDMjAyWFggaXMgbm90IHNldA0KIyBDT05GSUdfUERDMjAyWFhf QlVSU1QgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9PU0I0IGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfU0lTNTUxMyBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX1NMQzkwRTY2IGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfVFJNMjkwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf VklBODJDWFhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lERV9DSElQU0VUUyBp cyBub3Qgc2V0DQpDT05GSUdfSURFRE1BX0FVVE89eQ0KIyBDT05GSUdfSURF RE1BX0lWQiBpcyBub3Qgc2V0DQojIENPTkZJR19ETUFfTk9OUENJIGlzIG5v dCBzZXQNCkNPTkZJR19CTEtfREVWX0lERV9NT0RFUz15DQoNCiMNCiMgU0NT SSBzdXBwb3J0DQojDQojIENPTkZJR19TQ1NJIGlzIG5vdCBzZXQNCg0KIw0K IyBJRUVFIDEzOTQgKEZpcmVXaXJlKSBzdXBwb3J0DQojDQojIENPTkZJR19J RUVFMTM5NCBpcyBub3Qgc2V0DQoNCiMNCiMgSTJPIGRldmljZSBzdXBwb3J0 DQojDQojIENPTkZJR19JMk8gaXMgbm90IHNldA0KIyBDT05GSUdfSTJPX1BD SSBpcyBub3Qgc2V0DQojIENPTkZJR19JMk9fQkxPQ0sgaXMgbm90IHNldA0K IyBDT05GSUdfSTJPX0xBTiBpcyBub3Qgc2V0DQojIENPTkZJR19JMk9fU0NT SSBpcyBub3Qgc2V0DQojIENPTkZJR19JMk9fUFJPQyBpcyBub3Qgc2V0DQoN CiMNCiMgTmV0d29yayBkZXZpY2Ugc3VwcG9ydA0KIw0KQ09ORklHX05FVERF VklDRVM9eQ0KDQojDQojIEFSQ25ldCBkZXZpY2VzDQojDQojIENPTkZJR19B UkNORVQgaXMgbm90IHNldA0KQ09ORklHX0RVTU1ZPW0NCiMgQ09ORklHX0JP TkRJTkcgaXMgbm90IHNldA0KIyBDT05GSUdfRVFVQUxJWkVSIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1RVTiBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfU0Ix MDAwIGlzIG5vdCBzZXQNCg0KIw0KIyBFdGhlcm5ldCAoMTAgb3IgMTAwTWJp dCkNCiMNCkNPTkZJR19ORVRfRVRIRVJORVQ9eQ0KQ09ORklHX05FVF9WRU5E T1JfM0NPTT15DQojIENPTkZJR19FTDEgaXMgbm90IHNldA0KIyBDT05GSUdf RUwyIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VMUExVUyBpcyBub3Qgc2V0DQoj IENPTkZJR19FTDE2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0VMMyBpcyBub3Qg c2V0DQojIENPTkZJR18zQzUxNSBpcyBub3Qgc2V0DQojIENPTkZJR19FTE1D IGlzIG5vdCBzZXQNCiMgQ09ORklHX0VMTUNfSUkgaXMgbm90IHNldA0KQ09O RklHX1ZPUlRFWD1tDQojIENPTkZJR19MQU5DRSBpcyBub3Qgc2V0DQojIENP TkZJR19ORVRfVkVORE9SX1NNQyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRf VkVORE9SX1JBQ0FMIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUMTcwMCBpcyBu b3Qgc2V0DQojIENPTkZJR19ERVBDQSBpcyBub3Qgc2V0DQojIENPTkZJR19I UDEwMCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfSVNBIGlzIG5vdCBzZXQN CiMgQ09ORklHX05FVF9QQ0kgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX1BP Q0tFVCBpcyBub3Qgc2V0DQoNCiMNCiMgRXRoZXJuZXQgKDEwMDAgTWJpdCkN CiMNCiMgQ09ORklHX0FDRU5JQyBpcyBub3Qgc2V0DQojIENPTkZJR19IQU1B Q0hJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1lFTExPV0ZJTiBpcyBub3Qgc2V0 DQojIENPTkZJR19TSzk4TElOIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZEREkg aXMgbm90IHNldA0KIyBDT05GSUdfSElQUEkgaXMgbm90IHNldA0KQ09ORklH X1BQUD1tDQojIENPTkZJR19QUFBfTVVMVElMSU5LIGlzIG5vdCBzZXQNCkNP TkZJR19QUFBfQVNZTkM9bQ0KIyBDT05GSUdfUFBQX1NZTkNfVFRZIGlzIG5v dCBzZXQNCkNPTkZJR19QUFBfREVGTEFURT1tDQpDT05GSUdfUFBQX0JTRENP TVA9bQ0KIyBDT05GSUdfUFBQT0UgaXMgbm90IHNldA0KIyBDT05GSUdfU0xJ UCBpcyBub3Qgc2V0DQoNCiMNCiMgV2lyZWxlc3MgTEFOIChub24taGFtcmFk aW8pDQojDQojIENPTkZJR19ORVRfUkFESU8gaXMgbm90IHNldA0KDQojDQoj IFRva2VuIFJpbmcgZGV2aWNlcw0KIw0KIyBDT05GSUdfVFIgaXMgbm90IHNl dA0KIyBDT05GSUdfTkVUX0ZDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JDUENJ IGlzIG5vdCBzZXQNCkNPTkZJR19TSEFQRVI9bQ0KDQojDQojIFdhbiBpbnRl cmZhY2VzDQojDQojIENPTkZJR19XQU4gaXMgbm90IHNldA0KDQojDQojIFBD TUNJQSBuZXR3b3JrIGRldmljZSBzdXBwb3J0DQojDQpDT05GSUdfTkVUX1BD TUNJQT15DQpDT05GSUdfUENNQ0lBXzNDNTg5PW0NCiMgQ09ORklHX1BDTUNJ QV8zQzU3NCBpcyBub3Qgc2V0DQojIENPTkZJR19QQ01DSUFfRk1WSjE4WCBp cyBub3Qgc2V0DQojIENPTkZJR19QQ01DSUFfUENORVQgaXMgbm90IHNldA0K IyBDT05GSUdfUENNQ0lBX05NQ0xBTiBpcyBub3Qgc2V0DQojIENPTkZJR19Q Q01DSUFfU01DOTFDOTIgaXMgbm90IHNldA0KQ09ORklHX1BDTUNJQV9YSVJD MlBTPW0NCiMgQ09ORklHX0FSQ05FVF9DT00yMDAyMF9DUyBpcyBub3Qgc2V0 DQojIENPTkZJR19QQ01DSUFfSUJNVFIgaXMgbm90IHNldA0KQ09ORklHX1BD TUNJQV9YSVJUVUxJUD1tDQojIENPTkZJR19ORVRfUENNQ0lBX1JBRElPIGlz IG5vdCBzZXQNCg0KIw0KIyBBbWF0ZXVyIFJhZGlvIHN1cHBvcnQNCiMNCiMg Q09ORklHX0hBTVJBRElPIGlzIG5vdCBzZXQNCg0KIw0KIyBJckRBIChpbmZy YXJlZCkgc3VwcG9ydA0KIw0KQ09ORklHX0lSREE9bQ0KQ09ORklHX0lSTEFO PW0NCkNPTkZJR19JUk5FVD1tDQpDT05GSUdfSVJDT01NPW0NCkNPTkZJR19J UkRBX1VMVFJBPXkNCkNPTkZJR19JUkRBX09QVElPTlM9eQ0KQ09ORklHX0lS REFfQ0FDSEVfTEFTVF9MU0FQPXkNCkNPTkZJR19JUkRBX0ZBU1RfUlI9eQ0K IyBDT05GSUdfSVJEQV9ERUJVRyBpcyBub3Qgc2V0DQoNCiMNCiMgSW5mcmFy ZWQtcG9ydCBkZXZpY2UgZHJpdmVycw0KIw0KQ09ORklHX0lSVFRZX1NJUj1t DQpDT05GSUdfSVJQT1JUX1NJUj1tDQojIENPTkZJR19OU0NfRklSIGlzIG5v dCBzZXQNCiMgQ09ORklHX1dJTkJPTkRfRklSIGlzIG5vdCBzZXQNCkNPTkZJ R19UT1NISUJBX0ZJUj1tDQojIENPTkZJR19TTUNfSVJDQ19GSVIgaXMgbm90 IHNldA0KIyBDT05GSUdfRE9OR0xFIGlzIG5vdCBzZXQNCg0KIw0KIyBJU0RO IHN1YnN5c3RlbQ0KIw0KIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0DQoNCiMN CiMgT2xkIENELVJPTSBkcml2ZXJzIChub3QgU0NTSSwgbm90IElERSkNCiMN CiMgQ09ORklHX0NEX05PX0lERVNDU0kgaXMgbm90IHNldA0KDQojDQojIElu cHV0IGNvcmUgc3VwcG9ydA0KIw0KQ09ORklHX0lOUFVUPXkNCkNPTkZJR19J TlBVVF9LRVlCREVWPXkNCkNPTkZJR19JTlBVVF9NT1VTRURFVj15DQpDT05G SUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1g9MTAyNA0KQ09ORklHX0lOUFVU X01PVVNFREVWX1NDUkVFTl9ZPTc2OA0KIyBDT05GSUdfSU5QVVRfSk9ZREVW IGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX0VWREVWIGlzIG5vdCBzZXQN Cg0KIw0KIyBDaGFyYWN0ZXIgZGV2aWNlcw0KIw0KQ09ORklHX1ZUPXkNCkNP TkZJR19WVF9DT05TT0xFPXkNCkNPTkZJR19TRVJJQUw9eQ0KIyBDT05GSUdf U0VSSUFMX0NPTlNPTEUgaXMgbm90IHNldA0KIyBDT05GSUdfU0VSSUFMX0VY VEVOREVEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklBTF9OT05TVEFOREFS RCBpcyBub3Qgc2V0DQpDT05GSUdfVU5JWDk4X1BUWVM9eQ0KQ09ORklHX1VO SVg5OF9QVFlfQ09VTlQ9MjU2DQoNCiMNCiMgSTJDIHN1cHBvcnQNCiMNCiMg Q09ORklHX0kyQyBpcyBub3Qgc2V0DQoNCiMNCiMgTWljZQ0KIw0KIyBDT05G SUdfQlVTTU9VU0UgaXMgbm90IHNldA0KQ09ORklHX01PVVNFPXkNCkNPTkZJ R19QU01PVVNFPXkNCiMgQ09ORklHXzgyQzcxMF9NT1VTRSBpcyBub3Qgc2V0 DQojIENPTkZJR19QQzExMF9QQUQgaXMgbm90IHNldA0KDQojDQojIEpveXN0 aWNrcw0KIw0KIyBDT05GSUdfSk9ZU1RJQ0sgaXMgbm90IHNldA0KIyBDT05G SUdfUUlDMDJfVEFQRSBpcyBub3Qgc2V0DQoNCiMNCiMgV2F0Y2hkb2cgQ2Fy ZHMNCiMNCiMgQ09ORklHX1dBVENIRE9HIGlzIG5vdCBzZXQNCiMgQ09ORklH X0lOVEVMX1JORyBpcyBub3Qgc2V0DQojIENPTkZJR19OVlJBTSBpcyBub3Qg c2V0DQpDT05GSUdfUlRDPXkNCiMgQ09ORklHX0RUTEsgaXMgbm90IHNldA0K IyBDT05GSUdfUjM5NjQgaXMgbm90IHNldA0KIyBDT05GSUdfQVBQTElDT00g aXMgbm90IHNldA0KDQojDQojIEZ0YXBlLCB0aGUgZmxvcHB5IHRhcGUgZGV2 aWNlIGRyaXZlcg0KIw0KIyBDT05GSUdfRlRBUEUgaXMgbm90IHNldA0KQ09O RklHX0FHUD15DQpDT05GSUdfQUdQX0lOVEVMPXkNCiMgQ09ORklHX0FHUF9J ODEwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FHUF9WSUEgaXMgbm90IHNldA0K IyBDT05GSUdfQUdQX0FNRCBpcyBub3Qgc2V0DQojIENPTkZJR19BR1BfU0lT IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FHUF9BTEkgaXMgbm90IHNldA0KIyBD T05GSUdfRFJNIGlzIG5vdCBzZXQNCkNPTkZJR19QQ01DSUFfU0VSSUFMPXkN Cg0KIw0KIyBQQ01DSUEgY2hhcmFjdGVyIGRldmljZSBzdXBwb3J0DQojDQpD T05GSUdfUENNQ0lBX1NFUklBTF9DUz1tDQpDT05GSUdfUENNQ0lBX1NFUklB TF9DQj1tDQoNCiMNCiMgTXVsdGltZWRpYSBkZXZpY2VzDQojDQojIENPTkZJ R19WSURFT19ERVYgaXMgbm90IHNldA0KDQojDQojIEZpbGUgc3lzdGVtcw0K Iw0KQ09ORklHX1FVT1RBPXkNCkNPTkZJR19GU19QT1NJWF9BQ0w9eQ0KQ09O RklHX0FVVE9GU19GUz1tDQpDT05GSUdfQVVUT0ZTNF9GUz1tDQpDT05GSUdf UkVJU0VSRlNfRlM9eQ0KIyBDT05GSUdfUkVJU0VSRlNfQ0hFQ0sgaXMgbm90 IHNldA0KIyBDT05GSUdfQURGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19B REZTX0ZTX1JXIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FGRlNfRlMgaXMgbm90 IHNldA0KIyBDT05GSUdfSEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JG U19GUyBpcyBub3Qgc2V0DQpDT05GSUdfRkFUX0ZTPW0NCkNPTkZJR19NU0RP U19GUz1tDQojIENPTkZJR19VTVNET1NfRlMgaXMgbm90IHNldA0KQ09ORklH X1ZGQVRfRlM9bQ0KIyBDT05GSUdfRUZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09O RklHX0pGRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JBTUZTIGlzIG5v dCBzZXQNCiMgQ09ORklHX1JBTUZTIGlzIG5vdCBzZXQNCkNPTkZJR19JU085 NjYwX0ZTPXkNCkNPTkZJR19KT0xJRVQ9eQ0KQ09ORklHX01JTklYX0ZTPW0N CkNPTkZJR19OVEZTX0ZTPW0NCiMgQ09ORklHX05URlNfUlcgaXMgbm90IHNl dA0KIyBDT05GSUdfSFBGU19GUyBpcyBub3Qgc2V0DQpDT05GSUdfUFJPQ19G Uz15DQpDT05GSUdfREVWRlNfRlM9eQ0KQ09ORklHX0RFVkZTX01PVU5UPXkN CiMgQ09ORklHX0RFVkZTX0RFQlVHIGlzIG5vdCBzZXQNCkNPTkZJR19ERVZQ VFNfRlM9eQ0KIyBDT05GSUdfUU5YNEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09O RklHX1FOWDRGU19SVyBpcyBub3Qgc2V0DQpDT05GSUdfUk9NRlNfRlM9bQ0K Q09ORklHX0VYVDJfRlM9eQ0KIyBDT05GSUdfU1lTVl9GUyBpcyBub3Qgc2V0 DQojIENPTkZJR19TWVNWX0ZTX1dSSVRFIGlzIG5vdCBzZXQNCkNPTkZJR19V REZfRlM9bQ0KIyBDT05GSUdfVURGX1JXIGlzIG5vdCBzZXQNCiMgQ09ORklH X1VGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19VRlNfRlNfV1JJVEUgaXMg bm90IHNldA0KQ09ORklHX1BBR0VfQlVGPXkNCkNPTkZJR19YRlNfRlM9eQ0K IyBDT05GSUdfWEZTX0RNQVBJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1hGU19R VU9UQSBpcyBub3Qgc2V0DQojIENPTkZJR19YRlNfREVCVUcgaXMgbm90IHNl dA0KIyBDT05GSUdfWEZTX1ZOT0RFX1RSQUNJTkcgaXMgbm90IHNldA0KQ09O RklHX1hGU19TVVBQT1JUPXkNCg0KIw0KIyBOZXR3b3JrIEZpbGUgU3lzdGVt cw0KIw0KQ09ORklHX0NPREFfRlM9bQ0KQ09ORklHX05GU19GUz1tDQpDT05G SUdfTkZTX1YzPXkNCiMgQ09ORklHX1JPT1RfTkZTIGlzIG5vdCBzZXQNCkNP TkZJR19ORlNEPW0NCkNPTkZJR19ORlNEX1YzPXkNCkNPTkZJR19TVU5SUEM9 bQ0KQ09ORklHX0xPQ0tEPW0NCkNPTkZJR19MT0NLRF9WND15DQpDT05GSUdf U01CX0ZTPW0NCkNPTkZJR19TTUJfTkxTX0RFRkFVTFQ9eQ0KQ09ORklHX1NN Ql9OTFNfUkVNT1RFPSJjcDQzNyINCiMgQ09ORklHX05DUF9GUyBpcyBub3Qg c2V0DQojIENPTkZJR19OQ1BGU19QQUNLRVRfU0lHTklORyBpcyBub3Qgc2V0 DQojIENPTkZJR19OQ1BGU19JT0NUTF9MT0NLSU5HIGlzIG5vdCBzZXQNCiMg Q09ORklHX05DUEZTX1NUUk9ORyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BG U19ORlNfTlMgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQRlNfT1MyX05TIGlz IG5vdCBzZXQNCiMgQ09ORklHX05DUEZTX1NNQUxMRE9TIGlzIG5vdCBzZXQN CiMgQ09ORklHX05DUEZTX05MUyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BG U19FWFRSQVMgaXMgbm90IHNldA0KDQojDQojIFBhcnRpdGlvbiBUeXBlcw0K Iw0KIyBDT05GSUdfUEFSVElUSU9OX0FEVkFOQ0VEIGlzIG5vdCBzZXQNCkNP TkZJR19NU0RPU19QQVJUSVRJT049eQ0KQ09ORklHX1NNQl9OTFM9eQ0KQ09O RklHX05MUz15DQoNCiMNCiMgTmF0aXZlIExhbmd1YWdlIFN1cHBvcnQNCiMN CkNPTkZJR19OTFNfREVGQVVMVD0iaXNvODg1OS0xIg0KQ09ORklHX05MU19D T0RFUEFHRV80Mzc9bQ0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzczNyBpcyBu b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfNzc1IGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTAgaXMgbm90IHNldA0KQ09ORklH X05MU19DT0RFUEFHRV84NTI9bQ0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1 NSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODU3IGlzIG5v dCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNldA0K IyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MSBpcyBub3Qgc2V0DQojIENPTkZJ R19OTFNfQ09ERVBBR0VfODYyIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19D T0RFUEFHRV84NjMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdF Xzg2NCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODY1IGlz IG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNl dA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0DQojIENP TkZJR19OTFNfQ09ERVBBR0VfODc0IGlzIG5vdCBzZXQNCiMgQ09ORklHX05M U19DT0RFUEFHRV85MzIgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzkzNiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfOTQ5 IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV85NTAgaXMgbm90 IHNldA0KQ09ORklHX05MU19JU084ODU5XzE9eQ0KIyBDT05GSUdfTkxTX0lT Tzg4NTlfMiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV8zIGlz IG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzQgaXMgbm90IHNldA0K IyBDT05GSUdfTkxTX0lTTzg4NTlfNSBpcyBub3Qgc2V0DQojIENPTkZJR19O TFNfSVNPODg1OV82IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5 XzcgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfOCBpcyBub3Qg c2V0DQojIENPTkZJR19OTFNfSVNPODg1OV85IGlzIG5vdCBzZXQNCiMgQ09O RklHX05MU19JU084ODU5XzE0IGlzIG5vdCBzZXQNCkNPTkZJR19OTFNfSVNP ODg1OV8xNT1tDQojIENPTkZJR19OTFNfS09JOF9SIGlzIG5vdCBzZXQNCkNP TkZJR19OTFNfVVRGOD1tDQoNCiMNCiMgQ29uc29sZSBkcml2ZXJzDQojDQpD T05GSUdfVkdBX0NPTlNPTEU9eQ0KQ09ORklHX1ZJREVPX1NFTEVDVD15DQoj IENPTkZJR19NREFfQ09OU09MRSBpcyBub3Qgc2V0DQoNCiMNCiMgRnJhbWUt YnVmZmVyIHN1cHBvcnQNCiMNCkNPTkZJR19GQj15DQpDT05GSUdfRFVNTVlf Q09OU09MRT15DQojIENPTkZJR19GQl9SSVZBIGlzIG5vdCBzZXQNCiMgQ09O RklHX0ZCX0NMR0VOIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZCX1BNMiBpcyBu b3Qgc2V0DQojIENPTkZJR19GQl9DWUJFUjIwMDAgaXMgbm90IHNldA0KQ09O RklHX0ZCX1ZFU0E9eQ0KIyBDT05GSUdfRkJfVkdBMTYgaXMgbm90IHNldA0K IyBDT05GSUdfRkJfSEdBIGlzIG5vdCBzZXQNCkNPTkZJR19WSURFT19TRUxF Q1Q9eQ0KIyBDT05GSUdfRkJfTUFUUk9YIGlzIG5vdCBzZXQNCiMgQ09ORklH X0ZCX0FUWSBpcyBub3Qgc2V0DQojIENPTkZJR19GQl9BVFkxMjggaXMgbm90 IHNldA0KIyBDT05GSUdfRkJfM0RGWCBpcyBub3Qgc2V0DQojIENPTkZJR19G Ql9TSVMgaXMgbm90IHNldA0KIyBDT05GSUdfRkJfVklSVFVBTCBpcyBub3Qg c2V0DQpDT05GSUdfRkJDT05fQURWQU5DRUQ9eQ0KIyBDT05GSUdfRkJDT05f TUZCIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZCQ09OX0NGQjIgaXMgbm90IHNl dA0KIyBDT05GSUdfRkJDT05fQ0ZCNCBpcyBub3Qgc2V0DQpDT05GSUdfRkJD T05fQ0ZCOD15DQpDT05GSUdfRkJDT05fQ0ZCMTY9eQ0KQ09ORklHX0ZCQ09O X0NGQjI0PXkNCkNPTkZJR19GQkNPTl9DRkIzMj15DQojIENPTkZJR19GQkNP Tl9BRkIgaXMgbm90IHNldA0KIyBDT05GSUdfRkJDT05fSUxCTSBpcyBub3Qg c2V0DQojIENPTkZJR19GQkNPTl9JUExBTjJQMiBpcyBub3Qgc2V0DQojIENP TkZJR19GQkNPTl9JUExBTjJQNCBpcyBub3Qgc2V0DQojIENPTkZJR19GQkNP Tl9JUExBTjJQOCBpcyBub3Qgc2V0DQojIENPTkZJR19GQkNPTl9NQUMgaXMg bm90IHNldA0KIyBDT05GSUdfRkJDT05fVkdBX1BMQU5FUyBpcyBub3Qgc2V0 DQojIENPTkZJR19GQkNPTl9WR0EgaXMgbm90IHNldA0KIyBDT05GSUdfRkJD T05fSEdBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZCQ09OX0ZPTlRXSURUSDhf T05MWSBpcyBub3Qgc2V0DQpDT05GSUdfRkJDT05fRk9OVFM9eQ0KQ09ORklH X0ZPTlRfOHg4PXkNCkNPTkZJR19GT05UXzh4MTY9eQ0KQ09ORklHX0ZPTlRf U1VOOHgxNj15DQojIENPTkZJR19GT05UX1NVTjEyeDIyIGlzIG5vdCBzZXQN CiMgQ09ORklHX0ZPTlRfNngxMSBpcyBub3Qgc2V0DQojIENPTkZJR19GT05U X1BFQVJMXzh4OCBpcyBub3Qgc2V0DQojIENPTkZJR19GT05UX0FDT1JOXzh4 OCBpcyBub3Qgc2V0DQoNCiMNCiMgU291bmQNCiMNCkNPTkZJR19TT1VORD15 DQojIENPTkZJR19TT1VORF9DTVBDSSBpcyBub3Qgc2V0DQojIENPTkZJR19T T1VORF9FTVUxMEsxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX0ZVU0lP TiBpcyBub3Qgc2V0DQojIENPTkZJR19TT1VORF9DUzQyODEgaXMgbm90IHNl dA0KIyBDT05GSUdfU09VTkRfRVMxMzcwIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NPVU5EX0VTMTM3MSBpcyBub3Qgc2V0DQojIENPTkZJR19TT1VORF9FU1NT T0xPMSBpcyBub3Qgc2V0DQpDT05GSUdfU09VTkRfTUFFU1RSTz15DQojIENP TkZJR19TT1VORF9TT05JQ1ZJQkVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NP VU5EX1RSSURFTlQgaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRfTVNORENM QVMgaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRfTVNORFBJTiBpcyBub3Qg c2V0DQojIENPTkZJR19TT1VORF9WSUE4MkNYWFggaXMgbm90IHNldA0KIyBD T05GSUdfU09VTkRfT1NTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX1RW TUlYRVIgaXMgbm90IHNldA0KDQojDQojIFVTQiBzdXBwb3J0DQojDQpDT05G SUdfVVNCPW0NCiMgQ09ORklHX1VTQl9ERUJVRyBpcyBub3Qgc2V0DQpDT05G SUdfVVNCX0RFVklDRUZTPXkNCiMgQ09ORklHX1VTQl9CQU5EV0lEVEggaXMg bm90IHNldA0KIyBDT05GSUdfVVNCX1VIQ0kgaXMgbm90IHNldA0KQ09ORklH X1VTQl9VSENJX0FMVD1tDQpDT05GSUdfVVNCX09IQ0k9bQ0KQ09ORklHX1VT Ql9BVURJTz1tDQojIENPTkZJR19VU0JfQkxVRVRPT1RIIGlzIG5vdCBzZXQN CiMgQ09ORklHX1VTQl9TVE9SQUdFIGlzIG5vdCBzZXQNCkNPTkZJR19VU0Jf QUNNPW0NCkNPTkZJR19VU0JfUFJJTlRFUj1tDQpDT05GSUdfVVNCX0hJRD1t DQpDT05GSUdfVVNCX0tCRD1tDQpDT05GSUdfVVNCX01PVVNFPW0NCiMgQ09O RklHX1VTQl9XQUNPTSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfREMyWFgg aXMgbm90IHNldA0KIyBDT05GSUdfVVNCX01EQzgwMCBpcyBub3Qgc2V0DQpD T05GSUdfVVNCX1NDQU5ORVI9bQ0KIyBDT05GSUdfVVNCX01JQ1JPVEVLIGlz IG5vdCBzZXQNCiMgQ09ORklHX1VTQl9JQk1DQU0gaXMgbm90IHNldA0KIyBD T05GSUdfVVNCX09WNTExIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9EU0JS IGlzIG5vdCBzZXQNCkNPTkZJR19VU0JfREFCVVNCPW0NCkNPTkZJR19VU0Jf UExVU0I9bQ0KQ09ORklHX1VTQl9QRUdBU1VTPW0NCkNPTkZJR19VU0JfTkVU MTA4MD1tDQojIENPTkZJR19VU0JfVVNTNzIwIGlzIG5vdCBzZXQNCg0KIw0K IyBVU0IgU2VyaWFsIENvbnZlcnRlciBzdXBwb3J0DQojDQojIENPTkZJR19V U0JfU0VSSUFMIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9SSU81MDAgaXMg bm90IHNldA0KDQojDQojIEtlcm5lbCBoYWNraW5nDQojDQojIENPTkZJR19N QUdJQ19TWVNSUSBpcyBub3Qgc2V0DQojIENPTkZJR19LREIgaXMgbm90IHNl dA0KIyBDT05GSUdfS0FMTFNZTVMgaXMgbm90IHNldA0KIyBDT05GSUdfRlJB TUVfUE9JTlRFUiBpcyBub3Qgc2V0DQo= --1296032289-1045275365-981579524=:20195-- From owner-linux-xfs@oss.sgi.com Wed Feb 7 13:20:35 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 13:20:26 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:40035 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 7 Feb 2001 13:20:06 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA01869 for ; Wed, 7 Feb 2001 13:20:05 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA69317; Wed, 7 Feb 2001 15:18:49 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f17LHne10106; Wed, 7 Feb 2001 15:17:49 -0600 Message-ID: <3A81BB7C.D887E1E8@thebarn.com> Date: Wed, 07 Feb 2001 15:17:49 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: "Chris 'Chipper' Chiapusio" CC: linux-xfs@oss.sgi.com Subject: Re: Unresolved Symbols problem w/ 2.4.1-XFS cvs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Chris 'Chipper' Chiapusio wrote: try turning off CONFIG_MODVERSIONS > I've been trying to get this going for days now. I've read the list > archives, checked Documentation/Changes and ensured that all my tools are > up to date. I've done cp .config ..;make mrproper;cp ../.config .;make > oldconfig; make dep && make clean && make bzlilo && make modules && make > modules_install > > I've updated my cvs tree repeatedly and I still cannot build a kernel that > doesn have Unresolved symbols. My system is the RH7-XFS install, I've > changed /usr/include/{asm,include,pcmcia} to point to the appropriate > directories in my source tree (symlinked ala /usr/src/linux) > > and the last thing I can think of that I changed in an effort to make it > all work is: > [root@fury linux]# grep gcc Makefile > HOSTCC = kgcc > #CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 > CC = $(CROSS_COMPILE)kgcc > [root@fury linux]# > > the kernel builds and is even bootable, but no modules work. what in the > world have I missed? I've even nuked my source tree and re-downloaded > from CVS, reconfigured from scratch. > > just on the off chance that I'm configuring something foolishly I've > attached my .config file for examination. > > Thanks in advance, > Chipper > > PS. this is on a Toshiba Laptop. > ------ > Please encrypt anything important. > PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D > > ------------------------------------------------------------------------ > Name: 241 > 241 Type: Plain Text (TEXT/PLAIN) > Encoding: BASE64 -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Feb 7 13:41:55 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 13:41:46 -0800 Received: from PIERRE.MIT.EDU ([18.77.0.109]:35854 "EHLO pierre.mit.edu") by oss.sgi.com with ESMTP id ; Wed, 7 Feb 2001 13:41:32 -0800 Received: from localhost (gelinas@localhost) by pierre.mit.edu (8.9.3/8.9.3) with ESMTP id QAA03209; Wed, 7 Feb 2001 16:41:09 -0500 (EST) X-Authentication-Warning: pierre.mit.edu: gelinas owned process doing -bs Date: Wed, 7 Feb 2001 16:41:09 -0500 (EST) From: "J. Maynard Gelinas" X-Sender: To: Keith Owens cc: Subject: Re: CVS 2.4.1-XFS module support broken? In-Reply-To: <12041.981165709@ocs3.ocs-net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I followed these instructions and got a successful kernel build. Thanks for the tip! --M On Sat, 3 Feb 2001, Keith Owens wrote: > On Fri, 2 Feb 2001 20:07:11 -0500 (EST), > "J. Maynard Gelinas" wrote: > >Last login: Fri Feb 2 17:03:57 2001 from ctpjaguar.mit.edu > >[root@ctpraid1 /root]# grep printk /proc/ksyms > >c011446c printk_R__ver_printk > > You have been bitten by the broken kernel makefiles. This is not an > XFS problem, it is a generic kernel bug. > > http://www.tux.org/lkml/#s8-8 > > From owner-linux-xfs@oss.sgi.com Wed Feb 7 14:24:17 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 14:23:57 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:52761 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 7 Feb 2001 14:23:49 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id OAA23496 for ; Wed, 7 Feb 2001 14:22:46 -0800 (PST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id JAA21867; Thu, 8 Feb 2001 09:22:25 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Chris 'Chipper' Chiapusio" cc: linux-xfs@oss.sgi.com Subject: Re: Unresolved Symbols problem w/ 2.4.1-XFS cvs In-reply-to: Your message of "Wed, 07 Feb 2001 15:58:44 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Feb 2001 09:22:24 +1100 Message-ID: <20435.981584544@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 7 Feb 2001 15:58:44 -0500 (EST), "Chris 'Chipper' Chiapusio" wrote: >I've been trying to get this going for days now. I've read the list >archives, checked Documentation/Changes and ensured that all my tools are >up to date. I've done cp .config ..;make mrproper;cp ../.config .;make >oldconfig; make dep && make clean && make bzlilo && make modules && make >modules_install Which should give you a clean build, even with the makefile bugs and modversions turned on. You have not said what errors you are getting which makes it difficult to see what is wrong. From owner-linux-xfs@oss.sgi.com Wed Feb 7 17:46:58 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 17:46:49 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36411 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 7 Feb 2001 17:46:26 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA07617 for ; Wed, 7 Feb 2001 17:55:34 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA89329 for linux-xfs@oss.sgi.com; Thu, 8 Feb 2001 12:44:54 +1100 (EST) Date: Thu, 8 Feb 2001 12:44:54 +1100 (EST) From: Nathan Scott Message-Id: <200102080144.MAA89329@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Feb 5 13:46:04 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:84955a cmd/xfstests/tools/auto-qa - 1.6 - with recent changes to quota configure.in we were installing to the wrong spot. Date: Wed Feb 7 17:43:21 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:85193a cmd/quota/quotaon.c - 1.8 - messages re changes in xfs quota state are inappropriate at default "verbose" level since most distros run quotaon/off with -v by default. this stuff is very handy however, so just move it to a higher verbosity level. From owner-linux-xfs@oss.sgi.com Wed Feb 7 22:38:22 2001 Received: by oss.sgi.com id ; Wed, 7 Feb 2001 22:38:12 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:37893 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Wed, 7 Feb 2001 22:37:49 -0800 Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.2/8.10.1) with ESMTP id f186bhb21414; Thu, 8 Feb 2001 00:37:43 -0600 (CST) Message-ID: <3A823EB1.10E12173@thebarn.com> Date: Thu, 08 Feb 2001 00:37:37 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: hhp@unitycode.org CC: linux-xfs@oss.sgi.com Subject: Re: GCC 2.95.x and stalled processes [PATCH] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Hong H. Pham" wrote: Thanks for the patch. I'll try to get this integrated in the next day or so. > I have tracked down the probable cause for processes hanging when acting > on an XFS filesystem, running on a system with a kernel compiled with > GCC 2.95.x. I have included a patch that seems to correct this problem. > The first mention of this bug was in the following thread: > http://oss.sgi.com/projects/linux-xfs/indexed/msg01455.html > > This bug can be easily observed by untaring a large tarball on to the > XFS mount. For testing, I used the Debian base2_2.tgz tarball; it has a > good mix of large and many small files (eg. the /dev/* files). > ftp://ftp.us.debian.org:/debian/dists/potato/main/disks-i386/current/base2_2.tgz > > This bug is only triggered when compiling a kernel using GCC 2.95.x with > the -march=i686 optimization flag enabled. Using -march=i386, -march=i486, > or -march=i586 will produce a working kernel. > > In xfs_trans_ail.c, xfs_trans_push_ail() line 141, GCC 2.95.x generates > incorrect code for the following line: > > while (((restarts < XFS_TRANS_PUSH_AIL_RESTARTS) && > (XFS_LSN_CMP(lip->li_lsn, threshold_lsn) < 0))) { > > More specifically, XFS_LSN_CMP(), really a macro wrapper for the static > inline function _lsn_cmp(), defined in xfs_log.h, is inlined incorrectly > by the i686 optimizer. The resulting code causes the condition in the > while() statement to always be false. Consequently the body of the > while() statement never executes. > > Making _lsm_cmp() into a non-inlined function is a quick fix for the > problem. I don't know specifically what triggers this bug, so I can't > offer any suggestions for an elegant work around for an inlined > _lsm_cmp(). > > Cheers, > ..h > > ---- Patch Starts ---- > > diff -urN linux.orig/Makefile linux/Makefile > --- linux.orig/Makefile Thu Feb 1 12:10:24 2001 > +++ linux/Makefile Wed Feb 7 13:39:22 2001 > @@ -29,7 +29,7 @@ > #comment out this line if compiling on RH 7.0 > #CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 > # AND uncomment the following line > -CC = $(CROSS_COMPILE)kgcc > +CC = $(CROSS_COMPILE)gcc > CPP = $(CC) -E > AR = $(CROSS_COMPILE)ar > NM = $(CROSS_COMPILE)nm > diff -urN linux.orig/fs/xfs/xfs_log.h linux/fs/xfs/xfs_log.h > --- linux.orig/fs/xfs/xfs_log.h Tue Nov 14 18:40:34 2000 > +++ linux/fs/xfs/xfs_log.h Wed Feb 7 13:30:17 2001 > @@ -50,7 +50,8 @@ > * By comparing each compnent, we don't have to worry about extra > * endian issues in treating two 32 bit numbers as one 64 bit number > */ > -static inline xfs_lsn_t _lsn_cmp(xfs_lsn_t lsn1, xfs_lsn_t lsn2, xfs_arch_t arch) > + > +static inline xfs_lsn_t _lsn_cmp_inline(xfs_lsn_t lsn1, xfs_lsn_t lsn2, xfs_arch_t arch) > { > if (CYCLE_LSN(lsn1, arch) != CYCLE_LSN(lsn2, arch)) > return (CYCLE_LSN(lsn1, arch) @@ -60,6 +61,19 @@ > > return 0; > } > + > +#define _lsn_cmp_inline(x,y,arch) _lsn_cmp(x,y,arch) > +/* > + * Unfortunately, the __i686__ or __pentiumpro__ macros do not seem to be > + * defined in gcc-2.95.x, so checking for GCC version will have to do for now. > + */ > +#ifdef __GNUC__ > +# if ((__GNUC__ == 2) && (__GNUC_MINOR__ == 95)) > +/* defined in xfs_trans_ail.c */ > +# undef _lsn_cmp > +extern xfs_lsn_t _lsn_cmp(xfs_lsn_t lsn1, xfs_lsn_t lsn2, xfs_arch_t arch); > +# endif > +#endif > > #define XFS_LSN_CMP_ARCH(x,y,arch) _lsn_cmp(x, y, arch) > #define XFS_LSN_CMP(x,y) XFS_LSN_CMP_ARCH(x,y,ARCH_NOCONVERT) > diff -urN linux.orig/fs/xfs/xfs_trans_ail.c linux/fs/xfs/xfs_trans_ail.c > --- linux.orig/fs/xfs/xfs_trans_ail.c Mon Sep 25 00:42:07 2000 > +++ linux/fs/xfs/xfs_trans_ail.c Wed Feb 7 13:30:17 2001 > @@ -59,6 +59,38 @@ > #define xfs_ail_check(a) > #endif /* XFSDEBUG */ > > +#ifdef __GNUC__ > +# if ((__GNUC__ == 2) && (__GNUC_MINOR__ == 95)) > +/* > + * Un-inlined version of _lsn_cmp(), to work around a gcc-2.95.x inlining > + * bug. This bug is only invoked by the -march=i686 flag; other > + * architecture specific optimizations, such as -march=i586, seem fine. > + * > + * I don't know where this function should belong; although the lsn macros > + * are defined in xfs_log.h, it doesn't really belong with the xlog_* > + * functions in xfs_log.c. > + * > + * HHP > + */ > +xfs_lsn_t _lsn_cmp( > + xfs_lsn_t lsn1, > + xfs_lsn_t lsn2, > + xfs_arch_t arch) > +{ > + /* copy and pasted from xfs_log.h */ > + if (CYCLE_LSN(lsn1, arch) != CYCLE_LSN(lsn2, arch)) > + return (CYCLE_LSN(lsn1, arch) + > + if (BLOCK_LSN(lsn1, arch) != BLOCK_LSN(lsn2, arch)) > + return (BLOCK_LSN(lsn1, arch) + > + return 0; > + > + /* return _lsn_cmp_inline( lsn1, lsn2, arch ); */ > +} > +# endif > +#endif > + > > /* > * This is called by the log manager code to determine the LSN -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Feb 8 01:39:33 2001 Received: by oss.sgi.com id ; Thu, 8 Feb 2001 01:39:24 -0800 Received: from david.siemens.de ([192.35.17.14]:48086 "EHLO david.siemens.de") by oss.sgi.com with ESMTP id ; Thu, 8 Feb 2001 01:39:10 -0800 X-Envelope-Sender-Is: Pavan.Burbure@blr.spcnl.co.in (at relayer david.siemens.de) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.0/8.11.0) with ESMTP id f189d7u02315 for ; Thu, 8 Feb 2001 10:39:07 +0100 (MET) Received: from titanic.blr.spcnl.co.in (titanic.blr.spcnl.co.in [132.186.64.133]) by mail3.siemens.de (8.11.1/8.11.1) with ESMTP id f189d3724452906 for ; Thu, 8 Feb 2001 10:39:04 +0100 (MET) Received: from blrm202e.blr.spcnl.co.in (blrm202e [132.186.64.102]) by titanic.blr.spcnl.co.in (8.8.8/8.8.8) with ESMTP id OAA07089 for ; Thu, 8 Feb 2001 14:16:04 +0530 (IST) Received: by blrm202e.blr.spcnl.co.in with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Feb 2001 14:29:04 +0530 Message-ID: From: Burbure Pavan To: "'linux-xfs@oss.sgi.com'" Subject: 2.4.0-SGI.XFS.0 Date: Thu, 8 Feb 2001 14:29:00 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I had downloaded the kernel version 2.4.0-SGI.XFS.0 i686 rpm. I needed the kernel-headers package of this kernel. Please let me know where I can find the old kernel rpms. Regards, Pavan From owner-linux-xfs@oss.sgi.com Thu Feb 8 04:41:53 2001 Received: by oss.sgi.com id ; Thu, 8 Feb 2001 04:41:43 -0800 Received: from [209.101.91.34] ([209.101.91.34]:45833 "EHLO mail.compro.net") by oss.sgi.com with ESMTP id ; Thu, 8 Feb 2001 04:41:31 -0800 Received: from compro.net (markh@PC120.COMPRO.NET [10.10.10.120]) by mail.compro.net (8.9.3/8.9.3) with ESMTP id JAA08743; Thu, 8 Feb 2001 09:00:15 -0500 Message-ID: <3A8295DD.DC050118@compro.net> Date: Thu, 08 Feb 2001 07:49:33 -0500 From: Mark Hounschell Reply-To: markh@compro.net Organization: Compro Computer Svcs. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: hhp@unitycode.org, linux-xfs@oss.sgi.com Subject: Re: GCC 2.95.x and stalled processes [PATCH] References: <3A823EB1.10E12173@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > > "Hong H. Pham" wrote: > > Thanks for the patch. > I'll try to get this integrated in the next day or so. > This is good news.. Will this fix also be put into the "patch" package anytime soon? -- Mark Hounschell markh@compro.net From owner-linux-xfs@oss.sgi.com Thu Feb 8 04:54:23 2001 Received: by oss.sgi.com id ; Thu, 8 Feb 2001 04:54:13 -0800 Received: from Cantor.suse.de ([213.95.15.193]:27655 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Thu, 8 Feb 2001 04:54:03 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 1B0441E0DF; Thu, 8 Feb 2001 13:54:02 +0100 (MET) Date: Thu, 8 Feb 2001 13:53:37 +0100 From: Andi Kleen To: Mark Hounschell Cc: Russell Cattelan , hhp@unitycode.org, linux-xfs@oss.sgi.com Subject: Re: GCC 2.95.x and stalled processes [PATCH] Message-ID: <20010208135337.A14856@gruyere.muc.suse.de> References: <3A823EB1.10E12173@thebarn.com> <3A8295DD.DC050118@compro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A8295DD.DC050118@compro.net>; from markh@compro.net on Thu, Feb 08, 2001 at 07:49:33AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, Feb 08, 2001 at 07:49:33AM -0500, Mark Hounschell wrote: > Russell Cattelan wrote: > > > > "Hong H. Pham" wrote: > > > > Thanks for the patch. > > I'll try to get this integrated in the next day or so. > > > This is good news.. > Will this fix also be put into the "patch" package anytime soon? Don't be so optimistic -- there was at least another long long related bug triggered in 2.95 by XFS. -Andi From owner-linux-xfs@oss.sgi.com Thu Feb 8 07:38:16 2001 Received: by oss.sgi.com id ; Thu, 8 Feb 2001 07:38:06 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:25094 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Thu, 8 Feb 2001 07:37:57 -0800 Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.2/8.10.1) with ESMTP id f18Fbpb24677; Thu, 8 Feb 2001 09:37:51 -0600 (CST) Message-ID: <3A82BD49.2476DE61@thebarn.com> Date: Thu, 08 Feb 2001 09:37:45 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: Mark Hounschell , hhp@unitycode.org, linux-xfs@oss.sgi.com Subject: Re: GCC 2.95.x and stalled processes [PATCH] References: <3A823EB1.10E12173@thebarn.com> <3A8295DD.DC050118@compro.net> <20010208135337.A14856@gruyere.muc.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Andi Kleen wrote: > On Thu, Feb 08, 2001 at 07:49:33AM -0500, Mark Hounschell wrote: > > Russell Cattelan wrote: > > > > > > "Hong H. Pham" wrote: > > > > > > Thanks for the patch. > > > I'll try to get this integrated in the next day or so. > > > > > This is good news.. > > Will this fix also be put into the "patch" package anytime soon? > > Don't be so optimistic -- there was at least another long long related bug > triggered in 2.95 by XFS. Yes our little shift bug is still lurking. I'll see if I can dig that one up also... no promises. > > > -Andi -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Feb 8 07:49:16 2001 Received: by oss.sgi.com id ; Thu, 8 Feb 2001 07:49:06 -0800 Received: from Cantor.suse.de ([213.95.15.193]:4876 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Thu, 8 Feb 2001 07:48:47 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 08D771E12A; Thu, 8 Feb 2001 16:48:46 +0100 (MET) Date: Thu, 8 Feb 2001 16:48:44 +0100 From: Andi Kleen To: Russell Cattelan Cc: Andi Kleen , Mark Hounschell , hhp@unitycode.org, linux-xfs@oss.sgi.com Subject: Re: GCC 2.95.x and stalled processes [PATCH] Message-ID: <20010208164844.A20012@gruyere.muc.suse.de> References: <3A823EB1.10E12173@thebarn.com> <3A8295DD.DC050118@compro.net> <20010208135337.A14856@gruyere.muc.suse.de> <3A82BD49.2476DE61@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A82BD49.2476DE61@thebarn.com>; from cattelan@thebarn.com on Thu, Feb 08, 2001 at 09:37:45AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, Feb 08, 2001 at 09:37:45AM -0600, Russell Cattelan wrote: > Andi Kleen wrote: > > > On Thu, Feb 08, 2001 at 07:49:33AM -0500, Mark Hounschell wrote: > > > Russell Cattelan wrote: > > > > > > > > "Hong H. Pham" wrote: > > > > > > > > Thanks for the patch. > > > > I'll try to get this integrated in the next day or so. > > > > > > > This is good news.. > > > Will this fix also be put into the "patch" package anytime soon? > > > > Don't be so optimistic -- there was at least another long long related bug > > triggered in 2.95 by XFS. > > Yes our little shift bug is still lurking. > > I'll see if I can dig that one up also... no promises. Just putting the shift into another function may also help. long long bugs seem to trigger under register pressure Just noone knows how many else are triggered by XFS in more obscure places :-/ -Andi From owner-linux-xfs@oss.sgi.com Thu Feb 8 08:25:35 2001 Received: by oss.sgi.com id ; Thu, 8 Feb 2001 08:25:26 -0800 Received: from mail11.jump.net ([206.196.91.11]:5524 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Thu, 8 Feb 2001 08:25:14 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f18GPAi24320; Thu, 8 Feb 2001 10:25:10 -0600 (CST) Message-ID: <3A82C881.2A22468C@sgi.com> Date: Thu, 08 Feb 2001 10:25:37 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Burbure Pavan CC: "'linux-xfs@oss.sgi.com'" Subject: Re: 2.4.0-SGI.XFS.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Pavan - Please see ftp://oss.sgi.com/projects/xfs/download/PreRelease-0.9/RH7.0-SGI-XFS_PR/RedHat/RPMS/ for a complete set of RPMs. SRPMs are a couple of levels above that. -Eric Burbure Pavan wrote: > > I had downloaded the kernel version 2.4.0-SGI.XFS.0 i686 rpm. I needed the > kernel-headers package of this kernel. Please let me know where I can find > the old kernel rpms. > > Regards, > Pavan From owner-linux-xfs@oss.sgi.com Thu Feb 8 08:56:16 2001 Received: by oss.sgi.com id ; Thu, 8 Feb 2001 08:55:56 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:55582 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 8 Feb 2001 08:55:36 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08858 for ; Thu, 8 Feb 2001 08:55:35 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA31736; Thu, 8 Feb 2001 10:54:19 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f18GrJe25651; Thu, 8 Feb 2001 10:53:19 -0600 Message-ID: <3A82CEFF.F748F0B2@thebarn.com> Date: Thu, 08 Feb 2001 10:53:19 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Burbure Pavan , "'linux-xfs@oss.sgi.com'" Subject: Re: 2.4.0-SGI.XFS.0 References: <3A82C881.2A22468C@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Eric Sandeen wrote: > Pavan - > > Please see > > ftp://oss.sgi.com/projects/xfs/download/PreRelease-0.9/RH7.0-SGI-XFS_PR/RedHat/RPMS/ > This iso image has those rpms ftp://oss.sgi.com/projects/xfs/download/PreRelease-0.9/iso/OLD/RH7.0-XFS-test2.iso > > for a complete set of RPMs. SRPMs are a couple of levels above that. > > -Eric > > Burbure Pavan wrote: > > > > I had downloaded the kernel version 2.4.0-SGI.XFS.0 i686 rpm. I needed the > > kernel-headers package of this kernel. Please let me know where I can find > > the old kernel rpms. > > > > Regards, > > Pavan -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Thu Feb 8 16:54:00 2001 Received: by oss.sgi.com id ; Thu, 8 Feb 2001 16:53:41 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:37725 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 8 Feb 2001 16:53:33 -0800 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA20452; Thu, 8 Feb 2001 16:52:32 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA62639; Thu, 8 Feb 2001 16:53:32 -0800 (PST) Date: Thu, 8 Feb 2001 16:53:32 -0800 (PST) Message-Id: <200102090053.QAA62639@info.engr.sgi.com> X-Pv-Incident: 814810 webPV: wobbly.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: BUG 814810 - xfs_logprint core dump To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=814810 Submitter : nathans Submitter Domain : engr Assigned Engineer : nathans Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : QA test 018 can reliably cause xfs_logprint to dump core when the usrquota mount option has been specified via MOUNT_OPTIONS, and when using an xfs_logprint binary linked with libefence. Using a binary without libefence - no core dump, so xfs_logprint likely has some questionable memory access pattern(s) in this case. [root@troppo xfstests]# gdb /usr/sbin/xfs_logprint 018.core GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `xfs_logprint /dev/hdb7'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0 0x804b662 in xlog_print_trans_buffer (ptr=0xbffff938, len=24, i=0xbffff924, num_ops=253) at log_misc.c:373 373 printf("0x%x ", (gdb) l 368 } 369 for (bucket = 0; bucket < buckets;) { 370 printf("bucket[%d - %d]: ", bucket, bucket+3); 371 for (col = 0; col < 4; col++, bucket++) { 372 if (bucket < buckets) { 373 printf("0x%x ", 374 INT_GET(agi->agi_unlinked[bucket], ARCH_CONVERT)); 375 } 376 } 377 printf("\n"); (gdb) p agi $1 = (xfs_agi_t *) 0x40116fa8 (gdb) p agi->agi_unlinked Cannot access memory at address 0x40116fd0 (gdb) p bucket $2 = 12 (gdb) p buckets $3 = 64 (gdb) p col $4 = 0 (gdb) From owner-linux-xfs@oss.sgi.com Thu Feb 8 17:49:00 2001 Received: by oss.sgi.com id ; Thu, 8 Feb 2001 17:48:42 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:32538 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 8 Feb 2001 17:48:13 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA04199 for ; Thu, 8 Feb 2001 17:47:45 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA38184 for linux-xfs@oss.sgi.com; Fri, 9 Feb 2001 12:46:26 +1100 (EST) Date: Fri, 9 Feb 2001 12:46:26 +1100 (EST) From: Nathan Scott Message-Id: <200102090146.MAA38184@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - tests Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Feb 8 16:09:18 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:85464a cmd/xfstests/050 - 1.2 - fix path to diagnostic binary (quot). Modid: 2.4.x-xfs:slinx:85489a cmd/xfstests/016 - 1.2 - tidy up the feature checking - can break in either enfd/acct quota cases. Modid: 2.4.x-xfs:slinx:85628a cmd/xfstests/018.usrquota - 1.1 - correct output for user quota mount option. cmd/xfstests/050 - 1.3 - be consistent in handling of seq.out files. cmd/xfstests/018 - 1.2 - setup the out file according to enabled mount options (dquots permute the logprint output when any form of quota is enabled). From owner-linux-xfs@oss.sgi.com Thu Feb 8 20:03:21 2001 Received: by oss.sgi.com id ; Thu, 8 Feb 2001 20:03:02 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:64068 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 8 Feb 2001 20:02:48 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA07893 for ; Thu, 8 Feb 2001 20:02:45 -0800 (PST) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA63774 for linux-xfs@oss.sgi.com; Fri, 9 Feb 2001 15:01:28 +1100 (EST) Date: Fri, 9 Feb 2001 15:01:28 +1100 (EST) From: Andrew Gildfind Message-Id: <200102090401.PAA63774@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsqa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Feb 8 20:00:02 PST 2001 Workarea: snort.melbourne.sgi.com:/home/ajag/isms/slinx The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:85899a cmd/xfstests/src/fill2attr - 1.1 - Spray randomly created/checksummed extended attributes across a filesystem. If invoked as fill2attr_check, recompute and verify checksums for extended attributes of all listed files (either on stdin or in the files specified on the command line). cmd/xfstests/src/fill2fs_check - 1.2 cmd/xfstests/src/fill2fs - 1.3 - change sum to sum -r From owner-linux-xfs@oss.sgi.com Fri Feb 9 09:58:46 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 09:58:37 -0800 Received: from [65.100.85.35] ([65.100.85.35]:63886 "EHLO localhost.localdomain") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 09:58:19 -0800 Received: from localhost (IDENT:ringram@gargoyle [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id LAA15135 for ; Fri, 9 Feb 2001 11:00:23 -0700 Date: Fri, 9 Feb 2001 11:00:23 -0700 (MST) From: Russ Ingram X-Sender: ringram@localhost.localdomain To: linux-xfs@oss.sgi.com Subject: PreRelease install over network Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing There is a bootnet image so I assume an FTP install of the RH7.0-SGI-XFS_PR is possible. Are there instructions for how to make this work somewhere. I haven't been able to find any. -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Fri Feb 9 10:27:17 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 10:27:07 -0800 Received: from mail11.jump.net ([206.196.91.11]:21905 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 10:26:52 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f19IQc526952; Fri, 9 Feb 2001 12:26:38 -0600 (CST) Message-ID: <3A84366B.D1E1E3FF@sgi.com> Date: Fri, 09 Feb 2001 12:26:51 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Russ Ingram CC: linux-xfs@oss.sgi.com Subject: Re: PreRelease install over network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russ Ingram wrote: > > There is a bootnet image so I assume an FTP install of the > RH7.0-SGI-XFS_PR is possible. Are there instructions for how to make > this work somewhere. I haven't been able to find any. I haven't tried FTP, but I think there are reports of NFS and http working so it will probably work fine. You need to create a source for everything to be installed, and make it available via FTP/HTTP/NFS. Basically, follow Red Hat's instructions: - Insert CD 1 mount /dev/cdrom /mnt/cdrom cp -var /mnt/cdrom/RedHat /location/of/disk/space umount /mnt/cdrom - Insert CD 2 mount /dev/cdrom /mnt/cdrom cp -var /mnt/cdrom/RedHat /location/of/disk/space umount /mnt/cdrom then do the same for the SGI CD - - Insert SGI CD mount /dev/cdrom /mnt/cdrom cp -var /mnt/cdrom/RedHat /location/of/disk/space umount /mnt/cdrom Do the SGI disc last, so that the installer & images & hdlist, etc all overwrite Red Hat's. Don't worry about duplicate kernel RPMs etc - the installer looks at the "hdlist" file for which RPMs to install, and it will ignore any duplicates from the Red Hat discs. Once your source is set up, it should proceed like a normal Red Hat network install. I think our bootnet disk image may not have quite as many network drivers as the standard Red Hat does, to make room for a bigger kernel. -Eric From owner-linux-xfs@oss.sgi.com Fri Feb 9 11:37:08 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 11:36:48 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:63807 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 11:36:39 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA02290 for ; Fri, 9 Feb 2001 10:26:22 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA27779; Fri, 9 Feb 2001 12:15:49 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f19IEn020364; Fri, 9 Feb 2001 12:14:49 -0600 Message-ID: <3A843399.24426EAD@thebarn.com> Date: Fri, 09 Feb 2001 12:14:49 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Russ Ingram CC: linux-xfs@oss.sgi.com Subject: Re: PreRelease install over network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russ Ingram wrote: > There is a bootnet image so I assume an FTP install of the > RH7.0-SGI-XFS_PR is possible. Are there instructions for how to make > this work somewhere. I haven't been able to find any. ftp://ftp.thebarn.com/SGI/RH7.0-SGI-XFS-withUpdates/images/bootnet.img Use the same location for you install. host:ftp.thebarn.com ftpdir: SGI/install This will install a system that is already updated. > > > -- > Russ Ingram > Gargoyle Computer Consulting > (307)742-1361 > www.gargoylecc.com -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Fri Feb 9 12:48:28 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 12:48:08 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:28521 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 12:47:53 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA09913 for ; Fri, 9 Feb 2001 12:47:53 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA764387 for ; Fri, 9 Feb 2001 14:46:37 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA13181 for ; Fri, 9 Feb 2001 14:46:37 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f19KjWc10736; Fri, 9 Feb 2001 14:45:32 -0600 Message-Id: <200102092045.f19KjWc10736@jen.americas.sgi.com> Date: Fri, 9 Feb 2001 14:45:32 -0600 Subject: TAKE - fix page table corruption caused by xfs To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing A 2.4.1 merge bug in the xfs tree would cause XFS to corrupt the page tables by using an uninitialzed pointer to a pte structure, because of the way this code is called in a loop it is probably pointing to an existing pte which ends up getting the wrong page pointer placed in it. This led to dropping the reference count on the wrong page, and when it hit zero we went belly up. Date: Fri Feb 9 12:44:34 PST 2001 Workarea: 128.162.184.86:/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:87201a linux/mm/vmscan.c - 1.48 - Fix a page table corruption caused by delalloc pages and swapping out of memory mapped files. Bug introduced in 2.4.1 merge. From owner-linux-xfs@oss.sgi.com Fri Feb 9 14:01:29 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 14:01:19 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:29046 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 14:01:01 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA01359 for ; Fri, 9 Feb 2001 14:00:00 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA767673 for ; Fri, 9 Feb 2001 15:59:45 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA29108 for ; Fri, 9 Feb 2001 15:59:45 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f19LwdA19497; Fri, 9 Feb 2001 15:58:39 -0600 Message-Id: <200102092158.f19LwdA19497@jen.americas.sgi.com> Date: Fri, 9 Feb 2001 15:58:39 -0600 Subject: TAKE - fix a deadlock in high memory situations To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Feb 9 13:58:35 PST 2001 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:87215a linux/fs/xfs/xfs_iget.c - 1.130 - Pass flag to vn_alloc to indicate if we are within a transaction or not linux/fs/xfs/linux/xfs_vnode.c - 1.47 - Use PF_MEMALLOC around a get_empty_inode call to avoid calling back into the filesystem again under memory pressure, this call was happening out of a transaction with locked resources, and we had a deadlock case. linux/fs/xfs/linux/xfs_vnode.h - 1.15 - Add flag to vn_alloc to indicate if we are within a transaction or not From owner-linux-xfs@oss.sgi.com Fri Feb 9 14:31:48 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 14:31:38 -0800 Received: from [65.100.85.34] ([65.100.85.34]:49792 "EHLO roujin.gargoylecc.com") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 14:31:26 -0800 Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [65.100.85.34]) by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id GAA08486; Sat, 10 Feb 2001 06:42:45 -0700 Date: Sat, 10 Feb 2001 06:42:45 -0700 (MST) From: Russel Ingram To: Russell Cattelan cc: linux-xfs@oss.sgi.com Subject: Re: PreRelease install over network In-Reply-To: <3A843399.24426EAD@thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 9 Feb 2001, Russell Cattelan wrote: > Date: Fri, 09 Feb 2001 12:14:49 -0600 > From: Russell Cattelan > To: Russ Ingram > Cc: linux-xfs@oss.sgi.com > Subject: Re: PreRelease install over network > > Russ Ingram wrote: > > > There is a bootnet image so I assume an FTP install of the > > RH7.0-SGI-XFS_PR is possible. Are there instructions for how to make > > this work somewhere. I haven't been able to find any. > > ftp://ftp.thebarn.com/SGI/RH7.0-SGI-XFS-withUpdates/images/bootnet.img > > Use the same location for you install. > host:ftp.thebarn.com > ftpdir: SGI/install > This will install a system that is already updated. > > Very cool. I was actually in the process of creating an ftp site of my own to do just that based on your previous message. This will save me some trouble. Thanx. Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Fri Feb 9 15:17:08 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 15:16:49 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:54029 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 15:16:20 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA10718 for ; Fri, 9 Feb 2001 15:15:18 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA69020; Fri, 9 Feb 2001 17:15:03 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f19NE3028595; Fri, 9 Feb 2001 17:14:03 -0600 Message-ID: <3A8479BA.51BC5B03@thebarn.com> Date: Fri, 09 Feb 2001 17:14:02 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Russel Ingram CC: linux-xfs@oss.sgi.com Subject: Re: PreRelease install over network References: Content-Type: multipart/mixed; boundary="------------ACDC3B9811437F179D1B8988" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------ACDC3B9811437F179D1B8988 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Russel Ingram wrote: > On Fri, 9 Feb 2001, Russell Cattelan wrote: > > > Date: Fri, 09 Feb 2001 12:14:49 -0600 > > From: Russell Cattelan > > To: Russ Ingram > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: PreRelease install over network > > > > Russ Ingram wrote: > > > > > There is a bootnet image so I assume an FTP install of the > > > RH7.0-SGI-XFS_PR is possible. Are there instructions for how to make > > > this work somewhere. I haven't been able to find any. > > > > ftp://ftp.thebarn.com/SGI/RH7.0-SGI-XFS-withUpdates/images/bootnet.img > > > > Use the same location for you install. > > host:ftp.thebarn.com > > ftpdir: SGI/install > > This will install a system that is already updated. > > > > > > Very cool. I was actually in the process of creating an ftp site of my > own to do just that based on your previous message. This will save me > some trouble. Thanx. If your interested this script is what I use to generate that dir. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. --------------ACDC3B9811437F179D1B8988 Content-Type: application/x-perl; name="updateCD.pl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="updateCD.pl" #!/usr/bin/perl # rsync and genhdlist must be installed before running this script. # gendhlist is part of the anoconda-runtime paackage. # rsync is it's own package. use strict; use Data::Dumper; use File::Find (); # for the convenience of &wanted calls, including -eval statements: use vars qw/*name *dir *prune/; *name = *File::Find::name; *dir = *File::Find::dir; *prune = *File::Find::prune; my $RHVERSION="7.0"; my $ARCH="i386"; my $LANG="en"; # The next three lines must be changed. my $RHROOT = "/export/hole/redhat/redhat-${RHVERSION}"; my $DESTDIR = "/export/blam/FULL"; my $SGIROOT = '/build2/rh7-sgi-installer/sgiInstall'; # The following command will set up RHROOT and SGIROOT # rsync --exclude redhat-6.2 --delete -av ftp.borg.umn.edu::ftp/redhat/ $RHROOT # /rsync --delete -aLv oss.sgi.com::xfsftp/SGI-XFS-latest/ $SGIROOT my $genhdlist = '/usr/lib/anaconda-runtime/genhdlist'; # Note: This script works by using a keyed hash. # Each rpm is keyed into the hash my NAME and ARCHITECTURE # The following list of directories must be in order # of oldest rpms to newest rpms. # Each time a newer version of an rpm is found it # knocks the old one of the hash and puts it on a # list to be deleted. my @rpmdirs = ("$RHROOT/$ARCH/$LANG/RedHat/RPMS", "$RHROOT/updates/i386", "$RHROOT/updates/i586", "$RHROOT/updates/i686", "$SGIROOT/RedHat/RPMS"); my @rpms; my %rpmkeys; my @delete = (); #print Dumper($rpmdirs); $dir = "$DESTDIR/RedHat/RPMS"; if ( ! -d $dir ){ system("mkdir -p $DESTDIR/RedHat/RPMS/"); } else { File::Find::find({wanted => \&wanted}, $dir); foreach my $rpm (@rpms){ my $rpmname = `rpm --queryformat "%{NAME}%{ARCH}" -qp $rpm`; # seed the list so we know where the conflicts are and which onces to delete $rpmkeys{$rpmname}->{'name'} = $rpm; } } foreach my $dir (@rpmdirs){ @rpms = (); print "Looking in $dir\n"; File::Find::find({wanted => \&wanted}, $dir); foreach my $rpm (@rpms){ my $rpmname = `rpm --queryformat "%{NAME}%{ARCH}" -qp $rpm`; # print "$rpm -> $rpmname\n"; if($rpmkeys{$rpmname}->{'name'}){ my @b1 = split('/',$rpmkeys{$rpmname}->{'name'}); my @b2 = split('/',$rpm); if (!($b1[$#b1] eq $b2[$#b2])){ push(@delete,$b1[$#b1]); } } $rpmkeys{$rpmname}->{'name'} = $rpm; } } foreach my $del (@delete){ print "deleting $DESTDIR/RedHat/RPMS/$del\n"; unlink ("$DESTDIR/RedHat/RPMS/$del") || warn "$! $DESTDIR/RedHat/RPMS/$del\n"; } my $cmd = "rsync -v "; foreach my $rpmcp (keys(%rpmkeys)){ # print "$rpmcp -> $rpmkeys{$rpmcp}\n"; # print "$rpmkeys{$rpmcp}\n"; $cmd = $cmd . $rpmkeys{$rpmcp}->{'name'} . " "; } $cmd = $cmd . "$DESTDIR/RedHat/RPMS/"; #print "$cmd\n"; my $ret; $ret = system($cmd); #print "Ret $ret $cmd\n"; $cmd = "rsync -aLv $SGIROOT/images $SGIROOT/dosutils $DESTDIR/"; $ret = system($cmd); #print "Ret $ret $cmd\n"; $cmd = "rsync -aLv --exclude hdlist $SGIROOT/RedHat/base $DESTDIR/RedHat/"; $ret = system($cmd); #print "Ret $ret $cmd\n"; $cmd = "$genhdlist $DESTDIR"; $ret = system($cmd); print "Ret $ret $cmd\n"; sub wanted { /^.*\.rpm\z/s && push @rpms,$name; } --------------ACDC3B9811437F179D1B8988-- From owner-linux-xfs@oss.sgi.com Fri Feb 9 15:38:19 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 15:38:10 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:53340 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 15:37:58 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id PAA06905 for ; Fri, 9 Feb 2001 15:47:13 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25289 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Sat, 10 Feb 2001 10:36:40 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA14391 for linux-xfs@oss.sgi.com; Sat, 10 Feb 2001 10:36:38 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102101036.ZM97796@wobbly.melbourne.sgi.com> Date: Sat, 10 Feb 2001 10:36:36 -0400 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: linux-xfs@oss.sgi.com Subject: (Fwd) TAKE - attribute support for XFS dump restore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing (wrong mail alias, needs to be sent here) --- Forwarded mail from Andrew Gildfind Date: Fri, 9 Feb 2001 19:21:31 +1100 (EST) From: Andrew Gildfind To: ptg@melbourne.sgi.com Subject: TAKE - attribute support for XFS dump restore Fix up attribute support for xfsdump/restore, add an attrctl_by_handle ioctl. Previous mod provided fill2attr which has been used to test this stuff, qa test is coming. Date: Thu Feb 8 23:45:14 PST 2001 Workarea: snort.melbourne.sgi.com:/home/ajag/isms/slinx The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:86403a linux/include/linux/xfs_fs.h - 1.21 add xfs_fsop_attr_handlereq add XFS_IOC_ATTRCTL_BY_HANDLE linux/fs/xfs/linux/xfs_ioctl.c - 1.28 add xfs_attrctl_by_handle (XFS_IOC_ATTRCTL_BY_HANDLE) linux/include/linux/attributes.h - 1.4 cmd/attr/include/attributes.h - 1.2 update IRIX_OP_LIST comment cmd/attr/libattr/attr.c - 1.3 remove attr_multi_by_handle, attr_list_by_handle, jdm_attr_multi, jdm_attr_list (removed from xfsprogs/libhandle/(handle.c|jdm.c) cmd/xfsdump/dump/inomap.c - 1.2 add DMEXTATTR cmd/xfsdump/dump/content.c - 1.2 replace fcntl with ioctl (XFS_IOC_FSSETXATTR) add DMEXTATTR cmd/xfsdump/dump/Makefile - 1.3 configure extended attribute support cmd/xfsdump/common/main.c - 1.2 add DMEXTATTR cmd/xfsdump/common/attr.h - 1.2 cleanup use jdm_filehandle_t jdm_fshandle_t cmd/xfsdump/common/attr.c - 1.2 add attr_list_by_handle, jdm_attr_list, attr_multi_by_handle, jdm_attr_multi cmd/xfsdump/restore/content.c - 1.2 replace fcntl with ioctl (XFS_IOC_FSSETXATTR) add DMEXTATTR cmd/xfsdump/restore/Makefile - 1.3 configure EXTATTR, add LIBATTR cmd/xfsdump/man/man8/xfsdump.8 - 1.2 update -A description cmd/xfsprogs/include/jdm.h - 1.2 add jdm_filehandle_t export jdm_new_filehandle, jdm_delete_filehandle cmd/xfsprogs/include/handle.h - 1.2 export handle_to_fsfd() cmd/xfsprogs/include/xfs_fs.h - 1.3 add xfs_fsop_attr_handlereq add XFS_IOC_ATTRCTL_BY_HANDLE cmd/xfsprogs/libhandle/Makefile - 1.3 configure EXTATTR cmd/xfsprogs/libhandle/handle.c - 1.2 add handle_to_fsfd() cmd/xfsprogs/libhandle/jdm.c - 1.2 remove jdm_attr_* ---End of forwarded mail from Andrew Gildfind -- Nathan From owner-linux-xfs@oss.sgi.com Fri Feb 9 15:52:39 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 15:52:20 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13406 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 15:51:59 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA09830 for ; Fri, 9 Feb 2001 16:01:13 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA768405 for ; Fri, 9 Feb 2001 17:49:45 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA15025 for ; Fri, 9 Feb 2001 17:49:44 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f19NmcY21351; Fri, 9 Feb 2001 17:48:38 -0600 Message-Id: <200102092348.f19NmcY21351@jen.americas.sgi.com> Date: Fri, 9 Feb 2001 17:48:38 -0600 Subject: TAKE - more pagebuf cleanup and fix a potential bug To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I did not like the way we cleared delalloc state on a page before getting an extra reference on it. That's one line, most of this is dead code cleanup. Date: Fri Feb 9 15:48:44 PST 2001 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:87227a linux/include/linux/page_buf.h - 1.73 - Changed prototype for _pagebuf_lookup_pages(), remove some unused definitions. linux/fs/pagebuf/page_buf.c - 1.52 - Remove unused code from the _pagebuf_lookup_pages() function, it had the capability to populate partial pagebufs, this is not used, and is somewhat obscure code. linux/fs/pagebuf/page_buf_io.c - 1.50 - In the read_full_page path always attach buffer heads to pages, this appears to help. change calls to _pagebuf_lookup_pages to remove deleted parameters, use page_cache calls instead of direct page calls, and in the delalloc conversion path, take a reference on the page being converted before removing the delalloc flag. From owner-linux-xfs@oss.sgi.com Fri Feb 9 16:19:40 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 16:19:20 -0800 Received: from [65.100.85.35] ([65.100.85.35]:65425 "EHLO localhost.localdomain") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 16:19:06 -0800 Received: from localhost (IDENT:ringram@gargoyle [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id RAA18367; Fri, 9 Feb 2001 17:21:24 -0700 Date: Fri, 9 Feb 2001 17:21:24 -0700 (MST) From: Russ Ingram X-Sender: ringram@localhost.localdomain To: Russell Cattelan cc: linux-xfs@oss.sgi.com Subject: Re: PreRelease install over network In-Reply-To: <3A8479BA.51BC5B03@thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 9 Feb 2001, Russell Cattelan wrote: > Russel Ingram wrote: > > > On Fri, 9 Feb 2001, Russell Cattelan wrote: > > > > > Date: Fri, 09 Feb 2001 12:14:49 -0600 > > > From: Russell Cattelan > > > To: Russ Ingram > > > Cc: linux-xfs@oss.sgi.com > > > Subject: Re: PreRelease install over network > > > > > > Russ Ingram wrote: > > > > > > > There is a bootnet image so I assume an FTP install of the > > > > RH7.0-SGI-XFS_PR is possible. Are there instructions for how to make > > > > this work somewhere. I haven't been able to find any. > > > > > > ftp://ftp.thebarn.com/SGI/RH7.0-SGI-XFS-withUpdates/images/bootnet.img > > > > > > Use the same location for you install. > > > host:ftp.thebarn.com > > > ftpdir: SGI/install > > > This will install a system that is already updated. > > > > > > > > > > Very cool. I was actually in the process of creating an ftp site of my > > own to do just that based on your previous message. This will save me > > some trouble. Thanx. > > If your interested this script is what I use to generate that dir. > > > -- > Russell Cattelan > -- > Digital Elves inc. -- Currently on loan to SGI > Linux XFS core developer. > > > Thanks again. That will be helpful as well. I have one more problem yet with this FTP install, though. I get as far as where the installer is ready to start anaconda and it gives me a couple of "Terminated" messages and complains of a missing library. The library in question is libdl.so.2. Any ideas? Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Fri Feb 9 16:33:40 2001 Received: by oss.sgi.com id ; Fri, 9 Feb 2001 16:33:20 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:41503 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 9 Feb 2001 16:32:58 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA19517 for ; Fri, 9 Feb 2001 16:31:55 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA05149 for linux-xfs@oss.sgi.com; Sat, 10 Feb 2001 11:31:39 +1100 (EST) Date: Sat, 10 Feb 2001 11:31:39 +1100 (EST) From: Nathan Scott Message-Id: <200102100031.LAA05149@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - commands Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Feb 9 16:31:03 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:87233a cmd/xfsdump/VERSION - 1.3 cmd/xfsdump/doc/CHANGES - 1.3 cmd/xfsprogs/doc/CHANGES - 1.3 cmd/xfsprogs/VERSION - 1.3 - bump minor version number after work for extended attributes. From owner-linux-xfs@oss.sgi.com Sat Feb 10 13:47:31 2001 Received: by oss.sgi.com id ; Sat, 10 Feb 2001 13:47:21 -0800 Received: from [65.100.85.34] ([65.100.85.34]:11140 "EHLO roujin.gargoylecc.com") by oss.sgi.com with ESMTP id ; Sat, 10 Feb 2001 13:47:06 -0800 Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [65.100.85.34]) by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id FAA06940; Sun, 11 Feb 2001 05:56:26 -0700 Date: Sun, 11 Feb 2001 05:56:26 -0700 (MST) From: Russel Ingram To: ringram@gargoylecc.com cc: linux-xfs@oss.sgi.com Subject: Re: PreRelease install over network In-Reply-To: <3A8479BA.51BC5B03@thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Never mind the last message about libdl.so.2. I figured it out. I was trying to install with only 32M of memory and it couldn't load everything it needed. Duh. :-P Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Sat Feb 10 17:45:13 2001 Received: by oss.sgi.com id ; Sat, 10 Feb 2001 17:45:03 -0800 Received: from usr-mtp-31.sensible-net.com ([208.18.226.31]:21257 "EHLO www.esplot.com") by oss.sgi.com with ESMTP id ; Sat, 10 Feb 2001 17:44:37 -0800 Received: from esplot.com (IDENT:jeffh@blast [192.180.82.4]) by www.esplot.com (8.9.3/8.9.3) with ESMTP id UAA16437 for ; Sat, 10 Feb 2001 20:44:21 -0500 Message-ID: <3A85EE79.AB708A22@esplot.com> Date: Sat, 10 Feb 2001 20:44:25 -0500 From: Jeff Hengesbach X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kgcc now required ?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have just updated from cvs as I went to "make bzImage" I received: "make: kgcc: Command not found" Is kgcc now required? If so what version. I'm running RH6.2 TIA, Jeff H From owner-linux-xfs@oss.sgi.com Sat Feb 10 17:49:33 2001 Received: by oss.sgi.com id ; Sat, 10 Feb 2001 17:49:23 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:262 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Sat, 10 Feb 2001 17:49:15 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id CAA10863; Sun, 11 Feb 2001 02:48:40 +0100 Date: Sun, 11 Feb 2001 02:48:40 +0100 From: sooo lame To: Jeff Hengesbach Cc: linux-xfs@oss.sgi.com Subject: Re: kgcc now required ?? Message-ID: <20010211024840.A10579@main.braxis.co.uk> References: <3A85EE79.AB708A22@esplot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A85EE79.AB708A22@esplot.com>; from jeffh@esplot.com on Sat, Feb 10, 2001 at 08:44:25PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sat, Feb 10, 2001 at 08:44:25PM -0500, Jeff Hengesbach wrote: > Is kgcc now required? If so what version. I'm running RH6.2 it's not required, but guys at SGI switched to RH7 and it's kgcc and think that others also did ;-) just edit Makefile in linux/ comment line with kgcc out and uncomment line with gcc -V 2.91.66 Regards - kszysiu From owner-linux-xfs@oss.sgi.com Sat Feb 10 23:17:14 2001 Received: by oss.sgi.com id ; Sat, 10 Feb 2001 23:17:05 -0800 Received: from [165.246.96.224] ([165.246.96.224]:43401 "EHLO super.inha.ac.kr") by oss.sgi.com with ESMTP id ; Sat, 10 Feb 2001 23:16:44 -0800 Received: from lightcse (light-cse.inha.ac.kr [165.246.96.233]) by super.inha.ac.kr (8.9.3/8.9.3) with SMTP id QAA20360 for ; Sun, 11 Feb 2001 16:13:42 +0900 (KST) From: =?ks_c_5601-1987?B?sejAz7/r?= To: Subject: how to use pwrite(...)? Date: Sun, 11 Feb 2001 16:18:14 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing SGl+DQoNCkkgaGFkIGJlZW4gdXBncmFkZSBteUxpbnV4IHRvIExpbnV4IDcuMCAtIGtlcm5lbCAy LjQgLSB4ZnMgZmlsZXN5c3RlbS4uLg0KDQpCZWNhdXNlIGkgbXVzdCB1c2UgcHdyaXRlKC4uLikg aW4gbXkgcHJvZ3JhbS4uLg0KDQpidXQuLi4gYXJndW1lbnQgb2YgcHdyaXRlIC4uLiBvZmZfdCBp cyA0Ynl0ZXMuLi4NCg0Kc28gd2hlbiBpIG1ha2luZyBhIGZpbGUgLi4uIHRoZSBtYXhpbXVtIHNp emUgaXMgNEdCLi4uVC5UDQoNCmhvdyB0byBncm93IG15IG1heGltdW0gZmlsZXNpemUgdXB0byAy MEdCIHVzaW5nIHB3cml0ZSguLi4pDQoNCg== From owner-linux-xfs@oss.sgi.com Sat Feb 10 23:21:04 2001 Received: by oss.sgi.com id ; Sat, 10 Feb 2001 23:20:55 -0800 Received: from cortex.ama.ttuhsc.edu ([168.49.129.1]:42505 "EHLO cortex.ama.ttuhsc.edu") by oss.sgi.com with ESMTP id ; Sat, 10 Feb 2001 23:20:39 -0800 Received: (from sean@localhost) by cortex.ama.ttuhsc.edu (8.10.2/8.10.2) id f1B7JwZ09026; Sun, 11 Feb 2001 01:19:58 -0600 (CST) Date: Sun, 11 Feb 2001 01:19:58 -0600 (CST) From: Sean Dougherty To: linux-xfs@oss.sgi.com Subject: xfs causes machine to freeze Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have run into a strange problem testing xfs. My test is quite simple, take 2 drives make them both xfs, create dummy data (eg tar /usr into usr.tar) create more dummy data so that some of the individual tar files are greater than 2G, when I have about 10G total data do the following: loop forever tar dummy data (both large and small files) from one xfs drive to the other delete all the data on the 2nd xfs drive continue loop After a while, sometimes in the middle of the first loop, other times after 6 loops, or 15 loops, or 1.5 days worth of loops the whole machine freezes. (one test machine actually turns off). I have had this happen on pentiums, pentium II, and Athlons. I test with maxtor drives mostly though I can get the same thing happening with western digital drives. The ide controlers include VIA vt82xxxx and Intel PIIx and Promise PDC202xxx. I have been squeezing the most speed out of the IDE stuff for a while, meaning compiling into the kernel the right drivers, and turning on multicount (multi_mode) and DMA. These kernel patches have worked in the past (meaning same test, just no >2G files) using ext2. The xfs file systems are corrupted after the freeze. After the reboot it is necessary to umount the files systems and xfs_repair them. I am currently using the .9 pre-release. I have tried with multi_mode off, with dma off. I have tried with building the file system using mkfs -t xfs -l internal,size=16000b -f /dev/hdg1 and mkfs -t xfs -l internal,size=16000b -d unwritten=0 -f /dev/hdg1 and mkfs -t xfs -l size=8000b -d unwritten=0 -f /dev/hdg1 and mkfs -t xfs -d unwritten=0 -f /dev/hdg1 I am hoping someone recognizes this, and can point me in the right direction. I have a hunch it is something in my making of the kernel, because prior to sending this email, I downloaded the install RPM, and installed the SGI-REDHAT7-XFS default system on yet another test machine--without making any changes at all it seems to be running my little stress test the longest (this test machine also has brand new drives/mother board/memory/etc) This email is long enough as it is, but if seeing the .config or my turning on any xfs debugging would help anyone help me...please let me know. Thank you Sean Dougherty Manager of way too much TTUHSC At Amarillo sean@ama.ttuhsc.edu From owner-linux-xfs@oss.sgi.com Sun Feb 11 07:07:29 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 07:07:20 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:53117 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 07:07:03 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA00701 for ; Sun, 11 Feb 2001 07:07:00 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA779695; Sun, 11 Feb 2001 09:05:34 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA97928; Sun, 11 Feb 2001 09:05:33 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1BF3lH19265; Sun, 11 Feb 2001 09:03:48 -0600 Message-Id: <200102111503.f1BF3lH19265@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: sooo lame cc: Jeff Hengesbach , linux-xfs@oss.sgi.com Subject: Re: kgcc now required ?? In-Reply-To: Message from sooo lame of "Sun, 11 Feb 2001 02:48:40 +0100." <20010211024840.A10579@main.braxis.co.uk> Date: Sun, 11 Feb 2001 09:03:47 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Sat, Feb 10, 2001 at 08:44:25PM -0500, Jeff Hengesbach wrote: > > > Is kgcc now required? If so what version. I'm running RH6.2 > > it's not required, but guys at SGI switched to RH7 and it's kgcc > and think that others also did ;-) > > just edit Makefile in linux/ comment line with kgcc out and uncomment line > with gcc -V 2.91.66 > > Regards > > - kszysiu I suspect I did this in the 2.4.1 merge, I am doing my development on a redhat 7 platform. kgcc is no longer a redhat specific thing though, I think Mandrake is using it now too. If you were successfully compiling xfs beforehand you should still be able to do so using the above suggestion. Steve From owner-linux-xfs@oss.sgi.com Sun Feb 11 07:17:19 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 07:17:09 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:20752 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 07:16:45 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA22326 for ; Sun, 11 Feb 2001 07:15:43 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA779973; Sun, 11 Feb 2001 09:15:27 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA58796; Sun, 11 Feb 2001 09:15:27 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1BFDf919327; Sun, 11 Feb 2001 09:13:41 -0600 Message-Id: <200102111513.f1BFDf919327@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: =?ks_c_5601-1987?B?sejAz7/r?= cc: linux-xfs@oss.sgi.com Subject: Re: how to use pwrite(...)? In-Reply-To: Message from =?ks_c_5601-1987?B?sejAz7/r?= of "Sun, 11 Feb 2001 16:18:14 +0900." Date: Sun, 11 Feb 2001 09:13:41 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing bush@super.inha.ac.kr said: >> Hi~ >> I had been upgrade myLinux to Linux 7.0 - kernel 2.4 - xfs >> filesystem... >> Because i must use pwrite(...) in my program... >> but... argument of pwrite ... off_t is 4bytes... >> so when i making a file ... the maximum size is 4GB...T.T >> how to grow my maximum filesize upto 20GB using pwrite(...) The pwrite system call takes an loff_t (64 bit value) as its file offset parameter: asmlinkage ssize_t sys_pwrite(unsigned int fd, const char * buf, size_t count, loff_t pos) This is more likely to be an issue with the glibc version in the distribution you are using. You need an LFS (large file support) enabled distribution to use this version of pwrite and other calls. Another possibility is that you are not using -D_FILE_OFFSET_BITS=64 to compile your code, look in unistd.h for the prototypes for pread and pwrite, if it looks something like this: #ifdef __USE_UNIX98 # ifndef __USE_FILE_OFFSET64 extern ssize_t pread (int __fd, void *__buf, size_t __nbytes, __off_t __offset) __THROW; extern ssize_t pwrite (int __fd, __const void *__buf, size_t __n, __off_t __offset) __THROW; # else # ifdef __REDIRECT extern ssize_t __REDIRECT (pread, (int __fd, void *__buf, size_t __nbytes, __off64_t __offset) __THROW, pread64); extern ssize_t __REDIRECT (pwrite, (int __fd, __const void *__buf, size_t __nbytes, __off64_t __offset) __THROW, pwrite64); # else # define pread pread64 # define pwrite pwrite64 # endif # endif Then you can use the above define to switch to the 64 bit versions, otherwise you may have to upgrade your glibc. Steve From owner-linux-xfs@oss.sgi.com Sun Feb 11 07:18:39 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 07:18:29 -0800 Received: from pD901EDAE.dip.t-dialin.net ([217.1.237.174]:27560 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 07:18:18 -0800 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f1BFaAW21682 for linux-xfs@oss.sgi.com; Sun, 11 Feb 2001 16:36:10 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Sun, 11 Feb 2001 16:36:10 +0100 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: data corruption after unclean shutdown, sync does not work. Message-ID: <20010211163610.A21525@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi i found a bug with the newer development kernels. i have files with data corruption after hitting the reset button. it seems that "sync" does not sync the data to disk. i made following test: cp -av /usr/src/linux/drivers/ drivers diff -r -u /usr/src/linux/drivers/ drivers/ (no differs) sync sync sync hit the reset button. after that, the diff reports about 190 (of 3134) files are different. the files have the right size, but they are only filled with null chars. xfs_bmap reports, that they have no extends. i have made the test with some older kernels: the last working kernel is from feb, 4th 14:00 CET. the first buggy kernel is from feb, 6th 0:50 CET. the tests were made on a xfs root partition (ide drive, no kio). and i notice that on the buggy kernels, when the (root) fs is marked readonly while shutdown, there were more diskactivity than on the good ones. the data is only written to disk while marking readonly? hope that helps. utz From owner-linux-xfs@oss.sgi.com Sun Feb 11 08:59:21 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 08:59:13 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57373 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 08:58:53 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA08074 for ; Sun, 11 Feb 2001 09:08:10 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA779466; Sun, 11 Feb 2001 10:57:34 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA65227; Sun, 11 Feb 2001 10:57:34 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1BGtm019460; Sun, 11 Feb 2001 10:55:48 -0600 Message-Id: <200102111655.f1BGtm019460@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: utz lehmann cc: linux-xfs@oss.sgi.com Subject: Re: data corruption after unclean shutdown, sync does not work. In-Reply-To: Message from utz lehmann of "Sun, 11 Feb 2001 16:36:10 +0100." <20010211163610.A21525@s2y4n2c.de> Date: Sun, 11 Feb 2001 10:55:48 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing We have been making changes in how delayed allocation data is flushed out to disk, we know it is not totally correct at the moment, looks like this is more true than I realized. As an experiment try this change, in linvfs_write_super() in fs/xfs/linux/xfs_super.c change VFS_SYNC(vfsp, SYNC_FSDATA|SYNC_BDFLUSH|SYNC_NOWAIT|SYNC_ATTR, to VFS_SYNC(vfsp, SYNC_FSDATA|SYNC_BDFLUSH|SYNC_WAIT|SYNC_ATTR, This may fix your problem, but may change the characteristics of the system in undesirable ways since write_super is getting called every few seconds and this will make it more synchronous. If this does not help then the sync activity is not finding everything and things are seriously broken. Steve > hi > > i found a bug with the newer development kernels. > > i have files with data corruption after hitting the reset button. > it seems that "sync" does not sync the data to disk. > > i made following test: > > > cp -av /usr/src/linux/drivers/ drivers > diff -r -u /usr/src/linux/drivers/ drivers/ (no differs) > sync > sync > sync > > hit the reset button. > > after that, the diff reports about 190 (of 3134) files are different. > > the files have the right size, but they are only filled with null chars. > xfs_bmap reports, that they have no extends. > > i have made the test with some older kernels: > > the last working kernel is from feb, 4th 14:00 CET. > the first buggy kernel is from feb, 6th 0:50 CET. > > the tests were made on a xfs root partition (ide drive, no kio). > > and i notice that on the buggy kernels, when the (root) fs is marked > readonly while shutdown, there were more diskactivity than on the good ones. > the data is only written to disk while marking readonly? > > > hope that helps. > > > utz From owner-linux-xfs@oss.sgi.com Sun Feb 11 09:03:41 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 09:03:32 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:8206 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 09:03:20 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14RztD-0007jf-00; Sun, 11 Feb 2001 18:02:19 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14Rzt8-0007bR-00; Sun, 11 Feb 2001 18:02:14 +0100 Date: Sun, 11 Feb 2001 18:02:14 +0100 From: Jens Axboe To: Steve Lord Cc: sooo lame , Jeff Hengesbach , linux-xfs@oss.sgi.com Subject: Re: kgcc now required ?? Message-ID: <20010211180214.J16362@suse.de> References: <200102111503.f1BF3lH19265@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200102111503.f1BF3lH19265@jen.americas.sgi.com>; from lord@sgi.com on Sun, Feb 11, 2001 at 09:03:47AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, Feb 11 2001, Steve Lord wrote: > > > Is kgcc now required? If so what version. I'm running RH6.2 > > > > it's not required, but guys at SGI switched to RH7 and it's kgcc > > and think that others also did ;-) > > > > just edit Makefile in linux/ comment line with kgcc out and uncomment line > > with gcc -V 2.91.66 > > > > Regards > > > > - kszysiu > > I suspect I did this in the 2.4.1 merge, I am doing my development on a > redhat 7 platform. kgcc is no longer a redhat specific thing though, I > think Mandrake is using it now too. > > If you were successfully compiling xfs beforehand you should still be able > to do so using the above suggestion. But can we at least get a decent work-around, that doesn't barf if kgcc isn't available? It seems rather silly to assume gcc is borken. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Sun Feb 11 09:08:51 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 09:08:34 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:47636 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 09:08:23 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA04401 for ; Sun, 11 Feb 2001 09:08:22 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA780005; Sun, 11 Feb 2001 11:07:05 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA03115; Sun, 11 Feb 2001 11:07:05 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1BH5IM19540; Sun, 11 Feb 2001 11:05:18 -0600 Message-Id: <200102111705.f1BH5IM19540@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Sean Dougherty cc: linux-xfs@oss.sgi.com Subject: Re: xfs causes machine to freeze In-Reply-To: Message from Sean Dougherty of "Sun, 11 Feb 2001 01:19:58 CST." Date: Sun, 11 Feb 2001 11:05:18 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing We have seen some cases where XFS deadlocks under heavy memory pressure, we end up trying to free memory from a code path which has xfs locks, the freeing of memory requires other xfs locks and sometimes a dependency between the two can cause a hang. There are changes in the current development cvs tree which may fix this, we know that it is not bug free right now, and are working on it. In the meantime, could you possibly try a kernel built from the development tree and let us know if you can hang it in the same way. Steve > I have run into a strange problem testing xfs. My test is quite simple, > take 2 drives make them both xfs, create dummy data (eg tar /usr into > usr.tar) create more dummy data so that some of the individual tar files > are greater than 2G, when I have about 10G total data do the following: > > loop forever > tar dummy data (both large and small files) from one xfs drive to the other > delete all the data on the 2nd xfs drive > continue loop > > After a while, sometimes in the middle of the first loop, other times > after 6 loops, or 15 loops, or 1.5 days worth of loops the whole machine > freezes. (one test machine actually turns off). > > I have had this happen on pentiums, pentium II, and Athlons. I test with > maxtor drives mostly though I can get the same thing happening with > western digital drives. The ide controlers include VIA vt82xxxx and > Intel PIIx and Promise PDC202xxx. I have been squeezing the most speed > out of the IDE stuff for a while, meaning compiling into the kernel the > right drivers, and turning on multicount (multi_mode) and DMA. These > kernel patches have worked in the past (meaning same test, just no >2G > files) using ext2. > > The xfs file systems are corrupted after the freeze. After the reboot it > is necessary to umount the files systems and xfs_repair them. > > I am currently using the .9 pre-release. > > I have tried with multi_mode off, with dma off. I have tried with > building the file system using > > mkfs -t xfs -l internal,size=16000b -f /dev/hdg1 > and > mkfs -t xfs -l internal,size=16000b -d unwritten=0 -f /dev/hdg1 > and > mkfs -t xfs -l size=8000b -d unwritten=0 -f /dev/hdg1 > and > mkfs -t xfs -d unwritten=0 -f /dev/hdg1 > > I am hoping someone recognizes this, and can point me in the right > direction. I have a hunch it is something in my making of the kernel, > because prior to sending this email, I downloaded the install RPM, and > installed the SGI-REDHAT7-XFS default system on yet another test > machine--without making > any changes at all it seems to be running my little stress test the > longest (this test machine also has brand new drives/mother board/memory/etc) > > This email is long enough as it is, but if seeing the .config or my > turning on any xfs debugging would help anyone help me...please let me know. > > Thank you > > Sean Dougherty > Manager of way too much > TTUHSC At Amarillo > sean@ama.ttuhsc.edu From owner-linux-xfs@oss.sgi.com Sun Feb 11 09:21:11 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 09:20:52 -0800 Received: from mail11.jump.net ([206.196.91.11]:43484 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 09:20:42 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f1BHKfV21295 for ; Sun, 11 Feb 2001 11:20:41 -0600 (CST) Message-ID: <3A86C9FC.EE891A9@sgi.com> Date: Sun, 11 Feb 2001 11:21:00 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: kgcc now required ?? References: <200102111503.f1BF3lH19265@jen.americas.sgi.com> <20010211180214.J16362@suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jens Axboe wrote: > But can we at least get a decent work-around, that doesn't barf > if kgcc isn't available? It seems rather silly to assume gcc > is borken. As of 2.4.0, the official Makefile uses: CC :=$(shell if which $(CROSS_COMPILE)kgcc > /dev/null 2>&1; then echo $(CROSS_COMPILE)kgcc; else echo $(CROSS_COMPILE)gcc; fi) -D__KERNEL__ -I$(HPATH) We should probably throw that into our tree as well... -Eric From owner-linux-xfs@oss.sgi.com Sun Feb 11 09:38:12 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 09:37:52 -0800 Received: from ns.caldera.de ([212.34.180.1]:48908 "EHLO ns.caldera.de") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 09:37:33 -0800 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id SAA11301; Sun, 11 Feb 2001 18:37:19 +0100 Date: Sun, 11 Feb 2001 18:37:19 +0100 From: Christoph Hellwig To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: kgcc now required ?? Message-ID: <20010211183719.A11057@caldera.de> References: <200102111503.f1BF3lH19265@jen.americas.sgi.com> <20010211180214.J16362@suse.de> <3A86C9FC.EE891A9@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A86C9FC.EE891A9@sgi.com>; from sandeen@sgi.com on Sun, Feb 11, 2001 at 11:21:00AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, Feb 11, 2001 at 11:21:00AM -0600, Eric Sandeen wrote: > Jens Axboe wrote: > > > But can we at least get a decent work-around, that doesn't barf > > if kgcc isn't available? It seems rather silly to assume gcc > > is borken. > > As of 2.4.0, the official Makefile uses: > > CC :=$(shell if which $(CROSS_COMPILE)kgcc > /dev/null 2>&1; then echo > $(CROSS_COMPILE)kgcc; else echo $(CROSS_COMPILE)gcc; fi) -D__KERNEL__ > -I$(HPATH) No - you seem to use some patched (-ac?) tree. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Sun Feb 11 09:54:12 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 09:54:02 -0800 Received: from nernst.chem.gla.ac.uk ([130.209.221.174]:18409 "EHLO nernst.chem.gla.ac.uk") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 09:53:46 -0800 Received: from nernst.chem.gla.ac.uk ([130.209.221.174] helo=chata.eu.org ident=asia) by nernst.chem.gla.ac.uk with smtp (Exim 2.02 #2) id 14S0gm-000790-00 for linux-xfs@oss.sgi.com; Sun, 11 Feb 2001 17:53:32 +0000 From: Slawomir Pol To: linux-xfs@oss.sgi.com Subject: Re: Unresolved Symbols problem w/ 2.4.1-XFS cvs Date: Sun, 11 Feb 2001 17:56:12 +0000 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: <01021117561202.01165@chata.eu.org> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 7 Feb 2001 15:58:44 -0500 (EST), "Chris 'Chipper' Chiapusio" wrote: >I've been trying to get this going for days now. I've read the list >archives, checked Documentation/Changes and ensured that all my tools are >up to date. I've done cp .config ..;make mrproper;cp ../.config .;make >oldconfig; make dep && make clean && make bzlilo && make modules && make >modules_install I have had the same problem. Try to do this: Compaile kernel in normal way ( with Set modversion on ). After compilation of kernel copy file /usr/src/yourkernel/System.map to /boot/System.map-2.4.1-XFS and then make symlink /boot/System.map to this file. It should help. Poluvex From owner-linux-xfs@oss.sgi.com Sun Feb 11 09:59:42 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 09:59:22 -0800 Received: from nic-31-c12-219.mn.mediaone.net ([24.31.12.219]:37640 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 09:59:14 -0800 Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130]) by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id f1BHx8c32066 for ; Sun, 11 Feb 2001 11:59:08 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <3A86E158.B61439E4@thebarn.com> Date: Sun, 11 Feb 2001 13:00:40 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: kgcc now required ?? References: <200102111503.f1BF3lH19265@jen.americas.sgi.com> <20010211180214.J16362@suse.de> <3A86C9FC.EE891A9@sgi.com> <20010211183719.A11057@caldera.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Christoph Hellwig wrote: > On Sun, Feb 11, 2001 at 11:21:00AM -0600, Eric Sandeen wrote: > > Jens Axboe wrote: > > > > > But can we at least get a decent work-around, that doesn't barf > > > if kgcc isn't available? It seems rather silly to assume gcc > > > is borken. > > > > As of 2.4.0, the official Makefile uses: > > > > CC :=$(shell if which $(CROSS_COMPILE)kgcc > /dev/null 2>&1; then echo > > $(CROSS_COMPILE)kgcc; else echo $(CROSS_COMPILE)gcc; fi) -D__KERNEL__ > > -I$(HPATH) > > No - you seem to use some patched (-ac?) tree. There has been some debate as to the best way to do this. The extra shell invocation for every file compiled could be a bit expensive. I think most people brave enough to compile their own kernel should be able to edit the Makefile and adjust the compiler line. > > > Christoph > > -- > Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Sun Feb 11 10:00:42 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 10:00:22 -0800 Received: from pD901E22C.dip.t-dialin.net ([217.1.226.44]:27817 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 10:00:11 -0800 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f1BIHmW23089; Sun, 11 Feb 2001 19:17:48 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Sun, 11 Feb 2001 19:17:47 +0100 From: utz lehmann To: Steve Lord Cc: utz lehmann , linux-xfs@oss.sgi.com Subject: Re: data corruption after unclean shutdown, sync does not work. Message-ID: <20010211191747.A23068@s2y4n2c.de> References: <200102111655.f1BGtm019460@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102111655.f1BGtm019460@jen.americas.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi same problem with the change .-( utz Steve Lord [lord@sgi.com] wrote: > > > We have been making changes in how delayed allocation data is flushed out > to disk, we know it is not totally correct at the moment, looks like this > is more true than I realized. > > As an experiment try this change, in linvfs_write_super() in > fs/xfs/linux/xfs_super.c change > > VFS_SYNC(vfsp, SYNC_FSDATA|SYNC_BDFLUSH|SYNC_NOWAIT|SYNC_ATTR, > > to > > VFS_SYNC(vfsp, SYNC_FSDATA|SYNC_BDFLUSH|SYNC_WAIT|SYNC_ATTR, > > This may fix your problem, but may change the characteristics of the system > in undesirable ways since write_super is getting called every few seconds and > this will make it more synchronous. > > If this does not help then the sync activity is not finding everything and > things are seriously broken. > > Steve > > > > hi > > > > i found a bug with the newer development kernels. > > > > i have files with data corruption after hitting the reset button. > > it seems that "sync" does not sync the data to disk. > > > > i made following test: > > > > > > cp -av /usr/src/linux/drivers/ drivers > > diff -r -u /usr/src/linux/drivers/ drivers/ (no differs) > > sync > > sync > > sync > > > > hit the reset button. > > > > after that, the diff reports about 190 (of 3134) files are different. > > > > the files have the right size, but they are only filled with null chars. > > xfs_bmap reports, that they have no extends. > > > > i have made the test with some older kernels: > > > > the last working kernel is from feb, 4th 14:00 CET. > > the first buggy kernel is from feb, 6th 0:50 CET. > > > > the tests were made on a xfs root partition (ide drive, no kio). > > > > and i notice that on the buggy kernels, when the (root) fs is marked > > readonly while shutdown, there were more diskactivity than on the good ones. > > the data is only written to disk while marking readonly? > > > > > > hope that helps. > > > > > > utz > From owner-linux-xfs@oss.sgi.com Sun Feb 11 10:09:12 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 10:08:52 -0800 Received: from porgy.srv.nld.sonera.net ([195.66.15.137]:213 "EHLO porgy.srv.nld.sonera.net") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 10:08:42 -0800 Received: from qn-213-73-144-89.quicknet.nl ([213.73.144.89]:64708 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Sun, 11 Feb 2001 19:08:22 +0100 Message-Id: <4.3.2.7.2.20010211185113.040d4188@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 11 Feb 2001 19:06:03 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Oopses during heavy IDE IO Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, I have a machine at work which is a PIII 450 with 128MB ram and a 15GB IDE disk that will oops on the moment That I am trying to write large amounts of data on a samba share. The samba share is located on /home which is a XFS partition most of the times it happens about the time that the system runs out of ram buffer (eg 100MB) and then oopses mentioning swapper. 2.4.0-XFS (before 2.4.1 merge) does boot and takes the punishment with ease. Unfortunately I can not send the oops because: - The file is on the disk there. - The machine is currently displaying another oops - I can not reboot it on untill tommorow when I get to work. I can also trigger a oops using the Eicon Diva server which it contains. The drivver is lost after sending a fax. Open minicom on the isdn device. Modem init goes OK and as soon as I type atdt 000 and enter it oopses. Although the oops says swapper is involved I don't see the link. These are things that started happening after the 2.4.1 merge. This machined has been rock stable for the past testing period. Sarcastic side Note: This $1800 desktop machine with samba beats a $10.000 dell poweredge 2400 with twice the amount of ram and disk space with raid 10 on 4 18GB 10KRPM disks. ... by a factor of 5 that is using the 2.4.0-XFS kernel. Now my boss is not happy anymore (concerning NotToday) Bye -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Sun Feb 11 10:15:23 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 10:15:12 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:40965 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 10:15:01 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id TAA26005 for linux-xfs@oss.sgi.com; Sun, 11 Feb 2001 19:12:58 +0100 Date: Sun, 11 Feb 2001 19:12:58 +0100 From: sooo lame To: linux-xfs@oss.sgi.com Subject: linux-xfs@oss.sgi.com Message-ID: <20010211191258.A19510@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I, similarly to Sean and Utz, had lockups and data loss on my 2 of 4 XFS hard drives (one machine). After one lockup one partition refused to be mounted These were non-root partitions.. What can seem important: XFS disks were NOT heaviliy used, moreover there was practically no writes to that disks... Feb 7 12:39:08 main kernel: Start mounting filesystem: ide2(33,1) Feb 7 12:39:08 main kernel: Starting XFS recovery on filesystem: ide2(33,1) (dev: 33/1) Feb 7 12:39:08 main kernel: cmn_err level 1 Filesystem "ide2(33,1)": xfs_inode_recover: Bad inode magic numbe r, dino ptr = 0xc2fc6600, dino bp = 0xc78d8c60, ino = 65456518 Feb 7 12:39:08 main kernel: XFS: log mount/recovery failed Feb 7 12:39:08 main kernel: XFS: log mount failed (i change kernels as soon as CVS, so the "vital" change must have occured 'bout Feb 6 - unfortunately i haven't kept previous tree) After xfs_recovery few files/dirs were _lost_ (as i noticed it was _NOT_ lost inodes ... lost+found directory was still empty), but, what's interesting free disk space reported by "df" did NOT change (files were 'bout 500MB each so change would be noticeable). What's also interesting, another (a friend of mine) machine with _same_ (buggy?) kernel had no lockups at all - no data loss consequently... my machine: Mendocino 366 , 128MB, VT82C596A & PROMISE PDC20262 Samsung Spinpoint Series Hard drives (SVxxxxD , 20,30 and 40G) Davicom DM9102 Fast Ethernet friend's machine: Mendocino 400, 256MB, VT82C596B Seagate ST313021A, IBM-DTLA-307030 3Com 3C509C Tornado Can it be related to "serious IDE multimode write bug" fixed in 2.4.2-pre2 ? Regards - Krzysztof From owner-linux-xfs@oss.sgi.com Sun Feb 11 10:19:12 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 10:18:53 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12063 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 10:18:45 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA00247 for ; Sun, 11 Feb 2001 10:28:03 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA780344; Sun, 11 Feb 2001 12:17:27 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA55621; Sun, 11 Feb 2001 12:17:27 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1BIFcf19776; Sun, 11 Feb 2001 12:15:38 -0600 Message-Id: <200102111815.f1BIFcf19776@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: Oopses during heavy IDE IO In-Reply-To: Message from Seth Mos of "Sun, 11 Feb 2001 19:06:03 +0100." <4.3.2.7.2.20010211185113.040d4188@pop.xs4all.nl> Date: Sun, 11 Feb 2001 12:15:38 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing We are not having a good day here in XFS land! > hi, > > I have a machine at work which is a PIII 450 with 128MB ram and a 15GB IDE > disk that will oops on the moment That I am trying to write large amounts > of data on a samba share. > The samba share is located on /home which is a XFS partition most of the > times it happens about the time that the system runs out of ram buffer (eg > 100MB) and then oopses mentioning swapper. Samba itself does not do anything special - it just does writes to push data out. Are you using kio or kiocluster in the mount options? > > 2.4.0-XFS (before 2.4.1 merge) does boot and takes the punishment with ease. > Unfortunately I can not send the oops because: > - The file is on the disk there. > - The machine is currently displaying another oops > - I can not reboot it on untill tommorow when I get to work. > > I can also trigger a oops using the Eicon Diva server which it contains. > The drivver is lost after sending a fax. Open minicom on the isdn device. > Modem init goes OK and as soon as I type atdt 000 and enter it oopses. > Although the oops says swapper is involved I don't see the link. > These are things that started happening after the 2.4.1 merge. > This machined has been rock stable for the past testing period. This problem has got to be a generic linux problem - not xfs (I hope). > > Sarcastic side Note: This $1800 desktop machine with samba beats a $10.000 > dell poweredge 2400 with twice the amount of ram and disk space with raid > 10 on 4 18GB 10KRPM disks. ... by a factor of 5 that is using the 2.4.0-XFS > kernel. Can you elaborate on this - is this an XFS is slower than yyy or is this a dell is slower than xxx? And now the baby monitor is calling, I have to go be 'da da' ;-) Steve > Now my boss is not happy anymore (concerning NotToday) > > Bye > -- > Seth > Has anybody seen my lightbulb? > I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Sun Feb 11 11:02:32 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 11:02:13 -0800 Received: from porgy.srv.nld.sonera.net ([195.66.15.137]:819 "EHLO porgy.srv.nld.sonera.net") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 11:01:51 -0800 Received: from qn-213-73-144-89.quicknet.nl ([213.73.144.89]:61392 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Sun, 11 Feb 2001 20:01:33 +0100 Message-Id: <4.3.2.7.2.20010211193709.0400daa0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 11 Feb 2001 19:59:11 +0100 To: Steve Lord From: Seth Mos Subject: Re: Oopses during heavy IDE IO Cc: linux-xfs@oss.sgi.com In-Reply-To: <200102111815.f1BIFcf19776@jen.americas.sgi.com> References: <4.3.2.7.2.20010211185113.040d4188@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 12:15 11-2-2001 -0600, Steve Lord wrote: >We are not having a good day here in XFS land! Neither am I, tommorow morning I am positively sure that nox faxes will be sent... ugh > > hi, > > > > I have a machine at work which is a PIII 450 with 128MB ram and a 15GB IDE > > disk that will oops on the moment That I am trying to write large amounts > > of data on a samba share. > > The samba share is located on /home which is a XFS partition most of the > > times it happens about the time that the system runs out of ram buffer (eg > > 100MB) and then oopses mentioning swapper. > >Samba itself does not do anything special - it just does writes to push >data out. Are you using kio or kiocluster in the mount options? Nope, straight mounting without any extra options. > > 2.4.0-XFS (before 2.4.1 merge) does boot and takes the punishment with > ease. > > Unfortunately I can not send the oops because: > > - The file is on the disk there. > > - The machine is currently displaying another oops > > - I can not reboot it on untill tommorow when I get to work. > > > > I can also trigger a oops using the Eicon Diva server which it contains. > > The drivver is lost after sending a fax. Open minicom on the isdn device. > > Modem init goes OK and as soon as I type atdt 000 and enter it oopses. > > Although the oops says swapper is involved I don't see the link. > > These are things that started happening after the 2.4.1 merge. > > This machined has been rock stable for the past testing period. > >This problem has got to be a generic linux problem - not xfs (I hope). I don't know for sure. I can replicate the Oops using the Eicon Diva server ISDN adapter ($500) using 2.4.0 I am positively sure that something in the 2.4.0-2.4.1 merge went wrong, horribly wrong. > > Sarcastic side Note: This $1800 desktop machine with samba beats a $10.000 > > dell poweredge 2400 with twice the amount of ram and disk space with raid > > 10 on 4 18GB 10KRPM disks. ... by a factor of 5 that is using the > 2.4.0-XFS > > kernel. > >Can you elaborate on this - is this an XFS is slower than yyy or is this a >dell is slower than xxx? It is more of a puny linux desktop beats the pants of a big NT server. XFS speed is speedy by my standards. And the error recovery is even more appreciated then the faster disk IO. It justs takes 2 minutes to come up after a crash. That's worth a lot more to me. The linux box is a Dell Optiplex Gx1 PIII 450 with a standard Maxtor 5400 RPM ide disk and a 3c905 network adapter connected to the same 3com SuperStack 3300 that the Dell poweredge is connected and our IT department. 100Mbit Fast ethernet back to back over this switch. The NT box is a Dell Poweredge 2400 with a PIII 733EB and 256MB ram using 4 10K rpm 18GB Ultra2 scsi LVD disk drives connected in raid 0+1 (raid 10) on a Ami Megaraid controller. The system is equiped with a Intel Etherexpress 100+ server adapter. Beaming over 2.8GB of binary data from a laptop (windows 2K) to the NT server took 56 minutes. Beaming it over to the linux machine took just under 10 minutes. When beaming over the file from the linux box to the NT server it took about 10+ Minutes So it seems that the server part is relatively slow. When using Norton ghost on this laptop to restore that disk image to a new machine it would clock a 80MB/min restore rate when streaming the Image from the image located on the network share of the NT machine. When using the image located on the samba share of the linux box and restoring we clocked a new restore speed record of 200+MB/min. We never restored images residing on a linux box before, so this was a first. And the old one was at 120MB/s. Very cool indeed. This is not directly XFS related. It just shows that both linux 2.4 and 2.2.18 are very fast in networking when coupled with samba. These things bring back netware memories (decent speed) >And now the baby monitor is calling, I have to go be 'da da' ;-) Cool, good luck :-) >Steve -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Sun Feb 11 11:19:33 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 11:19:23 -0800 Received: from porgy.srv.nld.sonera.net ([195.66.15.137]:9383 "EHLO porgy.srv.nld.sonera.net") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 11:18:59 -0800 Received: from qn-213-73-144-89.quicknet.nl ([213.73.144.89]:61450 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Sun, 11 Feb 2001 20:18:47 +0100 Message-Id: <4.3.2.7.2.20010211201447.04113328@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 11 Feb 2001 20:16:29 +0100 To: lord@sgi.com From: Seth Mos Subject: Re: Oopses during heavy IDE IO Cc: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20010211193709.0400daa0@pop.xs4all.nl> References: <200102111815.f1BIFcf19776@jen.americas.sgi.com> <4.3.2.7.2.20010211185113.040d4188@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >I don't know for sure. I can replicate the Oops using the Eicon Diva >server ISDN adapter ($500) using 2.4.0 >I am positively sure that something in the 2.4.0-2.4.1 merge went wrong, >horribly wrong. That should have been "can _not_" replicate. whoops sorry about that. Bye -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Sun Feb 11 15:16:46 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 15:16:36 -0800 Received: from cortex.ama.ttuhsc.edu ([168.49.129.1]:31763 "EHLO cortex.ama.ttuhsc.edu") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 15:16:13 -0800 Received: (from sean@localhost) by cortex.ama.ttuhsc.edu (8.10.2/8.10.2) id f1BNFQm07656; Sun, 11 Feb 2001 17:15:26 -0600 (CST) Date: Sun, 11 Feb 2001 17:15:26 -0600 (CST) From: Sean Dougherty To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: xfs causes machine to freeze In-Reply-To: <200102111705.f1BH5IM19540@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, 11 Feb 2001, Steve Lord wrote: > > There are changes in the current development cvs tree which may fix this, > we know that it is not bug free right now, and are working on it. In the > meantime, could you possibly try a kernel built from the development tree > and let us know if you can hang it in the same way. > > Steve I have just downloaded this new cvs tree, and it is running now on a pentium II/128M/PIIX and PDC2xxx both drives are maxtor. I will let you know, if it does hang, I plan to try the 2.4.pre-3 patch which was suggested by both Scott Hoffman and Krzysztof. The strange thing is, the brand new test machine I built on thursday, (athalon 1000,512M,20G and 80G maxtor drives, via and promise controllers) using the install RPM from the iso distribution...is running like a champ. I just checked and it has not crashed since late thursday. Would it be possible for you to email me the .config for your default install (or tell me how to generate it from the iso image), then I can compare what I have turned on that the install does not. I am tending to think this is more a 2.4X problem than an xfs problem. All my machines running 2.2.16-3 (with the appropriate ide patches from hendrick so I can have multicount and dma on the ide drives) run my little stress test fine (by fine I mean if my stress test runs from Friday night when I go home till Monday morning when I get back). Thanks Sean Dougherty Manager of way too much TTUHSC At Amarillo ps..for the group: With reguards to Seth Moss comment about the speed of NT...my experience has shown that pretty much a trained monkey with an etch-a-sketch is faster than an NT box :-) From owner-linux-xfs@oss.sgi.com Sun Feb 11 23:54:22 2001 Received: by oss.sgi.com id ; Sun, 11 Feb 2001 23:54:02 -0800 Received: from edge.coltex.nl ([194.151.97.115]:30987 "EHLO mail.coltex.nl") by oss.sgi.com with ESMTP id ; Sun, 11 Feb 2001 23:53:42 -0800 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f1C6rEe06435 for ; Mon, 12 Feb 2001 07:53:15 +0100 Message-Id: <4.3.2.7.2.20010212084826.037636a8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Feb 2001 08:51:21 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Oops when dialing over a Eicon Diva Server card Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1435504==_" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --=====================_1435504==_ Content-Type: text/plain; charset="us-ascii"; format=flowed I attached the file that is produced when I'm trying to dial over the ISDN device using minicom. I will reproduce the samba oops later and send that one to the list. Maybe this will give some pointers to the instability that is occuring with the 2.4.1 tree. Bye --=====================_1435504==_ Content-Type: text/plain; name="lsautom-kysmoops-07022001.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lsautom-kysmoops-07022001.txt" a3N5bW9vcHMgMi4zLjQgb24gaTY4NiAyLjQuMS1YRlMuICBPcHRpb25zIHVzZWQKICAgICAtViAo ZGVmYXVsdCkKICAgICAtayAvcHJvYy9rc3ltcyAoZGVmYXVsdCkKICAgICAtbCAvcHJvYy9tb2R1 bGVzIChkZWZhdWx0KQogICAgIC1vIC9saWIvbW9kdWxlcy8yLjQuMS1YRlMvIChkZWZhdWx0KQog ICAgIC1tIC91c3Ivc3JjL2xpbnV4L1N5c3RlbS5tYXAgKGRlZmF1bHQpCgpXYXJuaW5nOiBZb3Ug ZGlkIG5vdCB0ZWxsIG1lIHdoZXJlIHRvIGZpbmQgc3ltYm9sIGluZm9ybWF0aW9uLiAgSSB3aWxs CmFzc3VtZSB0aGF0IHRoZSBsb2cgbWF0Y2hlcyB0aGUga2VybmVsIGFuZCBtb2R1bGVzIHRoYXQg YXJlIHJ1bm5pbmcKcmlnaHQgbm93IGFuZCBJJ2xsIHVzZSB0aGUgZGVmYXVsdCBvcHRpb25zIGFi b3ZlIGZvciBzeW1ib2wgcmVzb2x1dGlvbi4KSWYgdGhlIGN1cnJlbnQga2VybmVsIGFuZC9vciBt b2R1bGVzIGRvIG5vdCBtYXRjaCB0aGUgbG9nLCB5b3UgY2FuIGdldAptb3JlIGFjY3VyYXRlIG91 dHB1dCBieSB0ZWxsaW5nIG1lIHRoZSBrZXJuZWwgdmVyc2lvbiBhbmQgd2hlcmUgdG8gZmluZApt YXAsIG1vZHVsZXMsIGtzeW1zIGV0Yy4gIGtzeW1vb3BzIC1oIGV4cGxhaW5zIHRoZSBvcHRpb25z LgoKVW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgcGFnaW5nIHJlcXVlc3QgYXQgdmlydHVhbCBhZGRy ZXNzIDMzNTMyM2YKKnBkZSA9IDAwMDAwMDAwCk9vcHM6IDAwMDAKQ1BVOiAgICAwCkVJUDogICAg MDAxMDpbPGM4OGI5MzQwPl0KVXNpbmcgZGVmYXVsdHMgZnJvbSBrc3ltb29wcyAtdCBlbGYzMi1p Mzg2IC1hIGkzODYKRUZMQUdTOiAwMDAxMDIwNgplYXg6IDMzMzUzMjM3ICAgZWJ4OiBjMzVjZmMx YiAgICAgZWN4OiAwMDAwMDAwMCAgICAgICBlZHg6IDMzMzUzMjNmCmVzaTogYzM1Y2ZjMmIgICBl ZGk6IGMzNWNmYzNmICAgICBlYnA6IGMzNzhmMDAwICAgICAgIGVzcDpjMDJjNWMyMApkczogMDAx OCAgICAgICAgZXM6IDAwMTggICAgICAgc3M6IDAwMTgKUHJvY2VzcyBzd2FwcGVyIChwaWQ6MCwg c3RhY2twYWdlPWMwMmM1MDAwKQpTdGFjazogIGMzNWNmYzEyIGMzNWNmYzAwIGMyODYzNGEwIGM3 ZWI1MDgwIDAwMDAwMDAwIDAwMDAwMDAwIGMzODI0YjU0IGM3ZDZkNjgwCiAgICAgICAgMDAwMDAw MDAgYzM4MjRiNTQgMDAwMDAwMDAgMDAwMDAyNDYgYzdlYjUwODAgYzAzMTBmYTAgMDAwMDAwMDIg YzAyMmIzMDYKICAgICAgICAwMDAwMDAxNCBjODhiNzQ2NiBjMzc4ZjAwMCBjMzVjZmMxYiAwMDAw MDcwMSBjMzVjZmMwMCBjODhiNzgwMCBjMzVjZmMwMApDYWxsIFRyYWNlOiBbPGMwMjJiMzA2Pl0g WzxjODhiNzQ2Nj5dIFs8Yzg4Yjc4MDA+XSBbPGM4OGJjMWY3Pl0gWzxjODg4OTVmYz5dIFs8YzAy MzI0YzI+XSBbPGMwMjMyNGMyPl0KICAgICAgICBbPGMwMjNhMzBjPl0gWzxjMDIzMjRjMj5dIFs8 YzAyMzkzOWI+XSBbPGM4OGNiMjAwPl0gWzxjODhiZmU0OT5dIFs8Yzg4Y2FiNDA+XSBbPGM4OGNh YjQwPl0gWzxjODhiZmU0OT5dCiAgICAgICAgWzxjODhjYWI0MD5dIFs8Yzg4Y2FiNDA+XSBbPGM4 OGNvY2JiPl0gWzxjODhiZTA0Mz5dIFs8Yzg4Y2IyMDA+XSBbPGM4ODNjOTFkPl0gWzxjODhiNDEw MD5dIFs8YzAxMTdmNWM+XQogICAgICAgIFs8YzAxMWE0MDI+XSBbPGMwMTE3ZTc3Pl0gWzxjMDEx N2RiOD5dIFs8YzAxMTdjYmU+XSBbPGMwMTBhMGM4Pl0gWzxjMDEwNzE2MD5dIFs8YzAxMDcxNjA+ XSBbPGMwMTA4ZTMwPl0KICAgICAgICBbPGMwMTA3MTYwPl0gWzxjMDEwNzE2MD5dIFs8YzAxMDAw MTg+XSBbPGMwMTA3MTgzPl0gWzxjMDEwNzFlND5dIFs8YzAxMDUwMDA+XSBbPGMwMTAwMTkxPl0K Q29kZTogOGIgNDAgMDggODkgNDMgMTAgOGIgNGEgMDQgODkgNGUgMDQgOGIgN2EgMDggODkgN2Ug MDggOGIgNDIKCj4+RUlQOyBjODhiOTM0MCA8W2VpY29uXWlkaV9maWxsX2luX1QzMCs0OC8yZGM+ ICAgPD09PT09ClRyYWNlOyBjMDIyYjMwNiA8YWxsb2Nfc2tiK2U2LzE3OD4KVHJhY2U7IGM4OGI3 NDY2IDxbZWljb25daWRpX2Fzc2lnbl9yZXErMTA2LzEzYz4KVHJhY2U7IGM4OGI3ODAwIDxbZWlj b25daWRpX2RvX3JlcSsyMTAvNDEwPgpUcmFjZTsgYzg4YmMxZjcgPFtlaWNvbl1pZGlfaGFuZGxl X2luZCthMGYvMTBlMD4KVHJhY2U7IGM4ODg5NWZjIDxbaXNkbl1pc2RuX3N0YXR1c19jYWxsYmFj ayswLzljOD4KVHJhY2U7IGMwMjMyNGMyIDxuZl9ob29rX3Nsb3crY2EvMTBjPgpUcmFjZTsgYzAy MzI0YzIgPG5mX2hvb2tfc2xvdytjYS8xMGM+ClRyYWNlOyBjMDIzYTMwYyA8aXBfcXVldWVfeG1p dDIrMTQwLzFlND4KVHJhY2U7IGMwMjMyNGMyIDxuZl9ob29rX3Nsb3crY2EvMTBjPgpUcmFjZTsg YzAyMzkzOWIgPGlwX3F1ZXVlX3htaXQrMjUzLzJhYz4KVHJhY2U7IGM4OGNiMjAwIDxbZWljb25d X19tb2R1bGVfcGFybV9pcnErNmIxLzQxNzA+ClRyYWNlOyBjODhiZmU0OSA8W2VpY29uXWlvX291 dCs0OS81ND4KVHJhY2U7IGM4OGNhYjQwIDxbZWljb25dX19tb2R1bGVfcGFybV9tZW1iYXNlKzAv MD4KVHJhY2U7IGM4OGNhYjQwIDxbZWljb25dX19tb2R1bGVfcGFybV9tZW1iYXNlKzAvMD4KVHJh Y2U7IGM4OGJmZTQ5IDxbZWljb25daW9fb3V0KzQ5LzU0PgpUcmFjZTsgYzg4Y2FiNDAgPFtlaWNv bl1fX21vZHVsZV9wYXJtX21lbWJhc2UrMC8wPgpUcmFjZTsgYzg4Y2FiNDAgPFtlaWNvbl1fX21v ZHVsZV9wYXJtX21lbWJhc2UrMC8wPgpUcmFjZTsgYzAxMWE0MDIgPGltbWVkaWF0ZV9iaCsxNi8x Yz4KVHJhY2U7IGMwMTE3ZTc3IDxiaF9hY3Rpb24rMWIvNjg+ClRyYWNlOyBjMDExN2RiOCA8dGFz a2xldF9oaV9hY3Rpb24rM2MvNjA+ClRyYWNlOyBjMDExN2NiZSA8ZG9fc29mdGlycSs0ZS83ND4K VHJhY2U7IGMwMTBhMGM4IDxkb19JUlErOWMvYWM+ClRyYWNlOyBjMDEwNzE2MCA8ZGVmYXVsdF9p ZGxlKzAvMjg+ClRyYWNlOyBjMDEwNzE2MCA8ZGVmYXVsdF9pZGxlKzAvMjg+ClRyYWNlOyBjMDEw OGUzMCA8cmV0X2Zyb21faW50ciswLzIwPgpUcmFjZTsgYzAxMDcxNjAgPGRlZmF1bHRfaWRsZSsw LzI4PgpUcmFjZTsgYzAxMDcxNjAgPGRlZmF1bHRfaWRsZSswLzI4PgpUcmFjZTsgYzAxMDAwMTgg PHN0YXJ0dXBfMzIrMTgvMTM5PgpUcmFjZTsgYzAxMDcxODMgPGRlZmF1bHRfaWRsZSsyMy8yOD4K VHJhY2U7IGMwMTA3MWU0IDxjcHVfaWRsZSszYy81MD4KVHJhY2U7IGMwMTA1MDAwIDxlbXB0eV9i YWRfcGFnZSswLzEwMDA+ClRyYWNlOyBjMDEwMDE5MSA8TDYrMC8yPgpDb2RlOyAgYzg4YjkzNDAg PFtlaWNvbl1pZGlfZmlsbF9pbl9UMzArNDgvMmRjPgowMDAwMDAwMCA8X0VJUD46CkNvZGU7ICBj ODhiOTM0MCA8W2VpY29uXWlkaV9maWxsX2luX1QzMCs0OC8yZGM+ICAgPD09PT09CiAgIDA6ICAg OGIgNDAgMDggICAgICAgICAgICAgICAgICBtb3YgICAgMHg4KCVlYXgpLCVlYXggICA8PT09PT0K Q29kZTsgIGM4OGI5MzQzIDxbZWljb25daWRpX2ZpbGxfaW5fVDMwKzRiLzJkYz4KICAgMzogICA4 OSA0MyAxMCAgICAgICAgICAgICAgICAgIG1vdiAgICAlZWF4LDB4MTAoJWVieCkKQ29kZTsgIGM4 OGI5MzQ2IDxbZWljb25daWRpX2ZpbGxfaW5fVDMwKzRlLzJkYz4KICAgNjogICA4YiA0YSAwNCAg ICAgICAgICAgICAgICAgIG1vdiAgICAweDQoJWVkeCksJWVjeApDb2RlOyAgYzg4YjkzNDkgPFtl aWNvbl1pZGlfZmlsbF9pbl9UMzArNTEvMmRjPgogICA5OiAgIDg5IDRlIDA0ICAgICAgICAgICAg ICAgICAgbW92ICAgICVlY3gsMHg0KCVlc2kpCkNvZGU7ICBjODhiOTM0YyA8W2VpY29uXWlkaV9m aWxsX2luX1QzMCs1NC8yZGM+CiAgIGM6ICAgOGIgN2EgMDggICAgICAgICAgICAgICAgICBtb3Yg ICAgMHg4KCVlZHgpLCVlZGkKQ29kZTsgIGM4OGI5MzRmIDxbZWljb25daWRpX2ZpbGxfaW5fVDMw KzU3LzJkYz4KICAgZjogICA4OSA3ZSAwOCAgICAgICAgICAgICAgICAgIG1vdiAgICAlZWRpLDB4 OCglZXNpKQpDb2RlOyAgYzg4YjkzNTIgPFtlaWNvbl1pZGlfZmlsbF9pbl9UMzArNWEvMmRjPgog IDEyOiAgIDhiIDQyIDAwICAgICAgICAgICAgICAgICAgbW92ICAgIDB4MCglZWR4KSwlZWF4CgpL ZXJuZWwgcGFuaWM6IEFpZWUsIGtpbGxpbmcgaW50ZXJydXB0IGhhbmRsZXIhCgoxIHdhcm5pbmcg aXNzdWVkLiAgUmVzdWx0cyBtYXkgbm90IGJlIHJlbGlhYmxlLgo= --=====================_1435504==_ Content-Type: text/plain; charset="us-ascii"; format=flowed -- Seth Has anybody seen my lightbulb? I _really_ need some light here. --=====================_1435504==_-- From owner-linux-xfs@oss.sgi.com Mon Feb 12 02:27:02 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 02:26:43 -0800 Received: from ns.suse.de ([213.95.15.193]:41484 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 12 Feb 2001 02:26:29 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 172A61E0AC; Mon, 12 Feb 2001 11:26:28 +0100 (MET) Date: Mon, 12 Feb 2001 11:26:04 +0100 From: Andi Kleen To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Oops when dialing over a Eicon Diva Server card Message-ID: <20010212112604.A21839@gruyere.muc.suse.de> References: <4.3.2.7.2.20010212084826.037636a8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010212084826.037636a8@pop.xs4all.nl>; from knuffie@xs4all.nl on Mon, Feb 12, 2001 at 08:51:21AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Feb 12, 2001 at 08:51:21AM +0100, Seth Mos wrote: > I attached the file that is produced when I'm trying to dial over the ISDN > device using minicom. I will reproduce the samba oops later and send that > one to the list. [...] Very much looks like a Eicon bug. I would suggest to contact the Eicon or ISDN maintainers. If XFS would corrupt random memory other subsystems would break too. -Andi From owner-linux-xfs@oss.sgi.com Mon Feb 12 07:00:55 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 07:00:36 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:13584 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 07:00:19 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA06500 for ; Mon, 12 Feb 2001 07:00:18 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA786787; Mon, 12 Feb 2001 08:59:01 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA14000; Mon, 12 Feb 2001 08:59:01 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1CEv4X20512; Mon, 12 Feb 2001 08:57:04 -0600 Message-Id: <200102121457.f1CEv4X20512@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Oops when dialing over a Eicon Diva Server card In-Reply-To: Message from Andi Kleen of "Mon, 12 Feb 2001 11:26:04 +0100." <20010212112604.A21839@gruyere.muc.suse.de> Date: Mon, 12 Feb 2001 08:57:03 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Mon, Feb 12, 2001 at 08:51:21AM +0100, Seth Mos wrote: > > I attached the file that is produced when I'm trying to dial over the ISDN > > device using minicom. I will reproduce the samba oops later and send that > > one to the list. > > [...] > > Very much looks like a Eicon bug. I would suggest to contact the Eicon or > ISDN maintainers. If XFS would corrupt random memory other subsystems would > break too. > > > -Andi I would second Andi's opinion on this - we do not have changes in the kernel which should affect this. Mind you, nothing in the isdn code appears to have changed much in 2.4.1 either. 2.4.2-pre3 takes a rather large swipe at isdn. However, I do notice empty_bad_page in the trace - this is not a function call, but a special page. I checked in one fix in a swapout path on Friday which was related to pte corruption with XFS, you need the latest version of mm/vmscan.c. Are you running with this file? Steve From owner-linux-xfs@oss.sgi.com Mon Feb 12 07:17:26 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 07:17:17 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:2620 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 07:16:54 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA18707 for ; Mon, 12 Feb 2001 07:15:52 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA786163; Mon, 12 Feb 2001 09:15:36 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA08487; Mon, 12 Feb 2001 09:15:36 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1CFDd620558; Mon, 12 Feb 2001 09:13:39 -0600 Message-Id: <200102121513.f1CFDd620558@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Sean Dougherty cc: linux-xfs@oss.sgi.com Subject: Re: xfs causes machine to freeze In-Reply-To: Message from Sean Dougherty of "Sun, 11 Feb 2001 17:15:26 CST." Date: Mon, 12 Feb 2001 09:13:39 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Sun, 11 Feb 2001, Steve Lord wrote: > > > > > There are changes in the current development cvs tree which may fix this, > > we know that it is not bug free right now, and are working on it. In the > > meantime, could you possibly try a kernel built from the development tree > > and let us know if you can hang it in the same way. > > > > Steve > > I have just downloaded this new cvs tree, and it is running now on a > pentium II/128M/PIIX and PDC2xxx both drives are maxtor. I will let you > know, if it does hang, I plan to try the 2.4.pre-3 patch which was > suggested by both Scott Hoffman and Krzysztof. I am attempting to merge 2.4.2-pre3 at the moment, and am running into difficulties with the ide code - the changes in our tree and the changes in Linus's tree do not like each other at the moment. I would hold off on attempting to use this right now - unless you understand the ide code very well ;-) Steve > > The strange thing is, the brand new test machine I built on thursday, > (athalon 1000,512M,20G and 80G maxtor drives, via and promise > controllers) using the install RPM from the iso distribution...is running > like a champ. I just checked and it has not crashed since late > thursday. Would it be possible for you to email me the .config for your > default install (or tell me how to generate it from the iso image), then > I can compare what I have turned on that the install does not. > > I am tending to think this is more a 2.4X problem than an xfs problem. > All my machines running 2.2.16-3 (with the appropriate ide patches from > hendrick so I can have multicount and dma on the ide drives) run my > little stress test fine (by fine I mean if my stress test runs from Friday > night when I go home till Monday morning when I get back). > > Thanks > > Sean Dougherty > Manager of way too much > TTUHSC At Amarillo > > ps..for the group: With reguards to Seth Moss comment about the speed of > NT...my experience has shown that pretty much a trained monkey with an > etch-a-sketch is faster than an NT box :-) > > From owner-linux-xfs@oss.sgi.com Mon Feb 12 07:23:26 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 07:23:16 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14665 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 07:23:00 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA07442 for ; Mon, 12 Feb 2001 07:32:19 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA785886; Mon, 12 Feb 2001 09:21:42 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA03943; Mon, 12 Feb 2001 09:21:42 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1CFJim20576; Mon, 12 Feb 2001 09:19:44 -0600 Message-Id: <200102121519.f1CFJim20576@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: sooo lame cc: linux-xfs@oss.sgi.com Subject: Re: linux-xfs@oss.sgi.com In-Reply-To: Message from sooo lame of "Sun, 11 Feb 2001 19:12:58 +0100." <20010211191258.A19510@main.braxis.co.uk> Date: Mon, 12 Feb 2001 09:19:44 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > I, similarly to Sean and Utz, had lockups and data loss on my 2 of 4 XFS > hard drives (one machine). After one lockup one partition refused > to be mounted > > These were non-root partitions.. > What can seem important: XFS disks were NOT heaviliy used, moreover > there was practically no writes to that disks... > > Feb 7 12:39:08 main kernel: Start mounting filesystem: ide2(33,1) > Feb 7 12:39:08 main kernel: Starting XFS recovery on filesystem: ide2(33,1) > (dev: 33/1) > Feb 7 12:39:08 main kernel: cmn_err level 1 Filesystem "ide2(33,1)": > xfs_inode_recover: Bad inode magic numbe > r, dino ptr = 0xc2fc6600, dino bp = 0xc78d8c60, ino = 65456518 > Feb 7 12:39:08 main kernel: XFS: log mount/recovery failed > Feb 7 12:39:08 main kernel: XFS: log mount failed > > (i change kernels as soon as CVS, so the "vital" change must have > occured 'bout Feb 6 - unfortunately i haven't kept previous tree) I did change how delayed allocate writes are processed - on Feb 5th, I suspect this as being related to these problems - the data loss after an oops especially. We used to scan the complete page table converting pages to delayed allocate, now we scan the inactive dirty list, of course if a page never gets to the inactive dirty list we could be in trouble.... It is possible I fixed the oops on Friday, I spent most of last week chasing a page table corruption problem which was introduced in the 2.4.1 merge. For me this came out as a panic freeing a page, but for others it could well look different - since a page table entry was being filled in with an uninitialized stack variable. Steve > > After xfs_recovery few files/dirs were _lost_ (as i noticed it was > _NOT_ lost inodes ... lost+found directory was still empty), but, > what's interesting free disk space reported by "df" did NOT > change (files were 'bout 500MB each so change would be noticeable). > > What's also interesting, another (a friend of mine) machine with _same_ > (buggy?) kernel had no lockups at all - no data loss consequently... > > my machine: Mendocino 366 , 128MB, VT82C596A & PROMISE PDC20262 > Samsung Spinpoint Series Hard drives (SVxxxxD , 20,30 and 40G) > Davicom DM9102 Fast Ethernet > > friend's machine: Mendocino 400, 256MB, VT82C596B > Seagate ST313021A, IBM-DTLA-307030 > 3Com 3C509C Tornado > > Can it be related to "serious IDE multimode write bug" fixed in 2.4.2-pre2 ? I am not an expert on the ins and outs of the ide system, but I seem to recall people reporting problems with promise ide controllers on the list - I see the word promise in your machine spec, or is this grasping at straws? Steve From owner-linux-xfs@oss.sgi.com Mon Feb 12 08:37:45 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 08:37:35 -0800 Received: from ns.suse.de ([213.95.15.193]:2578 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 12 Feb 2001 08:37:15 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id EE1511E191; Mon, 12 Feb 2001 17:37:13 +0100 (MET) Date: Mon, 12 Feb 2001 17:35:28 +0100 From: Andi Kleen To: Steve Lord Cc: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Oops when dialing over a Eicon Diva Server card Message-ID: <20010212173528.A27186@gruyere.muc.suse.de> References: <200102121457.f1CEv4X20512@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102121457.f1CEv4X20512@jen.americas.sgi.com>; from lord@sgi.com on Mon, Feb 12, 2001 at 08:57:03AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi Steve, On Mon, Feb 12, 2001 at 08:57:03AM -0600, Steve Lord wrote: > However, I do notice empty_bad_page in the trace - this is not a function > call, but a special page. I checked in one fix in a swapout path on Friday > which was related to pte corruption with XFS, you need the latest > version of mm/vmscan.c. Are you running with this file? Bogus symbols in ksymoops backtraces are rather normal, they're just stack noise. Unlike KDB the standard backtrace which doesn't have stack frames so it just scans the stack for addresses that look like code/ module address. This includes empty_bad_page. The reader has to filter the impossible cases out. So I wouldn't worry about it, -Andi From owner-linux-xfs@oss.sgi.com Mon Feb 12 08:49:16 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 08:49:06 -0800 Received: from cortex.ama.ttuhsc.edu ([168.49.129.1]:17680 "EHLO cortex.ama.ttuhsc.edu") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 08:48:44 -0800 Received: (from sean@localhost) by cortex.ama.ttuhsc.edu (8.10.2/8.10.2) id f1CGm1O05070; Mon, 12 Feb 2001 10:48:01 -0600 (CST) Date: Mon, 12 Feb 2001 10:48:00 -0600 (CST) From: Sean Dougherty To: linux-xfs@oss.sgi.com Subject: Question about xfs In-Reply-To: <200102121513.f1CFDd620558@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing As I have been testing, I have crashed a few times :-). When I do an xfs_repair of the crashed drive, that seem to run very well. Then I remount the drive and then delete everything on that drive (getting set up for the next test) I have noticed that when I do a "df" the drive shows oh between 30-40K still used. Whereas when I created the file system (mkfs -t xfs....) a df shows about 1200 bytes used. I am sure this has to do with the journaling and want to learn more, can someone point me to reference where I can read up on this. Thanks. Sean Dougherty Manager of way too much TTUHSC At Amarillo From owner-linux-xfs@oss.sgi.com Mon Feb 12 08:55:45 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 08:55:36 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:5210 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 08:55:21 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA02695 for ; Mon, 12 Feb 2001 09:04:40 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA788336; Mon, 12 Feb 2001 10:54:03 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA77594; Mon, 12 Feb 2001 10:54:03 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1CGq5L25182; Mon, 12 Feb 2001 10:52:05 -0600 Message-Id: <200102121652.f1CGq5L25182@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Sean Dougherty cc: linux-xfs@oss.sgi.com Subject: Re: Question about xfs In-Reply-To: Message from Sean Dougherty of "Mon, 12 Feb 2001 10:48:00 CST." Date: Mon, 12 Feb 2001 10:52:04 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > As I have been testing, I have crashed a few times :-). > > When I do an xfs_repair of the crashed drive, that seem to run very > well. Then I remount the drive and then delete everything on that drive > (getting set up for the next test) I have noticed that when I do a "df" > the drive shows oh between 30-40K still used. Whereas when I created the > file system (mkfs -t xfs....) a df shows about 1200 bytes used. The quick answer is that XFS allocates inodes dynamically, so as you create files, blocks of disk space are taken out of free space and made into inode blocks. When you delete files this space does not go back to being free again, but remains as free inode blocks. The free space calculation is based on the amount of space which is not used for anything, so free inode blocks do not count towards it. Hence the difference in the df report. If you were using something like ext2 then inodes are allocated at mkfs time and the space is gone from 'free space' immediately. Steve > > I am sure this has to do with the journaling and want to learn more, can > someone point me to reference where I can read up on this. Apart from the documents hanging of the oss web site there is nothing beyond the code and what is in peoples heads. http://oss.sgi.com/projects/xfs/design_docs/ Steve > > Thanks. > > Sean Dougherty > Manager of way too much > TTUHSC At Amarillo > From owner-linux-xfs@oss.sgi.com Mon Feb 12 08:56:05 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 08:55:45 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:34323 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 08:55:28 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.22 #4) id 14SMFh-0006LC-00; Mon, 12 Feb 2001 17:55:01 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14SMFc-00021J-00; Mon, 12 Feb 2001 17:54:56 +0100 Date: Mon, 12 Feb 2001 17:54:56 +0100 From: Jens Axboe To: Steve Lord Cc: Sean Dougherty , linux-xfs@oss.sgi.com Subject: Re: xfs causes machine to freeze Message-ID: <20010212175456.M1611@suse.de> References: <200102121513.f1CFDd620558@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200102121513.f1CFDd620558@jen.americas.sgi.com>; from lord@sgi.com on Mon, Feb 12, 2001 at 09:13:39AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Feb 12 2001, Steve Lord wrote: > I am attempting to merge 2.4.2-pre3 at the moment, and am running into > difficulties with the ide code - the changes in our tree and the changes > in Linus's tree do not like each other at the moment. I would hold off > on attempting to use this right now - unless you understand the ide code > very well ;-) The IDE changes to multwrite are crucial, and fix a long standing 2.3/4 bug when using multi on IDE with IRQ unmasking. Basically what you need to do to make this work, is to make _sure_ that you have setup the request for the next transfer before you do idedisk_output_data. ide_multwrite is called both from IRQ context and when the transfer is first started, so ide_multwrite can be reentered right after the transfer. I didn't notice this bug either when rewriting ide_multwrite for the kio stuff, so it has been broken too. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Mon Feb 12 10:04:05 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 10:03:46 -0800 Received: from mail15.jump.net ([206.196.91.15]:16041 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 10:03:36 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f1CI3DA21329; Mon, 12 Feb 2001 12:03:13 -0600 (CST) Message-ID: <3A882575.E69F5A07@sgi.com> Date: Mon, 12 Feb 2001 12:03:33 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephane KLEIN CC: linux-xfs@oss.sgi.com Subject: [Fwd: Re: ide-cd not loaded on boot] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Stephane - Just to be clear, you mean that this problem: > Even with a terminal sometimes the "ls -l to*" commands gives you a > list but "cp to* /tmp" does not copy all the files that matches "to*" !!!! happens even with a local disc? (not over NFS?) Thanks, -Eric > Stephane KLEIN wrote: > > Hi Eric, Thanks for your answer, As you said in your message I have decided to go further with my tests without using XFS on root partition ( but it would still be interesting to know how to do it ). I do not know if the problem I see has something to do with the ramdisk loading. During my tests I have seen very very strange behaviour with this distrib. The main part of my problems came out when I tried to use my newly installed server with our software as an NFS client to read images files shared by some IRIX and Linux nfs servers. It seems that sometimes some nfs shared files simply disapears !!!. Under havy loads I have even seen the whole nfs mounted partition that was not accessible anymore ( ls -l gives "no match" !!! ). Even with a terminal sometimes the "ls -l to*" commands gives you a list but "cp to* /tmp" does not copy all the files that matches "to*" !!!! The same tests works fine on same hardware with RH7.0. To me it seems that this distrib is far from been usable in a production environment. We are really in search of a good journaling file system to use in a pre-press environment as we did in the past with IRIX. In the near futur we are going to implement several big pre-press sites with Linux and I need to qualify a stable and relayable platform on which I could plug a 500Gb RAID. Thanks in advance for any advice, Best Regards, Stephane Klein. From owner-linux-xfs@oss.sgi.com Mon Feb 12 13:47:49 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 13:47:39 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:64564 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 13:47:16 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA10768 for ; Mon, 12 Feb 2001 13:46:13 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA14145; Tue, 13 Feb 2001 08:45:58 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA21906; Tue, 13 Feb 2001 08:45:45 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102130845.ZM115924@wobbly.melbourne.sgi.com> Date: Tue, 13 Feb 2001 08:45:43 -0400 In-Reply-To: httpd@oss.sgi.com "New XFS Survey Response" (Feb 12, 12:50pm) References: <20010212205054Z553849-486+1344@oss.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: steve@math.tamu.edu Subject: Re: Survey problem report Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Steve, > Date: Mon Feb 12, 12:50pm -0800 > Name: Steve Johnson > ... > 2.4.0-XFS seems to be _very_ stable (Jan 19, 2001). We used > this server to install images onto 56 new notebooks - not even > a hiccup. The only problem I've come across is rpc.rquotad > returns all zeroes to the client (RedHat 6.2, 2.4.0 kernel). > Yes, there was no support for XFS in rpc.rquotad at the time of that release (2.4.0-XFS) - if you obtain the quota tools from the current XFS CVS repository, this should now work. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 12 14:28:48 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 14:28:29 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:44657 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 14:28:22 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA08421 for ; Mon, 12 Feb 2001 14:28:21 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA795234 for ; Mon, 12 Feb 2001 16:27:03 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA14251 for ; Mon, 12 Feb 2001 16:27:03 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1CMP2K06561; Mon, 12 Feb 2001 16:25:02 -0600 Message-Id: <200102122225.f1CMP2K06561@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: For those people with IDE problems with XFS Date: Mon, 12 Feb 2001 16:25:02 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing If you are using the development tree and ide is blowing chunks for you, can you try the following patch, it removes some of the code added for the kio patch, and backports some changes from 2.4.2-pre3 which fix ide problems. No guarantees on this one but for me it appears to be working here. I think you can expect to see 2.4.2-pre3 in a day or so, it may be a real 2.4.2 by then. Steve =========================================================================== Index: linux/drivers/ide/ide-disk.c =========================================================================== --- /usr/tmp/TmpDir.6536-0/linux/drivers/ide/ide-disk.c_1.10 Mon Feb 12 16:21:42 2001 +++ linux/drivers/ide/ide-disk.c Mon Feb 12 15:25:18 2001 @@ -140,7 +140,7 @@ byte stat; int i; unsigned int msect, nsect; - struct request *rq = HWGROUP(drive)->rq; + struct request *rq; /* new way for dealing with premature shared PCI interrupts */ if (!OK_STAT(stat=GET_STAT(),DATA_READY,BAD_R_STAT)) { @@ -154,6 +154,7 @@ msect = drive->mult_count; read_next: + rq = HWGROUP(drive)->rq; if (msect) { if ((nsect = rq->current_nr_sectors) > msect) nsect = msect; @@ -200,7 +201,7 @@ rq->nr_sectors-1); #endif if ((rq->nr_sectors == 1) ^ ((stat & DRQ_STAT) != 0)) { - //rq->sector++; + rq->sector++; rq->buffer += 512; rq->errors = 0; i = --rq->nr_sectors; @@ -224,40 +225,53 @@ * ide_multwrite() transfers a block of up to mcount sectors of data * to a drive as part of a disk multiple-sector write operation. * - * Returns 0 if successful; returns 1 if request had to be aborted due to corrupted buffer list. + * Returns 0 on success. + * + * Note that we may be called from two contexts - the do_rw_disk context + * and IRQ context. The IRQ can happen any time after we've output the + * full "mcount" number of sectors, so we must make sure we update the + * state _before_ we output the final part of the data! */ int ide_multwrite (ide_drive_t *drive, unsigned int mcount) { ide_hwgroup_t *hwgroup= HWGROUP(drive); - struct request *rq = hwgroup->rq; - + struct request *rq = &hwgroup->wrq; + do { - unsigned int nsect = rq->current_nr_sectors; + char *buffer; + int nsect = rq->current_nr_sectors; + if (nsect > mcount) nsect = mcount; mcount -= nsect; + buffer = rq->buffer; - idedisk_output_data(drive, rq->buffer, nsect<<7); -#ifdef DEBUG - printk("%s: multwrite: sector %ld, buffer=0x%08lx, count=%d, remaining=%ld\n", - drive->name, rq->sector, (unsigned long) rq->buffer, - nsect, rq->nr_sectors - nsect); -#endif -#ifdef CONFIG_BLK_DEV_PDC4030 rq->sector += nsect; -#endif - if (((long)(rq->nr_sectors -= nsect)) <= 0) { -#ifdef DEBUG - printk("%s: multwrite: count=%d, current=%ld\n", - drive->name, nsect, rq->nr_sectors); -#endif - break; + rq->buffer += nsect << 9; + rq->nr_sectors -= nsect; + rq->current_nr_sectors -= nsect; + + /* Do we move to the next bh after this? */ + if (!rq->current_nr_sectors) { + struct buffer_head *bh = rq->bh->b_reqnext; + + /* end early early we ran out of requests */ + if (!bh) { + mcount = 0; + } else { + rq->bh = bh; + rq->current_nr_sectors = bh->b_size >> 9; + rq->buffer = bh->b_data; + } } - if ((rq->current_nr_sectors -= nsect) == 0) - ide_end_request(1, hwgroup); - else - rq->buffer += nsect << 9; + + /* + * Ok, we're all setup for the interrupt + * re-entering us on the last transfer. + */ + idedisk_output_data(drive, buffer, nsect<<7); } while (mcount); + return 0; } @@ -267,8 +281,9 @@ static ide_startstop_t multwrite_intr (ide_drive_t *drive) { byte stat; + int i; ide_hwgroup_t *hwgroup = HWGROUP(drive); - struct request *rq = hwgroup->rq; + struct request *rq = &hwgroup->wrq; if (OK_STAT(stat=GET_STAT(),DRIVE_READY,drive->bad_wstat)) { if (stat & DRQ_STAT) { @@ -283,10 +298,20 @@ return ide_started; } } else { - if (!rq->nr_sectors) - ide_end_request(1, hwgroup); + /* + * If the copy has all the blocks completed then + * we can end the original request. + */ + if (!rq->nr_sectors) { /* all done? */ + rq = hwgroup->rq; + for (i = rq->nr_sectors; i > 0;){ + i -= rq->current_nr_sectors; + ide_end_request(1, hwgroup); + } + return ide_stopped; + } } - return ide_stopped; + return ide_stopped; /* the original code did this here (?) */ } return ide_error(drive, "multwrite_intr", stat); } @@ -423,6 +448,7 @@ * * Except when you get an error it seems... */ + hwgroup->wrq = *rq; /* scratchpad */ ide_set_handler (drive, &multwrite_intr, WAIT_CMD, NULL); if (ide_multwrite(drive, drive->mult_count)) { unsigned long flags; =========================================================================== Index: linux/drivers/ide/ide.c =========================================================================== --- /usr/tmp/TmpDir.6536-0/linux/drivers/ide/ide.c_1.16 Mon Feb 12 16:21:42 2001 +++ linux/drivers/ide/ide.c Mon Feb 12 15:25:28 2001 @@ -512,6 +512,8 @@ if ((nr_sectors = rq->hard_nr_sectors) > 256) nr_sectors = 256; + blk_finished_io(sectors); + nr_pages = rq->kiobuf->nr_pages; total_bytes = nr_sectors << 9; curr_offset = rq->kiobuf->offset; =========================================================================== Index: linux/drivers/ide/pdc4030.c =========================================================================== --- /usr/tmp/TmpDir.6536-0/linux/drivers/ide/pdc4030.c_1.3 Mon Feb 12 16:21:42 2001 +++ linux/drivers/ide/pdc4030.c Mon Feb 12 15:25:38 2001 @@ -453,7 +453,7 @@ static ide_startstop_t promise_write (ide_drive_t *drive) { ide_hwgroup_t *hwgroup = HWGROUP(drive); - struct request *rq = hwgroup->rq; + struct request *rq = &hwgroup->wrq; #ifdef DEBUG_WRITE printk(KERN_DEBUG "%s: promise_write: sectors(%ld-%ld), " @@ -541,6 +541,7 @@ } if (!drive->unmask) __cli(); /* local CPU only */ + HWGROUP(drive)->wrq = *rq; /* scratchpad */ return promise_write(drive); } else { =========================================================================== Index: linux/include/linux/ide.h =========================================================================== --- /usr/tmp/TmpDir.6536-0/linux/include/linux/ide.h_1.26 Mon Feb 12 16:21:42 2001 +++ linux/include/linux/ide.h Mon Feb 12 15:23:31 2001 @@ -497,6 +497,7 @@ ide_hwif_t *hwif; /* ptr to current hwif in linked-list */ struct request *rq; /* current request */ struct timer_list timer; /* failsafe timer */ + struct request wrq; /* local copy of current write rq */ unsigned long poll_timeout; /* timeout value during long polls */ ide_expiry_t *expiry; /* queried upon timeouts */ } ide_hwgroup_t; From owner-linux-xfs@oss.sgi.com Mon Feb 12 14:53:08 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 14:52:59 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:40262 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 14:52:37 -0800 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA19462 for ; Mon, 12 Feb 2001 14:51:34 -0800 (PST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.66.65]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA29964 for ; Mon, 12 Feb 2001 14:55:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 41BBB13A for ; Mon, 12 Feb 2001 14:50:59 -0800 (PST) Subject: Re: kgcc now required ?? From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: <20010211180214.J16362@suse.de> References: <200102111503.f1BF3lH19265@jen.americas.sgi.com> <20010211180214.J16362@suse.de> Content-Type: multipart/mixed; boundary="=-SrsrVcv+6dV2Lmg8NRKP" X-Mailer: Evolution (0.8/+cvs.2001.02.10.08.59 - Preview Release) Date: 12 Feb 2001 14:50:59 -0800 Mime-Version: 1.0 Message-Id: <20010212225059.41BBB13A@stantz.corp.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --=-SrsrVcv+6dV2Lmg8NRKP Content-Type: text/plain On 11 Feb 2001 18:02:14 +0100, Jens Axboe wrote: > > But can we at least get a decent work-around, that doesn't barf > if kgcc isn't available? It seems rather silly to assume gcc > is borken. I think the best way is to: - copy the CC= line from the Makefile from vanilla 2.2.18 and put it instead of your CC= line in your kernel's Makefile - then copy /usr/src/linux-*/scripts/kwhich from 2.2.18 and put it into scripts/ subdirectory of your kernel tree See attach. -- Florin Andrei --=-SrsrVcv+6dV2Lmg8NRKP Content-Type: text/plain Content-Disposition: attachment; filename=kwhich Content-Transfer-Encoding: 7bit # kwhich 1.0 (C) 2000 Miquel van Smoorenburg # This program is GPLed if [ $# -lt 1 ] then echo "Usage: $0 cmd [cmd..]" >&2 exit 1 fi IFS=: for cmd in $* do for path in $PATH do if [ -x "$path/$cmd" ] then echo "$path/$cmd" exit 0 fi done done echo "$*: not found" >&2 exit 1 --=-SrsrVcv+6dV2Lmg8NRKP Content-Type: text/x-makefile Content-Disposition: attachment; filename=Makefile.part Content-Transfer-Encoding: 7bit CC =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)gcc; else \ $(CONFIG_SHELL) scripts/kwhich gcc272 2>/dev/null || $(CONFIG_SHELL) scripts/kwhich kgcc 2>/dev/null || echo cc; fi) \ -D__KERNEL__ -I$(HPATH) --=-SrsrVcv+6dV2Lmg8NRKP-- From owner-linux-xfs@oss.sgi.com Mon Feb 12 16:14:09 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 16:13:49 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:6945 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 16:13:24 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA02612 for ; Mon, 12 Feb 2001 16:13:23 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA11123 for ; Mon, 12 Feb 2001 18:12:07 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f1D0B8030021 for ; Mon, 12 Feb 2001 18:11:08 -0600 Message-ID: <3A887B9A.FA1B4178@thebarn.com> Date: Mon, 12 Feb 2001 18:11:06 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Syncing problems. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hmm looks like we are not always writing stuff out. This system was up for several minutes before I locked it up. This file has size but no extents. chuckle[5:45pm]#less /etc/raidtab ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ chuckle[6:08pm]#xfs_bmap /etc/raidtab /etc/raidtab: no extents -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Feb 12 16:38:59 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 16:38:39 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:53033 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 16:38:07 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA00380 for ; Mon, 12 Feb 2001 16:37:59 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA40516 for ; Mon, 12 Feb 2001 18:36:43 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.2/8.11.0) id f1D0Zhx30286 for linux-xfs@oss.sgi.com; Mon, 12 Feb 2001 18:35:43 -0600 Date: Mon, 12 Feb 2001 18:35:43 -0600 From: Russell Cattelan Message-Id: <200102130035.f1D0Zhx30286@gibble.americas.sgi.com> Subject: TAKE - Compiler independence fix To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing With this fix XFS does appear to work correctly. I have not seen the block beyond end of device problem yet, but it may still be lurking. Date: Mon Feb 12 16:33:03 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:87361a linux/fs/xfs/xfs_log.h - 1.55 - This removes the "inline" from the lsn_cmp function. This function appears to be incorrectly compiled by the gcc 2.95.x compiler. This does produce a warning messages when compiling with the 2.95 compiler fixing this would require code restructuring which would be incompatible with the irix source. Hopefully the compiler will be fixed in the future and the inline can be restored. From owner-linux-xfs@oss.sgi.com Mon Feb 12 18:09:31 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 18:09:11 -0800 Received: from relay02.sportsline.com ([63.72.118.49]:45069 "HELO relay02.sportsline.com") by oss.sgi.com with SMTP id ; Mon, 12 Feb 2001 18:08:53 -0800 Received: (qmail 2134 invoked from network); 13 Feb 2001 02:08:51 -0000 Received: from chipsworld.llamas.net (63.77.33.226) by relay02.sportsline.com with SMTP; 13 Feb 2001 02:08:51 -0000 Received: from localhost (chipper@localhost) by chipsworld.llamas.net (8.11.0/8.11.0) with ESMTP id f1D28o307558; Mon, 12 Feb 2001 21:08:50 -0500 Date: Mon, 12 Feb 2001 21:08:50 -0500 (EST) From: "Chris 'Chipper' Chiapusio" To: Steve Lord cc: Sean Dougherty , Subject: Re: xfs causes machine to freeze In-Reply-To: <200102111705.f1BH5IM19540@jen.americas.sgi.com> Message-ID: X-Files: Resist or serve MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, 11 Feb 2001, Steve Lord wrote: > >We have seen some cases where XFS deadlocks under heavy memory pressure, >we end up trying to free memory from a code path which has xfs locks, >the freeing of memory requires other xfs locks and sometimes a dependency >between the two can cause a hang. Something that I have seen is while FTP GET'ing data to a local XFS FS, aftar a while free memory disappears rapidly and when it is completly depleted the machine appears to freeze, but if I stop the FTP (running at full 100Mb/s) soon enough, i can watch (in vmstat) the data get flushed to disk in slow, even increments. During this flushing time, read I/O performance suffers (FTP PUT'ing data back to the other host), but as soon as I see the flushes stop, read preformance goes back up. > >There are changes in the current development cvs tree which may fix this, >we know that it is not bug free right now, and are working on it. In the >meantime, could you possibly try a kernel built from the development tree >and let us know if you can hang it in the same way. > >Steve I'll get current CVS and test the FS flushing issues and the module symbols items again. Chipper ------ Please encrypt anything important. PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D From owner-linux-xfs@oss.sgi.com Mon Feb 12 18:11:31 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 18:11:12 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:30578 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 18:11:06 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA12925 for ; Mon, 12 Feb 2001 18:10:04 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA796978; Mon, 12 Feb 2001 20:09:49 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA35685; Mon, 12 Feb 2001 20:09:48 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1D27kc07973; Mon, 12 Feb 2001 20:07:46 -0600 Message-Id: <200102130207.f1D27kc07973@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Russell Cattelan cc: linux-xfs@oss.sgi.com Subject: Re: Syncing problems. In-Reply-To: Message from Russell Cattelan of "Mon, 12 Feb 2001 18:11:06 CST." <3A887B9A.FA1B4178@thebarn.com> Date: Mon, 12 Feb 2001 20:07:46 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Yes, some of the email from this weeking suggested as much, I changed how we look for delalloc pages. Instead of scanning the complete page array, we scan the inactive dirty list. It looks like not all the delalloc pages are making it onto this list - or the logic in the cleaner thread is always leaving some pages dirty. How long before you went down do you think the file was updated? Steve > Hmm looks like we are not always writing stuff out. > > This system was up for several minutes before I locked it up. > This file has size but no extents. > > chuckle[5:45pm]#less /etc/raidtab > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > @^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > chuckle[6:08pm]#xfs_bmap /etc/raidtab > /etc/raidtab: no extents > > > -- > Russell Cattelan > -- > Digital Elves inc. -- Currently on loan to SGI > Linux XFS core developer. > > From owner-linux-xfs@oss.sgi.com Mon Feb 12 22:52:43 2001 Received: by oss.sgi.com id ; Mon, 12 Feb 2001 22:52:24 -0800 Received: from pipt.oz.cc.utah.edu ([155.99.2.7]:50411 "EHLO pipt.oz.cc.utah.edu") by oss.sgi.com with ESMTP id ; Mon, 12 Feb 2001 22:52:08 -0800 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id XAA09356 for ; Mon, 12 Feb 2001 23:51:56 -0700 (MST) Date: Mon, 12 Feb 2001 23:51:56 -0700 (MST) From: james rich To: linux-xfs@oss.sgi.com Subject: make fails in cmd/* directories Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I know I must be missing something simple but I haven't found it yet. When I try to build anything in cmd/* the build fails. I do: autoconf configure --prefix=/usr make Make dies with: root@growler:/usr/src/linux-2.4-xfs/cmd/xfsprogs# make === include === gcc: default: No such file or directory make: *** [default] Error 1 What am I doing wrong? I searched the mail archives and didn't find anything similar to this. James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Tue Feb 13 02:03:55 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 02:03:34 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:24112 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 02:03:09 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id CAA16207 for ; Tue, 13 Feb 2001 02:02:05 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA19661; Tue, 13 Feb 2001 21:01:50 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id VAA21080; Tue, 13 Feb 2001 21:01:49 +1100 (EDT) Date: Tue, 13 Feb 2001 21:01:48 +1100 From: Nathan Scott To: james rich Cc: linux-xfs@oss.sgi.com Subject: Re: make fails in cmd/* directories Message-ID: <20010213210148.A124188@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from james.rich@m.cc.utah.edu on Mon, Feb 12, 2001 at 11:51:56PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi James, On Mon, Feb 12, 2001 at 11:51:56PM -0700, james rich wrote: > I know I must be missing something simple but I haven't found it yet. > When I try to build anything in cmd/* the build fails. I do: > > autoconf > configure --prefix=/usr > make > "make" is enough, but the above should work. There's more docs in cmd/xfsprogs/PORTING on the build process if needed. > Make dies with: > > root@growler:/usr/src/linux-2.4-xfs/cmd/xfsprogs# make > === include === > gcc: default: No such file or directory > make: *** [default] Error 1 > hmmm - I've never seen this one before. Which distribution are you using? make --version output? What does your environment look like (env(1) output)? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 13 02:04:04 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 02:03:55 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:38153 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 02:03:43 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id KAA17277; Tue, 13 Feb 2001 10:59:57 +0100 Date: Tue, 13 Feb 2001 10:59:57 +0100 From: Krzysztof Rusocki To: linux-kernel@vger.kernel.org Cc: linux-xfs@oss.sgi.com Subject: [?] __alloc_pages: 1-order allocation failed. Message-ID: <20010213105957.A16713@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, Here's what i've found today in logs: Feb 13 02:10:41 main kernel: __alloc_pages: 1-order allocation failed. Feb 13 02:10:42 main last message repeated 143 times Feb 13 02:10:47 main kernel: ed. Feb 13 02:10:47 main kernel: __alloc_pages: 1-order allocation failed. Feb 13 02:50:30 main syslogd 1.3-3: restart (remote reception). After that there was possibly lock-up or reboot (i don't know, when i connected to the machine it was already running). What can be possible cause of such things ? I am running 2.4.1-XFS (2001/02/10) on a Mendocino 366/128MB/VT82C596A/PDC20262. Regards, - Krzysztof PS. lkml subscribers: please reply to my email if it's possible :) From owner-linux-xfs@oss.sgi.com Tue Feb 13 05:10:05 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 05:09:45 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:58888 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 05:09:18 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id OAA08195; Tue, 13 Feb 2001 14:09:10 +0100 Date: Tue, 13 Feb 2001 14:09:10 +0100 From: Krzysztof Rusocki To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: [?] __alloc_pages: 1-order allocation failed. Message-ID: <20010213140910.C4452@main.braxis.co.uk> References: <20010213105957.A16713@main.braxis.co.uk> <200102131204.f1DC4lN09967@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102131204.f1DC4lN09967@jen.americas.sgi.com>; from lord@sgi.com on Tue, Feb 13, 2001 at 06:04:47AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Feb 13, 2001 at 06:04:47AM -0600, Steve Lord wrote: > > This is almost certainly xfs getting itself tied in knots, the development > tree is a bit unstable under heavy load right now. Do you know what you were > doing prior to this, and how much memory do you have? > > Steve > Unfortunately i'm not able to say what's going on the system till those printk's (this is a remote machine - i wasn't logged in). I am not running process monitor or any program of that kind.. (can you point me one?). All i can provide right now are previous syslog entries, tell me if you want them but i have to say there's nothing unusual there ... (standard sshd2/sendmail/identd/PAM/bind messages). Krzysztof From owner-linux-xfs@oss.sgi.com Tue Feb 13 05:15:45 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 05:15:35 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:50035 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 05:15:13 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA06165 for ; Tue, 13 Feb 2001 05:15:12 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA799713; Tue, 13 Feb 2001 07:13:55 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA65507; Tue, 13 Feb 2001 07:13:55 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1DDBlJ11350; Tue, 13 Feb 2001 07:11:47 -0600 Message-Id: <200102131311.f1DDBlJ11350@jen.americas.sgi.com> To: Krzysztof Rusocki cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: [?] __alloc_pages: 1-order allocation failed. References: <20010213105957.A16713@main.braxis.co.uk> <200102131204.f1DC4lN09967@jen.americas.sgi.com> <20010213140910.C4452@main.braxis.co.uk> Comments: In-reply-to Krzysztof Rusocki message dated "Tue, 13 Feb 2001 14:09:10 +0100." Date: Tue, 13 Feb 2001 07:11:47 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Tue, Feb 13, 2001 at 06:04:47AM -0600, Steve Lord wrote: > > > > This is almost certainly xfs getting itself tied in knots, the development > > tree is a bit unstable under heavy load right now. Do you know what you wer > e > > doing prior to this, and how much memory do you have? > > > > Steve > > > > Unfortunately i'm not able to say what's going on the system till those > printk's (this is a remote machine - i wasn't logged in). I am not running > process monitor or any program of that kind.. (can you point me one?). > All i can provide right now are previous syslog entries, tell me if you > want them but i have to say there's nothing unusual there ... > (standard sshd2/sendmail/identd/PAM/bind messages). > > Krzysztof Do you have any cron jobs which do recursive finds during the night? If so, is there any correspondence time wise? You could still answer the memory question - I need to know if I should push down the memory on my system more during testing. Steve From owner-linux-xfs@oss.sgi.com Tue Feb 13 05:57:35 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 05:57:25 -0800 Received: from ns.suse.de ([213.95.15.193]:49937 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Tue, 13 Feb 2001 05:57:08 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id B05881E1B3; Tue, 13 Feb 2001 14:57:06 +0100 (MET) Date: Tue, 13 Feb 2001 14:56:10 +0100 From: Andi Kleen To: Krzysztof Rusocki Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [?] __alloc_pages: 1-order allocation failed. Message-ID: <20010213145610.A16767@gruyere.muc.suse.de> References: <20010213105957.A16713@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010213105957.A16713@main.braxis.co.uk>; from kszysiu@braxis.co.uk on Tue, Feb 13, 2001 at 10:59:57AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Feb 13, 2001 at 10:59:57AM +0100, Krzysztof Rusocki wrote: > > Hi, > > Here's what i've found today in logs: > > Feb 13 02:10:41 main kernel: __alloc_pages: 1-order allocation failed. > Feb 13 02:10:42 main last message repeated 143 times > Feb 13 02:10:47 main kernel: ed. > Feb 13 02:10:47 main kernel: __alloc_pages: 1-order allocation failed. > Feb 13 02:50:30 main syslogd 1.3-3: restart (remote reception). > > > After that there was possibly lock-up or reboot (i don't know, when i > connected to the machine it was already running). > > What can be possible cause of such things ? When you add the following patch you should see the addresses of functions that cause allocation failures. Look the hex value up in the System.map then. For this XFS should be compiled in, not be a module. Is it always the same address? -Andi Index: mm/page_alloc.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/mm/page_alloc.c,v retrieving revision 1.32 diff -u -r1.32 page_alloc.c --- mm/page_alloc.c 2000/12/17 19:15:00 1.32 +++ mm/page_alloc.c 2001/02/13 13:54:33 @@ -529,7 +529,8 @@ } /* No luck.. */ - printk(KERN_ERR "__alloc_pages: %lu-order allocation failed.\n", order); + printk(KERN_ERR "__alloc_pages: %lu-order allocation failed from %p\n", + order, __builtin_return_address(0)); return NULL; } From owner-linux-xfs@oss.sgi.com Tue Feb 13 06:06:45 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 06:06:36 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:42506 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 06:06:24 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id PAA11491; Tue, 13 Feb 2001 15:00:33 +0100 Date: Tue, 13 Feb 2001 15:00:32 +0100 From: Krzysztof Rusocki To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: [?] __alloc_pages: 1-order allocation failed. Message-ID: <20010213150032.A8601@main.braxis.co.uk> References: <20010213105957.A16713@main.braxis.co.uk> <200102131204.f1DC4lN09967@jen.americas.sgi.com> <20010213140910.C4452@main.braxis.co.uk> <200102131311.f1DDBlJ11350@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102131311.f1DDBlJ11350@jen.americas.sgi.com>; from lord@sgi.com on Tue, Feb 13, 2001 at 07:11:47AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Do you have any cron jobs which do recursive finds during the night? > If so, is there any correspondence time wise? > > You could still answer the memory question - I need to know if I should > push down the memory on my system more during testing. > > Steve Actually, i do have cron jobs.. but they were NOT executed before that printk's... I've just installed processlogger http://freshmeat.net/projects/procmon/ - in case of any crash .. i'll have somewhat of process information... Only memory info i can provide is "free" output (no console, no sysrqs) total used free shared buffers cached Mem: 126516 124992 1524 0 1280 77888 -/+ buffers/cache: 45824 80692 Swap: 136544 0 136544 and /proc/meminfo output: total: used: free: shared: buffers: cached: Mem: 129552384 127528960 2023424 0 2088960 75046912 Swap: 139821056 0 139821056 MemTotal: 126516 kB MemFree: 1976 kB MemShared: 0 kB Buffers: 2040 kB Cached: 73288 kB Active: 21092 kB Inact_dirty: 45844 kB Inact_clean: 8392 kB Inact_target: 396 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 126516 kB LowFree: 1976 kB SwapTotal: 136544 kB SwapFree: 136544 kB [ it's information from the present.. not the moment of crash, of course.. currently i'm running 2.4.1-XFS (2001/02/10) with patched MM - http://www.uwsg.indiana.edu/hypermail/linux/kernel/0102.1/0827.html with ide-patch from you and linux/net part from 2.4.1-ac8 (hope that it doesn't matter) can that crash be related to running out of disk space on /home ? (it could happen that time... and /home is ext2, not XFS) Krzysztof From owner-linux-xfs@oss.sgi.com Tue Feb 13 08:33:16 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 08:32:56 -0800 Received: from cortex.ama.ttuhsc.edu ([168.49.129.1]:40972 "EHLO cortex.ama.ttuhsc.edu") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 08:32:40 -0800 Received: (from sean@localhost) by cortex.ama.ttuhsc.edu (8.10.2/8.10.2) id f1DGVfo17192; Tue, 13 Feb 2001 10:31:41 -0600 (CST) Date: Tue, 13 Feb 2001 10:31:41 -0600 (CST) From: Sean Dougherty To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: FYI In-Reply-To: <200102131311.f1DDBlJ11350@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I tried the cvs development tree...prior to the patch you sent on this list yesterday. Same freezing problems. I am trying this morning with the patch. The tests are now being run on one pentium II(266) 128M maxtor drives PIIX and Promise controllers and one athalon (1G) 528M maxtor drives VIA82XX and Promise controllers I will let you know how it goes. From owner-linux-xfs@oss.sgi.com Tue Feb 13 08:38:16 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 08:37:57 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:22901 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 08:37:51 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA03119 for ; Tue, 13 Feb 2001 08:47:11 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA766578; Tue, 13 Feb 2001 10:36:33 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA17384; Tue, 13 Feb 2001 10:36:33 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1DGcBR11554; Tue, 13 Feb 2001 10:38:11 -0600 Message-Id: <200102131638.f1DGcBR11554@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Sean Dougherty cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: FYI In-Reply-To: Message from Sean Dougherty of "Tue, 13 Feb 2001 10:31:41 CST." Date: Tue, 13 Feb 2001 10:38:11 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > I tried the cvs development tree...prior to the patch you sent on this > list yesterday. > > Same freezing problems. > > I am trying this morning with the patch. The tests are now being run on > one pentium II(266) 128M maxtor drives PIIX and Promise controllers > and > one athalon (1G) 528M maxtor drives VIA82XX and Promise controllers > > I will let you know how it goes. > This patch has worked for me when using dma on ide, and when using the multwrite path. If you turn on kiobufs with the kio mount option, you have to use dma, the multwrite path will panic your system. We are working on the complete fix. i.e. if you setup a system using hdparm -d0 -m16 /dev/hdX you cannot currently use the kio mount option. Steve From owner-linux-xfs@oss.sgi.com Tue Feb 13 09:09:18 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 09:08:59 -0800 Received: from pipt.oz.cc.utah.edu ([155.99.2.7]:39330 "EHLO pipt.oz.cc.utah.edu") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 09:08:49 -0800 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id KAA28261 for ; Tue, 13 Feb 2001 10:08:37 -0700 (MST) Date: Tue, 13 Feb 2001 10:08:36 -0700 (MST) From: james rich To: linux-xfs@oss.sgi.com Subject: More on failing build of cmd/* Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing First I apologize for not keeping the same thread going here. I'm on different machines today and can't use reply. I wrote earlier: > When I try to build anything in cmd/* the build fails. I do: > > autoconf > configure --prefix=/usr > make I know 'make' should do all this but I wanted to specify --prefix (wasn't sure what the default is). > Make dies with: > > root@growler:/usr/src/linux-2.4-xfs/cmd/xfsprogs# make > === include === > gcc: default: No such file or directory > make: *** [default] Error 1 I am using Slackware 7.1. make --version = GNU Make version 3.79. I had to link kgcc to gcc (egcs-2.91.66) to build the kernel (which built fine). I built the xfsprogs without problem with the beta release. This is from last night cvs. The first rule in cmd/xfsprogs/Makefile is default: $(CONFIGURE) ifeq ($(HAVE_BUILDDEFS), no) $(MAKE) -C . $@ else $(SUBDIRS_MAKERULE) endif and then later down: install: default $(SUBDIRS_MAKERULE) (etc...) It looks like make is trying to build a file called 'default' which in cmd/xfsprogs/include/Makefile is the first rule: default install : the above line looks wrong? James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Tue Feb 13 09:20:48 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 09:20:28 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49019 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 09:20:22 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA00315 for ; Tue, 13 Feb 2001 09:29:42 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA802267; Tue, 13 Feb 2001 11:19:04 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA49237; Tue, 13 Feb 2001 11:19:04 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1DHKft14229; Tue, 13 Feb 2001 11:20:41 -0600 Message-Id: <200102131720.f1DHKft14229@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: james rich cc: linux-xfs@oss.sgi.com Subject: Re: More on failing build of cmd/* In-Reply-To: Message from james rich of "Tue, 13 Feb 2001 10:08:36 MST." Date: Tue, 13 Feb 2001 11:20:41 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I can run the same sequence here successfully, I notice that the first output from make is this: === include === make[1]: Nothing to be done for `default'. === libxfs === I am running: Autoconf version 2.13 GNU Make version 3.79.1 both from redhat 7 I seem to recall there being one more package involved in the config process, but I cannot remember what it is. I suspect this is an autoconf or make version issue. The folks who work on this are in Australia, so it will be a few hours before they can respond. but that line does look wierd. Steve > First I apologize for not keeping the same thread going here. I'm on > different machines today and can't use reply. > > I wrote earlier: > > > When I try to build anything in cmd/* the build fails. I do: > > > > autoconf > > configure --prefix=/usr > > make > > I know 'make' should do all this but I wanted to specify --prefix (wasn't > sure what the default is). > > > Make dies with: > > > > root@growler:/usr/src/linux-2.4-xfs/cmd/xfsprogs# make > > === include === > > gcc: default: No such file or directory > > make: *** [default] Error 1 > > I am using Slackware 7.1. make --version = GNU Make version 3.79. I had > to link kgcc to gcc (egcs-2.91.66) to build the kernel (which built fine). > > I built the xfsprogs without problem with the beta release. This is from > last night cvs. > > The first rule in cmd/xfsprogs/Makefile is > > default: $(CONFIGURE) > ifeq ($(HAVE_BUILDDEFS), no) > $(MAKE) -C . $@ > else > $(SUBDIRS_MAKERULE) > endif > > and then later down: > > install: default > $(SUBDIRS_MAKERULE) > (etc...) > > It looks like make is trying to build a file called 'default' which in > cmd/xfsprogs/include/Makefile is the first rule: > > default install : > > the above line looks wrong? > > James Rich > james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Tue Feb 13 10:04:47 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 10:04:37 -0800 Received: from moe.rice.edu ([128.42.5.4]:33508 "EHLO moe.rice.edu") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 10:04:23 -0800 Received: from photino.sid.rice.edu (photino.sid.rice.edu [128.42.162.116]) by moe.rice.edu (8.9.0/8.9.0) with ESMTP id MAA11578; Tue, 13 Feb 2001 12:04:18 -0600 (CST) Received: (from rjain@localhost) by photino.sid.rice.edu (8.11.2/8.11.2/Debian 8.11.2-1) id f1DI4IQ03296; Tue, 13 Feb 2001 12:04:18 -0600 Date: Tue, 13 Feb 2001 12:04:18 -0600 From: Rahul Jain To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [?] __alloc_pages: 1-order allocation failed. Message-ID: <20010213120418.A2468@photino.sid.rice.edu> Reply-To: Rahul Jain References: <20010213105957.A16713@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20010213105957.A16713@main.braxis.co.uk>; from kszysiu@braxis.co.uk on Tue, Feb 13, 2001 at 10:59:57AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Feb 13, 2001 at 10:59:57AM +0100, Krzysztof Rusocki wrote: > > Hi, > > Here's what i've found today in logs: > > Feb 13 02:10:41 main kernel: __alloc_pages: 1-order allocation failed. > Feb 13 02:10:42 main last message repeated 143 times > Feb 13 02:10:47 main kernel: ed. > Feb 13 02:10:47 main kernel: __alloc_pages: 1-order allocation failed. > Feb 13 02:50:30 main syslogd 1.3-3: restart (remote reception). > I typically get thousands of such messages when using my SCSI CDRW (I think it's specifically when I'm cat'ing or dd'ing from the drive. Specifically, I get 2- and 3-order allocation failures. I'll use the patch Andi Kleen posted to track down the exact locations of these errors. There seem to be no ill effects at all from these errors. -- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request. From owner-linux-xfs@oss.sgi.com Tue Feb 13 10:38:58 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 10:38:48 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:6405 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 10:38:29 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA00282 for ; Tue, 13 Feb 2001 10:38:28 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA804800; Tue, 13 Feb 2001 12:37:10 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA98387; Tue, 13 Feb 2001 12:37:10 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1DIci514428; Tue, 13 Feb 2001 12:38:44 -0600 Message-Id: <200102131838.f1DIci514428@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Rahul Jain cc: linux-xfs@oss.sgi.com Subject: Re: [?] __alloc_pages: 1-order allocation failed. In-Reply-To: Message from Rahul Jain of "Tue, 13 Feb 2001 12:04:18 CST." <20010213120418.A2468@photino.sid.rice.edu> Date: Tue, 13 Feb 2001 12:38:44 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Tue, Feb 13, 2001 at 10:59:57AM +0100, Krzysztof Rusocki wrote: > > > > Hi, > > > > Here's what i've found today in logs: > > > > Feb 13 02:10:41 main kernel: __alloc_pages: 1-order allocation failed. > > Feb 13 02:10:42 main last message repeated 143 times > > Feb 13 02:10:47 main kernel: ed. > > Feb 13 02:10:47 main kernel: __alloc_pages: 1-order allocation failed. > > Feb 13 02:50:30 main syslogd 1.3-3: restart (remote reception). > > > > I typically get thousands of such messages when using my SCSI CDRW (I think > it's specifically when I'm cat'ing or dd'ing from the drive. Specifically, I > get 2- and 3-order allocation failures. I'll use the patch Andi Kleen posted > to > track down the exact locations of these errors. There seem to be no ill effec > ts > at all from these errors. > Was that an XFS kernel or just a regular kernel? Since you posted to both lists I was not not sure. We are working on cleaning up XFS's memory hogging behavior right now. Steve From owner-linux-xfs@oss.sgi.com Tue Feb 13 10:54:48 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 10:54:37 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23053 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 10:54:21 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA04925 for ; Tue, 13 Feb 2001 11:03:41 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA800321 for ; Tue, 13 Feb 2001 12:53:04 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA28220 for ; Tue, 13 Feb 2001 12:53:04 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f1DIscN14561; Tue, 13 Feb 2001 12:54:38 -0600 Message-Id: <200102131854.f1DIscN14561@jen.americas.sgi.com> Date: Tue, 13 Feb 2001 12:54:38 -0600 Subject: TAKE - fix delalloc data not getting flushed to disk To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing There were some cases where delalloc data would never get flushed out to disk unless you unmounted the filesystem, specifically the tail end of files (or all of small files) when there was insufficient memory pressure to push them onto the inactive dirty list. This adds explicit aging on these pages so that they will get flushed soon after being written to. This should fix most of the problems people have had with missing data after a crash. Note that missing data is still possible in the case where the file size gets updated on disk and the data does not get written out before a crash, the window is just smaller now. This can happen in all filesystems if the inode gets on to disk before the data. Date: Tue Feb 13 10:47:43 PST 2001 Workarea: 128.162.184.86:/src/lord/merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:87434a linux/fs/pagebuf/page_buf.c - 1.53 - Fix one more case where we need to be careful about how we allocate memory. linux/fs/pagebuf/page_buf_io.c - 1.51 - Add some explicit aging of delalloc pages out of the active list, without this there are cases where delalloc just sits in memory until we unmount. From owner-linux-xfs@oss.sgi.com Tue Feb 13 14:04:39 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 14:04:29 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:22553 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 14:04:01 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA11184 for ; Tue, 13 Feb 2001 14:02:58 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA20646; Tue, 13 Feb 2001 13:58:11 -0800 (PST) Message-ID: <3A89AEC1.209C05D4@sgi.com> Date: Tue, 13 Feb 2001 14:01:37 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: Syncing problems. References: <200102130207.f1D27kc07973@jen.americas.sgi.com> Content-Type: multipart/mixed; boundary="------------A2EBF1DC8F024061DE467590" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------A2EBF1DC8F024061DE467590 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Hmm looks like we are not always writing stuff out. > > > > This system was up for several minutes before I locked it up. > > This file has size but no extents. > > It may also be the case I ran into recently: when writepage is employed to convert a delalloc page, prepare/commit_write is used to convert a page if the page falls at EOF. In this case, writepage used PBF_FILE_ALLOCATE, but prepare_write doesn't honor that. Can you try the attached (but untested) patch? ---- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- --------------A2EBF1DC8F024061DE467590 Content-Type: text/plain; charset=us-ascii; name="prepare-write.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="prepare-write.patch" --- /usr/tmp/TmpDir.25410-0/linux/fs/pagebuf/page_buf_io.c_1.51 Tue Feb 13 13:56:53 2001 +++ linux/fs/pagebuf/page_buf_io.c Tue Feb 13 13:56:01 2001 @@ -1248,7 +1248,7 @@ * go get some space. */ bh = page->buffers; - if ((!bh || !buffer_mapped(bh)) && !DelallocPage(page)) { + if ((!bh || !buffer_mapped(bh)) && (!DelallocPage(page) || (flags & PBF_FILE_ALLOCATE))) { if (!mp) { mp = ↦ err = inode->i_op->pagebuf_bmap(inode, --------------A2EBF1DC8F024061DE467590-- From owner-linux-xfs@oss.sgi.com Tue Feb 13 14:32:38 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 14:32:29 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:54386 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 14:32:11 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id OAA08115 for ; Tue, 13 Feb 2001 14:32:04 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA24261; Wed, 14 Feb 2001 09:30:48 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA27047; Wed, 14 Feb 2001 09:30:46 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102140930.ZM127044@wobbly.melbourne.sgi.com> Date: Wed, 14 Feb 2001 09:30:45 -0400 In-Reply-To: james rich "More on failing build of cmd/*" (Feb 13, 10:08am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: james rich , linux-xfs@oss.sgi.com Subject: Re: More on failing build of cmd/* Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Feb 13, 10:08am, james rich wrote: > Subject: More on failing build of cmd/* > First I apologize for not keeping the same thread going here. I'm on > different machines today and can't use reply. > > I wrote earlier: > > > When I try to build anything in cmd/* the build fails. I do: > > > > autoconf > > configure --prefix=/usr > > make > > I know 'make' should do all this but I wanted to specify --prefix (wasn't > sure what the default is). > /usr is the default for most things (not mkfs.xfs and xfs_repair). > > Make dies with: > > > > root@growler:/usr/src/linux-2.4-xfs/cmd/xfsprogs# make > > === include === > > gcc: default: No such file or directory > > make: *** [default] Error 1 > do you have an environment variable "MAKE" set to "gcc"? I can reproduce your problem if I do this ... xfsprogs 40> setenv MAKE gcc xfsprogs 41> autoconf xfsprogs 42> ./configure creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for gcc... /usr/bin/gcc checking for ld... /usr/bin/ld checking for tar... /bin/tar checking for gzip... /bin/gzip checking for rpm... /bin/rpm checking for makedepend... /usr/X11R6/bin/makedepend checking whether ln -s works... yes checking for awk... /bin/awk checking for sed... /bin/sed checking for echo... /bin/echo checking how to run the C preprocessor... gcc -E checking for uuid/uuid.h... yes checking for uuid_generate in -luuid... yes checking for liblvm.a... no checking for __psint_t ... no checking for __psunsigned_t ... no checking sizeof long... 4 checking sizeof pointer... 4 updating cache ./config.cache creating ./config.status creating include/builddefs creating include/platform_defs.h xfsprogs 43> perl -ne '/^MAKE\b/ && print' < include/builddefs MAKE = /usr/bin/gcc xfsprogs 44> make === include === gcc: default: No such file or directory make: *** [default] Error 1 xfsprogs 45> > I am using Slackware 7.1. make --version = GNU Make version 3.79. I had > to link kgcc to gcc (egcs-2.91.66) to build the kernel (which built fine). These versions should all (still) build fine. If it turns out that the above is what is biting you, then you'll need to: (rm include/builddefs config.*; unsetenv MAKE; make) > > The first rule in cmd/xfsprogs/Makefile is > ... > It looks like make is trying to build a file called 'default' which in "default" is a make target not a file. > cmd/xfsprogs/include/Makefile is the first rule: > > default install : > > the above line looks wrong? > no, it looks OK to me. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 13 14:41:38 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 14:41:19 -0800 Received: from moe.rice.edu ([128.42.5.4]:709 "EHLO moe.rice.edu") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 14:41:09 -0800 Received: from photino.sid.rice.edu (photino.sid.rice.edu [128.42.162.116]) by moe.rice.edu (8.9.0/8.9.0) with ESMTP id QAA12941 for ; Tue, 13 Feb 2001 16:41:04 -0600 (CST) Received: (from rjain@localhost) by photino.sid.rice.edu (8.11.2/8.11.2/Debian 8.11.2-1) id f1DMf4214327 for linux-xfs@oss.sgi.com; Tue, 13 Feb 2001 16:41:04 -0600 Date: Tue, 13 Feb 2001 16:41:04 -0600 From: Rahul Jain To: linux-xfs@oss.sgi.com Subject: Re: [?] __alloc_pages: 1-order allocation failed. Message-ID: <20010213164104.B14311@photino.sid.rice.edu> Reply-To: Rahul Jain References: <200102131838.f1DIci514428@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200102131838.f1DIci514428@jen.americas.sgi.com>; from lord@sgi.com on Tue, Feb 13, 2001 at 12:38:44PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Feb 13, 2001 at 12:38:44PM -0600, Steve Lord wrote: > > On Tue, Feb 13, 2001 at 10:59:57AM +0100, Krzysztof Rusocki wrote: > > > > > > Hi, > > > > > > Here's what i've found today in logs: > > > > > > Feb 13 02:10:41 main kernel: __alloc_pages: 1-order allocation failed. > > > Feb 13 02:10:42 main last message repeated 143 times > > > Feb 13 02:10:47 main kernel: ed. > > > Feb 13 02:10:47 main kernel: __alloc_pages: 1-order allocation failed. > > > Feb 13 02:50:30 main syslogd 1.3-3: restart (remote reception). > > > > > > > I typically get thousands of such messages when using my SCSI CDRW (I think > > it's specifically when I'm cat'ing or dd'ing from the drive. Specifically, I > > get 2- and 3-order allocation failures. I'll use the patch Andi Kleen posted > > to > > track down the exact locations of these errors. There seem to be no ill effec > > ts > > at all from these errors. > > > > Was that an XFS kernel or just a regular kernel? Since you posted to both > lists I was not not sure. We are working on cleaning up XFS's memory hogging > behavior right now. It seems to be unrelated to XFS, as I was getting these errors even before I started using XFS. -- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request. From owner-linux-xfs@oss.sgi.com Tue Feb 13 14:49:48 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 14:49:39 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:62225 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 14:49:23 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id UAA31887; Tue, 13 Feb 2001 20:48:58 -0200 Date: Tue, 13 Feb 2001 19:00:45 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Rahul Jain cc: linux-xfs@oss.sgi.com Subject: Re: [?] __alloc_pages: 1-order allocation failed. In-Reply-To: <20010213164104.B14311@photino.sid.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 13 Feb 2001, Rahul Jain wrote: > On Tue, Feb 13, 2001 at 12:38:44PM -0600, Steve Lord wrote: > > > On Tue, Feb 13, 2001 at 10:59:57AM +0100, Krzysztof Rusocki wrote: > > > > > > > > Hi, > > > > > > > > Here's what i've found today in logs: > > > > > > > > Feb 13 02:10:41 main kernel: __alloc_pages: 1-order allocation failed. > > > > Feb 13 02:10:42 main last message repeated 143 times > > > > Feb 13 02:10:47 main kernel: ed. > > > > Feb 13 02:10:47 main kernel: __alloc_pages: 1-order allocation failed. > > > > Feb 13 02:50:30 main syslogd 1.3-3: restart (remote reception). > > > > > > > > > > I typically get thousands of such messages when using my SCSI CDRW (I think > > > it's specifically when I'm cat'ing or dd'ing from the drive. Specifically, I > > > get 2- and 3-order allocation failures. I'll use the patch Andi Kleen posted > > > to > > > track down the exact locations of these errors. There seem to be no ill effec > > > ts > > > at all from these errors. > > > > > > > Was that an XFS kernel or just a regular kernel? Since you posted to both > > lists I was not not sure. We are working on cleaning up XFS's memory hogging > > behavior right now. > > It seems to be unrelated to XFS, as I was getting these errors even before I > started using XFS. Ok. Please Andi's patch and report the results if possible. From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:02:39 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:02:19 -0800 Received: from pD901E263.dip.t-dialin.net ([217.1.226.99]:39857 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:02:02 -0800 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f1DNK1x14058 for linux-xfs@oss.sgi.com; Wed, 14 Feb 2001 00:20:01 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Wed, 14 Feb 2001 00:20:00 +0100 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: less data lost, more fs corruption Message-ID: <20010214002000.A13755@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi this mail covers two problems: the sync-reboot-data lost problem and xfs_fsr kernel crash with fs corruptions. i dont separte it, because it happens in the same test session. my system is a k6-500 with ide drive and via chipset (udma enabled). /dev/hda6 is xfs root. /dev/hda4 is an ext2 root for runnig xfs_check. i made my sync-reboot-data lost test again with the fix (TAKE - fix delalloc data not getting flushed to disk (page_buf.c - 1.53, page_buf_io.c - 1.51)) the test was: cp -av /usr/src/linux/drivers/ drivers diff -r -u /usr/src/linux/drivers/ drivers/ (no differs) sync sync sync hit the reset button. after the reboot diff again. the first 6-8 test succeeded. i cycled the tests without clean shutdowns between (hmmm maybe one or two). then i made only one sync. after reboot some files differ. same problem, size is ok, but no extents. the number of differs are small. i played with the numbers of sync and the time between sync and hitting reset. when reset is hit just after the sync is finished i got data lost. waiting about 10-20s after the sync finished, everything is ok. regardless the number of syncs. after the first sync small diskactivity is there for about 10s. 2 times i check the fs with xfs_check (ext2 root), no errors. then i got the idea to run xfs_fsr. the result was a kernel crash and fs corruption (this is the first time a got problems with fsr): kernel BUG at dcache.c:356! Entering kdb (current=0xc7fbc000, pid 3) Panic: invalid operand due to panic @ 0xc0141ec2 eax = 0x0000001c ebx = 0xc7c870e0 ecx = 0x00000000 edx = 0x00000000 esi = 0xc7c870c0 edi = 0xc61c3840 esp = 0xc7fbdf98 eip = 0xc0141ec2 ebp = 0xffffff3b xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010292 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc7fbdf64 kdb> bt EBP EIP Function(args) 0xffffff3b 0xc0141ec2 prune_dcache+0x76 (0x2a) kernel .text 0xc0100000 0xc0141e4c 0xc0141f98 0xc0142201 shrink_dcache_memory+0x21 (0x6, 0x4) kernel .text 0xc0100000 0xc01421e0 0xc0142210 0xc012ad3b do_try_to_free_pages+0x5f (0x4, 0x0) kernel .text 0xc0100000 0xc012acdc 0xc012ad58 0xc012adcb kswapd+0x73 kernel .text 0xc0100000 0xc012ad58 0xc012ae68 0xc0107457 kernel_thread+0x23 kernel .text 0xc0100000 0xc0107434 0xc0107464 kdb> reboot i made some tests with xfs_fsr again. i will mail console capture only to Steve Lord because it is very very long (11238 lines). after that (xfs_repair eleminates the corruption) i made the sync-reboot-data lost tests again, with the same results above. a xfs_check at end of it reports no errors. btw: after this torture the system is running well. i noticed no corruptions of old files (ok, not tested very well). i can not imagine what happend with ext2 or reiserfs. the fs was made about half an year ago. and now i will test the change from Rajagopal Ananthanarayanan. utz From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:13:38 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:13:19 -0800 Received: from pD901E263.dip.t-dialin.net ([217.1.226.99]:40625 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:12:49 -0800 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f1DNUoW14166 for linux-xfs@oss.sgi.com; Wed, 14 Feb 2001 00:30:50 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Wed, 14 Feb 2001 00:30:50 +0100 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: Re: less data lost, more fs corruption Message-ID: <20010214003050.A14148@s2y4n2c.de> References: <20010214002000.A13755@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010214002000.A13755@s2y4n2c.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing utz lehmann [xfs@s2y4n2c.de] wrote: > and now i will test the change from Rajagopal Ananthanarayanan. ARGH!!! the monitor on my test computer just died. i cant test the change. utz From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:37:09 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:36:50 -0800 Received: from andante.eidetica.com ([62.58.2.2]:58642 "EHLO andante.eidetica.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:36:49 -0800 Received: from localhost (avg@localhost) by andante.eidetica.com (8.9.3/8.9.0) with ESMTP id AAA05240; Wed, 14 Feb 2001 00:36:47 +0100 Date: Wed, 14 Feb 2001 00:36:47 +0100 (CET) From: Annius Groenink To: linux-xfs@oss.sgi.com cc: Joost Remijn , Annius Groenink Subject: Mounting real-time device - can it be done? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi. I am new to XFS and this list. Great initiative. I tried the following: mkfs.xfs /dev/hdb4 -r size=1g,extsize=65536,rtdev=/dev/hdb3 -f i.e. setting up an XFS filesystem on /dev/hdb4 with a real-time section on /dev/hdb3. Mkfs says it's happy about it. But when I try to mount, I get the following response (whereas mounting an XFS without a real-time section will go just fine): iep:/usr/include/linux# mount /dev/hdb4 mount: wrong fs type, bad option, bad superblock on /dev/hdb4, or too many mounted file systems Isn't that a pity! Is this an unsupported feature? The header files seem to do all the necessary ioctl() calls to open a file as part of the real-time section... How much work would it be to implement the feature, if it is indeed missing? We'd be prepared to put some effort into this. -- dr Annius V. Groenink groenink@eidetica.com tel +31 20 888 4126 fax 4001 Kruislaan 400 Eidetica, Amsterdam NL 1098 SM Amsterdam http://www.eidetica.com/ Knowledge services - Internet intelligence From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:41:59 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:41:49 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:15183 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:41:45 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA04690 for ; Tue, 13 Feb 2001 15:51:05 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA807070; Tue, 13 Feb 2001 17:40:27 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA56376; Tue, 13 Feb 2001 17:40:27 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1DNfwY16686; Tue, 13 Feb 2001 17:41:59 -0600 Message-Id: <200102132341.f1DNfwY16686@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Annius Groenink cc: linux-xfs@oss.sgi.com, Joost Remijn Subject: Re: Mounting real-time device - can it be done? In-Reply-To: Message from Annius Groenink of "Wed, 14 Feb 2001 00:36:47 +0100." Date: Tue, 13 Feb 2001 17:41:58 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Hi. > > I am new to XFS and this list. Great initiative. > > > I tried the following: > > mkfs.xfs /dev/hdb4 -r size=1g,extsize=65536,rtdev=/dev/hdb3 -f > > i.e. setting up an XFS filesystem on /dev/hdb4 with a real-time section on > /dev/hdb3. Mkfs says it's happy about it. > > But when I try to mount, I get the following response (whereas mounting an > XFS without a real-time section will go just fine): > > iep:/usr/include/linux# mount /dev/hdb4 > mount: wrong fs type, bad option, bad superblock on /dev/hdb4, > or too many mounted file systems Try mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /xfs This should let you mount, I suspect you will find problems with actual file I/O into realtime files, but we can fix those as we find them. The realtime subvolume has not had any attention payed to it in quite a while. Steve > > > Isn't that a pity! Is this an unsupported feature? The header > files seem to do all the necessary ioctl() calls to open a file > as part of the real-time section... > > > How much work would it be to implement the feature, if it is > indeed missing? We'd be prepared to put some effort into this. > > > -- > > dr Annius V. Groenink > groenink@eidetica.com > tel +31 20 888 4126 fax 4001 > > Kruislaan 400 Eidetica, Amsterdam > NL 1098 SM Amsterdam > http://www.eidetica.com/ Knowledge services - Internet intelligence From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:46:28 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:46:09 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:42021 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:46:00 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA18205 for ; Tue, 13 Feb 2001 15:44:57 -0800 (PST) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25093; Wed, 14 Feb 2001 10:44:43 +1100 Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA23426; Wed, 14 Feb 2001 10:44:42 +1100 (EST) Message-Id: <200102132344.KAA23426@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: Mounting real-time device - can it be done? In-reply-to: Your message of "Tue, 13 Feb 2001 17:41:58 MDT." <200102132341.f1DNfwY16686@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 10:44:42 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord writes: => Try => => mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /xfs => => This should let you mount, I suspect you will find problems with actual fil => e => I/O into realtime files, but we can fix those as we find them. The realtime => subvolume has not had any attention payed to it in quite a while. The last time I recall, writing to real time subvolumes worked ok, but wrote the blocks to the data subvolume not the real time subvolume. Which, needless to say, is not a good thing. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:46:28 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:46:09 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:39717 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:45:56 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA18186 for ; Tue, 13 Feb 2001 15:44:53 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA808561 for ; Tue, 13 Feb 2001 17:44:39 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA74029 for ; Tue, 13 Feb 2001 17:44:39 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1DNkB116716; Tue, 13 Feb 2001 17:46:11 -0600 Message-Id: <200102132346.f1DNkB116716@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: pagebuf as a module in the development tree Date: Tue, 13 Feb 2001 17:46:11 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I just found out my last checkin broke building pagebuf as a module, sorry about that, a fix will be forthcoming. Steve From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:47:29 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:47:19 -0800 Received: from andante.eidetica.com ([62.58.2.2]:9747 "EHLO andante.eidetica.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:47:07 -0800 Received: from localhost (avg@localhost) by andante.eidetica.com (8.9.3/8.9.0) with ESMTP id AAA05498; Wed, 14 Feb 2001 00:46:55 +0100 Date: Wed, 14 Feb 2001 00:46:55 +0100 (CET) From: Annius Groenink To: Steve Lord cc: linux-xfs@oss.sgi.com, Joost Remijn Subject: Re: Mounting real-time device - can it be done? In-Reply-To: <200102132341.f1DNfwY16686@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi. Thanks for the prompt reply! > Try > > mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /xfs > > This should let you mount, I suspect you will find problems with actual file > I/O into realtime files, but we can fix those as we find them. The realtime > subvolume has not had any attention payed to it in quite a while. > > Steve Unfortunately, this still gives me: iep:/usr/include/linux# mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /mnt/xfs mount: wrong fs type, bad option, bad superblock on /dev/hdb4, or too many mounted file systems Perhaps I am making some mistake. Will investigate further. I am using the most recent build (2.4.1-XFS) without any patches. -- dr Annius V. Groenink groenink@eidetica.com tel +31 20 888 4126 fax 4001 Kruislaan 400 Eidetica, Amsterdam NL 1098 SM Amsterdam http://www.eidetica.com/ Knowledge services - Internet intelligence From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:50:08 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:49:58 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:80 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:49:38 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA04414 for ; Tue, 13 Feb 2001 15:58:59 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA809214; Tue, 13 Feb 2001 17:48:18 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA84455; Tue, 13 Feb 2001 17:48:18 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1DNnoV16729; Tue, 13 Feb 2001 17:49:50 -0600 Message-Id: <200102132349.f1DNnoV16729@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Daniel Moore cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Mounting real-time device - can it be done? In-Reply-To: Message from Daniel Moore of "Wed, 14 Feb 2001 10:44:42 +1100." <200102132344.KAA23426@clouds.melbourne.sgi.com> Date: Tue, 13 Feb 2001 17:49:50 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Steve Lord writes: > => Try > => > => mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /xfs > => > => This should let you mount, I suspect you will find problems with actual f > il > => e > => I/O into realtime files, but we can fix those as we find them. The realti > me > => subvolume has not had any attention payed to it in quite a while. > > The last time I recall, writing to real time subvolumes worked ok, but > wrote the blocks to the data subvolume not the real time subvolume. Yes, I recall some comments in there about what about the realtime device? I think there is more work to be done here. Steve > > Which, needless to say, is not a good thing. > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:50:58 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:50:38 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:9040 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:50:33 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id PAA09803 for ; Tue, 13 Feb 2001 15:59:52 -0800 (PST) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25191; Wed, 14 Feb 2001 10:49:14 +1100 Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA84040; Wed, 14 Feb 2001 10:49:13 +1100 (EST) Message-Id: <200102132349.KAA84040@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Annius Groenink cc: linux-xfs@oss.sgi.com Subject: Re: Mounting real-time device - can it be done? In-reply-to: Your message of "Wed, 14 Feb 2001 00:46:55 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 10:49:13 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Annius Groenink writes: => Unfortunately, this still gives me: => => iep:/usr/include/linux# mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /mnt/xfs => mount: wrong fs type, bad option, bad superblock on /dev/hdb4, => or too many mounted file systems => Oh yeah - check the syslog output too - the message from mount is useless, but the syslog can be quite informative. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:53:59 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:53:39 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:48160 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:53:28 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA09677 for ; Tue, 13 Feb 2001 15:53:26 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25223; Wed, 14 Feb 2001 10:52:07 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA09706; Wed, 14 Feb 2001 10:52:06 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102141052.ZM126592@wobbly.melbourne.sgi.com> Date: Wed, 14 Feb 2001 10:52:04 -0400 In-Reply-To: Annius Groenink "Re: Mounting real-time device - can it be done?" (Feb 14, 12:46am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Annius Groenink Subject: Re: Mounting real-time device - can it be done? Cc: linux-xfs@oss.sgi.com, Joost Remijn Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Feb 14, 12:46am, Annius Groenink wrote: > Subject: Re: Mounting real-time device - can it be done? > ... > Unfortunately, this still gives me: > > iep:/usr/include/linux# mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /mnt/xfs > mount: wrong fs type, bad option, bad superblock on /dev/hdb4, > or too many mounted file systems > > > Perhaps I am making some mistake. Will investigate further. > there should be a more useful diagnostic message on the console/syslog, coming from around line 170 of fs/xfs/linux/xfs_super.c? if you need them, all of the xfs mount options are also described in Documentation/filesystems/xfs.txt. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:57:58 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:57:38 -0800 Received: from andante.eidetica.com ([62.58.2.2]:28435 "EHLO andante.eidetica.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:57:25 -0800 Received: from localhost (avg@localhost) by andante.eidetica.com (8.9.3/8.9.0) with ESMTP id AAA05584; Wed, 14 Feb 2001 00:57:04 +0100 Date: Wed, 14 Feb 2001 00:57:04 +0100 (CET) From: Annius Groenink To: Daniel Moore cc: linux-xfs@oss.sgi.com Subject: Re: Mounting real-time device - can it be done? In-Reply-To: <200102132349.KAA84040@clouds.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Annius Groenink writes: > => Unfortunately, this still gives me: > => > => iep:/usr/include/linux# mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /mnt/xfs > => mount: wrong fs type, bad option, bad superblock on /dev/hdb4, > => or too many mounted file systems > => > > Oh yeah - check the syslog output too - the message from mount is > useless, but the syslog can be quite informative. Did that. Nothing. Anything I can do to make it more verbose? -- dr Annius V. Groenink groenink@eidetica.com tel +31 20 888 4126 fax 4001 Kruislaan 400 Eidetica, Amsterdam NL 1098 SM Amsterdam http://www.eidetica.com/ Knowledge services - Internet intelligence From owner-linux-xfs@oss.sgi.com Tue Feb 13 15:59:28 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 15:59:09 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:57634 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 15:58:57 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA00926 for ; Tue, 13 Feb 2001 15:58:57 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA808962; Tue, 13 Feb 2001 17:57:40 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA92940; Tue, 13 Feb 2001 17:57:39 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1DNxB716755; Tue, 13 Feb 2001 17:59:11 -0600 Message-Id: <200102132359.f1DNxB716755@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: utz lehmann cc: linux-xfs@oss.sgi.com Subject: Re: less data lost, more fs corruption In-Reply-To: Message from utz lehmann of "Wed, 14 Feb 2001 00:20:00 +0100." <20010214002000.A13755@s2y4n2c.de> Date: Tue, 13 Feb 2001 17:59:11 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > hi > > this mail covers two problems: the sync-reboot-data lost problem and > xfs_fsr kernel crash with fs corruptions. > i dont separte it, because it happens in the same test session. > > > my system is a k6-500 with ide drive and via chipset (udma enabled). > /dev/hda6 is xfs root. > /dev/hda4 is an ext2 root for runnig xfs_check. > > > i made my sync-reboot-data lost test again with the fix > (TAKE - fix delalloc data not getting flushed to disk (page_buf.c - 1.53, > page_buf_io.c - 1.51)) > > the test was: > > cp -av /usr/src/linux/drivers/ drivers > diff -r -u /usr/src/linux/drivers/ drivers/ (no differs) > sync > sync > sync > > hit the reset button. > > after the reboot diff again. > > > the first 6-8 test succeeded. > i cycled the tests without clean shutdowns between (hmmm maybe one or two). > > then i made only one sync. after reboot some files differ. same problem, > size is ok, but no extents. the number of differs are small. Have you tried this with ext2? OK the real issue here is that sync is not really doing sync, the sync system call is starting I/O, but not waiting for it to complete. At least two syncs are probably necessary for this scenario right now. If you wait a few seconds there will be a kernel initiated sync anyway. And as Ananth pointed out, there are some bits of I/O which will take a couple of passes to get triggered. Obviously we cannot immediately flush everything to disk or performance would tank. The issue with XFS in this area has always been that the inode size gets out to disk in advance of the file data. You are looking at a consistent filesystem, it just has data missing! This is why xfs_check does not complain. For apps which require a guarantee of data being down on disk immediately O_SYNC or fsync is supposed to be used, we are working on those too at the moment ;-) Steve > > i played with the numbers of sync and the time between sync and hitting > reset. > > when reset is hit just after the sync is finished i got data lost. > > waiting about 10-20s after the sync finished, everything is ok. regardless > the number of syncs. > after the first sync small diskactivity is there for about 10s. > > 2 times i check the fs with xfs_check (ext2 root), no errors. > > > > then i got the idea to run xfs_fsr. the result was a kernel crash and fs > corruption (this is the first time a got problems with fsr): > > kernel BUG at dcache.c:356! > > Entering kdb (current=0xc7fbc000, pid 3) Panic: invalid operand > due to panic @ 0xc0141ec2 > eax = 0x0000001c ebx = 0xc7c870e0 ecx = 0x00000000 edx = 0x00000000 > esi = 0xc7c870c0 edi = 0xc61c3840 esp = 0xc7fbdf98 eip = 0xc0141ec2 > ebp = 0xffffff3b xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010292 > xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc7fbdf64 > kdb> bt > EBP EIP Function(args) > 0xffffff3b 0xc0141ec2 prune_dcache+0x76 (0x2a) > kernel .text 0xc0100000 0xc0141e4c 0xc0141f98 > 0xc0142201 shrink_dcache_memory+0x21 (0x6, 0x4) > kernel .text 0xc0100000 0xc01421e0 0xc0142210 > 0xc012ad3b do_try_to_free_pages+0x5f (0x4, 0x0) > kernel .text 0xc0100000 0xc012acdc 0xc012ad58 > 0xc012adcb kswapd+0x73 > kernel .text 0xc0100000 0xc012ad58 0xc012ae68 > 0xc0107457 kernel_thread+0x23 > kernel .text 0xc0100000 0xc0107434 0xc0107464 > kdb> reboot > > > i made some tests with xfs_fsr again. i will mail console capture only to > Steve Lord because it is very very long (11238 lines). > > > after that (xfs_repair eleminates the corruption) i made the > sync-reboot-data lost tests again, with the same results above. > > a xfs_check at end of it reports no errors. > > > btw: after this torture the system is running well. i noticed no corruptions > of old files (ok, not tested very well). i can not imagine what happend with > ext2 or reiserfs. the fs was made about half an year ago. > > > and now i will test the change from Rajagopal Ananthanarayanan. > > utz From owner-linux-xfs@oss.sgi.com Tue Feb 13 16:03:58 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 16:03:38 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:53284 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 16:03:26 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA06403 for ; Tue, 13 Feb 2001 16:03:24 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA809636; Tue, 13 Feb 2001 18:02:05 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA93509; Tue, 13 Feb 2001 18:02:05 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1E03aD16783; Tue, 13 Feb 2001 18:03:36 -0600 Message-Id: <200102140003.f1E03aD16783@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Annius Groenink cc: Daniel Moore , linux-xfs@oss.sgi.com Subject: Re: Mounting real-time device - can it be done? In-Reply-To: Message from Annius Groenink of "Wed, 14 Feb 2001 00:57:04 +0100." Date: Tue, 13 Feb 2001 18:03:36 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > Annius Groenink writes: > > => Unfortunately, this still gives me: > > => > > => iep:/usr/include/linux# mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /mnt/ > xfs > > => mount: wrong fs type, bad option, bad superblock on /dev/hdb4, > > => or too many mounted file systems > > => > > > > Oh yeah - check the syslog output too - the message from mount is > > useless, but the syslog can be quite informative. > > > Did that. Nothing. Anything I can do to make it more verbose? > Dumb question, but do you have xfs in the kernel? Have you successfully mounted a simple filesystem without a realtime subvolume? cat /proc/filesystems nodev sockfs nodev shm nodev pipefs nodev proc ext2 xfs nodev devpts nodev autofs nodev nfs If you build xfs as a module, try doing a modprobe xfs and see what it reports. Steve From owner-linux-xfs@oss.sgi.com Tue Feb 13 17:34:49 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 17:34:29 -0800 Received: from pD901E270.dip.t-dialin.net ([217.1.226.112]:57777 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 17:34:26 -0800 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f1E1qMS15206; Wed, 14 Feb 2001 02:52:22 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Wed, 14 Feb 2001 02:52:22 +0100 From: utz lehmann To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: less data lost, more fs corruption Message-ID: <20010214025222.A15140@s2y4n2c.de> References: <200102132359.f1DNxB716755@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102132359.f1DNxB716755@jen.americas.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord [lord@sgi.com] wrote: > > the first 6-8 test succeeded. > > i cycled the tests without clean shutdowns between (hmmm maybe one or two). > > > > then i made only one sync. after reboot some files differ. same problem, > > size is ok, but no extents. the number of differs are small. > > > Have you tried this with ext2? no. shoud i? > OK the real issue here is that sync is not really doing sync, the sync system > call is starting I/O, but not waiting for it to complete. At least two syncs > are probably necessary for this scenario right now. If you wait a few seconds > there will be a kernel initiated sync anyway. And as Ananth pointed out, > there are some bits of I/O which will take a couple of passes to get triggered. > > Obviously we cannot immediately flush everything to disk or performance > would tank. The issue with XFS in this area has always been that the > inode size gets out to disk in advance of the file data. You are looking > at a consistent filesystem, it just has data missing! This is why xfs_check > does not complain. ok, when the return of sync means "writing data to disk will done" instead "writing data to disk is done" then the fix works. btw: with 3 syncs and reset in less than a second lost data is seen. is this on irix the same? sometimes i found those no extend files on irix after a crash. utz From owner-linux-xfs@oss.sgi.com Tue Feb 13 18:59:39 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 18:59:29 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:60481 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 18:59:17 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA05394 for ; Tue, 13 Feb 2001 18:58:14 -0800 (PST) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA50751 for linux-xfs@oss.sgi.com; Wed, 14 Feb 2001 13:57:53 +1100 (EST) Date: Wed, 14 Feb 2001 13:57:53 +1100 (EST) From: Daniel Moore Message-Id: <200102140257.NAA50751@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix pagebuf as module build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Feb 13 18:13:43 PST 2001 Workarea: snort.melbourne.sgi.com:/home/dxm/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:87480a linux/fs/xfs/linux/xfs_ioctl.c - 1.29 - remove note to self Date: Tue Feb 13 18:57:05 PST 2001 Workarea: snort.melbourne.sgi.com:/home/dxm/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:87482a linux/kernel/ksyms.c - 1.74 - fix pagebuf as module build From owner-linux-xfs@oss.sgi.com Tue Feb 13 19:07:11 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 19:06:49 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35686 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 19:06:37 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA08479 for ; Tue, 13 Feb 2001 19:15:55 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA13452 for linux-xfs@oss.sgi.com; Wed, 14 Feb 2001 14:05:16 +1100 (EST) Date: Wed, 14 Feb 2001 14:05:16 +1100 (EST) From: Nathan Scott Message-Id: <200102140305.OAA13452@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Feb 13 19:04:23 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:87484a cmd/quota/rquota_server.c - 1.5 - fix bug in remote setting of quota information for NFS mounted XFS filesystems. From owner-linux-xfs@oss.sgi.com Tue Feb 13 19:07:19 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 19:07:11 -0800 Received: from relay02.sportsline.com ([63.72.118.49]:34310 "HELO relay02.sportsline.com") by oss.sgi.com with SMTP id ; Tue, 13 Feb 2001 19:07:02 -0800 Received: (qmail 9045 invoked from network); 14 Feb 2001 03:07:00 -0000 Received: from chipsworld.llamas.net (63.77.33.226) by relay02.sportsline.com with SMTP; 14 Feb 2001 03:07:00 -0000 Received: from localhost (chipper@localhost) by chipsworld.llamas.net (8.11.0/8.11.0) with ESMTP id f1E36xa21483; Tue, 13 Feb 2001 22:07:00 -0500 Date: Tue, 13 Feb 2001 22:06:59 -0500 (EST) From: "Chris 'Chipper' Chiapusio" To: Keith Owens cc: Subject: Re: Unresolved Symbols problem w/ 2.4.1-XFS cvs In-Reply-To: <20435.981584544@kao2.melbourne.sgi.com> Message-ID: X-Files: Resist or serve MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1296032289-682324171-982120019=:25289" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1296032289-682324171-982120019=:25289 Content-Type: TEXT/PLAIN; charset=US-ASCII a current cvs checkout (as of 02/12/01) gives me mostly usable modules, only two are not working: [root@zhadum /root]# depmod -ae depmod: *** Unresolved symbols in /lib/modules/2.4.1-XFStest2/kernel/drivers/md/md.o depmod: name_to_kdev_t depmod: *** Unresolved symbols in /lib/modules/2.4.1-XFStest2/kernel/net/ipv6/ipv6.o depmod: rtnetlink_links depmod: __rta_fill depmod: rtnetlink_put_metrics depmod: rtnl with the attached .config Chipper On Thu, 8 Feb 2001, Keith Owens wrote: >On Wed, 7 Feb 2001 15:58:44 -0500 (EST), >"Chris 'Chipper' Chiapusio" wrote: >>I've been trying to get this going for days now. I've read the list >>archives, checked Documentation/Changes and ensured that all my tools are >>up to date. I've done cp .config ..;make mrproper;cp ../.config .;make >>oldconfig; make dep && make clean && make bzlilo && make modules && make >>modules_install > >Which should give you a clean build, even with the makefile bugs and >modversions turned on. You have not said what errors you are getting >which makes it difficult to see what is wrong. > ------ Please encrypt anything important. PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D --1296032289-682324171-982120019=:25289 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="241XFS.config" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="241XFS.config" Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBieSBtYWtlIG1lbnVjb25m aWc6IGRvbid0IGVkaXQNCiMNCkNPTkZJR19YODY9eQ0KQ09ORklHX0lTQT15 DQojIENPTkZJR19TQlVTIGlzIG5vdCBzZXQNCkNPTkZJR19VSUQxNj15DQoN CiMNCiMgQ29kZSBtYXR1cml0eSBsZXZlbCBvcHRpb25zDQojDQpDT05GSUdf RVhQRVJJTUVOVEFMPXkNCg0KIw0KIyBMb2FkYWJsZSBtb2R1bGUgc3VwcG9y dA0KIw0KQ09ORklHX01PRFVMRVM9eQ0KQ09ORklHX01PRFZFUlNJT05TPXkN CkNPTkZJR19LTU9EPXkNCg0KIw0KIyBQcm9jZXNzb3IgdHlwZSBhbmQgZmVh dHVyZXMNCiMNCiMgQ09ORklHX00zODYgaXMgbm90IHNldA0KIyBDT05GSUdf TTQ4NiBpcyBub3Qgc2V0DQojIENPTkZJR19NNTg2IGlzIG5vdCBzZXQNCiMg Q09ORklHX001ODZUU0MgaXMgbm90IHNldA0KIyBDT05GSUdfTTU4Nk1NWCBp cyBub3Qgc2V0DQojIENPTkZJR19NNjg2IGlzIG5vdCBzZXQNCkNPTkZJR19N UEVOVElVTUlJST15DQojIENPTkZJR19NUEVOVElVTTQgaXMgbm90IHNldA0K IyBDT05GSUdfTUs2IGlzIG5vdCBzZXQNCiMgQ09ORklHX01LNyBpcyBub3Qg c2V0DQojIENPTkZJR19NQ1JVU09FIGlzIG5vdCBzZXQNCiMgQ09ORklHX01X SU5DSElQQzYgaXMgbm90IHNldA0KIyBDT05GSUdfTVdJTkNISVAyIGlzIG5v dCBzZXQNCiMgQ09ORklHX01XSU5DSElQM0QgaXMgbm90IHNldA0KQ09ORklH X1g4Nl9XUF9XT1JLU19PSz15DQpDT05GSUdfWDg2X0lOVkxQRz15DQpDT05G SUdfWDg2X0NNUFhDSEc9eQ0KQ09ORklHX1g4Nl9CU1dBUD15DQpDT05GSUdf WDg2X1BPUEFEX09LPXkNCkNPTkZJR19YODZfTDFfQ0FDSEVfU0hJRlQ9NQ0K Q09ORklHX1g4Nl9UU0M9eQ0KQ09ORklHX1g4Nl9HT09EX0FQSUM9eQ0KQ09O RklHX1g4Nl9QR0U9eQ0KQ09ORklHX1g4Nl9VU0VfUFBST19DSEVDS1NVTT15 DQojIENPTkZJR19UT1NISUJBIGlzIG5vdCBzZXQNCkNPTkZJR19NSUNST0NP REU9bQ0KQ09ORklHX1g4Nl9NU1I9eQ0KQ09ORklHX1g4Nl9DUFVJRD15DQoj IENPTkZJR19OT0hJR0hNRU0gaXMgbm90IHNldA0KQ09ORklHX0hJR0hNRU00 Rz15DQojIENPTkZJR19ISUdITUVNNjRHIGlzIG5vdCBzZXQNCkNPTkZJR19I SUdITUVNPXkNCiMgQ09ORklHX01BVEhfRU1VTEFUSU9OIGlzIG5vdCBzZXQN CkNPTkZJR19NVFJSPXkNCkNPTkZJR19TTVA9eQ0KQ09ORklHX0hBVkVfREVD X0xPQ0s9eQ0KDQojDQojIEdlbmVyYWwgc2V0dXANCiMNCkNPTkZJR19ORVQ9 eQ0KIyBDT05GSUdfVklTV1MgaXMgbm90IHNldA0KQ09ORklHX1g4Nl9JT19B UElDPXkNCkNPTkZJR19YODZfTE9DQUxfQVBJQz15DQpDT05GSUdfUENJPXkN CiMgQ09ORklHX1BDSV9HT0JJT1MgaXMgbm90IHNldA0KIyBDT05GSUdfUENJ X0dPRElSRUNUIGlzIG5vdCBzZXQNCkNPTkZJR19QQ0lfR09BTlk9eQ0KQ09O RklHX1BDSV9CSU9TPXkNCkNPTkZJR19QQ0lfRElSRUNUPXkNCkNPTkZJR19Q Q0lfTkFNRVM9eQ0KIyBDT05GSUdfRUlTQSBpcyBub3Qgc2V0DQojIENPTkZJ R19NQ0EgaXMgbm90IHNldA0KQ09ORklHX0hPVFBMVUc9eQ0KDQojDQojIFBD TUNJQS9DYXJkQnVzIHN1cHBvcnQNCiMNCiMgQ09ORklHX1BDTUNJQSBpcyBu b3Qgc2V0DQpDT05GSUdfU1lTVklQQz15DQpDT05GSUdfQlNEX1BST0NFU1Nf QUNDVD15DQpDT05GSUdfU1lTQ1RMPXkNCkNPTkZJR19LQ09SRV9FTEY9eQ0K IyBDT05GSUdfS0NPUkVfQU9VVCBpcyBub3Qgc2V0DQpDT05GSUdfQklORk1U X0FPVVQ9bQ0KQ09ORklHX0JJTkZNVF9FTEY9eQ0KQ09ORklHX0JJTkZNVF9N SVNDPW0NCkNPTkZJR19QTT15DQojIENPTkZJR19BQ1BJIGlzIG5vdCBzZXQN CkNPTkZJR19BUE09eQ0KIyBDT05GSUdfQVBNX0lHTk9SRV9VU0VSX1NVU1BF TkQgaXMgbm90IHNldA0KIyBDT05GSUdfQVBNX0RPX0VOQUJMRSBpcyBub3Qg c2V0DQojIENPTkZJR19BUE1fQ1BVX0lETEUgaXMgbm90IHNldA0KIyBDT05G SUdfQVBNX0RJU1BMQVlfQkxBTksgaXMgbm90IHNldA0KQ09ORklHX0FQTV9S VENfSVNfR01UPXkNCiMgQ09ORklHX0FQTV9BTExPV19JTlRTIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0FQTV9SRUFMX01PREVfUE9XRVJfT0ZGIGlzIG5vdCBz ZXQNCg0KIw0KIyBNZW1vcnkgVGVjaG5vbG9neSBEZXZpY2VzIChNVEQpDQoj DQojIENPTkZJR19NVEQgaXMgbm90IHNldA0KDQojDQojIFBhcmFsbGVsIHBv cnQgc3VwcG9ydA0KIw0KQ09ORklHX1BBUlBPUlQ9bQ0KQ09ORklHX1BBUlBP UlRfUEM9bQ0KQ09ORklHX1BBUlBPUlRfUENfRklGTz15DQpDT05GSUdfUEFS UE9SVF9QQ19TVVBFUklPPXkNCiMgQ09ORklHX1BBUlBPUlRfQU1JR0EgaXMg bm90IHNldA0KIyBDT05GSUdfUEFSUE9SVF9NRkMzIGlzIG5vdCBzZXQNCiMg Q09ORklHX1BBUlBPUlRfQVRBUkkgaXMgbm90IHNldA0KIyBDT05GSUdfUEFS UE9SVF9TVU5CUFAgaXMgbm90IHNldA0KQ09ORklHX1BBUlBPUlRfT1RIRVI9 eQ0KQ09ORklHX1BBUlBPUlRfMTI4ND15DQoNCiMNCiMgUGx1ZyBhbmQgUGxh eSBjb25maWd1cmF0aW9uDQojDQpDT05GSUdfUE5QPXkNCkNPTkZJR19JU0FQ TlA9eQ0KDQojDQojIEJsb2NrIGRldmljZXMNCiMNCkNPTkZJR19CTEtfREVW X0ZEPXkNCiMgQ09ORklHX0JMS19ERVZfWEQgaXMgbm90IHNldA0KIyBDT05G SUdfUEFSSURFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19DUFFfREEgaXMg bm90IHNldA0KIyBDT05GSUdfQkxLX0NQUV9DSVNTX0RBIGlzIG5vdCBzZXQN CkNPTkZJR19CTEtfREVWX0RBQzk2MD15DQpDT05GSUdfQkxLX0RFVl9MT09Q PW0NCiMgQ09ORklHX0JMS19ERVZfTkJEIGlzIG5vdCBzZXQNCkNPTkZJR19C TEtfREVWX1JBTT1tDQpDT05GSUdfQkxLX0RFVl9SQU1fU0laRT00MDk2DQoj IENPTkZJR19CTEtfREVWX0lOSVRSRCBpcyBub3Qgc2V0DQoNCiMNCiMgTXVs dGktZGV2aWNlIHN1cHBvcnQgKFJBSUQgYW5kIExWTSkNCiMNCkNPTkZJR19N RD15DQpDT05GSUdfQkxLX0RFVl9NRD1tDQpDT05GSUdfTURfTElORUFSPW0N CkNPTkZJR19NRF9SQUlEMD1tDQpDT05GSUdfTURfUkFJRDE9bQ0KQ09ORklH X01EX1JBSUQ1PW0NCkNPTkZJR19CTEtfREVWX0xWTT15DQoNCiMNCiMgTmV0 d29ya2luZyBvcHRpb25zDQojDQpDT05GSUdfUEFDS0VUPXkNCkNPTkZJR19Q QUNLRVRfTU1BUD15DQpDT05GSUdfTkVUTElOSz15DQpDT05GSUdfUlRORVRM SU5LPXkNCiMgQ09ORklHX05FVExJTktfREVWIGlzIG5vdCBzZXQNCkNPTkZJ R19ORVRGSUxURVI9eQ0KIyBDT05GSUdfTkVURklMVEVSX0RFQlVHIGlzIG5v dCBzZXQNCkNPTkZJR19GSUxURVI9eQ0KQ09ORklHX1VOSVg9eQ0KQ09ORklH X0lORVQ9eQ0KQ09ORklHX0lQX01VTFRJQ0FTVD15DQojIENPTkZJR19JUF9B RFZBTkNFRF9ST1VURVIgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfUE5QIGlz IG5vdCBzZXQNCiMgQ09ORklHX05FVF9JUElQIGlzIG5vdCBzZXQNCiMgQ09O RklHX05FVF9JUEdSRSBpcyBub3Qgc2V0DQojIENPTkZJR19JUF9NUk9VVEUg aXMgbm90IHNldA0KIyBDT05GSUdfQVJQRCBpcyBub3Qgc2V0DQpDT05GSUdf SU5FVF9FQ049eQ0KQ09ORklHX1NZTl9DT09LSUVTPXkNCg0KIw0KIyAgIElQ OiBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbg0KIw0KQ09ORklHX0lQX05GX0NP Tk5UUkFDSz1tDQpDT05GSUdfSVBfTkZfRlRQPW0NCkNPTkZJR19JUF9ORl9R VUVVRT1tDQpDT05GSUdfSVBfTkZfSVBUQUJMRVM9bQ0KQ09ORklHX0lQX05G X01BVENIX0xJTUlUPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9NQUM9bQ0KQ09O RklHX0lQX05GX01BVENIX01BUks9bQ0KQ09ORklHX0lQX05GX01BVENIX01V TFRJUE9SVD1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfVE9TPW0NCkNPTkZJR19J UF9ORl9NQVRDSF9TVEFURT1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfVU5DTEVB Tj1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfT1dORVI9bQ0KQ09ORklHX0lQX05G X0ZJTFRFUj1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX1JFSkVDVD1tDQpDT05G SUdfSVBfTkZfVEFSR0VUX01JUlJPUj1tDQpDT05GSUdfSVBfTkZfTkFUPW0N CkNPTkZJR19JUF9ORl9OQVRfTkVFREVEPXkNCkNPTkZJR19JUF9ORl9UQVJH RVRfTUFTUVVFUkFERT1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX1JFRElSRUNU PW0NCkNPTkZJR19JUF9ORl9OQVRfRlRQPW0NCkNPTkZJR19JUF9ORl9NQU5H TEU9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9UT1M9bQ0KQ09ORklHX0lQX05G X1RBUkdFVF9NQVJLPW0NCkNPTkZJR19JUF9ORl9UQVJHRVRfTE9HPW0NCkNP TkZJR19JUF9ORl9DT01QQVRfSVBDSEFJTlM9bQ0KQ09ORklHX0lQX05GX05B VF9ORUVERUQ9eQ0KQ09ORklHX0lQX05GX0NPTVBBVF9JUEZXQURNPW0NCkNP TkZJR19JUF9ORl9OQVRfTkVFREVEPXkNCkNPTkZJR19JUFY2PW0NCkNPTkZJ R19JUFY2X0VVSTY0PXkNCkNPTkZJR19JUFY2X05PX1BCPXkNCg0KIw0KIyAg IElQdjY6IE5ldGZpbHRlciBDb25maWd1cmF0aW9uDQojDQpDT05GSUdfSVA2 X05GX0lQVEFCTEVTPW0NCkNPTkZJR19JUDZfTkZfTUFUQ0hfTElNSVQ9bQ0K Q09ORklHX0lQNl9ORl9NQVRDSF9NQVJLPW0NCkNPTkZJR19JUDZfTkZfRklM VEVSPW0NCkNPTkZJR19JUDZfTkZfTUFOR0xFPW0NCkNPTkZJR19JUDZfTkZf VEFSR0VUX01BUks9bQ0KQ09ORklHX0tIVFRQRD1tDQojIENPTkZJR19BVE0g aXMgbm90IHNldA0KIyBDT05GSUdfSVBYIGlzIG5vdCBzZXQNCiMgQ09ORklH X0FUQUxLIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQ05FVCBpcyBub3Qgc2V0 DQojIENPTkZJR19CUklER0UgaXMgbm90IHNldA0KIyBDT05GSUdfWDI1IGlz IG5vdCBzZXQNCiMgQ09ORklHX0xBUEIgaXMgbm90IHNldA0KIyBDT05GSUdf TExDIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9ESVZFUlQgaXMgbm90IHNl dA0KIyBDT05GSUdfRUNPTkVUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1dBTl9S T1VURVIgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX0ZBU1RST1VURSBpcyBu b3Qgc2V0DQojIENPTkZJR19ORVRfSFdfRkxPV0NPTlRST0wgaXMgbm90IHNl dA0KDQojDQojIFFvUyBhbmQvb3IgZmFpciBxdWV1ZWluZw0KIw0KIyBDT05G SUdfTkVUX1NDSEVEIGlzIG5vdCBzZXQNCg0KIw0KIyBUZWxlcGhvbnkgU3Vw cG9ydA0KIw0KIyBDT05GSUdfUEhPTkUgaXMgbm90IHNldA0KIyBDT05GSUdf UEhPTkVfSVhKIGlzIG5vdCBzZXQNCg0KIw0KIyBBVEEvSURFL01GTS9STEwg c3VwcG9ydA0KIw0KQ09ORklHX0lERT1tDQoNCiMNCiMgSURFLCBBVEEgYW5k IEFUQVBJIEJsb2NrIGRldmljZXMNCiMNCkNPTkZJR19CTEtfREVWX0lERT1t DQojIENPTkZJR19CTEtfREVWX0hEX0lERSBpcyBub3Qgc2V0DQojIENPTkZJ R19CTEtfREVWX0hEIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERURJ U0s9bQ0KQ09ORklHX0lERURJU0tfTVVMVElfTU9ERT15DQojIENPTkZJR19C TEtfREVWX0lERURJU0tfVkVORE9SIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM S19ERVZfSURFRElTS19GVUpJVFNVIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM S19ERVZfSURFRElTS19JQk0gaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RF Vl9JREVESVNLX01BWFRPUiBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X0lERURJU0tfUVVBTlRVTSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X0lERURJU0tfU0VBR0FURSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X0lERURJU0tfV0QgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9DT01N RVJJQUwgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9USVZPIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSURFQ1MgaXMgbm90IHNldA0KQ09O RklHX0JMS19ERVZfSURFQ0Q9bQ0KIyBDT05GSUdfQkxLX0RFVl9JREVUQVBF IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSURFRkxPUFBZIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSURFU0NTSSBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX0NNRDY0MCBpcyBub3Qgc2V0DQojIENPTkZJR19C TEtfREVWX0NNRDY0MF9FTkhBTkNFRCBpcyBub3Qgc2V0DQojIENPTkZJR19C TEtfREVWX0lTQVBOUCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1Ja MTAwMCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9JREVQQ0k9eQ0KQ09O RklHX0lERVBDSV9TSEFSRV9JUlE9eQ0KQ09ORklHX0JMS19ERVZfSURFRE1B X1BDST15DQojIENPTkZJR19CTEtfREVWX09GRkJPQVJEIGlzIG5vdCBzZXQN CkNPTkZJR19JREVETUFfUENJX0FVVE89eQ0KQ09ORklHX0JMS19ERVZfSURF RE1BPXkNCiMgQ09ORklHX0lERURNQV9QQ0lfV0lQIGlzIG5vdCBzZXQNCiMg Q09ORklHX0lERURNQV9ORVdfRFJJVkVfTElTVElOR1MgaXMgbm90IHNldA0K IyBDT05GSUdfQkxLX0RFVl9BRUM2MlhYIGlzIG5vdCBzZXQNCiMgQ09ORklH X0FFQzYyWFhfVFVOSU5HIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf QUxJMTVYMyBpcyBub3Qgc2V0DQojIENPTkZJR19XRENfQUxJMTVYMyBpcyBu b3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0FNRDc0MDkgaXMgbm90IHNldA0K IyBDT05GSUdfQU1ENzQwOV9PVkVSUklERSBpcyBub3Qgc2V0DQojIENPTkZJ R19CTEtfREVWX0NNRDY0WCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X0NZODJDNjkzIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQ1M1NTMw IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSFBUMzRYIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0hQVDM0WF9BVVRPRE1BIGlzIG5vdCBzZXQNCiMgQ09O RklHX0JMS19ERVZfSFBUMzY2IGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVW X1BJSVg9eQ0KQ09ORklHX1BJSVhfVFVOSU5HPXkNCiMgQ09ORklHX0JMS19E RVZfTlM4NzQxNSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX09QVEk2 MjEgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9QREMyMDJYWCBpcyBu b3Qgc2V0DQojIENPTkZJR19QREMyMDJYWF9CVVJTVCBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX09TQjQgaXMgbm90IHNldA0KIyBDT05GSUdfQkxL X0RFVl9TSVM1NTEzIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfU0xD OTBFNjYgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9UUk0yOTAgaXMg bm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9WSUE4MkNYWFggaXMgbm90IHNl dA0KIyBDT05GSUdfSURFX0NISVBTRVRTIGlzIG5vdCBzZXQNCkNPTkZJR19J REVETUFfQVVUTz15DQojIENPTkZJR19JREVETUFfSVZCIGlzIG5vdCBzZXQN CiMgQ09ORklHX0RNQV9OT05QQ0kgaXMgbm90IHNldA0KQ09ORklHX0JMS19E RVZfSURFX01PREVTPXkNCg0KIw0KIyBTQ1NJIHN1cHBvcnQNCiMNCkNPTkZJ R19TQ1NJPXkNCkNPTkZJR19CTEtfREVWX1NEPXkNCkNPTkZJR19TRF9FWFRS QV9ERVZTPTQwDQojIENPTkZJR19DSFJfREVWX1NUIGlzIG5vdCBzZXQNCiMg Q09ORklHX0NIUl9ERVZfT1NTVCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RF Vl9TUj1tDQpDT05GSUdfQkxLX0RFVl9TUl9WRU5ET1I9eQ0KQ09ORklHX1NS X0VYVFJBX0RFVlM9Mg0KQ09ORklHX0NIUl9ERVZfU0c9eQ0KIyBDT05GSUdf U0NTSV9ERUJVR19RVUVVRVMgaXMgbm90IHNldA0KQ09ORklHX1NDU0lfTVVM VElfTFVOPXkNCiMgQ09ORklHX1NDU0lfQ09OU1RBTlRTIGlzIG5vdCBzZXQN CkNPTkZJR19TQ1NJX0xPR0dJTkc9eQ0KDQojDQojIFNDU0kgbG93LWxldmVs IGRyaXZlcnMNCiMNCiMgQ09ORklHX0JMS19ERVZfM1dfWFhYWF9SQUlEIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfNzAwMEZBU1NUIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NDU0lfQUNBUkQgaXMgbm90IHNldA0KIyBDT05GSUdfU0NT SV9BSEExNTJYIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfQUhBMTU0MiBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FIQTE3NDAgaXMgbm90IHNldA0K Q09ORklHX1NDU0lfQUlDN1hYWD1tDQpDT05GSUdfQUlDN1hYWF9UQ1FfT05f QllfREVGQVVMVD15DQpDT05GSUdfQUlDN1hYWF9DTURTX1BFUl9ERVZJQ0U9 MzINCiMgQ09ORklHX0FJQzdYWFhfUFJPQ19TVEFUUyBpcyBub3Qgc2V0DQpD T05GSUdfQUlDN1hYWF9SRVNFVF9ERUxBWT01DQojIENPTkZJR19TQ1NJX0FE VkFOU1lTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSU4yMDAwIGlzIG5v dCBzZXQNCiMgQ09ORklHX1NDU0lfQU01M0M5NzQgaXMgbm90IHNldA0KIyBD T05GSUdfU0NTSV9NRUdBUkFJRCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X0JVU0xPR0lDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfQ1BRRkNUUyBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0RNWDMxOTFEIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NDU0lfRFRDMzI4MCBpcyBub3Qgc2V0DQojIENPTkZJR19T Q1NJX0VBVEEgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9FQVRBX0RNQSBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0VBVEFfUElPIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NDU0lfRlVUVVJFX0RPTUFJTiBpcyBub3Qgc2V0DQojIENP TkZJR19TQ1NJX0dEVEggaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9HRU5F UklDX05DUjUzODAgaXMgbm90IHNldA0KQ09ORklHX1NDU0lfSVBTPXkNCiMg Q09ORklHX1NDU0lfSU5JVElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lf SU5JQTEwMCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1BQQSBpcyBub3Qg c2V0DQojIENPTkZJR19TQ1NJX0lNTSBpcyBub3Qgc2V0DQojIENPTkZJR19T Q1NJX05DUjUzQzQwNkEgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9OQ1I1 M0M3eHggaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9OQ1I1M0M4WFggaXMg bm90IHNldA0KIyBDT05GSUdfU0NTSV9TWU01M0M4WFggaXMgbm90IHNldA0K IyBDT05GSUdfU0NTSV9QQVMxNiBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X1BDSTIwMDAgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9QQ0kyMjIwSSBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1BTSTI0MEkgaXMgbm90IHNldA0K IyBDT05GSUdfU0NTSV9RTE9HSUNfRkFTIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NDU0lfUUxPR0lDX0lTUCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1FM T0dJQ19GQyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1FMT0dJQ18xMjgw IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfU0VBR0FURSBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX1NJTTcxMCBpcyBub3Qgc2V0DQojIENPTkZJR19T Q1NJX1NZTTUzQzQxNiBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0RDMzkw VCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1QxMjggaXMgbm90IHNldA0K IyBDT05GSUdfU0NTSV9VMTRfMzRGIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ND U0lfVUxUUkFTVE9SIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfREVCVUcg aXMgbm90IHNldA0KDQojDQojIElFRUUgMTM5NCAoRmlyZVdpcmUpIHN1cHBv cnQNCiMNCiMgQ09ORklHX0lFRUUxMzk0IGlzIG5vdCBzZXQNCg0KIw0KIyBJ Mk8gZGV2aWNlIHN1cHBvcnQNCiMNCkNPTkZJR19JMk89eQ0KQ09ORklHX0ky T19QQ0k9eQ0KQ09ORklHX0kyT19CTE9DSz15DQpDT05GSUdfSTJPX0xBTj15 DQpDT05GSUdfSTJPX1NDU0k9eQ0KQ09ORklHX0kyT19QUk9DPXkNCg0KIw0K IyBOZXR3b3JrIGRldmljZSBzdXBwb3J0DQojDQpDT05GSUdfTkVUREVWSUNF Uz15DQoNCiMNCiMgQVJDbmV0IGRldmljZXMNCiMNCiMgQ09ORklHX0FSQ05F VCBpcyBub3Qgc2V0DQpDT05GSUdfRFVNTVk9bQ0KQ09ORklHX0JPTkRJTkc9 bQ0KIyBDT05GSUdfRVFVQUxJWkVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RV TiBpcyBub3Qgc2V0DQojIENPTkZJR19FVEhFUlRBUCBpcyBub3Qgc2V0DQoj IENPTkZJR19ORVRfU0IxMDAwIGlzIG5vdCBzZXQNCg0KIw0KIyBFdGhlcm5l dCAoMTAgb3IgMTAwTWJpdCkNCiMNCkNPTkZJR19ORVRfRVRIRVJORVQ9eQ0K IyBDT05GSUdfTkVUX1ZFTkRPUl8zQ09NIGlzIG5vdCBzZXQNCiMgQ09ORklH X0xBTkNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9WRU5ET1JfU01DIGlz IG5vdCBzZXQNCiMgQ09ORklHX05FVF9WRU5ET1JfUkFDQUwgaXMgbm90IHNl dA0KIyBDT05GSUdfQVQxNzAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFUENB IGlzIG5vdCBzZXQNCiMgQ09ORklHX0hQMTAwIGlzIG5vdCBzZXQNCiMgQ09O RklHX05FVF9JU0EgaXMgbm90IHNldA0KQ09ORklHX05FVF9QQ0k9eQ0KIyBD T05GSUdfUENORVQzMiBpcyBub3Qgc2V0DQojIENPTkZJR19BREFQVEVDX1NU QVJGSVJFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FDMzIwMCBpcyBub3Qgc2V0 DQojIENPTkZJR19BUFJJQ09UIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NTODl4 MCBpcyBub3Qgc2V0DQojIENPTkZJR19UVUxJUCBpcyBub3Qgc2V0DQojIENP TkZJR19ERTRYNSBpcyBub3Qgc2V0DQojIENPTkZJR19ER1JTIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0RNOTEwMiBpcyBub3Qgc2V0DQpDT05GSUdfRUVQUk8x MDA9eQ0KIyBDT05GSUdfRUVQUk8xMDBfUE0gaXMgbm90IHNldA0KIyBDT05G SUdfTE5FMzkwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05BVFNFTUkgaXMgbm90 IHNldA0KIyBDT05GSUdfTkUyS19QQ0kgaXMgbm90IHNldA0KIyBDT05GSUdf TkUzMjEwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VTMzIxMCBpcyBub3Qgc2V0 DQojIENPTkZJR184MTM5VE9PIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUTDgx MjkgaXMgbm90IHNldA0KIyBDT05GSUdfU0lTOTAwIGlzIG5vdCBzZXQNCiMg Q09ORklHX0VQSUMxMDAgaXMgbm90IHNldA0KIyBDT05GSUdfU1VOREFOQ0Ug aXMgbm90IHNldA0KIyBDT05GSUdfVExBTiBpcyBub3Qgc2V0DQojIENPTkZJ R19WSUFfUkhJTkUgaXMgbm90IHNldA0KIyBDT05GSUdfV0lOQk9ORF84NDAg aXMgbm90IHNldA0KIyBDT05GSUdfSEFQUFlNRUFMIGlzIG5vdCBzZXQNCiMg Q09ORklHX05FVF9QT0NLRVQgaXMgbm90IHNldA0KDQojDQojIEV0aGVybmV0 ICgxMDAwIE1iaXQpDQojDQojIENPTkZJR19BQ0VOSUMgaXMgbm90IHNldA0K IyBDT05GSUdfSEFNQUNISSBpcyBub3Qgc2V0DQojIENPTkZJR19ZRUxMT1dG SU4gaXMgbm90IHNldA0KIyBDT05GSUdfU0s5OExJTiBpcyBub3Qgc2V0DQoj IENPTkZJR19GRERJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJUFBJIGlzIG5v dCBzZXQNCiMgQ09ORklHX1BMSVAgaXMgbm90IHNldA0KIyBDT05GSUdfUFBQ IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NMSVAgaXMgbm90IHNldA0KDQojDQoj IFdpcmVsZXNzIExBTiAobm9uLWhhbXJhZGlvKQ0KIw0KIyBDT05GSUdfTkVU X1JBRElPIGlzIG5vdCBzZXQNCg0KIw0KIyBUb2tlbiBSaW5nIGRldmljZXMN CiMNCiMgQ09ORklHX1RSIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9GQyBp cyBub3Qgc2V0DQojIENPTkZJR19SQ1BDSSBpcyBub3Qgc2V0DQpDT05GSUdf U0hBUEVSPW0NCg0KIw0KIyBXYW4gaW50ZXJmYWNlcw0KIw0KIyBDT05GSUdf V0FOIGlzIG5vdCBzZXQNCg0KIw0KIyBBbWF0ZXVyIFJhZGlvIHN1cHBvcnQN CiMNCiMgQ09ORklHX0hBTVJBRElPIGlzIG5vdCBzZXQNCg0KIw0KIyBJckRB IChpbmZyYXJlZCkgc3VwcG9ydA0KIw0KIyBDT05GSUdfSVJEQSBpcyBub3Qg c2V0DQoNCiMNCiMgSVNETiBzdWJzeXN0ZW0NCiMNCiMgQ09ORklHX0lTRE4g aXMgbm90IHNldA0KDQojDQojIE9sZCBDRC1ST00gZHJpdmVycyAobm90IFND U0ksIG5vdCBJREUpDQojDQojIENPTkZJR19DRF9OT19JREVTQ1NJIGlzIG5v dCBzZXQNCg0KIw0KIyBJbnB1dCBjb3JlIHN1cHBvcnQNCiMNCkNPTkZJR19J TlBVVD1tDQpDT05GSUdfSU5QVVRfS0VZQkRFVj1tDQpDT05GSUdfSU5QVVRf TU9VU0VERVY9bQ0KQ09ORklHX0lOUFVUX01PVVNFREVWX1NDUkVFTl9YPTEw MjQNCkNPTkZJR19JTlBVVF9NT1VTRURFVl9TQ1JFRU5fWT03NjgNCiMgQ09O RklHX0lOUFVUX0pPWURFViBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9F VkRFViBpcyBub3Qgc2V0DQoNCiMNCiMgQ2hhcmFjdGVyIGRldmljZXMNCiMN CkNPTkZJR19WVD15DQpDT05GSUdfVlRfQ09OU09MRT15DQpDT05GSUdfU0VS SUFMPXkNCkNPTkZJR19TRVJJQUxfQ09OU09MRT15DQojIENPTkZJR19TRVJJ QUxfRVhURU5ERUQgaXMgbm90IHNldA0KIyBDT05GSUdfU0VSSUFMX05PTlNU QU5EQVJEIGlzIG5vdCBzZXQNCkNPTkZJR19VTklYOThfUFRZUz15DQpDT05G SUdfVU5JWDk4X1BUWV9DT1VOVD0yNTYNCiMgQ09ORklHX1BSSU5URVIgaXMg bm90IHNldA0KIyBDT05GSUdfUFBERVYgaXMgbm90IHNldA0KDQojDQojIEky QyBzdXBwb3J0DQojDQpDT05GSUdfSTJDPXkNCkNPTkZJR19JMkNfQUxHT0JJ VD15DQojIENPTkZJR19JMkNfUEhJTElQU1BBUiBpcyBub3Qgc2V0DQpDT05G SUdfSTJDX0VMVj1tDQpDT05GSUdfSTJDX1ZFTExFTUFOPW0NCkNPTkZJR19J MkNfQUxHT1BDRj1tDQpDT05GSUdfSTJDX0VMRUtUT1I9bQ0KQ09ORklHX0ky Q19DSEFSREVWPXkNCg0KIw0KIyBNaWNlDQojDQojIENPTkZJR19CVVNNT1VT RSBpcyBub3Qgc2V0DQpDT05GSUdfTU9VU0U9eQ0KQ09ORklHX1BTTU9VU0U9 eQ0KIyBDT05GSUdfODJDNzEwX01PVVNFIGlzIG5vdCBzZXQNCiMgQ09ORklH X1BDMTEwX1BBRCBpcyBub3Qgc2V0DQoNCiMNCiMgSm95c3RpY2tzDQojDQoj IENPTkZJR19KT1lTVElDSyBpcyBub3Qgc2V0DQojIENPTkZJR19RSUMwMl9U QVBFIGlzIG5vdCBzZXQNCg0KIw0KIyBXYXRjaGRvZyBDYXJkcw0KIw0KIyBD T05GSUdfV0FUQ0hET0cgaXMgbm90IHNldA0KQ09ORklHX0lOVEVMX1JORz1t DQpDT05GSUdfTlZSQU09bQ0KQ09ORklHX1JUQz15DQojIENPTkZJR19EVExL IGlzIG5vdCBzZXQNCiMgQ09ORklHX1IzOTY0IGlzIG5vdCBzZXQNCiMgQ09O RklHX0FQUExJQ09NIGlzIG5vdCBzZXQNCg0KIw0KIyBGdGFwZSwgdGhlIGZs b3BweSB0YXBlIGRldmljZSBkcml2ZXINCiMNCiMgQ09ORklHX0ZUQVBFIGlz IG5vdCBzZXQNCkNPTkZJR19BR1A9eQ0KQ09ORklHX0FHUF9JTlRFTD15DQoj IENPTkZJR19BR1BfSTgxMCBpcyBub3Qgc2V0DQojIENPTkZJR19BR1BfVklB IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FHUF9BTUQgaXMgbm90IHNldA0KIyBD T05GSUdfQUdQX1NJUyBpcyBub3Qgc2V0DQojIENPTkZJR19BR1BfQUxJIGlz IG5vdCBzZXQNCiMgQ09ORklHX0RSTSBpcyBub3Qgc2V0DQoNCiMNCiMgTXVs dGltZWRpYSBkZXZpY2VzDQojDQojIENPTkZJR19WSURFT19ERVYgaXMgbm90 IHNldA0KDQojDQojIEZpbGUgc3lzdGVtcw0KIw0KQ09ORklHX1FVT1RBPXkN CkNPTkZJR19GU19QT1NJWF9BQ0w9eQ0KQ09ORklHX0FVVE9GU19GUz1tDQpD T05GSUdfQVVUT0ZTNF9GUz1tDQpDT05GSUdfUkVJU0VSRlNfRlM9eQ0KIyBD T05GSUdfUkVJU0VSRlNfQ0hFQ0sgaXMgbm90IHNldA0KIyBDT05GSUdfQURG U19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19BREZTX0ZTX1JXIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0FGRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfSEZT X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JGU19GUyBpcyBub3Qgc2V0DQpD T05GSUdfRkFUX0ZTPW0NCkNPTkZJR19NU0RPU19GUz1tDQojIENPTkZJR19V TVNET1NfRlMgaXMgbm90IHNldA0KQ09ORklHX1ZGQVRfRlM9bQ0KIyBDT05G SUdfRUZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0pGRlNfRlMgaXMgbm90 IHNldA0KIyBDT05GSUdfQ1JBTUZTIGlzIG5vdCBzZXQNCkNPTkZJR19SQU1G Uz15DQpDT05GSUdfSVNPOTY2MF9GUz15DQpDT05GSUdfSk9MSUVUPXkNCkNP TkZJR19NSU5JWF9GUz1tDQojIENPTkZJR19OVEZTX0ZTIGlzIG5vdCBzZXQN CiMgQ09ORklHX05URlNfUlcgaXMgbm90IHNldA0KIyBDT05GSUdfSFBGU19G UyBpcyBub3Qgc2V0DQpDT05GSUdfUFJPQ19GUz15DQpDT05GSUdfREVWRlNf RlM9eQ0KQ09ORklHX0RFVkZTX01PVU5UPXkNCiMgQ09ORklHX0RFVkZTX0RF QlVHIGlzIG5vdCBzZXQNCkNPTkZJR19ERVZQVFNfRlM9eQ0KIyBDT05GSUdf UU5YNEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1FOWDRGU19SVyBpcyBu b3Qgc2V0DQpDT05GSUdfUk9NRlNfRlM9bQ0KQ09ORklHX0VYVDJfRlM9eQ0K IyBDT05GSUdfU1lTVl9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19TWVNWX0ZT X1dSSVRFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VERl9GUyBpcyBub3Qgc2V0 DQojIENPTkZJR19VREZfUlcgaXMgbm90IHNldA0KIyBDT05GSUdfVUZTX0ZT IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VGU19GU19XUklURSBpcyBub3Qgc2V0 DQpDT05GSUdfUEFHRV9CVUY9eQ0KQ09ORklHX1hGU19GUz15DQojIENPTkZJ R19YRlNfRE1BUEkgaXMgbm90IHNldA0KQ09ORklHX1hGU19RVU9UQT15DQoj IENPTkZJR19YRlNfREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfWEZTX1ZO T0RFX1RSQUNJTkcgaXMgbm90IHNldA0KQ09ORklHX1hGU19TVVBQT1JUPXkN Cg0KIw0KIyBOZXR3b3JrIEZpbGUgU3lzdGVtcw0KIw0KQ09ORklHX0NPREFf RlM9bQ0KQ09ORklHX05GU19GUz1tDQpDT05GSUdfTkZTX1YzPXkNCiMgQ09O RklHX1JPT1RfTkZTIGlzIG5vdCBzZXQNCkNPTkZJR19ORlNEPW0NCkNPTkZJ R19ORlNEX1YzPXkNCkNPTkZJR19TVU5SUEM9bQ0KQ09ORklHX0xPQ0tEPW0N CkNPTkZJR19MT0NLRF9WND15DQpDT05GSUdfU01CX0ZTPW0NCkNPTkZJR19T TUJfTkxTX0RFRkFVTFQ9eQ0KQ09ORklHX1NNQl9OTFNfUkVNT1RFPSJjcDQz NyINCiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BG U19QQUNLRVRfU0lHTklORyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BGU19J T0NUTF9MT0NLSU5HIGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUEZTX1NUUk9O RyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BGU19ORlNfTlMgaXMgbm90IHNl dA0KIyBDT05GSUdfTkNQRlNfT1MyX05TIGlzIG5vdCBzZXQNCiMgQ09ORklH X05DUEZTX1NNQUxMRE9TIGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUEZTX05M UyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BGU19FWFRSQVMgaXMgbm90IHNl dA0KDQojDQojIFBhcnRpdGlvbiBUeXBlcw0KIw0KIyBDT05GSUdfUEFSVElU SU9OX0FEVkFOQ0VEIGlzIG5vdCBzZXQNCkNPTkZJR19NU0RPU19QQVJUSVRJ T049eQ0KQ09ORklHX1NNQl9OTFM9eQ0KQ09ORklHX05MUz15DQoNCiMNCiMg TmF0aXZlIExhbmd1YWdlIFN1cHBvcnQNCiMNCkNPTkZJR19OTFNfREVGQVVM VD0iaXNvODg1OS0xIg0KQ09ORklHX05MU19DT0RFUEFHRV80Mzc9bQ0KIyBD T05GSUdfTkxTX0NPREVQQUdFXzczNyBpcyBub3Qgc2V0DQojIENPTkZJR19O TFNfQ09ERVBBR0VfNzc1IGlzIG5vdCBzZXQNCkNPTkZJR19OTFNfQ09ERVBB R0VfODUwPW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfODUyPW0NCiMgQ09ORklH X05MU19DT0RFUEFHRV84NTUgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NP REVQQUdFXzg1NyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0Vf ODYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjEgaXMg bm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MiBpcyBub3Qgc2V0 DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODYzIGlzIG5vdCBzZXQNCiMgQ09O RklHX05MU19DT0RFUEFHRV84NjQgaXMgbm90IHNldA0KIyBDT05GSUdfTkxT X0NPREVQQUdFXzg2NSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBB R0VfODY2IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84Njkg aXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg3NCBpcyBub3Qg c2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfOTMyIGlzIG5vdCBzZXQNCiMg Q09ORklHX05MU19DT0RFUEFHRV85MzYgaXMgbm90IHNldA0KIyBDT05GSUdf TkxTX0NPREVQQUdFXzk0OSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09E RVBBR0VfOTUwIGlzIG5vdCBzZXQNCkNPTkZJR19OTFNfSVNPODg1OV8xPXkN CiMgQ09ORklHX05MU19JU084ODU5XzIgaXMgbm90IHNldA0KIyBDT05GSUdf TkxTX0lTTzg4NTlfMyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1 OV80IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzUgaXMgbm90 IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfNiBpcyBub3Qgc2V0DQojIENP TkZJR19OTFNfSVNPODg1OV83IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19J U084ODU5XzggaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfOSBp cyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV8xNCBpcyBub3Qgc2V0 DQpDT05GSUdfTkxTX0lTTzg4NTlfMTU9bQ0KIyBDT05GSUdfTkxTX0tPSThf UiBpcyBub3Qgc2V0DQpDT05GSUdfTkxTX1VURjg9bQ0KDQojDQojIENvbnNv bGUgZHJpdmVycw0KIw0KQ09ORklHX1ZHQV9DT05TT0xFPXkNCiMgQ09ORklH X1ZJREVPX1NFTEVDVCBpcyBub3Qgc2V0DQojIENPTkZJR19NREFfQ09OU09M RSBpcyBub3Qgc2V0DQoNCiMNCiMgRnJhbWUtYnVmZmVyIHN1cHBvcnQNCiMN CiMgQ09ORklHX0ZCIGlzIG5vdCBzZXQNCg0KIw0KIyBTb3VuZA0KIw0KIyBD T05GSUdfU09VTkQgaXMgbm90IHNldA0KDQojDQojIFVTQiBzdXBwb3J0DQoj DQpDT05GSUdfVVNCPW0NCkNPTkZJR19VU0JfREVCVUc9eQ0KQ09ORklHX1VT Ql9ERVZJQ0VGUz15DQojIENPTkZJR19VU0JfQkFORFdJRFRIIGlzIG5vdCBz ZXQNCkNPTkZJR19VU0JfVUhDST1tDQpDT05GSUdfVVNCX1VIQ0lfQUxUPW0N CkNPTkZJR19VU0JfT0hDST1tDQojIENPTkZJR19VU0JfQVVESU8gaXMgbm90 IHNldA0KQ09ORklHX1VTQl9CTFVFVE9PVEg9bQ0KQ09ORklHX1VTQl9TVE9S QUdFPW0NCiMgQ09ORklHX1VTQl9TVE9SQUdFX0RFQlVHIGlzIG5vdCBzZXQN CiMgQ09ORklHX1VTQl9TVE9SQUdFX0ZSRUVDT00gaXMgbm90IHNldA0KQ09O RklHX1VTQl9BQ009bQ0KQ09ORklHX1VTQl9QUklOVEVSPW0NCkNPTkZJR19V U0JfSElEPW0NCkNPTkZJR19VU0JfS0JEPW0NCkNPTkZJR19VU0JfTU9VU0U9 bQ0KIyBDT05GSUdfVVNCX1dBQ09NIGlzIG5vdCBzZXQNCkNPTkZJR19VU0Jf REMyWFg9bQ0KQ09ORklHX1VTQl9NREM4MDA9bQ0KQ09ORklHX1VTQl9TQ0FO TkVSPW0NCkNPTkZJR19VU0JfTUlDUk9URUs9bQ0KIyBDT05GSUdfVVNCX0lC TUNBTSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfT1Y1MTEgaXMgbm90IHNl dA0KIyBDT05GSUdfVVNCX0RTQlIgaXMgbm90IHNldA0KQ09ORklHX1VTQl9E QUJVU0I9bQ0KQ09ORklHX1VTQl9QTFVTQj1tDQpDT05GSUdfVVNCX1BFR0FT VVM9bQ0KQ09ORklHX1VTQl9ORVQxMDgwPW0NCkNPTkZJR19VU0JfVVNTNzIw PW0NCg0KIw0KIyBVU0IgU2VyaWFsIENvbnZlcnRlciBzdXBwb3J0DQojDQpD T05GSUdfVVNCX1NFUklBTD1tDQpDT05GSUdfVVNCX1NFUklBTF9ERUJVRz15 DQpDT05GSUdfVVNCX1NFUklBTF9HRU5FUklDPXkNCkNPTkZJR19VU0JfU0VS SUFMX0JFTEtJTj1tDQpDT05GSUdfVVNCX1NFUklBTF9XSElURUhFQVQ9bQ0K Q09ORklHX1VTQl9TRVJJQUxfRElHSV9BQ0NFTEVQT1JUPW0NCkNPTkZJR19V U0JfU0VSSUFMX0VNUEVHPW0NCkNPTkZJR19VU0JfU0VSSUFMX0ZURElfU0lP PW0NCkNPTkZJR19VU0JfU0VSSUFMX1ZJU09SPW0NCkNPTkZJR19VU0JfU0VS SUFMX0tFWVNQQU5fUERBPW0NCkNPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU49 bQ0KQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTl9VU0EyOD15DQpDT05GSUdf VVNCX1NFUklBTF9LRVlTUEFOX1VTQTI4WD15DQpDT05GSUdfVVNCX1NFUklB TF9LRVlTUEFOX1VTQTE5PXkNCkNPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU5f VVNBMThYPXkNCkNPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU5fVVNBMTlXPXkN CkNPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU5fVVNBNDlXPXkNCkNPTkZJR19V U0JfU0VSSUFMX01DVF9VMjMyPW0NCkNPTkZJR19VU0JfU0VSSUFMX09NTklO RVQ9bQ0KIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0DQoNCiMNCiMg S2VybmVsIGhhY2tpbmcNCiMNCkNPTkZJR19NQUdJQ19TWVNSUT15DQojIENP TkZJR19LREIgaXMgbm90IHNldA0KIyBDT05GSUdfS0FMTFNZTVMgaXMgbm90 IHNldA0KIyBDT05GSUdfRlJBTUVfUE9JTlRFUiBpcyBub3Qgc2V0DQo= --1296032289-682324171-982120019=:25289-- From owner-linux-xfs@oss.sgi.com Tue Feb 13 19:19:09 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 19:18:49 -0800 Received: from mail.connex.com ([216.100.236.3]:19462 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Tue, 13 Feb 2001 19:18:32 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id <1Z0V6WBA>; Tue, 13 Feb 2001 19:14:43 -0800 Message-ID: From: Scott Smyth To: "'linux-xfs@oss.sgi.com '" Subject: RE: less data lost, more fs corruption Date: Tue, 13 Feb 2001 19:14:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi; I have been seeing the same problem in very specific cases of using software RAID 1 and accessing a Samba share with smbclient. I never see it any other time and not every time in this configuration. In addition, it seems to help reproduce this if the RAID 1 is resyncing and smbclient is doing more than 16 clients in a 64 MB configuration on the server. Therefore, it is doing some swap. I applied Andy's patch and am trying to reproduce again. thanks, Scott -----Original Message----- From: utz lehmann To: Steve Lord Cc: linux-xfs@oss.sgi.com Sent: 2/13/01 5:52 PM Subject: Re: less data lost, more fs corruption Steve Lord [lord@sgi.com] wrote: > > the first 6-8 test succeeded. > > i cycled the tests without clean shutdowns between (hmmm maybe one or two). > > > > then i made only one sync. after reboot some files differ. same problem, > > size is ok, but no extents. the number of differs are small. > > > Have you tried this with ext2? no. shoud i? > OK the real issue here is that sync is not really doing sync, the sync system > call is starting I/O, but not waiting for it to complete. At least two syncs > are probably necessary for this scenario right now. If you wait a few seconds > there will be a kernel initiated sync anyway. And as Ananth pointed out, > there are some bits of I/O which will take a couple of passes to get triggered. > > Obviously we cannot immediately flush everything to disk or performance > would tank. The issue with XFS in this area has always been that the > inode size gets out to disk in advance of the file data. You are looking > at a consistent filesystem, it just has data missing! This is why xfs_check > does not complain. ok, when the return of sync means "writing data to disk will done" instead "writing data to disk is done" then the fix works. btw: with 3 syncs and reset in less than a second lost data is seen. is this on irix the same? sometimes i found those no extend files on irix after a crash. utz From owner-linux-xfs@oss.sgi.com Tue Feb 13 20:14:30 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 20:14:20 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:25095 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Tue, 13 Feb 2001 20:14:07 -0800 Received: (qmail 4536 invoked from network); 14 Feb 2001 04:13:59 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 14 Feb 2001 04:13:58 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Chris 'Chipper' Chiapusio" cc: linux-xfs@oss.sgi.com Subject: Re: Unresolved Symbols problem w/ 2.4.1-XFS cvs In-reply-to: Your message of "Tue, 13 Feb 2001 22:06:59 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 15:13:58 +1100 Message-ID: <13193.982124038@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 13 Feb 2001 22:06:59 -0500 (EST), "Chris 'Chipper' Chiapusio" wrote: >a current cvs checkout (as of 02/12/01) gives me mostly usable modules, >only two are not working: >[root@zhadum /root]# depmod -ae >depmod: *** Unresolved symbols in >/lib/modules/2.4.1-XFStest2/kernel/drivers/md/md.o >depmod: name_to_kdev_t Known bug in the md driver, fixed in later kernels. IOW, not our problem :). >depmod: *** Unresolved symbols in >/lib/modules/2.4.1-XFStest2/kernel/net/ipv6/ipv6.o >depmod: rtnetlink_links >depmod: __rta_fill >depmod: rtnetlink_put_metrics >depmod: rtnl This one is strange. I cannot reproduce the problem on 2.4.2-pre3 with your .config but I cannot see any changes between 2.4.1 and 2.4.2-pre3 that would affect rtnetlink. I need the output from strings -a /lib/modules/2.4.1-XFStest2/kernel/net/ipv6/ipv6.o | grep rtn strings -a net/netsyms.o | grep rtn The latter command needs to be issued in the top level linux directory. From owner-linux-xfs@oss.sgi.com Tue Feb 13 20:40:39 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 20:40:30 -0800 Received: from relay02.sportsline.com ([63.72.118.49]:55559 "HELO relay02.sportsline.com") by oss.sgi.com with SMTP id ; Tue, 13 Feb 2001 20:40:22 -0800 Received: (qmail 10540 invoked from network); 14 Feb 2001 04:40:20 -0000 Received: from chipsworld.llamas.net (63.77.33.226) by relay02.sportsline.com with SMTP; 14 Feb 2001 04:40:20 -0000 Received: from localhost (chipper@localhost) by chipsworld.llamas.net (8.11.0/8.11.0) with ESMTP id f1E4eK724281; Tue, 13 Feb 2001 23:40:20 -0500 Date: Tue, 13 Feb 2001 23:40:19 -0500 (EST) From: "Chris 'Chipper' Chiapusio" To: Keith Owens cc: Subject: Re: Unresolved Symbols problem w/ 2.4.1-XFS cvs In-Reply-To: <13193.982124038@ocs3.ocs-net> Message-ID: X-Files: Resist or serve MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing [root@zhadum linux]# strings -a /lib/modules/2.4.1-XFStest2/kernel/net/ipv6/ipv6.o | grep rtn inet6_rtnetlink_table rtnl_sem_Rsmp_96bcc44d rtnl_unlock_Rsmp_6e720ff2 rtnetlink_links rtnetlink_put_metrics rtnl rtnl_lock_Rsmp_c7a4fbed [root@zhadum linux]# strings -a net/netsyms.o | grep rtn rtnetlink_links_R__ver_rtnetlink_links rtnetlink_dump_ifinfo_R__ver_rtnetlink_dump_ifinfo rtnetlink_put_metrics_R__ver_rtnetlink_put_metrics rtnl_R__ver_rtnl rtnl_sem_Rsmp_96bcc44d rtnl_lock_Rsmp_c7a4fbed rtnl_unlock_Rsmp_6e720ff2 __kstrtab_rtnetlink_links __ksymtab_rtnetlink_links rtnetlink_links __kstrtab_rtnetlink_dump_ifinfo __ksymtab_rtnetlink_dump_ifinfo rtnetlink_dump_ifinfo __kstrtab_rtnetlink_put_metrics __ksymtab_rtnetlink_put_metrics rtnetlink_put_metrics __kstrtab_rtnl __ksymtab_rtnl rtnl __kstrtab_rtnl_sem __ksymtab_rtnl_sem rtnl_sem __kstrtab_rtnl_lock __ksymtab_rtnl_lock rtnl_lock __kstrtab_rtnl_unlock __ksymtab_rtnl_unlock rtnl_unlock [root@zhadum linux]# On Wed, 14 Feb 2001, Keith Owens wrote: >On Tue, 13 Feb 2001 22:06:59 -0500 (EST), >"Chris 'Chipper' Chiapusio" wrote: >>a current cvs checkout (as of 02/12/01) gives me mostly usable modules, >>only two are not working: >>[root@zhadum /root]# depmod -ae >>depmod: *** Unresolved symbols in >>/lib/modules/2.4.1-XFStest2/kernel/drivers/md/md.o >>depmod: name_to_kdev_t > >Known bug in the md driver, fixed in later kernels. IOW, not our problem :). > >>depmod: *** Unresolved symbols in >>/lib/modules/2.4.1-XFStest2/kernel/net/ipv6/ipv6.o >>depmod: rtnetlink_links >>depmod: __rta_fill >>depmod: rtnetlink_put_metrics >>depmod: rtnl > >This one is strange. I cannot reproduce the problem on 2.4.2-pre3 with >your .config but I cannot see any changes between 2.4.1 and 2.4.2-pre3 >that would affect rtnetlink. I need the output from > >strings -a /lib/modules/2.4.1-XFStest2/kernel/net/ipv6/ipv6.o | grep rtn >strings -a net/netsyms.o | grep rtn > >The latter command needs to be issued in the top level linux directory. > ------ Please encrypt anything important. PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D From owner-linux-xfs@oss.sgi.com Tue Feb 13 21:00:30 2001 Received: by oss.sgi.com id ; Tue, 13 Feb 2001 21:00:20 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:35335 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Tue, 13 Feb 2001 21:00:07 -0800 Received: (qmail 4871 invoked from network); 14 Feb 2001 05:00:02 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 14 Feb 2001 05:00:02 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Chris 'Chipper' Chiapusio" cc: linux-xfs@oss.sgi.com Subject: Re: Unresolved Symbols problem w/ 2.4.1-XFS cvs In-reply-to: Your message of "Tue, 13 Feb 2001 23:40:19 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 16:00:01 +1100 Message-ID: <13417.982126801@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 13 Feb 2001 23:40:19 -0500 (EST), "Chris 'Chipper' Chiapusio" wrote: >[root@zhadum linux]# strings -a net/netsyms.o | grep rtn >rtnetlink_links_R__ver_rtnetlink_links Sigh. Broken kernel makefiles again. cp .config .. make mrproper mv ../.config . make oldconfig make dep clean make bzImage modules Install From owner-linux-xfs@oss.sgi.com Wed Feb 14 03:25:32 2001 Received: by oss.sgi.com id ; Wed, 14 Feb 2001 03:25:22 -0800 Received: from h217n3fls20o974.telia.com ([212.181.166.217]:20744 "HELO neoblade.net") by oss.sgi.com with SMTP id ; Wed, 14 Feb 2001 03:25:10 -0800 Received: from student.liu.se (localhost.localdomain [127.0.0.1]) by neoblade.net (Postfix) with ESMTP id 5E8EA34; Wed, 14 Feb 2001 12:26:15 +0100 (CET) Message-ID: <3A8A6B4B.70007@student.liu.se> Date: Wed, 14 Feb 2001 12:26:03 +0100 From: Joakim Bodin User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.1-XFS i686; en-US; m18) Gecko/20010210 X-Accept-Language: sv, en MIME-Version: 1.0 To: Steve Lord Cc: Linux-XFS Mailing List Subject: Re: For those people with IDE problems with XFS References: <200102122225.f1CMP2K06561@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > If you are using the development tree and ide is blowing chunks for you, > can you try the following patch, it removes some of the code added for > the kio patch, and backports some changes from 2.4.2-pre3 which fix ide > problems. No guarantees on this one but for me it appears to be working > here. > > I think you can expect to see 2.4.2-pre3 in a day or so, it may be a real > 2.4.2 by then. > > Steve > I just want to report that this seems to fix all the lockup problems I've been having since xfs cvs moved to 2.4.1. It survives big slocates and compiles that locked it up previously. This is a P2-300, 128MB RAM with ide disk using udma33. Joakim Bodin From owner-linux-xfs@oss.sgi.com Wed Feb 14 08:58:35 2001 Received: by oss.sgi.com id ; Wed, 14 Feb 2001 08:58:15 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:42592 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 14 Feb 2001 08:58:03 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA25395 for ; Wed, 14 Feb 2001 08:57:01 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA815177; Wed, 14 Feb 2001 10:56:45 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA14857; Wed, 14 Feb 2001 10:56:44 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1EGw4n23266; Wed, 14 Feb 2001 10:58:04 -0600 Message-Id: <200102141658.f1EGw4n23266@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Annius Groenink cc: linux-xfs@oss.sgi.com Subject: Re: Mounting real-time device - can it be done? In-Reply-To: Message from Annius Groenink of "Wed, 14 Feb 2001 00:57:04 +0100." Date: Wed, 14 Feb 2001 10:58:04 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > Annius Groenink writes: > > => Unfortunately, this still gives me: > > => > > => iep:/usr/include/linux# mount -t xfs -o rtdev=/dev/hdb3 /dev/hdb4 /mnt/ > xfs > > => mount: wrong fs type, bad option, bad superblock on /dev/hdb4, > > => or too many mounted file systems > > => > > > > Oh yeah - check the syslog output too - the message from mount is > > useless, but the syslog can be quite informative. > > > Did that. Nothing. Anything I can do to make it more verbose? > > > -- > > dr Annius V. Groenink > groenink@eidetica.com > tel +31 20 888 4126 fax 4001 > Hi, I did some code reading, and realtime subvolume is somewhat broken at the moment, I will add it to my list. Once you get past the mount issue, the I/O path itself is not going to understand the realtime device too well and will trample on the rest of your filesystem. I will not be able to get to this until at least the end of next week (being on vaction most of the time in between). Feel free to dig around in the code, and see if you can work out what needs doing, but this will involve changes to xfs and pagebuf. Specifically, pagebuf bases all of it's I/O off the dev_t in the inode, for realtime we will need a different dev_t. I have some rough ideas on how to deal with this - we can extend the structure used by the pb_bmap call to include a device and use this for I/O in page_buf_io.c. Secondly, the code infs/xfs/linux/xfs_lrw.c does not care much about realtime either, this will probably take someone with access to the Irix source to fix up. There is probably a few days work by the right people to get realtime into some sort of shape where it actually does reasonable things. Note though, that all this gives us is a way to use a different allocation policy for file data, and a better chance of well formatted and non-fragmented data. It will still be accessed via the buffered I/O path until we get O_DIRECT to function. Hope this does not put you off XFS! Steve From owner-linux-xfs@oss.sgi.com Wed Feb 14 10:53:15 2001 Received: by oss.sgi.com id ; Wed, 14 Feb 2001 10:52:56 -0800 Received: from porgy.srv.nld.sonera.net ([195.66.15.137]:1657 "EHLO porgy.srv.nld.sonera.net") by oss.sgi.com with ESMTP id ; Wed, 14 Feb 2001 10:52:41 -0800 Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:63475 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Wed, 14 Feb 2001 19:51:59 +0100 Message-Id: <4.3.2.7.2.20010214194910.03fffed8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2001 19:49:39 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Oops when dialing over a Eicon Diva Server card Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 08:57 12-2-2001 -0600, you wrote: > > On Mon, Feb 12, 2001 at 08:51:21AM +0100, Seth Mos wrote: > > > I attached the file that is produced when I'm trying to dial over the > ISDN > > > device using minicom. I will reproduce the samba oops later and send > that > > > one to the list. > > > > [...] > > > > Very much looks like a Eicon bug. I would suggest to contact the Eicon or > > ISDN maintainers. If XFS would corrupt random memory other subsystems would > > break too. > > > > > > -Andi > > >I would second Andi's opinion on this - we do not have changes in the kernel >which should affect this. Mind you, nothing in the isdn code appears to have >changed much in 2.4.1 either. 2.4.2-pre3 takes a rather large swipe at isdn. > >However, I do notice empty_bad_page in the trace - this is not a function >call, but a special page. I checked in one fix in a swapout path on Friday >which was related to pte corruption with XFS, you need the latest >version of mm/vmscan.c. Are you running with this file? > >Steve I waxed the tree the other day, rebuilt it from scratch and rebuild it. I can't oops the machine under high long disk and aggresive memory use. Network speed is also normal. Files of 2.8GB are no problem to put onto the samba share. So I consider this "fixed". Bye -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Wed Feb 14 13:41:07 2001 Received: by oss.sgi.com id ; Wed, 14 Feb 2001 13:40:49 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:51066 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 14 Feb 2001 13:40:15 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05939 for ; Wed, 14 Feb 2001 13:40:13 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA819476; Wed, 14 Feb 2001 15:38:57 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA33763; Wed, 14 Feb 2001 15:38:57 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1ELeFp11507; Wed, 14 Feb 2001 15:40:15 -0600 Message-Id: <200102142140.f1ELeFp11507@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Joakim Bodin cc: Steve Lord , Linux-XFS Mailing List Subject: Re: For those people with IDE problems with XFS In-Reply-To: Message from Joakim Bodin of "Wed, 14 Feb 2001 12:26:03 +0100." <3A8A6B4B.70007@student.liu.se> Date: Wed, 14 Feb 2001 15:40:15 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Joakim Bodin wrote: > Steve Lord wrote: > > > If you are using the development tree and ide is blowing chunks for you, > > can you try the following patch, it removes some of the code added for > > the kio patch, and backports some changes from 2.4.2-pre3 which fix ide > > problems. No guarantees on this one but for me it appears to be working > > here. > > > > I think you can expect to see 2.4.2-pre3 in a day or so, it may be a real > > 2.4.2 by then. > > > > Steve > > > I just want to report that this seems to fix all the lockup problems > I've been having since xfs cvs moved to 2.4.1. It survives big slocates > and compiles that locked it up previously. This is a P2-300, 128MB RAM > with ide disk using udma33. > > Joakim Bodin Thanks for the feedback, We are fixing up some issues with kiobufs and multmode ide, once this is done I will either push this code into the 2.4.1 tree, or bring the tree up to 2.4.2-pre3. I was hoping to see a 2.4.2 come out by now and base the tree on that but we are still waiting. Steve From owner-linux-xfs@oss.sgi.com Wed Feb 14 15:59:59 2001 Received: by oss.sgi.com id ; Wed, 14 Feb 2001 15:59:39 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24435 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 14 Feb 2001 15:59:22 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA03502 for ; Wed, 14 Feb 2001 16:08:37 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA819214 for ; Wed, 14 Feb 2001 17:57:58 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA60541 for ; Wed, 14 Feb 2001 17:57:58 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f1ENxF615419; Wed, 14 Feb 2001 17:59:15 -0600 Message-Id: <200102142359.f1ENxF615419@jen.americas.sgi.com> Date: Wed, 14 Feb 2001 17:59:15 -0600 Subject: TAKE - here is a scary one! To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This removes the need for the partial page bitmap we added to the page structure. By always fully populating the page on the initial read we no longer have to deal with this. This simplifies some logic in pagebuf, makes it cleaner and removes a fairly major intrusion into the main kernel data structures. I have done fairly extensive testing on this (rpm builds of big things are a good test of this stuff) however, there is always a chance that I missed something. So if something bizzare happens after you are running this code please let me know. Steve Date: Wed Feb 14 15:54:41 PST 2001 Workarea: 128.162.184.86:/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:87627a linux/mm/filemap.c - 1.67 - remove initialization of partial page bitmap linux/include/linux/mm.h - 1.48 - remove partial page bitmap and associated macros for manipulating it. linux/kdb/modules/kdbm_pg.c - 1.27 - remove partial page info from dump of page structure. linux/fs/pagebuf/page_buf.c - 1.54 - Remove partial page logic, it is now dealt with by reading in the whole page initially. linux/fs/pagebuf/page_buf_io.c - 1.52 - Remove partial page logic From owner-linux-xfs@oss.sgi.com Wed Feb 14 16:18:58 2001 Received: by oss.sgi.com id ; Wed, 14 Feb 2001 16:18:39 -0800 Received: from mail.connex.com ([216.100.236.3]:30732 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Wed, 14 Feb 2001 16:18:15 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id <1Z0V6YBL>; Wed, 14 Feb 2001 16:14:31 -0800 Message-ID: From: Scott Smyth To: 'Steve Lord ' Cc: "'linux-xfs@oss.sgi.com'" , "'dcox@maindspring.com'" Subject: RE: For those people with IDE problems with XFS - RAID 0 Date: Wed, 14 Feb 2001 16:14:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi; More information with regard to RAID 1 usage and XFS. It appears that xfs_alloc_lookup is trying to copy a NULL reference (0x0...) during a sys_write call. I seem to only be able to reproduce this for a RAID 1 (not for RAID 0 or RAID 5) using UDMA IDE drives. kdb started and the stack traced down to a NULL reference for xfs_alloc_lookup. It does not happen every time, but it is very repeatable as samba (via smbtorture) tests (via samba dbench) cause the oops. A different kdb oops happened from: _page_buf_page_apply <- kio_cluster_write <- sys_write and a NULL reference. The one was prefaced by a kernel message of a 0-order allocation error (page_buf.c 1369 error). I applied Rajagopal Ananthanarayanan's prepare_write.patch to check its effect, but I have seen no change. The result is the same with the kernel reporting: __alloc_pages: 0-order allocation failed. In addition, the 2.4.2-pre3 patch with the kernel CVS tree up to date. thanks, Scott -----Original Message----- From: Steve Lord To: Joakim Bodin Cc: Steve Lord; Linux-XFS Mailing List Sent: 2/14/01 1:40 PM Subject: Re: For those people with IDE problems with XFS Joakim Bodin wrote: > Steve Lord wrote: > > > If you are using the development tree and ide is blowing chunks for you, > > can you try the following patch, it removes some of the code added for > > the kio patch, and backports some changes from 2.4.2-pre3 which fix ide > > problems. No guarantees on this one but for me it appears to be working > > here. > > > > I think you can expect to see 2.4.2-pre3 in a day or so, it may be a real > > 2.4.2 by then. > > > > Steve > > > I just want to report that this seems to fix all the lockup problems > I've been having since xfs cvs moved to 2.4.1. It survives big slocates > and compiles that locked it up previously. This is a P2-300, 128MB RAM > with ide disk using udma33. > > Joakim Bodin Thanks for the feedback, We are fixing up some issues with kiobufs and multmode ide, once this is done I will either push this code into the 2.4.1 tree, or bring the tree up to 2.4.2-pre3. I was hoping to see a 2.4.2 come out by now and base the tree on that but we are still waiting. Steve From owner-linux-xfs@oss.sgi.com Wed Feb 14 22:02:02 2001 Received: by oss.sgi.com id ; Wed, 14 Feb 2001 22:01:42 -0800 Received: from pipt.oz.cc.utah.edu ([155.99.2.7]:32968 "EHLO pipt.oz.cc.utah.edu") by oss.sgi.com with ESMTP id ; Wed, 14 Feb 2001 22:01:23 -0800 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id XAA16912 for ; Wed, 14 Feb 2001 23:01:08 -0700 (MST) Date: Wed, 14 Feb 2001 23:01:08 -0700 (MST) From: james rich To: linux-xfs@oss.sgi.com Subject: build failure update and raid 0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have an update on the build problems I'm having in cmd/*. If I enter (for example) cmd/xfsprogs and type make the build fails. But if I enter each subdirectory of xfsprogs and type make everything builds fine. So the problem seems to be with the top level Makefile building invalid targets. I'll investigate and hopefully come up with the right answer. I also thought I should mention that I am running xfs on a raid level 0 device (using the md driver). The XFS FAQ mentions that xfs hasn't been tested with raid and that people using it should let folks know how it works. The FAQ also says that xfs will not work with the md driver and the kiobuf option enabled. Now I don't remember if the kiobuf option is enabled, but xfs is working beautifully on md0. Any tests anyone would like me to try? The data on md0 doesn't matter so no problem if I lose it all (it would suck to lose stuff on the other devices though). James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Thu Feb 15 06:01:38 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 06:01:19 -0800 Received: from skl1.ukl.uni-freiburg.de ([193.196.199.1]:22510 "HELO skl1.ukl.uni-freiburg.de") by oss.sgi.com with SMTP id ; Thu, 15 Feb 2001 06:00:55 -0800 Received: (qmail 10376 invoked by alias); 15 Feb 2001 14:00:50 -0000 Received: (qmail 10371 invoked from network); 15 Feb 2001 14:00:50 -0000 Received: from msm138.ukl.uni-freiburg.de (HELO ukl.uni-freiburg.de) (193.196.218.138) by skl1.ukl.uni-freiburg.de with SMTP; 15 Feb 2001 14:00:50 -0000 Message-ID: <3A8BE135.9294EBC7@ukl.uni-freiburg.de> Date: Thu, 15 Feb 2001 15:01:25 +0100 From: "Manfred W. Baumstark" Organization: Medizinische Universitaetsklink Freiburg X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: PCMCIA and devfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have installed the pre-release 0.9 using the RPM methode on a redhat 7.0 system. Unfortunately I'm no real Linux expert, which might explain my questions: (I have updated the other packages as well, devfsd and modules.devfs are installed) First, the link to the mailing-list archive is broken. I know that some of my problems have been discussed there. The most serious problem is, that pcmcia does not work. If I insert my adaptec scsi card, the system looks up. Any suggestions? I want to attach an 72GB external xfs disk to my notebook for data collection and later read it on my IRIX machine. No root xfs is required. Probably I do not need devfs. How exactly can I switch devfs off, by including a option in lilo? Or do I have to recompile the kernel (with kgcc?)? The rest is also related to devfs, not important, but annoying: No device entry is generated for my ide-cd. If I manually execute "modprobe ide-cd" I get /dev/cdroms/cdrom* and /dev/hdb but not /dev/cdrom. How can I generate this entry? The same with /dev/mouse. I would like to have a symlink /dev/mouse --> /dev/psaux. Sincerely Manfred Baumstark From owner-linux-xfs@oss.sgi.com Thu Feb 15 09:36:49 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 09:36:39 -0800 Received: from jeremi.jeremi.pl ([212.160.232.2]:32730 "EHLO jeremi.jeremi.pl") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 09:36:25 -0800 Received: from localhost (linux-xfs@localhost) by jeremi.jeremi.pl (8.10.1/8.10.1) with ESMTP id f1FJVGZ18641; Thu, 15 Feb 2001 20:31:16 +0100 Date: Thu, 15 Feb 2001 20:31:11 +0100 (CET) From: To: "Manfred W. Baumstark" cc: linux-xfs@oss.sgi.com Subject: Re: PCMCIA and devfs In-Reply-To: <3A8BE135.9294EBC7@ukl.uni-freiburg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 15 Feb 2001, Manfred W. Baumstark wrote: > ide-cd" I get /dev/cdroms/cdrom* and /dev/hdb but not /dev/cdrom. How can I > generate this entry? > > The same with /dev/mouse. I would like to have a symlink /dev/mouse --> > /dev/psaux. Ensure you have devfsd in memory: [root@jeremi ipv4]# ps auxw | grep devfsd | grep -v grep root 35 0.0 0.2 1184 528 ? S Feb09 0:00 devfsd /dev and check /etc/devfsd.conf that you have autoloading uncommented # Enable module autoloading. You may comment this out if you don't use # autoloading LOOKUP .* MODLOAD (modprobe? whats modprobe? ;) and uncommented: # Enable full compatibility mode for old device names. You may comment these # out if you don't use the old device names. Make sure you know what you're # doing! REGISTER .* MKOLDCOMPAT UNREGISTER .* RMOLDCOMPAT there is one more file which defines what modules to autoload depending on what you are trying to finger in /dev directory: /etc/modules.devfs but that one should be left unchanged , its better to make sure that aliases in modules.conf are defined correctly and this unfortunate mouse link... just devfsd developer has serial mouse if any ;) (i'm investigating it now) heh, it creates this link even if i've serials away completely :) and i'm not starting daemon ;) for now only solution is to manually remove that link and make your own one rc.local or /etc/rc.d/init.d/gpm (if you use it) hope this brings some light Filip linux-xfs@jeremi.pl From owner-linux-xfs@oss.sgi.com Thu Feb 15 11:26:39 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 11:26:20 -0800 Received: from tux.mkp.net ([130.225.60.11]:17674 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 11:25:50 -0800 Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.16 #1) id 14TU1v-0007Em-00; Thu, 15 Feb 2001 20:25:48 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id JAA01049; Thu, 15 Feb 2001 09:24:39 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: james rich Cc: linux-xfs@oss.sgi.com Subject: Re: build failure update and raid 0 References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 15 Feb 2001 09:24:39 -0500 In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "james" == james rich writes: james> I also thought I should mention that I am running xfs on a raid james> level 0 device (using the md driver). The XFS FAQ mentions james> that xfs hasn't been tested with raid and that people using it james> should let folks know how it works. XFS works fine on MD RAID0. Some people have reported funnies with RAID1, and that's on my list of things to look into. We have fixes for RAID5, but performance suffers. Especially during resync. Fixing that will require major surgery to the stripe cache. james> The FAQ also says that xfs will not work with the md driver and james> the kiobuf option enabled. Now I don't remember if the kiobuf james> option is enabled, but xfs is working beautifully on md0. You enable kiobuf I/O by giving -o kio as mount option. I.e. mount -o kio /dev/sdb2 /foo That will currently fail miserably with MD and LVM, though. I'm very close to having kiobuf based LVM ready to go into the tree. MD RAID0 is next on my list. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Thu Feb 15 12:18:00 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 12:17:40 -0800 Received: from skl1.ukl.uni-freiburg.de ([193.196.199.1]:33021 "HELO skl1.ukl.uni-freiburg.de") by oss.sgi.com with SMTP id ; Thu, 15 Feb 2001 12:17:20 -0800 Received: (qmail 26413 invoked by alias); 15 Feb 2001 20:17:08 -0000 Received: (qmail 26408 invoked from network); 15 Feb 2001 20:17:07 -0000 Received: from msm205.ukl.uni-freiburg.de (HELO ukl.uni-freiburg.de) (193.196.218.205) by skl1.ukl.uni-freiburg.de with SMTP; 15 Feb 2001 20:17:07 -0000 Message-ID: <3A8C3919.51093E42@ukl.uni-freiburg.de> Date: Thu, 15 Feb 2001 21:16:25 +0100 From: "Manfred W. Baumstark" Organization: Medizinische Universitaetsklink Freiburg X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-SGI_XFS_PR i686) X-Accept-Language: en,de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: PCMCIA and devfs References: Content-Type: multipart/mixed; boundary="------------80D884886D0A306800D35328" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------80D884886D0A306800D35328 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My devfsd.conf file is unmodified from "devfsd-v1.3.11" and looks like you suggest. And devfsd is loaded: [maba@asus03 maba]$ ps -ef | grep devfs root 24 1 0 20:48 ? 00:00:00 /sbin/devfsd /dev maba 822 813 0 20:50 pts/0 00:00:00 grep devfs In my /dev there are a lot of compatibility entries. There must be a problem with autoloading the ide-cd driver. If I maually load the cd driver by "modprobe ide-cd" I can mount the cd. The mouse problem is only minor, as the mouse works in X. I nearly never need gpm. Once I have found the config-file for gpm I will change it to use /dev/psaux as the devfs FAQ suggests ;-). Manfred linux-xfs@jeremi.jeremi.pl wrote: > > On Thu, 15 Feb 2001, Manfred W. Baumstark wrote: > > > ide-cd" I get /dev/cdroms/cdrom* and /dev/hdb but not /dev/cdrom. How can I > > generate this entry? > > > > The same with /dev/mouse. I would like to have a symlink /dev/mouse --> > > /dev/psaux. > > Ensure you have devfsd in memory: > [root@jeremi ipv4]# ps auxw | grep devfsd | grep -v grep > root 35 0.0 0.2 1184 528 ? S Feb09 0:00 devfsd /dev > > and check /etc/devfsd.conf that you have autoloading uncommented > > # Enable module autoloading. You may comment this out if you don't use > # autoloading > LOOKUP .* MODLOAD > > (modprobe? whats modprobe? ;) > and uncommented: > > # Enable full compatibility mode for old device names. You may comment > these > # out if you don't use the old device names. Make sure you know what > you're > # doing! > REGISTER .* MKOLDCOMPAT > UNREGISTER .* RMOLDCOMPAT > > there is one more file which defines what modules to autoload depending on > what you are trying to finger in /dev directory: > /etc/modules.devfs > but that one should be left unchanged , its better to make sure that > aliases in modules.conf are defined correctly > --------------80D884886D0A306800D35328 Content-Type: text/x-vcard; charset=us-ascii; name="maba.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Manfred W. Baumstark Content-Disposition: attachment; filename="maba.vcf" begin:vcard n:Baumstark;Manfred tel;fax:+49 761 270 7470 tel;work:+49 761 270 7496 x-mozilla-html:TRUE org:University Hospital Freiburg;Rehabilitative and Preventive Sportsmedicine adr:;;Hugstetter Str. 55;Freiburg;;D-79106;Germany version:2.1 email;internet:manfred.baumstark@uni-freiburg.de title:Dr. x-mozilla-cpt:;29056 fn:Manfred Baumstark end:vcard --------------80D884886D0A306800D35328-- From owner-linux-xfs@oss.sgi.com Thu Feb 15 12:29:50 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 12:29:30 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:26221 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 12:29:13 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07859 for ; Thu, 15 Feb 2001 12:28:49 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA43489; Thu, 15 Feb 2001 14:27:29 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1FKQSe10786; Thu, 15 Feb 2001 20:26:29 GMT Message-ID: <3A8C3B74.14952557@thebarn.com> Date: Thu, 15 Feb 2001 20:26:28 +0000 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: "Chris 'Chipper' Chiapusio" CC: Keith Owens , linux-xfs@oss.sgi.com Subject: Re: Unresolved Symbols problem w/ 2.4.1-XFS cvs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Chris 'Chipper' Chiapusio wrote: > a current cvs checkout (as of 02/12/01) gives me mostly usable modules, > only two are not working: > [root@zhadum /root]# depmod -ae > depmod: *** Unresolved symbols in > /lib/modules/2.4.1-XFStest2/kernel/drivers/md/md.o > depmod: name_to_kdev_t I'm seeing this also... no clue as to why it is showing up? chuckle[2:12pm]-=>grep name_to_k /boot/System.map c032c248 T name_to_kdev_t I ended up compiling md into the kernel for now. > > depmod: *** Unresolved symbols in > /lib/modules/2.4.1-XFStest2/kernel/net/ipv6/ipv6.o > depmod: rtnetlink_links > depmod: __rta_fill > depmod: rtnetlink_put_metrics > depmod: rtnl > > with the attached .config > > Chipper > > On Thu, 8 Feb 2001, Keith Owens wrote: > > >On Wed, 7 Feb 2001 15:58:44 -0500 (EST), > >"Chris 'Chipper' Chiapusio" wrote: > >>I've been trying to get this going for days now. I've read the list > >>archives, checked Documentation/Changes and ensured that all my tools are > >>up to date. I've done cp .config ..;make mrproper;cp ../.config .;make > >>oldconfig; make dep && make clean && make bzlilo && make modules && make > >>modules_install > > > >Which should give you a clean build, even with the makefile bugs and > >modversions turned on. You have not said what errors you are getting > >which makes it difficult to see what is wrong. > > > > ------ > Please encrypt anything important. > PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D > > ------------------------------------------------------------------------ > Name: 241XFS.config > 241XFS.config Type: Plain Text (TEXT/PLAIN) > Encoding: BASE64 -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Thu Feb 15 12:35:20 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 12:35:11 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:2928 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 12:35:08 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07891 for ; Thu, 15 Feb 2001 12:35:06 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA833360; Thu, 15 Feb 2001 14:32:51 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA34524; Thu, 15 Feb 2001 14:32:51 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1FKXxV09462; Thu, 15 Feb 2001 14:33:59 -0600 Message-Id: <200102152033.f1FKXxV09462@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Russell Cattelan cc: "Chris 'Chipper' Chiapusio" , Keith Owens , linux-xfs@oss.sgi.com Subject: Re: Unresolved Symbols problem w/ 2.4.1-XFS cvs In-Reply-To: Message from Russell Cattelan of "Thu, 15 Feb 2001 20:26:28 GMT." <3A8C3B74.14952557@thebarn.com> Date: Thu, 15 Feb 2001 14:33:59 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This was already answered elsewhere by Keith, it is an md bug. Steve > Chris 'Chipper' Chiapusio wrote: > > > a current cvs checkout (as of 02/12/01) gives me mostly usable modules, > > only two are not working: > > [root@zhadum /root]# depmod -ae > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.1-XFStest2/kernel/drivers/md/md.o > > depmod: name_to_kdev_t > > I'm seeing this also... no clue as to why it is showing up? > chuckle[2:12pm]-=>grep name_to_k /boot/System.map > c032c248 T name_to_kdev_t > > I ended up compiling md into the kernel for now. > > > > > > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.1-XFStest2/kernel/net/ipv6/ipv6.o > > depmod: rtnetlink_links > > depmod: __rta_fill > > depmod: rtnetlink_put_metrics > > depmod: rtnl > > > > with the attached .config > > > > Chipper > > > > On Thu, 8 Feb 2001, Keith Owens wrote: > > > > >On Wed, 7 Feb 2001 15:58:44 -0500 (EST), > > >"Chris 'Chipper' Chiapusio" wrote: > > >>I've been trying to get this going for days now. I've read the list > > >>archives, checked Documentation/Changes and ensured that all my tools are > > >>up to date. I've done cp .config ..;make mrproper;cp ../.config .;make > > >>oldconfig; make dep && make clean && make bzlilo && make modules && make > > >>modules_install > > > > > >Which should give you a clean build, even with the makefile bugs and > > >modversions turned on. You have not said what errors you are getting > > >which makes it difficult to see what is wrong. > > > > > > > ------ > > Please encrypt anything important. > > PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D > > > > ------------------------------------------------------------------------ > > Name: 241XFS.config > > 241XFS.config Type: Plain Text (TEXT/PLAIN) > > Encoding: BASE64 > > -- > Russell Cattelan > -- > Digital Elves inc. -- Currently on loan to SGI > Linux XFS core developer. > > From owner-linux-xfs@oss.sgi.com Thu Feb 15 12:36:00 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 12:35:50 -0800 Received: from plato.arts.usyd.edu.au ([129.78.16.1]:21003 "EHLO plato.arts.usyd.edu.au") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 12:35:35 -0800 Received: from arts.usyd.edu.au (IDENT:matthew@holly.aitch.ucc.usyd.edu.au [129.78.226.234]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id HAA24170; Fri, 16 Feb 2001 07:31:34 +1100 (EST) Message-ID: <3A8C3D0F.B6E4A055@arts.usyd.edu.au> Date: Fri, 16 Feb 2001 07:33:19 +1100 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: "Manfred W. Baumstark" CC: linux-xfs@oss.sgi.com Subject: Re: PCMCIA and devfs References: <3A8BE135.9294EBC7@ukl.uni-freiburg.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2AA03504EEB0EBD44FE51744" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a cryptographically signed message in MIME format. --------------ms2AA03504EEB0EBD44FE51744 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Manfred W. Baumstark" wrote: > > I have installed the pre-release 0.9 using the RPM methode on a redhat 7.0 > system. Unfortunately I'm no real Linux expert, which might explain my > questions: > > (I have updated the other packages as well, devfsd and modules.devfs are > installed) > > First, the link to the mailing-list archive is broken. I know that some of > my problems have been discussed there. > > The most serious problem is, that pcmcia does not work. If I insert my > adaptec scsi card, the system looks up. Any suggestions? It is also a devfs problem - I posted about this a week or so back. Turn off devfs entirelty and run a 'traditional' /dev. My machine at least, started working with PCMCIA (I wanted to read CF cards from my cammera) > Probably I do not need devfs. How exactly can I switch devfs off, by > including a option in lilo? Or do I have to recompile the kernel (with > kgcc?)? devfs=nomount I think. Thats what I did to my Dell laptop. --------------ms2AA03504EEB0EBD44FE51744 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH4AYJKoZIhvcNAQcCoIIH0TCCB80CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BckwggKtMIICFqADAgECAgMC8UswDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyMTAyNDAzNFoXDTAxMDcyMTAyNDAz NFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYY bWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR gAKbBhCplgqyhkR0Ykn4XOW0Py1G40orbP+B2KkACTMx4GxhHNg2h3nPiNC/P/9BZETw6NA+ dp/mxtN7XHmvRounnCL+9pjG3yWpw/ONNEpObjRSfujGe/jJvUF2vrAfecI/J5DKQ0/5gZMv 5fqfl4spYSPl+9vc2hKG7uvjgQIDAQABo1YwVDAjBgNVHREEHDAagRhtYXR0aGV3QGFydHMu dXN5ZC5lZHUuYXUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORYx0YdwGG9 I9fDjDANBgkqhkiG9w0BAQQFAAOBgQBjjvY9P9hSktFnCJrkQSTKjh9ZBG9a58a0Hi+GvmyD t9e29sRgxHN+Nwtsu2yUs8+xv1BemYzCnri+y91uJsfRTrm4+1oc/TV+lDGWqBud68wf4x29 /xaj1oQ2vWMy1Y64KZSWyxjt+vcU5/nyNF3DGz9XtXlxTI8dntzEWkyq/DCCAxQwggJ9oAMC AQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxs ZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn /XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESw iy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL3Vx1b8aR kMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6syg1vcnpn LGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAd8wggHbAgEBMIGcMIGUMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UE ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAvFLMAkGBSsOAwIaBQCggZkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMjE1MjAzMzI4WjAjBgkq hkiG9w0BCQQxFgQUCl3WkVruGqVS7BjjLl/2zLKOumkwOgYJKoZIhvcNAQkPMS0wKzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwDQYJKoZIhvcNAQEBBQAE gYCpL3QBW9q52sA0J6okMXIS/1iJbK0nwO56FFsQ/BBV0m54F6nx8Dx08q9oLSz5xdfiQO1Y tDe5sn4KsWTjUIq/ulJbB0qXBiAq6rtFNWfaqSiV4FugLf6oljELrihhY494FGQesqeyffsk IgZlUsSCZFXHLBPTxYnO8QDUfSkpxA== --------------ms2AA03504EEB0EBD44FE51744-- From owner-linux-xfs@oss.sgi.com Thu Feb 15 12:37:30 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 12:37:21 -0800 Received: from mail15.jump.net ([206.196.91.15]:31370 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 12:36:59 -0800 Received: from Porter (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f1FKUuL08403; Thu, 15 Feb 2001 14:30:56 -0600 (CST) Message-Id: <200102152030.f1FKUuL08403@mail15.jump.net> Subject: Re: PCMCIA and devfs From: Eric Sandeen To: Manfred "W." Baumstark Cc: linux-xfs@oss.sgi.com In-Reply-To: <3A8C3919.51093E42@ukl.uni-freiburg.de> References: <3A8C3919.51093E42@ukl.uni-freiburg.de> Content-Type: text/plain X-Mailer: Evolution (0.8/+cvs.2001.02.13.10.28 - Preview Release) Date: 15 Feb 2001 14:31:25 -0600 Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing You should also have the file /etc/modules.devfs which was inadvertantly left out of the devfsd RPM we distributed... this file is needed for module autoloading. You can get the file out of the standard devfsd distribution, or from the "updates/" dir on our FTP site. -Eric On 15 Feb 2001 21:16:25 +0100, Manfred W. Baumstark wrote: > My devfsd.conf file is unmodified from "devfsd-v1.3.11" and looks like you > suggest. And devfsd is loaded: > > [maba@asus03 maba]$ ps -ef | grep devfs > root 24 1 0 20:48 ? 00:00:00 /sbin/devfsd /dev > maba 822 813 0 20:50 pts/0 00:00:00 grep devfs > > In my /dev there are a lot of compatibility entries. There must be a > problem with autoloading the ide-cd driver. If I maually load the cd driver > by "modprobe ide-cd" I can mount the cd. The mouse problem is only minor, > as the mouse works in X. I nearly never need gpm. Once I have found the > config-file for gpm I will change it to use /dev/psaux as the devfs FAQ > suggests ;-). > > Manfred From owner-linux-xfs@oss.sgi.com Thu Feb 15 13:11:20 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 13:11:00 -0800 Received: from skl1.ukl.uni-freiburg.de ([193.196.199.1]:17662 "HELO skl1.ukl.uni-freiburg.de") by oss.sgi.com with SMTP id ; Thu, 15 Feb 2001 13:10:35 -0800 Received: (qmail 27335 invoked by alias); 15 Feb 2001 21:10:32 -0000 Received: (qmail 27327 invoked from network); 15 Feb 2001 21:10:31 -0000 Received: from msm205.ukl.uni-freiburg.de (HELO ukl.uni-freiburg.de) (193.196.218.205) by skl1.ukl.uni-freiburg.de with SMTP; 15 Feb 2001 21:10:31 -0000 Message-ID: <3A8C459B.8F4400AC@ukl.uni-freiburg.de> Date: Thu, 15 Feb 2001 22:09:47 +0100 From: "Manfred W. Baumstark" Organization: Medizinische Universitaetsklink Freiburg X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-SGI_XFS_PR i686) X-Accept-Language: en,de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: PCMCIA and devfs References: <3A8C3919.51093E42@ukl.uni-freiburg.de> <200102152030.f1FKUuL08403@mail15.jump.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I also have /etc/modules.devfs and the latest version of devfsd (devfsd-v1.3.11) which made no difference compared to the RPM plus modules.devfs you distributed. Manfred Eric Sandeen wrote: > > You should also have the file /etc/modules.devfs which was inadvertantly > left out of the devfsd RPM we distributed... this file is needed for > module autoloading. > > You can get the file out of the standard devfsd distribution, or from > the "updates/" dir on our FTP site. > > -Eric > > On 15 Feb 2001 21:16:25 +0100, Manfred W. Baumstark wrote: > > My devfsd.conf file is unmodified from "devfsd-v1.3.11" and looks like you > > suggest. And devfsd is loaded: > > > > [maba@asus03 maba]$ ps -ef | grep devfs > > root 24 1 0 20:48 ? 00:00:00 /sbin/devfsd /dev > > maba 822 813 0 20:50 pts/0 00:00:00 grep devfs > > > > In my /dev there are a lot of compatibility entries. There must be a > > problem with autoloading the ide-cd driver. If I maually load the cd driver > > by "modprobe ide-cd" I can mount the cd. The mouse problem is only minor, > > as the mouse works in X. I nearly never need gpm. Once I have found the > > config-file for gpm I will change it to use /dev/psaux as the devfs FAQ > > suggests ;-). > > > > Manfred From owner-linux-xfs@oss.sgi.com Thu Feb 15 13:29:20 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 13:29:11 -0800 Received: from skl1.ukl.uni-freiburg.de ([193.196.199.1]:26110 "HELO skl1.ukl.uni-freiburg.de") by oss.sgi.com with SMTP id ; Thu, 15 Feb 2001 13:28:46 -0800 Received: (qmail 27515 invoked by alias); 15 Feb 2001 21:28:43 -0000 Received: (qmail 27510 invoked from network); 15 Feb 2001 21:28:42 -0000 Received: from msm205.ukl.uni-freiburg.de (HELO ukl.uni-freiburg.de) (193.196.218.205) by skl1.ukl.uni-freiburg.de with SMTP; 15 Feb 2001 21:28:42 -0000 Message-ID: <3A8C49A0.86D5DBF5@ukl.uni-freiburg.de> Date: Thu, 15 Feb 2001 22:26:56 +0100 From: "Manfred W. Baumstark" Organization: Medizinische Universitaetsklink Freiburg X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-SGI_XFS_PR i686) X-Accept-Language: en,de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: /dev/mouse Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing For other redhat 7 users like me: To get gpm working with a ps2 mouse (/dev/psaux) you need to apply the following patch to /etc/rc.d/init.d/gmp --- gpm.org Thu Feb 15 21:27:42 2001 +++ gpm Thu Feb 15 21:27:47 2001 @@ -36,9 +36,9 @@ fi if [ -n "$MOUSETYPE" ]; then - daemon gpm -t $MOUSETYPE + daemon gpm -t $MOUSETYPE -m /dev/psaux else - daemon gpm + daemon gpm -m /dev/psaux fi RETVAL=$? echo Manfred From owner-linux-xfs@oss.sgi.com Thu Feb 15 14:51:11 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 14:50:51 -0800 Received: from sdsl-64-7-3-226.dsl.nyc.megapath.net ([64.7.3.226]:55798 "EHLO thredbo.comview.com") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 14:50:30 -0800 Received: from mail.comview.com (IDENT:simonw@localhost [127.0.0.1]) by thredbo.comview.com (8.9.3/8.9.3) with ESMTP id RAA27519 for ; Thu, 15 Feb 2001 17:50:24 -0500 Message-Id: <200102152250.RAA27519@thredbo.comview.com> From: Simon Wail To: linux-xfs@oss.sgi.com Subject: Status of DMAPI in Linux port of XFS Date: Thu, 15 Feb 2001 17:50:24 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Can you please tell me the current status of DMAPI support in the Linux port of XFS. We are interested in developing a DM application on top of XFS and would like to use the DMAPI capabilities. Thanks, Simon. ------------------------------------------------------------------------------- | Dr. Simon Wail | ComView Corporation - Research and Development | | 220 White Plains Rd | Internet: simon.wail@comview.COM | | Tarrytown NY USA 10591 | (TEL) +1 914 332-4800 (FAX) +1 914 206-3566 | |=============================================================================| | "The Truth is out there... Time is an illusion, lunch-time doubly so" | | Chris Carter Douglas Adams | ------------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Feb 15 15:16:01 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 15:15:51 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:49980 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 15:15:25 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA00371 for ; Thu, 15 Feb 2001 15:15:22 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA93677 for linux-xfs@oss.sgi.com; Fri, 16 Feb 2001 10:13:56 +1100 (EST) Date: Fri, 16 Feb 2001 10:13:56 +1100 (EST) From: Nathan Scott Message-Id: <200102152313.KAA93677@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dquot.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Merge a permission check fix reported on linux-kernel. Date: Thu Feb 15 15:12:18 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:87733a linux/fs/dquot.c - 1.23 - correct the permission check when getting group quota info (doesn't affect xfs since we don't do group quota yet, but does affect other filesystems using quota, eg. ext2). From owner-linux-xfs@oss.sgi.com Thu Feb 15 17:36:33 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 17:36:23 -0800 Received: from ns5.novsvcs.net ([192.208.44.111]:30226 "EHLO novalfsmtp2.novsvcs.net") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 17:36:07 -0800 Received: from pp-rafiki-chbs.cp.chbs ([168.246.161.139]) by novalfsmtp2.novsvcs.net (8.10.2/8.9.3) with ESMTP id f1G1b1Y17830 for ; Thu, 15 Feb 2001 20:37:01 -0500 X-Authentication-Warning: novalfsmtp2.novsvcs.net: Host [168.246.161.139] claimed to be pp-rafiki-chbs.cp.chbs Received: from pp-banzai-chbs.cp.chbs (pp-banzai-chbs.cp.chbs [168.246.161.82]) by pp-rafiki-chbs.cp.chbs (Build 101 8.9.3/NT-8.9.3) with ESMTP id CAA02695 for ; Fri, 16 Feb 2001 02:36:00 +0100 From: kenneth.leung@syngenta.com Received: by pp-banzai-chbs with Internet Mail Service (5.5.2650.21) id <16P0CY5F>; Fri, 16 Feb 2001 02:36:01 +0100 Message-ID: To: linux-xfs@oss.sgi.com Subject: 3c90x not supported? Date: Fri, 16 Feb 2001 02:35:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, We are trying to install Linux + XFS using the SGI pre-release installation CD on a Dell Precision 420 system. It contains an integrated 3com 3c90x ethernet adapter. For some reason, the adapter is not identified at all during installation (installation does not ask for IP address, subnet mask, etc.), and after installation, Linux does not recognize any eth0 device. We tried adding the device through linuxconf, but after rebooting the system declares, "Delaying eth0 configuration". The command `ifconfig eth0` returns that the device could not be found. The card itself is enabled in the BIOS, and was fully functional under RedHat 6.2. Has anyone else had problems getting such a 3com network card to work with RedHat 7 + XFS, or have any suggestions on how to do so? Thank you, Ken ******************************************* Kenneth Leung IT Administrator Torrey Mesa Research Institute kenneth.leung@syngenta.com (858) 812-1223 ******************************************* From owner-linux-xfs@oss.sgi.com Thu Feb 15 19:23:24 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 19:23:15 -0800 Received: from srv13-poa.poa.zaz.com.br ([200.248.149.91]:21509 "EHLO srv13-poa.poa.terra.com.br") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 19:23:00 -0800 Received: from srv7-poa.poa.terra.com.br (srv7-poa.poa.terra.com.br [200.248.149.123]) by srv13-poa.poa.terra.com.br (8.9.3/8.9.3) with ESMTP id BAA04895; Fri, 16 Feb 2001 01:22:37 -0200 Received: from 404notfound.com.br (dl-tnt2-C8B1CAA9.sao.terra.com.br [200.177.202.169]) by srv7-poa.poa.terra.com.br (8.11.0/8.11.1) with ESMTP id f1G3MUJ09268; Fri, 16 Feb 2001 01:22:30 -0200 Message-ID: <3A8C9C70.6A35288B@404notfound.com.br> Date: Fri, 16 Feb 2001 01:20:16 -0200 From: =?iso-8859-1?Q?Jo=E3o?= Paulo Legat X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-SGI_XFS_PR i686) X-Accept-Language: en MIME-Version: 1.0 To: kenneth.leung@syngenta.com CC: linux-xfs@oss.sgi.com Subject: Re: 3c90x not supported? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I'm using a 3c905b PCI and had no problems with RH7+XFS. In theory the NIC's chip is the same or similar to your adapter. Also, the support is compiled in the kernel and not lodaded as module. 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ See Documentation/networking/vortex.txt eth0: 3Com PCI 3c905B Cyclone 100baseTx at 0x6800, PCI: Found IRQ 10 for device 00:10.0 00:10:4b:c8:83:2c, IRQ 10 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. MII transceiver found at address 0, status 786d. Enabling bus-master transmits and whole-frame receives. Regards, JP > > Hello, > > We are trying to install Linux + XFS using the SGI pre-release installation > CD on a Dell Precision 420 system. It contains an integrated 3com 3c90x > ethernet adapter. For some reason, the adapter is not identified at all > during installation (installation does not ask for IP address, subnet mask, > etc.), and after installation, Linux does not recognize any eth0 device. We > tried adding the device through linuxconf, but after rebooting the system > declares, "Delaying eth0 configuration". The command `ifconfig eth0` returns > that the device could not be found. The card itself is enabled in the BIOS, > and was fully functional under RedHat 6.2. Has anyone else had problems > getting such a 3com network card to work with RedHat 7 + XFS, or have any > suggestions on how to do so? > > Thank you, > Ken > > ******************************************* > Kenneth Leung > IT Administrator > Torrey Mesa Research Institute > kenneth.leung@syngenta.com > (858) 812-1223 > ******************************************* From owner-linux-xfs@oss.sgi.com Thu Feb 15 19:51:55 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 19:51:36 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:1851 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 19:51:11 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA09922 for ; Thu, 15 Feb 2001 19:50:08 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA96504 for ; Thu, 15 Feb 2001 21:49:54 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1G3mtY11690 for ; Fri, 16 Feb 2001 03:48:55 GMT Message-ID: <3A8CA326.DA5A1E24@thebarn.com> Date: Fri, 16 Feb 2001 03:48:55 +0000 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: raid5 patch Content-Type: multipart/mixed; boundary="------------086B1F13EE66A83D8017F822" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------086B1F13EE66A83D8017F822 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is a combined patch of Martin changes and mine. It does appear to keep the raid5 code a bit happier, and clue us in on the results. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. --------------086B1F13EE66A83D8017F822 Content-Type: text/plain; charset=us-ascii; name="r5resync2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r5resync2.patch" =========================================================================== Index: linux/drivers/md/md.c =========================================================================== --- /usr/tmp/TmpDir.3925-0/linux/drivers/md/md.c_1.6 Thu Feb 15 21:45:48 2001 +++ linux/drivers/md/md.c Thu Feb 15 13:46:59 2001 @@ -2033,65 +2033,69 @@ struct { int set; int noautodetect; -} raid_setup_args md__initdata; -void md_setup_drive (void) md__init; +} raid_setup_args md__initdata = { 0, 0 }; + +void md_setup_drive(void) md__init; /* * Searches all registered partitions for autorun RAID arrays * at boot time. */ -static int detected_devices[128] md__initdata; -static int dev_cnt; - +#define CONFIG_AUTODETECT_RAID +#ifdef CONFIG_AUTODETECT_RAID +static int detected_devices[128] md__initdata = { 0, }; +static int dev_cnt=0; void md_autodetect_dev(kdev_t dev) { if (dev_cnt >= 0 && dev_cnt < 127) detected_devices[dev_cnt++] = dev; } +#endif - -static void autostart_arrays (void) +int md__init md_run_setup(void) { +#ifdef CONFIG_AUTODETECT_RAID mdk_rdev_t *rdev; int i; - printk(KERN_INFO "autodetecting RAID arrays\n"); + if (raid_setup_args.noautodetect) + printk(KERN_INFO "skipping autodetection of RAID arrays\n"); + else { - for (i=0; ifaulty) { - MD_BUG(); - continue; + for (i=0; ifaulty) { + MD_BUG(); + continue; + } + md_list_add(&rdev->pending, &pending_raid_disks); } - md_list_add(&rdev->pending, &pending_raid_disks); - } - autorun_devices(-1); -} + autorun_devices(-1); + } -int md__init md_run_setup(void) -{ - if (raid_setup_args.noautodetect) - printk(KERN_INFO "skipping autodetection of RAID arrays\n"); - else - autostart_arrays(); dev_cnt = -1; /* make sure further calls to md_autodetect_dev are ignored */ +#endif +#ifdef CONFIG_MD_BOOT md_setup_drive(); +#endif return 0; } @@ -2555,11 +2559,6 @@ md_print_devices(); goto done_unlock; - case RAID_AUTORUN: - err = 0; - autostart_arrays(); - goto done; - case BLKGETSIZE: /* Return device size */ if (!arg) { err = -EINVAL; @@ -2713,6 +2712,7 @@ case BLKSETSIZE: set_blocksize (mddev, (int *) arg); goto done_unlock; + /* * We have a problem here : there is no easy way to give a CHS @@ -3056,9 +3056,11 @@ int sz = 0; unsigned long max_blocks, resync, res, dt, db, rt; - resync = mddev->curr_resync - atomic_read(&mddev->recovery_active); + resync = (mddev->curr_resync - atomic_read(&mddev->recovery_active)) >> 1; max_blocks = mddev->sb->size; + printk ("Res: %ld, Max Blocks: %ld\n", resync, max_blocks); + /* * Should not happen. */ @@ -3103,7 +3105,7 @@ if (!dt) dt++; db = resync - mddev->resync_mark_cnt; rt = (dt * ((max_blocks-resync) / (db/100+1)))/100; - + sz += sprintf(page + sz, " finish=%lu.%lumin", rt / 60, (rt % 60)/6); sz += sprintf(page + sz, " speed=%ldK/sec", db/dt); @@ -3274,10 +3276,10 @@ MD_DECLARE_WAIT_QUEUE_HEAD(resync_wait); -void md_done_sync(mddev_t *mddev, int blocks, int ok) +void md_done_sync(mddev_t *mddev, int sectors, int ok) { - /* another "blocks" (1K) blocks have been synced */ - atomic_sub(blocks, &mddev->recovery_active); + /* another chunk of sectors has been synced */ + atomic_sub(sectors, &mddev->recovery_active); wake_up(&mddev->recovery_wait); if (!ok) { // stop recovery, signal do_sync .... @@ -3289,7 +3291,7 @@ int md_do_sync(mddev_t *mddev, mdp_disk_t *spare) { mddev_t *mddev2; - unsigned int max_blocks, currspeed, + unsigned int max_sectors, currspeed, j, window, err, serialize; kdev_t read_disk = mddev_to_kdev(mddev); unsigned long mark[SYNC_MARKS]; @@ -3326,7 +3328,7 @@ mddev->curr_resync = 1; - max_blocks = mddev->sb->size; + max_sectors = mddev->sb->size << 1; printk(KERN_INFO "md: syncing RAID array md%d\n", mdidx(mddev)); printk(KERN_INFO "md: minimum _guaranteed_ reconstruction speed: %d KB/sec/disc.\n", @@ -3351,22 +3353,22 @@ * Tune reconstruction: */ window = MAX_READAHEAD*(PAGE_SIZE/1024); - printk(KERN_INFO "md: using %dk window, over a total of %d blocks.\n",window,max_blocks); + printk(KERN_INFO "md: using %dk window, over a total of %d sectors.\n",window, max_sectors); atomic_set(&mddev->recovery_active, 0); init_waitqueue_head(&mddev->recovery_wait); last_check = 0; - for (j = 0; j < max_blocks;) { - int blocks; + for (j = 0; j < max_sectors;) { + int sectors; - blocks = mddev->pers->sync_request(mddev, j); + sectors = mddev->pers->sync_request(mddev, j); - if (blocks < 0) { - err = blocks; + if (sectors < 0) { + err = sectors; goto out; } - atomic_add(blocks, &mddev->recovery_active); - j += blocks; + atomic_add(sectors, &mddev->recovery_active); + j += sectors; mddev->curr_resync = j; if (last_check + window > j) @@ -3384,7 +3386,7 @@ mark_cnt[next] = j - atomic_read(&mddev->recovery_active); last_mark = next; } - + if (md_signal_pending(current)) { /* @@ -3626,7 +3628,7 @@ &md_fops, NULL); /* forward all md request to md_make_request */ - blk_queue_make_request(BLK_DEFAULT_QUEUE(MAJOR_NR), md_make_request); + blk_queue_make_request(BLK_DEFAULT_QUEUE(MAJOR_NR), (void *) md_make_request); read_ahead[MAJOR_NR] = INT_MAX; @@ -3645,12 +3647,14 @@ return (0); } -static struct { - char device_set [MAX_MD_DEVS]; - int pers[MAX_MD_DEVS]; - int chunk[MAX_MD_DEVS]; - kdev_t devices[MAX_MD_DEVS][MD_SB_DISKS]; -} md_setup_args md__initdata; +#ifdef CONFIG_MD_BOOT +#define MAX_MD_BOOT_DEVS 8 +struct { + unsigned long set; + int pers[MAX_MD_BOOT_DEVS]; + int chunk[MAX_MD_BOOT_DEVS]; + kdev_t devices[MAX_MD_BOOT_DEVS][MD_SB_DISKS]; +} md_setup_args md__initdata = { 0, }; /* * Parse the command-line parameters given our kernel, but do not @@ -3680,10 +3684,10 @@ printk("md: Too few arguments supplied to md=.\n"); return 0; } - if (minor >= MAX_MD_DEVS) { + if (minor >= MAX_MD_BOOT_DEVS) { printk ("md: Minor device number too high.\n"); return 0; - } else if (md_setup_args.device_set[minor]) { + } else if (md_setup_args.set & (1 << minor)) { printk ("md: Warning - md=%d,... has been specified twice;\n" " will discard the first definition.\n", minor); } @@ -3741,7 +3745,7 @@ printk ("md: Will configure md%d (%s) from %s, below.\n", minor, pername, devnames); md_setup_args.devices[minor][i] = (kdev_t) 0; - md_setup_args.device_set[minor] = 1; + md_setup_args.set |= (1 << minor); return 1; } @@ -3751,11 +3755,10 @@ kdev_t dev; mddev_t*mddev; - for (minor = 0; minor < MAX_MD_DEVS; minor++) { + for (minor = 0; minor < MAX_MD_BOOT_DEVS; minor++) { mdu_disk_info_t dinfo; - - int err = 0; - if (!md_setup_args.device_set[minor]) + int err=0; + if (!(md_setup_args.set & (1 << minor))) continue; printk("md: Loading md%d.\n", minor); if (mddev_map[minor].mddev) { @@ -3781,7 +3784,7 @@ ainfo.layout = 0; ainfo.chunk_size = md_setup_args.chunk[minor]; err = set_array_info(mddev, &ainfo); - for (i = 0; !err && (dev = md_setup_args.devices[minor][i]); i++) { + for (i=0; !err && (dev = md_setup_args.devices[minor][i]); i++) { dinfo.number = i; dinfo.raid_disk = i; dinfo.state = (1< %d\n", oldsize, size); + printk("raid5: conf->buffer_size = %d\n", conf->buffer_size); shrink_stripe_cache(conf); if (size==0) BUG(); conf->buffer_size = size; @@ -714,16 +715,19 @@ break; } spin_unlock_irq(&conf->device_lock); - if (count>1) { - xor_block(count, bh_ptr); - count = 1; - } - + if (count>1) { + xor_block(count, bh_ptr); + count = 1; + } for (i = disks; i--;) if (chosen[i]) { struct buffer_head *bh = sh->bh_cache[i]; char *bdata; - mark_buffer_clean(chosen[i]); /* NO FIXME */ + if(!(test_bit(BH_End_io, &(chosen[i]->b_state)) + || chosen[i]->b_next_free == NULL + || chosen[i]->b_prev_free == NULL )){ + mark_buffer_clean(chosen[i]); + } bdata = bh_kmap(chosen[i]); memcpy(bh->b_data, bdata,sh->size); @@ -888,7 +892,7 @@ } spin_unlock_irq(&conf->device_lock); if (syncing) { - md_done_sync(conf->mddev, (sh->size>>10) - sh->sync_redone,0); + md_done_sync(conf->mddev, (sh->size>>9) - sh->sync_redone, 0); clear_bit(STRIPE_SYNCING, &sh->state); syncing = 0; } @@ -1063,7 +1067,7 @@ } } if (syncing && locked == 0 && test_bit(STRIPE_INSYNC, &sh->state)) { - md_done_sync(conf->mddev, (sh->size>>10) - sh->sync_redone,1); + md_done_sync(conf->mddev, (sh->size>>9) - sh->sync_redone, 1); clear_bit(STRIPE_SYNCING, &sh->state); } @@ -1159,13 +1163,13 @@ return correct_size; } -static int raid5_sync_request (mddev_t *mddev, unsigned long block_nr) +static int raid5_sync_request (mddev_t *mddev, unsigned long sector) { raid5_conf_t *conf = (raid5_conf_t *) mddev->private; struct stripe_head *sh; int sectors_per_chunk = conf->chunk_size >> 9; - unsigned long stripe = (block_nr<<1)/sectors_per_chunk; - int chunk_offset = (block_nr<<1) % sectors_per_chunk; + unsigned long stripe = sector/sectors_per_chunk; + int chunk_offset = sector % sectors_per_chunk; int dd_idx, pd_idx; unsigned long first_sector; int raid_disks = conf->raid_disks; @@ -1173,9 +1177,9 @@ int redone = 0; int bufsize; - sh = get_active_stripe(conf, block_nr<<1, 0, 0); + sh = get_active_stripe(conf, sector, 0, 0); bufsize = sh->size; - redone = block_nr-(sh->sector>>1); + redone = sector - sh->sector; first_sector = raid5_compute_sector(stripe*data_disks*sectors_per_chunk + chunk_offset, raid_disks, data_disks, &dd_idx, &pd_idx, conf); sh->pd_idx = pd_idx; @@ -1188,7 +1192,7 @@ handle_stripe(sh); release_stripe(sh); - return (bufsize>>10)-redone; + return (bufsize >> 9) - redone; } /* --------------086B1F13EE66A83D8017F822-- From owner-linux-xfs@oss.sgi.com Thu Feb 15 20:00:05 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 19:59:55 -0800 Received: from [65.100.85.34] ([65.100.85.34]:56709 "EHLO roujin.gargoylecc.com") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 19:59:39 -0800 Received: from [65.100.85.35] (IDENT:ringram@gargoyle.gargoylecc.com [65.100.85.35]) by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id MAA14665; Fri, 16 Feb 2001 12:10:19 -0700 Date: Thu, 15 Feb 2001 21:02:57 -0700 (MST) From: Russel Ingram X-Sender: To: =?iso-8859-1?Q?Jo=E3o?= Paulo Legat cc: , Subject: Re: 3c90x not supported? In-Reply-To: <3A8C9C70.6A35288B@404notfound.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 16 Feb 2001, João Paulo Legat wrote: > I'm using a 3c905b PCI and had no problems with RH7+XFS. > In theory the NIC's chip is the same or similar to your adapter. > > Also, the support is compiled in the kernel and not lodaded as module. > > 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. > http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ > See Documentation/networking/vortex.txt > eth0: 3Com PCI 3c905B Cyclone 100baseTx at 0x6800, PCI: Found IRQ 10 for > device 00:10.0 > 00:10:4b:c8:83:2c, IRQ 10 > 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. > MII transceiver found at address 24, status 786d. > MII transceiver found at address 0, status 786d. > Enabling bus-master transmits and whole-frame receives. > > Regards, > > JP > > > > Hello, > > > > We are trying to install Linux + XFS using the SGI pre-release installation > > CD on a Dell Precision 420 system. It contains an integrated 3com 3c90x > > ethernet adapter. For some reason, the adapter is not identified at all > > during installation (installation does not ask for IP address, subnet mask, > > etc.), and after installation, Linux does not recognize any eth0 device. We > > tried adding the device through linuxconf, but after rebooting the system > > declares, "Delaying eth0 configuration". The command `ifconfig eth0` returns > > that the device could not be found. The card itself is enabled in the BIOS, > > and was fully functional under RedHat 6.2. Has anyone else had problems > > getting such a 3com network card to work with RedHat 7 + XFS, or have any > > suggestions on how to do so? > > > > Thank you, > > Ken I have a system that used a network card that wasn't supported with the limited number of drivers included in the network installation (although I'm almost certain that the 3c90x is one that *is* included in that limited number of drivers) that was installed over a network connection with the xfs prerelease. The trick is to know that there is an option to use an additional driver disk during installation (enter "linux dd" at the boot: prompt when you first boot the installer). There is such a driver disk image available in the images directory that you would have downloaded the bootnet.img image from. The problem after installation is that the installation doesn't make the entry for you in the modules.conf file to identify that driver for eth0. If you have the installation finished, you just need to add the following line to your /etc/modules.conf file so the kernel knows what driver coresponds to the eth0 device: alias eth0 3c90x Russ -- --------------------------------------------------------------- "Bill Gates and Microsoft have ruined the computer industry for a long time to come by creating a class of ignorant and lazy computer users." --Russel Ingram "Mommy ... can I go out and ... KILL TONIGHT!?" --Glen Danzig, The Misfits --------------------------------------------------------------- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Thu Feb 15 20:44:15 2001 Received: by oss.sgi.com id ; Thu, 15 Feb 2001 20:43:55 -0800 Received: from mail15.jump.net ([206.196.91.15]:54249 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Thu, 15 Feb 2001 20:43:40 -0800 Received: from Porter (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f1G4hGV28583; Thu, 15 Feb 2001 22:43:16 -0600 (CST) Message-Id: <200102160443.f1G4hGV28583@mail15.jump.net> Subject: Re: 3c90x not supported? From: Eric Sandeen To: Russel Ingram Cc: =?ISO-8859-1?Q?Jo=E3o?= Paulo Legat , kenneth.leung@syngenta.com, linux-xfs@oss.sgi.com In-Reply-To: Content-Type: text/plain X-Mailer: Evolution (0.8/+cvs.2001.02.13.10.28 - Preview Release) Date: 15 Feb 2001 22:43:47 -0600 Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thanks for the good explanation, Russ. I think that the 3c59x module was _not_ included in the standard boot.img floppy, but I'm fairly certain that it is on the bootnet.img. I'd check it quickly except I'm afraid of the loopback filesystem bug in 2.4.x. :) We had to take out some of the modules that are in the normal RH 7.0 install images to make room for the larger 2.4 kernel + XFS. And I'm almost certain that the module is _not_ compiled into the kernel. I have the 2nd to last test ISO here, and all of the kernels contain the 3c59x driver as a module, and all of the kernel configs in the SRPM contain CONFIG_VORTEX=m At any rate, the module _is_ available on the system after installation, even if the installer didn't detect it. Russ's modules.conf advice is the way to go. -Eric From owner-linux-xfs@oss.sgi.com Fri Feb 16 00:34:57 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 00:34:48 -0800 Received: from edge.coltex.nl ([194.151.97.115]:62217 "EHLO mail.coltex.nl") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 00:34:23 -0800 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f1G7X9u10153; Fri, 16 Feb 2001 08:33:19 +0100 Message-Id: <4.3.2.7.2.20010216092928.03372b48@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Feb 2001 09:31:26 +0100 To: kenneth.leung@syngenta.com From: Seth Mos Subject: Re: 3c90x not supported? Cc: linux-xfs@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 02:35 16-2-2001 +0100, you wrote: >Hello, > >We are trying to install Linux + XFS using the SGI pre-release installation >CD on a Dell Precision 420 system. It contains an integrated 3com 3c90x >ethernet adapter. For some reason, the adapter is not identified at all >during installation (installation does not ask for IP address, subnet mask, >etc.), and after installation, Linux does not recognize any eth0 device. We >tried adding the device through linuxconf, but after rebooting the system >declares, "Delaying eth0 configuration". The command `ifconfig eth0` returns >that the device could not be found. The card itself is enabled in the BIOS, >and was fully functional under RedHat 6.2. Has anyone else had problems >getting such a 3com network card to work with RedHat 7 + XFS, or have any >suggestions on how to do so? Hmm that would be the 3c905C card. It should be recognized by the newer driver. We've got an newer Optiplex that recognizes this variant. I have to verify this with the XFS install CD Bye -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Fri Feb 16 05:19:39 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 05:19:19 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:21513 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 05:19:13 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id OAA26159 for linux-xfs@oss.sgi.com; Fri, 16 Feb 2001 14:16:54 +0100 Date: Fri, 16 Feb 2001 14:16:54 +0100 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Subject: kiobufs Message-ID: <20010216141654.B20022@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Is there any site/HOWTO/FAQ/sth other place where i can find comprehensive info about kiobufs ? Krzysztof From owner-linux-xfs@oss.sgi.com Fri Feb 16 08:15:30 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 08:15:20 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:28718 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 08:15:01 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA06900 for ; Fri, 16 Feb 2001 08:15:00 -0800 (PST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA842034; Fri, 16 Feb 2001 10:13:37 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.184.30]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA09612; Fri, 16 Feb 2001 10:13:37 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA18965; Fri, 16 Feb 2001 10:13:37 -0600 (CST) Message-Id: <200102161613.KAA18965@slobber.americas.sgi.com> To: Simon Wail cc: linux-xfs@oss.sgi.com Subject: Re: Status of DMAPI in Linux port of XFS Date: Fri, 16 Feb 2001 10:13:36 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >From: Simon Wail > >Can you please tell me the current status of DMAPI support in the Linux port o >f >XFS. We are interested in developing a DM application on top of XFS and would >like to use the DMAPI capabilities. Consult the file fs/xfs/dmapi/Status for the details. Each vendor's HSM relies on different pieces of the DMAPI spec, and I've concentrated on the more universal parts and then some. The testing has been light, at best, and the Status file will tell you for which functions I thought the test suite was weakest. Dean From owner-linux-xfs@oss.sgi.com Fri Feb 16 10:51:21 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 10:51:12 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:33403 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 10:51:01 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA01122 for ; Fri, 16 Feb 2001 10:51:00 -0800 (PST) mail_from (chait@getafix.engr.sgi.com) Received: from getafix.engr.sgi.com (IDENT:root@getafix.engr.sgi.com [163.154.5.110]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA00620; Fri, 16 Feb 2001 10:49:43 -0800 (PST) Received: from localhost (chait@localhost) by getafix.engr.sgi.com (8.9.3/8.9.3) with ESMTP id KAA17057; Fri, 16 Feb 2001 10:46:04 -0500 Date: Fri, 16 Feb 2001 10:46:03 -0500 (EST) From: Chaitanya Tumuluri To: Krzysztof Rusocki cc: linux-xfs@oss.sgi.com Subject: Re: kiobufs In-Reply-To: <20010216141654.B20022@main.braxis.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 16 Feb 2001, Krzysztof Rusocki wrote: > > Is there any site/HOWTO/FAQ/sth other place where i can find > comprehensive info about kiobufs ? > > Krzysztof AFAIK, there's no _authoratative_ and comprehensive info on kiobufs. However, Christoph Hellwig has extracted the kiobuf work in the XFS tree as a patch. He also provides additional patches for use of kiobufs in the a_ops for ext2 etc. at this sourceforge site: http://sourceforge.net/project/shownotes.php?release_id=19681 Also, there were some fairly heated discussions about kiobufs on the kiobuf-io-devel mailing list. You can find the archives of these discussions at: http://www.geocrawler.com/lists/3/SourceForge/8202/0/ Cheers, -Chait. From owner-linux-xfs@oss.sgi.com Fri Feb 16 10:59:41 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 10:59:31 -0800 Received: from ns.caldera.de ([212.34.180.1]:26116 "EHLO ns.caldera.de") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 10:59:22 -0800 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id TAA03828; Fri, 16 Feb 2001 19:58:04 +0100 Date: Fri, 16 Feb 2001 19:58:04 +0100 From: Christoph Hellwig To: Chaitanya Tumuluri Cc: Krzysztof Rusocki , linux-xfs@oss.sgi.com Subject: Re: kiobufs Message-ID: <20010216195804.A3066@caldera.de> References: <20010216141654.B20022@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from chait@getafix.engr.sgi.com on Fri, Feb 16, 2001 at 10:46:03AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, Feb 16, 2001 at 10:46:03AM -0500, Chaitanya Tumuluri wrote: > On Fri, 16 Feb 2001, Krzysztof Rusocki wrote: > > > > Is there any site/HOWTO/FAQ/sth other place where i can find > > comprehensive info about kiobufs ? > > > > Krzysztof > > AFAIK, there's no _authoratative_ and comprehensive info on kiobufs. > However, Christoph Hellwig has extracted the kiobuf work in the XFS > tree as a patch. He also provides additional patches for use of kiobufs > in the a_ops for ext2 etc. at this sourceforge site: > > http://sourceforge.net/project/shownotes.php?release_id=19681 > > Also, there were some fairly heated discussions about kiobufs on the > kiobuf-io-devel mailing list. You can find the archives of these > discussions at: > > http://www.geocrawler.com/lists/3/SourceForge/8202/0/ Yes - I've also written a small paper on that topic. It is at: ftp://ftp.openlinux.org/pub/people/hch/kio/kiobuf.txt Though it might get a little different in 2.5 ... Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Fri Feb 16 11:04:00 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 11:03:50 -0800 Received: from skl1.ukl.uni-freiburg.de ([193.196.199.1]:4777 "HELO skl1.ukl.uni-freiburg.de") by oss.sgi.com with SMTP id ; Fri, 16 Feb 2001 11:03:38 -0800 Received: (qmail 15023 invoked by alias); 16 Feb 2001 19:03:33 -0000 Received: (qmail 15018 invoked from network); 16 Feb 2001 19:03:33 -0000 Received: from msm205.ukl.uni-freiburg.de (HELO ukl.uni-freiburg.de) (193.196.218.205) by skl1.ukl.uni-freiburg.de with SMTP; 16 Feb 2001 19:03:33 -0000 Message-ID: <3A8D79FC.F45E0B0F@ukl.uni-freiburg.de> Date: Fri, 16 Feb 2001 20:05:32 +0100 From: "Manfred W. Baumstark" Organization: Medizinische Universitaetsklink Freiburg X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: PCMCIA and devfs References: <3A8BE135.9294EBC7@ukl.uni-freiburg.de> <3A8C3D0F.B6E4A055@arts.usyd.edu.au> Content-Type: multipart/mixed; boundary="------------FC37F08EDA5DE6F27686EF5C" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------FC37F08EDA5DE6F27686EF5C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew Geier wrote: ... > > It is also a devfs problem - I posted about this a week or so back. > Turn off devfs entirelty and run a 'traditional' /dev. If I turn devfs off, I get a boot failure. (Redhat 7 with your pre 0.9 RPMS applied). There is something in the installcavs that says "before turning devfs off you will need to obtain a fixed version of the kernel from the oss web site". Is this fixed version somewere? manfred --------------FC37F08EDA5DE6F27686EF5C Content-Type: text/x-vcard; charset=us-ascii; name="maba.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Manfred W. Baumstark Content-Disposition: attachment; filename="maba.vcf" begin:vcard n:Baumstark;Manfred tel;fax:+49 761 270 7470 tel;work:+49 761 270 7496 x-mozilla-html:TRUE org:University Hospital Freiburg;Rehabilitative and Preventive Sportsmedicine adr:;;Hugstetter Str. 55;Freiburg;;D-79106;Germany version:2.1 email;internet:manfred.baumstark@uni-freiburg.de title:Dr. x-mozilla-cpt:;29056 fn:Manfred Baumstark end:vcard --------------FC37F08EDA5DE6F27686EF5C-- From owner-linux-xfs@oss.sgi.com Fri Feb 16 11:15:11 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 11:15:01 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12382 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 11:14:47 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA06171 for ; Fri, 16 Feb 2001 11:23:44 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA54018; Fri, 16 Feb 2001 13:12:55 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1GJBsq19194; Fri, 16 Feb 2001 14:11:55 -0500 Message-ID: <3A8D7B7A.37F2F4FF@thebarn.com> Date: Fri, 16 Feb 2001 19:11:54 +0000 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: "Manfred W. Baumstark" CC: linux-xfs@oss.sgi.com Subject: Re: PCMCIA and devfs References: <3A8BE135.9294EBC7@ukl.uni-freiburg.de> <3A8C3D0F.B6E4A055@arts.usyd.edu.au> <3A8D79FC.F45E0B0F@ukl.uni-freiburg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Manfred W. Baumstark" wrote: > Matthew Geier wrote: > > ... > > > > It is also a devfs problem - I posted about this a week or so back. > > Turn off devfs entirelty and run a 'traditional' /dev. > > If I turn devfs off, I get a boot failure. (Redhat 7 with your pre 0.9 RPMS > applied). > There is something in the installcavs that says "before turning devfs off > you will need to obtain a fixed version of the kernel from the oss web > site". Is this fixed version somewere? Turning off devfs shouldn't cause boot failures? Any messages that might shed some light on things? I'm curious to find out why devfs has any affect on pcmcia. I've been running my laptop with devfs for about 6 months... no problems with pcmcia... well other than certain cards not working. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Fri Feb 16 11:19:20 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 11:19:10 -0800 Received: from mail11.jump.net ([206.196.91.11]:30102 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 11:18:54 -0800 Received: from Porter (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f1GJCqN05490; Fri, 16 Feb 2001 13:12:52 -0600 (CST) Message-Id: <200102161912.f1GJCqN05490@mail11.jump.net> Subject: Re: PCMCIA and devfs From: Eric Sandeen To: Manfred "W." Baumstark Cc: linux-xfs@oss.sgi.com In-Reply-To: <3A8D79FC.F45E0B0F@ukl.uni-freiburg.de> References: <3A8BE135.9294EBC7@ukl.uni-freiburg.de> <3A8C3D0F.B6E4A055@arts.usyd.edu.au> <3A8D79FC.F45E0B0F@ukl.uni-freiburg.de> Content-Type: text/plain X-Mailer: Evolution (0.8/+cvs.2001.02.15.08.59 - Preview Release) Date: 16 Feb 2001 13:13:31 -0600 Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 16 Feb 2001 20:05:32 +0100, Manfred W. Baumstark wrote: > If I turn devfs off, I get a boot failure. (Redhat 7 with your pre 0.9 RPMS > applied). This is due to a permissions problem bug on the files in /dev - if / is mounted as read-only (i.e. at boot) then it does not allow writes to _devices_ (such as /dev/console) on /. This is not correct behavior... > There is something in the installcavs that says "before turning devfs off > you will need to obtain a fixed version of the kernel from the oss web > site". Is this fixed version somewere? It has been fixed in the CVS tree for the beta, but new RPMS have not been generated, so you'll need to recompile the kernel yourself to fix it. Here is the patch to the kernel source provided in the kernel-source RPM: --- linux-2.4-xfs-beta/linux/fs/xfs/linux/xfs_vnode.h 2001/01/05 03:17:43 1.9 +++ linux-2.4-xfs-beta/linux/fs/xfs/linux/xfs_vnode.h 2001/01/19 21:14:09 1.10 @@ -690,8 +690,8 @@ typedef struct vattr { * access time can be modified. */ #define WRITEALLOWED(vp) \ - ((vp)->v_vfsp && ((vp)->v_vfsp->vfs_flag & VFS_RDONLY) == 0) - + (((vp)->v_vfsp && ((vp)->v_vfsp->vfs_flag & VFS_RDONLY) == 0) || \ + ((vp)->v_type != VREG ) && ((vp)->v_type != VDIR) && ((vp)->v_type != VLNK)) /* * Global vnode allocation: * From owner-linux-xfs@oss.sgi.com Fri Feb 16 13:20:50 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 13:20:31 -0800 Received: from plato.arts.usyd.edu.au ([129.78.16.1]:3601 "EHLO plato.arts.usyd.edu.au") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 13:20:11 -0800 Received: from arts.usyd.edu.au (IDENT:matthew@holly.aitch.ucc.usyd.edu.au [129.78.226.234]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id IAA28750 for ; Sat, 17 Feb 2001 08:20:06 +1100 (EST) Message-ID: <3A8D99F6.1370F2F3@arts.usyd.edu.au> Date: Sat, 17 Feb 2001 08:21:58 +1100 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: IDE DVD problem Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD34D8F59961A5D2B2683924D" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a cryptographically signed message in MIME format. --------------msD34D8F59961A5D2B2683924D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dunno to report this to the xfs list or linux-kernel. I am unable to do this test on a 'distribution' kernel, (as I then can't access the appropiate file system!) and I don't know if the xfs patches have changed something that might contribute... The linux video project's 'oms' dvd player can oops the IDE driver. The oms process becomes unkillable and the drive useless for any other process until the machine is rebooted. Feb 17 08:11:05 holly kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error } Feb 17 08:11:05 holly kernel: hdc: packet command error: error=0x50 Feb 17 08:11:05 holly kernel: ATAPI device hdc: Feb 17 08:11:05 holly kernel: Error: Illegal request -- (Sense key=0x05) Feb 17 08:11:05 holly kernel: Copy protection key exchange failure - Key not present -- (asc=0x6f, ascq=0x01) Feb 17 08:11:05 holly kernel: The failed "Report Key" packet command was: Feb 17 08:11:05 holly kernel: "a4 00 00 00 00 00 00 00 00 0c 04 00 " Feb 17 08:11:06 holly kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000034 Feb 17 08:11:06 holly kernel: printing eip: Feb 17 08:11:06 holly kernel: c88ee1f1 Feb 17 08:11:06 holly kernel: *pde = 00000000 Feb 17 08:11:06 holly kernel: Oops: 0000 Feb 17 08:11:06 holly kernel: CPU: 0 Feb 17 08:11:06 holly kernel: EIP: 0010:[af_packet:__insmod_af_packet_O/lib/modules/2.4.1-XFS/kernel/net/packe+-85519/96] Feb 17 08:11:06 holly kernel: EFLAGS: 00210246 Feb 17 08:11:06 holly kernel: eax: c2060000 ebx: c7f951a0 ecx: 00001600 edx: 00000000 Feb 17 08:11:06 holly kernel: esi: 00000000 edi: c028a8d0 ebp: c7f951a0 esp: c1df5c24 Feb 17 08:11:06 holly kernel: ds: 0018 es: 0018 ss: 0018 Feb 17 08:11:06 holly kernel: Process oms_shell (pid: 21827, stackpage=c1df5000) Feb 17 08:11:06 holly kernel: Stack: c7f951a0 c6fa2000 c028a8d0 c88ee265 c7f951a0 c028a8d0 c6fa2000 0012a3cc Feb 17 08:11:06 holly kernel: c88eea35 c028a8d0 0012a3cc 0012a3cc c028a8d0 c7f951a0 c88f38c0 c6fa2000 Feb 17 08:11:06 holly kernel: c0178188 c028a8d0 c7f951a0 0012a3cc c028a890 c028a8d0 c7ff6960 c028a8d0 Feb 17 08:11:06 holly kernel: Call Trace: [af_packet:__insmod_af_packet_O/lib/modules/2.4.1-XFS/kernel/net/packe+-85403/96] [af_packet:__insmod_af_packet_O/lib/modules/2.4.1-XFS/kernel/net/packe+-83403/96] [af_packet:__insmod_af_packet_O/lib/modules/2.4.1-XFS/kernel/net/packe+-63296/96] [start_request+436/556] [ide_do_request+665/736] [do_ide_request+15/20] [generic_unplug_device+32/40] Feb 17 08:11:06 holly kernel: [__run_task_queue+80/100] [kiobuf_wait_for_io+97/160] [rw_raw_dev+851/1100] [__alloc_pages+237/748] [do_anonymous_page+47/116] [do_no_page+48/192] [handle_mm_fault+232/356] [do_page_fault+347/1052] Feb 17 08:11:06 holly kernel: [do_page_fault+0/1052] [__alloc_pages+237/748] [do_anonymous_page+47/116] [do_no_page+48/192] [handle_mm_fault+232/356] [do_page_fault+347/1052] [do_page_fault+0/1052] [do_munmap+88/640] Feb 17 08:11:06 holly kernel: [default_llseek+0/140] [raw_read+28/36] [sys_read+142/196] [system_call+51/56] Feb 17 08:11:06 holly kernel: Feb 17 08:11:06 holly kernel: Code: 8b 4e 34 39 c8 74 1a 29 c8 8d 90 ff 01 00 00 83 f8 ff 0f 4f --------------msD34D8F59961A5D2B2683924D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH4AYJKoZIhvcNAQcCoIIH0TCCB80CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BckwggKtMIICFqADAgECAgMC8UswDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyMTAyNDAzNFoXDTAxMDcyMTAyNDAz NFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYY bWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR gAKbBhCplgqyhkR0Ykn4XOW0Py1G40orbP+B2KkACTMx4GxhHNg2h3nPiNC/P/9BZETw6NA+ dp/mxtN7XHmvRounnCL+9pjG3yWpw/ONNEpObjRSfujGe/jJvUF2vrAfecI/J5DKQ0/5gZMv 5fqfl4spYSPl+9vc2hKG7uvjgQIDAQABo1YwVDAjBgNVHREEHDAagRhtYXR0aGV3QGFydHMu dXN5ZC5lZHUuYXUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORYx0YdwGG9 I9fDjDANBgkqhkiG9w0BAQQFAAOBgQBjjvY9P9hSktFnCJrkQSTKjh9ZBG9a58a0Hi+GvmyD t9e29sRgxHN+Nwtsu2yUs8+xv1BemYzCnri+y91uJsfRTrm4+1oc/TV+lDGWqBud68wf4x29 /xaj1oQ2vWMy1Y64KZSWyxjt+vcU5/nyNF3DGz9XtXlxTI8dntzEWkyq/DCCAxQwggJ9oAMC AQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxs ZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn /XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESw iy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL3Vx1b8aR kMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6syg1vcnpn LGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAd8wggHbAgEBMIGcMIGUMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UE ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAvFLMAkGBSsOAwIaBQCggZkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMjE2MjEyMTU5WjAjBgkq hkiG9w0BCQQxFgQUwc0TE8dEXPf7kTj+ZoEDp5BjbNAwOgYJKoZIhvcNAQkPMS0wKzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwDQYJKoZIhvcNAQEBBQAE gYCpoB6wKOAMNvDeHT4nq6JIwNBblhVIcOvpD3pzh6M8JdEieb8A9b8hdSSN9GMtJqPVPglk x6ilmlq8igg0rrw07oLFqvSQewvpjCcQKmWCqSmbOs07/xIQQZD+1OkAVjKe+Kik/k+DsORa L5PSJBbMWfgDrQr+mzRrcl7y1eHTQw== --------------msD34D8F59961A5D2B2683924D-- From owner-linux-xfs@oss.sgi.com Fri Feb 16 14:00:11 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 13:59:51 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:55057 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 13:59:22 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id TAA26957 for ; Fri, 16 Feb 2001 19:59:18 -0200 Date: Fri, 16 Feb 2001 18:11:17 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: linux-xfs@oss.sgi.com Subject: _pagebuf_lookup_pages() allocation flags Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I noticed that _pagebuf_lookup_pages() may use two different allocation flags to allocate invalid pages depending on PBF_MAPPABLE flag: /* For pagebufs where we want to map an address, do not use * highmem pages - so that we do not need to use kmap resources * to access the data. */ if (flags & PBF_MAPPABLE) { gfp_mask = GFP_BUFFER; } else { gfp_mask = GFP_HIGHUSER; } My question is if only when the caller sets PBF_MAPPABLE it may hold some fs lock? (thats why GFP_BUFFER was used, I suppose) If callers which do not set PBF_MAPPABLE may have locks which are used on the ->writepage() codepath, it may be a problem (deadlock). I tried to track down the callers, but I want to read pagebuf code for now and the whole XFS code :) From owner-linux-xfs@oss.sgi.com Fri Feb 16 14:05:21 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 14:05:11 -0800 Received: from handi5-212-144-136-094.arcor-ip.net ([212.144.136.94]:6660 "EHLO eisbaer.lila.net") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 14:05:00 -0800 Received: from mpg.goe.ni.schule.de (localhost [127.0.0.1]) by eisbaer.lila.net (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f1GLNc200899 for ; Fri, 16 Feb 2001 22:23:48 +0100 X-Authentication-Warning: eisbaer.lila.net: Host localhost [127.0.0.1] claimed to be mpg.goe.ni.schule.de Message-ID: <3A8D9A5A.62778092@mpg.goe.ni.schule.de> Date: Fri, 16 Feb 2001 22:23:38 +0100 From: "Jan H. Schrewe" X-Mailer: Mozilla 4.74 [de] (X11; U; Linux 2.2.16 i586) X-Accept-Language: en MIME-Version: 1.0 To: xfs-liste Subject: Status of XFS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I would like to know the status of XFS for linux. The reason why I ask is that I want to build up a server that runs in a place that I can't access physically. The server will be a Dual Pentium II using mixed SCSI and IDE disks ( around 6-7 disks, 50 GB ) using software raid 0 and 5. The reason I ask is, that there have been several mails regarding the raid topic. The other reason is that I didn't have enough time yet to test the stability of XFS. So would you ( the developers and testers of XFS ) think that I can run a server ( without watchdog ) that I don't have physical access to using raid. BTW: The server is going to be an ftp-server. So if you need a mirror site for XFS I would be happy to do that. regards Jan From owner-linux-xfs@oss.sgi.com Fri Feb 16 14:10:21 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 14:10:11 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:56387 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 14:09:58 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA17566 for ; Fri, 16 Feb 2001 14:08:55 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA24521; Fri, 16 Feb 2001 14:04:20 -0800 (PST) Message-ID: <3A8DA4AC.980E3986@sgi.com> Date: Fri, 16 Feb 2001 14:07:40 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Marcelo Tosatti CC: linux-xfs@oss.sgi.com Subject: Re: _pagebuf_lookup_pages() allocation flags References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Marcelo Tosatti wrote: > > Hi, > > I noticed that _pagebuf_lookup_pages() may use two different allocation > flags to allocate invalid pages depending on PBF_MAPPABLE flag: > > /* For pagebufs where we want to map an address, do not use > * highmem pages - so that we do not need to use kmap resources > * to access the data. > */ > > if (flags & PBF_MAPPABLE) { > gfp_mask = GFP_BUFFER; > } else { > gfp_mask = GFP_HIGHUSER; > } > > My question is if only when the caller sets PBF_MAPPABLE it may hold some > fs lock? (thats why GFP_BUFFER was used, I suppose) PBF_MAPPABLE is used by meta data users ... XFS keeps its meta data in pages hashed to the mount-point inode. All other callers, basically the file I/O paths, don't use MAPPABLE. For example, _pb_buffered_read would not use MAPPABLE. > > If callers which do not set PBF_MAPPABLE may have locks which are used on > the ->writepage() codepath, it may be a problem (deadlock). > Can you please elaborate on the deadlock scenario? -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Feb 16 14:21:41 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 14:21:30 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:56593 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 14:21:07 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id UAA27124; Fri, 16 Feb 2001 20:20:58 -0200 Date: Fri, 16 Feb 2001 18:32:57 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Rajagopal Ananthanarayanan cc: linux-xfs@oss.sgi.com Subject: Re: _pagebuf_lookup_pages() allocation flags In-Reply-To: <3A8DA4AC.980E3986@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 16 Feb 2001, Rajagopal Ananthanarayanan wrote: > Marcelo Tosatti wrote: > > > > Hi, > > > > I noticed that _pagebuf_lookup_pages() may use two different allocation > > flags to allocate invalid pages depending on PBF_MAPPABLE flag: > > > > /* For pagebufs where we want to map an address, do not use > > * highmem pages - so that we do not need to use kmap resources > > * to access the data. > > */ > > > > if (flags & PBF_MAPPABLE) { > > gfp_mask = GFP_BUFFER; > > } else { > > gfp_mask = GFP_HIGHUSER; > > } > > > > My question is if only when the caller sets PBF_MAPPABLE it may hold some > > fs lock? (thats why GFP_BUFFER was used, I suppose) > > PBF_MAPPABLE is used by meta data users ... XFS keeps its > meta data in pages hashed to the mount-point inode. > > All other callers, basically the file I/O paths, don't use MAPPABLE. > For example, _pb_buffered_read would not use MAPPABLE. > > > > > If callers which do not set PBF_MAPPABLE may have locks which are used on > > the ->writepage() codepath, it may be a problem (deadlock). > > > > Can you please elaborate on the deadlock scenario? Thats what I wonder: some_xfs_operation -> down(&lock) -> _pagebuf_lookup_pages(_PBF_ENTER_PAGES) -> alloc_pages(GFP_HIGHUSER) -> do_try_to_free_pages() -> try_to_free_pages() -> page_launder() -> writepage() -> xfs_writepage() -> down(&lock) Is that possible? From owner-linux-xfs@oss.sgi.com Fri Feb 16 14:49:40 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 14:49:31 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:17023 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 14:49:06 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA05096 for ; Fri, 16 Feb 2001 14:58:29 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA24572; Fri, 16 Feb 2001 14:43:45 -0800 (PST) Message-ID: <3A8DADE9.15A7B549@sgi.com> Date: Fri, 16 Feb 2001 14:47:05 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Marcelo Tosatti CC: linux-xfs@oss.sgi.com Subject: Re: _pagebuf_lookup_pages() allocation flags References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Marcelo Tosatti wrote: > > some_xfs_operation -> down(&lock) -> > _pagebuf_lookup_pages(_PBF_ENTER_PAGES) -> alloc_pages(GFP_HIGHUSER) -> > do_try_to_free_pages() -> try_to_free_pages() -> page_launder() -> > writepage() -> xfs_writepage() -> down(&lock) > > Is that possible? The call sequence is certainly possible, but there is no one global "lock" as you've thought of above. A brief explanation of xfs locks: The two primary locks in xfs are per-inode: one is the ilock and the other is an iolock. Further both are read-write locks, in the sense, that they can be taken in SHARED or EXCLUSIVE mode. Generally, the I/O paths hold the iolock; the write I/O paths hold the iolock EXCLUSIVE. Any meta-data related operation will hold the ilock; bmap allocation would hold the ilock EXCLUSIVE. Notable exceptions are single page I/O operations, which don't hold any locks. Example, readpage() & writepage() don't hold any locks; since these routines are called with the page locked, the lock on the page acts as a serialization mechanism. The final wrinkle is that if writepage() involved a conversion, then ilock would be taken in EXCLUSIVE mode. So, there is no single "lock" that satisfies the above deadlock scenario as far as I can see ... Cheers, -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Feb 16 14:57:40 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 14:57:21 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:58385 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 14:57:06 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id UAA27288; Fri, 16 Feb 2001 20:56:47 -0200 Date: Fri, 16 Feb 2001 19:08:46 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Rajagopal Ananthanarayanan cc: linux-xfs@oss.sgi.com Subject: Re: _pagebuf_lookup_pages() allocation flags In-Reply-To: <3A8DADE9.15A7B549@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 16 Feb 2001, Rajagopal Ananthanarayanan wrote: > Marcelo Tosatti wrote: > > > > > some_xfs_operation -> down(&lock) -> > > _pagebuf_lookup_pages(_PBF_ENTER_PAGES) -> alloc_pages(GFP_HIGHUSER) -> > > do_try_to_free_pages() -> try_to_free_pages() -> page_launder() -> > > writepage() -> xfs_writepage() -> down(&lock) > > > > Is that possible? > > The call sequence is certainly possible, but there is no > one global "lock" as you've thought of above. A brief explanation > of xfs locks: > > The two primary locks in xfs are per-inode: one is the > ilock and the other is an iolock. Further both are > read-write locks, in the sense, that they can be taken > in SHARED or EXCLUSIVE mode. > > Generally, the I/O paths hold the iolock; > the write I/O paths hold the iolock EXCLUSIVE. > Any meta-data related operation will hold the ilock; > bmap allocation would hold the ilock EXCLUSIVE. > > Notable exceptions are single page I/O operations, which > don't hold any locks. Example, readpage() & writepage() > don't hold any locks; since these routines are called with > the page locked, the lock on the page acts as a serialization > mechanism. > > The final wrinkle is that if writepage() involved a conversion, > then ilock would be taken in EXCLUSIVE mode. > > So, there is no single "lock" that satisfies the above deadlock > scenario as far as I can see ... I see. I still wonder why GFP_BUFFER is being used as the flag for PBF_MAPPABLE callers. If there is no deadlock condition there, GFP_KERNEL instead GFP_BUFFER will work. Well, I'll try testing that if I find sometime. Back to pagebuf for now. Thanks! From owner-linux-xfs@oss.sgi.com Fri Feb 16 15:32:30 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 15:32:20 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:60937 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Fri, 16 Feb 2001 15:32:04 -0800 Received: (qmail 29915 invoked from network); 16 Feb 2001 23:31:58 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Feb 2001 23:31:58 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Matthew Geier cc: linux-xfs@oss.sgi.com Subject: Re: IDE DVD problem In-reply-to: Your message of "Sat, 17 Feb 2001 08:21:58 +1100." <3A8D99F6.1370F2F3@arts.usyd.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Feb 2001 10:31:57 +1100 Message-ID: <9993.982366317@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sat, 17 Feb 2001 08:21:58 +1100, Matthew Geier wrote: > The linux video project's 'oms' dvd player can oops the IDE driver. The >oms process >becomes unkillable and the drive useless for any other process until the >machine is rebooted. >Feb 17 08:11:06 holly kernel: EIP: >0010:[af_packet:__insmod_af_packet_O/lib/modules/2.4.1-XFS/kernel/net/packe+-85519/96] >Feb 17 08:11:06 holly kernel: Call Trace: >[af_packet:__insmod_af_packet_O/lib/modules/2.4.1-XFS/kernel/net/packe+-85403/96] Unfortunately the oops trace is useless, klogd tried to convert the addresses and made a complete mess of the data. Please edit /etc/rc.d/init.d/syslog, change "daemon klogd" to "daemon klogd -x" then /etc/rc.d/init.d/syslog restart. After klogd has been told to keep its sticky fingers off the data, reproduce the problem and run ksymoops over the syslog output. That will give a clean trace of the problem so we can see if it is XFS related or a general kernel bug. From owner-linux-xfs@oss.sgi.com Fri Feb 16 18:05:21 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 18:05:11 -0800 Received: from linux.CompuComIS.net ([207.8.143.10]:24336 "HELO linux.compucomis.net") by oss.sgi.com with SMTP id ; Fri, 16 Feb 2001 18:05:02 -0800 Received: from localhost (office.CompuComIS.net [207.8.143.11]) by linux.compucomis.net (Postfix) with SMTP id 10C32FB08 for ; Fri, 16 Feb 2001 21:04:52 -0500 (EST) From: "Michael Burger" To: "linux-xfs@oss.sgi.com" Date: Fri, 16 Feb 2001 21:04:45 -0400 Reply-To: "Michael Burger" X-Mailer: PMMail 1.96a For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: SGI-XFS-RedHat7.0 ISO Message-Id: <20010217020452.10C32FB08@linux.compucomis.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I'm running into a bit of a snag, and I'm hoping that this list is the place to ask. I've been attempting to install the downloaded ISO onto a Dell Latitude CPi 266...the laptop in question had RedHat 7.0 running without problem, with the default 2.2.16-22 kernel supplied by RedHat. The problem I'm having is in getting the 2.4.0 kernel supplied with XFS and the ISO image to recognize my NIC...a 3Com 3c575 card. If anyone has any helpful suggestions, I'd be most appreciative. From owner-linux-xfs@oss.sgi.com Fri Feb 16 19:03:41 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 19:03:32 -0800 Received: from mail15.jump.net ([206.196.91.15]:62920 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 19:03:15 -0800 Received: from Porter (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f1H33Df15252; Fri, 16 Feb 2001 21:03:13 -0600 (CST) Message-Id: <200102170303.f1H33Df15252@mail15.jump.net> Subject: Re: SGI-XFS-RedHat7.0 ISO From: Eric Sandeen To: Michael Burger Cc: "linux-xfs@oss.sgi.com" In-Reply-To: <20010217020452.10C32FB08@linux.compucomis.net> Content-Type: text/plain X-Mailer: Evolution (0.8/+cvs.2001.02.15.08.59 - Preview Release) Date: 16 Feb 2001 21:03:55 -0600 Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 16 Feb 2001 21:04:45 -0400, Michael Burger wrote: > I'm running into a bit of a snag, and I'm hoping that this list is > the place to ask. It is. :) > The problem I'm having is in getting the 2.4.0 kernel supplied with > XFS and the ISO image to recognize my NIC...a 3Com 3c575 card. If > anyone has any helpful suggestions, I'd be most appreciative. Are you trying to do a network install, or did you do a local CD install, and now you're trying to get the network up and running? If it's the former, I'll need to look and see if the bootnet.img has support for that card. If it's the latter, and it's just that the install didn't autoconfigure your card, have you tried setting it up manually after the install? Are you getting any sort of error messages? There's a discussion of 3com pcmcia network cards here, perhaps there's information there for you: http://pcmcia-cs.sourceforge.net/cgi-bin/HyperNews/get/pcmcia/coms.html -Eric From owner-linux-xfs@oss.sgi.com Fri Feb 16 19:34:11 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 19:34:02 -0800 Received: from linux.CompuComIS.net ([207.8.143.10]:28176 "HELO linux.compucomis.net") by oss.sgi.com with SMTP id ; Fri, 16 Feb 2001 19:33:42 -0800 Received: from localhost (office.CompuComIS.net [207.8.143.11]) by linux.compucomis.net (Postfix) with SMTP id F0488FB08; Fri, 16 Feb 2001 22:33:37 -0500 (EST) From: "Michael Burger" To: "Eric Sandeen" Cc: "linux-xfs@oss.sgi.com" Date: Fri, 16 Feb 2001 22:33:31 -0400 Reply-To: "Michael Burger" X-Mailer: PMMail 1.96a For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: SGI-XFS-RedHat7.0 ISO Message-Id: <20010217033337.F0488FB08@linux.compucomis.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 16 Feb 2001 21:03:55 -0600, Eric Sandeen wrote: >> I'm running into a bit of a snag, and I'm hoping that this list is >> the place to ask. > >It is. :) Great...thanks. >> The problem I'm having is in getting the 2.4.0 kernel supplied with > >> XFS and the ISO image to recognize my NIC...a 3Com 3c575 card. If >> anyone has any helpful suggestions, I'd be most appreciative. > > >Are you trying to do a network install, or did you do a local CD >install, and now you're trying to get the network up and running? > >If it's the former, I'll need to look and see if the bootnet.img has >support for that card. Burned the ISO image to CD, booted the laptop from the CD. Another note...after installation and reboot, the /dev system was lacking a number of things.../dev/cdrom didn't exist...not even /dev/hdc. >If it's the latter, and it's just that the install didn't autoconfigure >your card, have you tried setting it up manually after the install? Are >you getting any sort of error messages? Tried, yes. Did "insmod 3c59x", added "alias 3c59x eth0" (or is it alias eth0 3c59x) in /etc/modules.conf. >There's a discussion of 3com pcmcia network cards here, perhaps there's >information there for you: > >http://pcmcia-cs.sourceforge.net/cgi-bin/HyperNews/get/pcmcia/coms.html I'll take a look...thanks. Incidentally, on reboot, the pcmcia loader gives an error about setup timing out. From owner-linux-xfs@oss.sgi.com Fri Feb 16 23:21:54 2001 Received: by oss.sgi.com id ; Fri, 16 Feb 2001 23:21:43 -0800 Received: from plato.arts.usyd.edu.au ([129.78.16.1]:48913 "EHLO plato.arts.usyd.edu.au") by oss.sgi.com with ESMTP id ; Fri, 16 Feb 2001 23:21:19 -0800 Received: from arts.usyd.edu.au (IDENT:matthew@holly.aitch.ucc.usyd.edu.au [129.78.226.234]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id SAA00409; Sat, 17 Feb 2001 18:21:08 +1100 (EST) Message-ID: <3A8E26E0.3F80FC25@arts.usyd.edu.au> Date: Sat, 17 Feb 2001 18:23:12 +1100 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: IDE DVD problem References: <9993.982366317@ocs3.ocs-net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6252FFBC37A67A695793432E" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a cryptographically signed message in MIME format. --------------ms6252FFBC37A67A695793432E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Keith Owens wrote: > > On Sat, 17 Feb 2001 08:21:58 +1100, > Matthew Geier wrote: > > The linux video project's 'oms' dvd player can oops the IDE driver. The > >oms process > >becomes unkillable and the drive useless for any other process until the > >machine is rebooted. > After klogd has been told to keep its sticky fingers off the data, > reproduce the problem and run ksymoops over the syslog output. That > will give a clean trace of the problem so we can see if it is XFS > related or a general kernel bug. Unable to handle kernel NULL pointer dereference at virtual address 00000034 cda5f1f1 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210246 eax: c20ea000 ebx: c12742c0 ecx: 00001600 edx: 00000000 esi: 00000000 edi: c028c8d0 ebp: c12742c0 esp: c20edc24 ds: 0018 es: 0018 ss: 0018 Process oms_shell (pid: 1082, stackpage=c20ed000) Stack: c12742c0 c665ee00 c028c8d0 cda5f265 c12742c0 c028c8d0 c665ee00 0012a3cc cda5fa35 c028c8d0 0012a3cc 0012a3cc c028c8d0 c12742c0 cda648e0 c665ee00 c0178238 c028c8d0 c12742c0 0012a3cc c028c890 c028c8d0 c7ff6960 c028c8d0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 4e 34 39 c8 74 1a 29 c8 8d 90 ff 01 00 00 83 f8 ff 0f 4f >>EIP; cda5f1f1 <[ide-cd]restore_request+d/44> <===== Trace; cda5f265 <[ide-cd]cdrom_start_read+3d/a4> Trace; cda5fa35 <[ide-cd]ide_do_rw_cdrom+f9/158> Trace; cda648e0 <[ide-cd]ide_cdrom_driver+0/3c> Trace; c0178238 Trace; c0178571 Trace; c01785ef Trace; c015d854 Trace; c011949c <__run_task_queue+50/64> Trace; c01448d1 Trace; c01663d7 Trace; c012b764 <__alloc_pages_limit+94/b8> Trace; c012b8c4 <__alloc_pages+13c/2ec> Trace; c01218d3 Trace; c0121948 Trace; c0121ac0 Trace; c01129ff Trace; c01128a4 Trace; c0122774 Trace; c01300a8 Trace; c016602c Trace; c013032e Trace; c0108d87 Code; cda5f1f1 <[ide-cd]restore_request+d/44> 00000000 <_EIP>: Code; cda5f1f1 <[ide-cd]restore_request+d/44> <===== 0: 8b 4e 34 mov 0x34(%esi),%ecx <===== Code; cda5f1f4 <[ide-cd]restore_request+10/44> 3: 39 c8 cmp %ecx,%eax Code; cda5f1f6 <[ide-cd]restore_request+12/44> 5: 74 1a je 21 <_EIP+0x21> cda5f212 <[ide-cd]restore_request+2e/44> Code; cda5f1f8 <[ide-cd]restore_request+14/44> 7: 29 c8 sub %ecx,%eax Code; cda5f1fa <[ide-cd]restore_request+16/44> 9: 8d 90 ff 01 00 00 lea 0x1ff(%eax),%edx Code; cda5f200 <[ide-cd]restore_request+1c/44> f: 83 f8 ff cmp $0xffffffff,%eax Code; cda5f203 <[ide-cd]restore_request+1f/44> 12: 0f 4f 00 cmovg (%eax),%eax --------------ms6252FFBC37A67A695793432E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH4AYJKoZIhvcNAQcCoIIH0TCCB80CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BckwggKtMIICFqADAgECAgMC8UswDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyMTAyNDAzNFoXDTAxMDcyMTAyNDAz NFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYY bWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR gAKbBhCplgqyhkR0Ykn4XOW0Py1G40orbP+B2KkACTMx4GxhHNg2h3nPiNC/P/9BZETw6NA+ dp/mxtN7XHmvRounnCL+9pjG3yWpw/ONNEpObjRSfujGe/jJvUF2vrAfecI/J5DKQ0/5gZMv 5fqfl4spYSPl+9vc2hKG7uvjgQIDAQABo1YwVDAjBgNVHREEHDAagRhtYXR0aGV3QGFydHMu dXN5ZC5lZHUuYXUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORYx0YdwGG9 I9fDjDANBgkqhkiG9w0BAQQFAAOBgQBjjvY9P9hSktFnCJrkQSTKjh9ZBG9a58a0Hi+GvmyD t9e29sRgxHN+Nwtsu2yUs8+xv1BemYzCnri+y91uJsfRTrm4+1oc/TV+lDGWqBud68wf4x29 /xaj1oQ2vWMy1Y64KZSWyxjt+vcU5/nyNF3DGz9XtXlxTI8dntzEWkyq/DCCAxQwggJ9oAMC AQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxs ZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn /XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESw iy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL3Vx1b8aR kMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6syg1vcnpn LGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAd8wggHbAgEBMIGcMIGUMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UE ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAvFLMAkGBSsOAwIaBQCggZkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMjE3MDcyMzE2WjAjBgkq hkiG9w0BCQQxFgQU8f91gj4lt0Z1cqYevKSZrv6qew8wOgYJKoZIhvcNAQkPMS0wKzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwDQYJKoZIhvcNAQEBBQAE gYBsS1l4D3rzXnALn7mbQybmNO8NsfiRpkuNsJ0+aFOtGIoDMppqyrTQi99f6tJVBW0kp+hp 3F4TvZI90ssXYVhVqQhNP7PM5JSpKaHN0GTj8PLgN0hHPcF9pz9c9pvMNbJ/avL5ttH6ZPjg CjXLDyN6Lf9WWAQrJ0ioKE2ipRXa4A== --------------ms6252FFBC37A67A695793432E-- From owner-linux-xfs@oss.sgi.com Sat Feb 17 14:57:08 2001 Received: by oss.sgi.com id ; Sat, 17 Feb 2001 14:56:58 -0800 Received: from tux.mkp.net ([130.225.60.11]:36618 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Sat, 17 Feb 2001 14:56:30 -0800 Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.16 #1) id 14UGER-0000Xr-00; Sat, 17 Feb 2001 23:53:35 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id LAA03964; Sat, 17 Feb 2001 11:06:15 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Jan H. Schrewe" Cc: xfs-liste Subject: Re: Status of XFS References: <3A8D9A5A.62778092@mpg.goe.ni.schule.de> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 17 Feb 2001 11:06:14 -0500 In-Reply-To: <3A8D9A5A.62778092@mpg.goe.ni.schule.de> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Jan" == Jan H Schrewe writes: Jan, Jan> The other reason is that I didn't have enough time yet to test Jan> the stability of XFS. Well. If I were you I wouldn't put anything into production without testing it first. Jan> So would you ( the developers and testers of XFS ) think that I Jan> can run a server ( without watchdog ) that I don't have physical Jan> access to using raid. RAID0 is fine. We're still working on fixing the problems with RAID5. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Sun Feb 18 00:05:30 2001 Received: by oss.sgi.com id ; Sun, 18 Feb 2001 00:05:20 -0800 Received: from hermes.mixx.net ([212.84.196.2]:18437 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 18 Feb 2001 00:05:02 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 62BE7F804 for ; Sun, 18 Feb 2001 09:04:59 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id EB9D42CA6F; Sun, 18 Feb 2001 09:04:58 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: mysterious dbench results Date: 18 Feb 2001 08:04:58 GMT Organization: innominate AG, Berlin, Germany Lines: 24 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 982483498 17171 10.0.0.31 (18 Feb 2001 08:04:58 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing i have done some simple dbench test with ext2, reiserfs and xfs - all with the same kernel, same partition and run multiple times ... i did them on one machine (1 p233mmx, 64mb, ide) and the results looked like i expected them to be: all three filesystems are in about the same class with xfs the last - but for xfs the io between the dbench clients are much better balanced (all end close to eachother at the end of the run) - so - as steve once said - this might account for the a bit lower xfs results ... ok - then i ran them on another machine (2 pII333, 128mb, ide) and on this smp machine i now get only about 1/4 of the performance of ext2 and reiserfs with xfs ... it's in this setup absolutely reproducable (~1.5mb/sec vs. ~5.5mb/sec) ... i'll try to check this on another machine too if i find the time on monday - but maybe someone else may try it too - any idea? t p.s.: all this is with 2.4.1-XFS from about a week ago and without any kio stuff on ide with udma2 enabled -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sun Feb 18 00:40:50 2001 Received: by oss.sgi.com id ; Sun, 18 Feb 2001 00:40:40 -0800 Received: from hermes.mixx.net ([212.84.196.2]:47877 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 18 Feb 2001 00:40:15 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 35D80F804 for ; Sun, 18 Feb 2001 09:40:13 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id E223D2CA6F; Sun, 18 Feb 2001 09:40:12 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: mysterious dbench results Date: 18 Feb 2001 08:40:12 GMT Organization: innominate AG, Berlin, Germany Lines: 48 Distribution: local Message-ID: References: <96nvna$goj$1@mate.bln.innominate.de> Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 982485612 6902 10.0.0.31 (18 Feb 2001 08:40:12 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing small addition: another test - running pgbench from postgres against postgres 7.1beta4 on the same partition with all three filesystems on the same machines results in much more logic results: on both systems the results are best when xfs is used as filesystem - so looks like the below problem is very specific to dbench and smp ... t p.s.: btw. i reproducable and constantly see about 15% better results for the pgbench produced tpc numbers then running the data- base on an xfs filesystem compared to ext2 and reiserfs which looks pretty good i think - this is for 7.1beta4 - 7.0.x is worse because of the required fsyncs in it which results in xfs being not as good as the others (at least ext2 which i compared it to) Thomas Graichen wrote: > i have done some simple dbench test with ext2, reiserfs and xfs - all > with the same kernel, same partition and run multiple times ... i did > them on one machine (1 p233mmx, 64mb, ide) and the results looked > like i expected them to be: all three filesystems are in about the > same class with xfs the last - but for xfs the io between the dbench > clients are much better balanced (all end close to eachother at the > end of the run) - so - as steve once said - this might account for the > a bit lower xfs results ... ok - then i ran them on another machine > (2 pII333, 128mb, ide) and on this smp machine i now get only about > 1/4 of the performance of ext2 and reiserfs with xfs ... it's in this > setup absolutely reproducable (~1.5mb/sec vs. ~5.5mb/sec) ... i'll > try to check this on another machine too if i find the time on monday > - but maybe someone else may try it too - any idea? > t > p.s.: all this is with 2.4.1-XFS from about a week ago and without > any kio stuff on ide with udma2 enabled > -- > thomas.graichen@innominate.com > innominate AG > the linux architects > tel: +49-30-308806-13 fax: -77 http://www.innominate.com -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sun Feb 18 01:29:00 2001 Received: by oss.sgi.com id ; Sun, 18 Feb 2001 01:28:50 -0800 Received: from ci871421-a.lxintn1.ky.home.com ([24.9.209.212]:15358 "EHLO dosmonos") by oss.sgi.com with ESMTP id ; Sun, 18 Feb 2001 01:28:39 -0800 Received: from funnyguy (helo=localhost) by dosmonos with local-esmtp (Exim 3.22 #1 (Debian)) id 14UQ8z-0001n4-00 for ; Sun, 18 Feb 2001 04:28:37 -0500 Date: Sun, 18 Feb 2001 04:28:34 -0500 (EST) From: Mike Brancato X-Sender: funnyguy@dosmonos To: linux-xfs@oss.sgi.com Subject: undefined reference on xfstools Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing /usr/src/linux-2.4-xfs/cmd/xfsprogs/repair/xfs_repair.c:287: undefined reference to `va_start' i've tried patching 2.4.1 with both the patches from Feb 6th, and chcking out the linux-2.4-xfs tree. all produce an undefined reference to "va_start" and "va_end" in some files. this is a debian unstable/sid machine. any clues? i've been back and forth ont he project site, can't find it. toss me a URL if you can. mike From owner-linux-xfs@oss.sgi.com Sun Feb 18 03:19:41 2001 Received: by oss.sgi.com id ; Sun, 18 Feb 2001 03:19:21 -0800 Received: from skl1.ukl.uni-freiburg.de ([193.196.199.1]:10421 "HELO skl1.ukl.uni-freiburg.de") by oss.sgi.com with SMTP id ; Sun, 18 Feb 2001 03:19:01 -0800 Received: (qmail 1417 invoked by alias); 18 Feb 2001 11:18:58 -0000 Received: (qmail 1412 invoked from network); 18 Feb 2001 11:18:57 -0000 Received: from msm205.ukl.uni-freiburg.de (HELO ukl.uni-freiburg.de) (193.196.218.205) by skl1.ukl.uni-freiburg.de with SMTP; 18 Feb 2001 11:18:57 -0000 Message-ID: <3A8FB01C.E734120B@ukl.uni-freiburg.de> Date: Sun, 18 Feb 2001 12:21:00 +0100 From: "Manfred W. Baumstark" Organization: Medizinische Universitaetsklink Freiburg X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: PCMCIA and devfs References: <3A8BE135.9294EBC7@ukl.uni-freiburg.de> <3A8C3D0F.B6E4A055@arts.usyd.edu.au> <3A8D79FC.F45E0B0F@ukl.uni-freiburg.de> <3A8D7B7A.37F2F4FF@thebarn.com> Content-Type: multipart/mixed; boundary="------------EABF4167242A7CF5F4E2779C" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------EABF4167242A7CF5F4E2779C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In fact PCMCIA runs fine together with devfs now. I recompiled the kernel (to apply the patch from Eric) and got problems with pcmcia related modules. Read the PCMCIA docs. After switching kernel support for pcmcia OFF, the kernel compiled fine. Compiling and installing pcmcia-cs-3.1.23 made pcmcia work. Manfred Russell Cattelan wrote: > > "Manfred W. Baumstark" wrote: > > > Matthew Geier wrote: > > > > ... > > > > > > It is also a devfs problem - I posted about this a week or so back. > > > Turn off devfs entirelty and run a 'traditional' /dev. > > > > If I turn devfs off, I get a boot failure. (Redhat 7 with your pre 0.9 RPMS > > applied). > > There is something in the installcavs that says "before turning devfs off > > you will need to obtain a fixed version of the kernel from the oss web > > site". Is this fixed version somewere? > > Turning off devfs shouldn't cause boot failures? > Any messages that might shed some light on things? > > I'm curious to find out why devfs has any affect on pcmcia. > I've been running my laptop with devfs for about 6 months... no > problems with pcmcia... well other than certain cards not working. > > -- > Russell Cattelan > -- > Digital Elves inc. -- Currently on loan to SGI > Linux XFS core developer. --------------EABF4167242A7CF5F4E2779C Content-Type: text/x-vcard; charset=us-ascii; name="maba.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Manfred W. Baumstark Content-Disposition: attachment; filename="maba.vcf" begin:vcard n:Baumstark;Manfred tel;fax:+49 761 270 7470 tel;work:+49 761 270 7496 x-mozilla-html:TRUE org:University Hospital Freiburg;Rehabilitative and Preventive Sportsmedicine adr:;;Hugstetter Str. 55;Freiburg;;D-79106;Germany version:2.1 email;internet:manfred.baumstark@uni-freiburg.de title:Dr. x-mozilla-cpt:;29056 fn:Manfred Baumstark end:vcard --------------EABF4167242A7CF5F4E2779C-- From owner-linux-xfs@oss.sgi.com Sun Feb 18 05:36:31 2001 Received: by oss.sgi.com id ; Sun, 18 Feb 2001 05:36:21 -0800 Received: from ns.suse.de ([213.95.15.193]:47110 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Sun, 18 Feb 2001 05:36:00 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id C02F81E0AB; Sun, 18 Feb 2001 14:35:58 +0100 (MET) Date: Sun, 18 Feb 2001 14:35:53 +0100 From: Andi Kleen To: Mike Brancato Cc: linux-xfs@oss.sgi.com Subject: Re: undefined reference on xfstools Message-ID: <20010218143553.A19395@gruyere.muc.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from funnyguy@digitalsmackdown.net on Sun, Feb 18, 2001 at 04:28:34AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, Feb 18, 2001 at 04:28:34AM -0500, Mike Brancato wrote: > /usr/src/linux-2.4-xfs/cmd/xfsprogs/repair/xfs_repair.c:287: undefined > reference to `va_start' > > i've tried patching 2.4.1 with both the patches from Feb 6th, and chcking > out the linux-2.4-xfs tree. all produce an undefined reference to > "va_start" and "va_end" in some files. > > this is a debian unstable/sid machine. any clues? i've been back and > forth ont he project site, can't find it. toss me a URL if you can. Try adding a #include on top of the file -Andi From owner-linux-xfs@oss.sgi.com Sun Feb 18 08:28:21 2001 Received: by oss.sgi.com id ; Sun, 18 Feb 2001 08:28:12 -0800 Received: from hermes.mixx.net ([212.84.196.2]:58893 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 18 Feb 2001 08:27:52 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 820F3F81E for ; Sun, 18 Feb 2001 17:27:44 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id AE5DC2CA6F; Sun, 18 Feb 2001 17:27:39 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: mysterious dbench results Date: 18 Feb 2001 16:27:39 GMT Organization: innominate AG, Berlin, Germany Lines: 64 Distribution: local Message-ID: References: <96nvna$goj$1@mate.bln.innominate.de> Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 982513659 15331 10.0.0.31 (18 Feb 2001 16:27:39 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ok - now tested it on one machine once in smp and once in up mode and got the same results (very bad dbench results compared to ext2 or reiserfs) ... so it's not smp related - i'm right now updating the kernel and will post again - if the problem is still there ... t Thomas Graichen wrote: > small addition: another test - running pgbench from postgres against > postgres 7.1beta4 on the same partition with all three filesystems > on the same machines results in much more logic results: on both > systems the results are best when xfs is used as filesystem - > so looks like the below problem is very specific to dbench > and smp ... > t > p.s.: btw. i reproducable and constantly see about 15% better results > for the pgbench produced tpc numbers then running the data- > base on an xfs filesystem compared to ext2 and reiserfs > which looks pretty good i think - this is for 7.1beta4 > - 7.0.x is worse because of the required fsyncs in it > which results in xfs being not as good as the others > (at least ext2 which i compared it to) > Thomas Graichen wrote: >> i have done some simple dbench test with ext2, reiserfs and xfs - all >> with the same kernel, same partition and run multiple times ... i did >> them on one machine (1 p233mmx, 64mb, ide) and the results looked >> like i expected them to be: all three filesystems are in about the >> same class with xfs the last - but for xfs the io between the dbench >> clients are much better balanced (all end close to eachother at the >> end of the run) - so - as steve once said - this might account for the >> a bit lower xfs results ... ok - then i ran them on another machine >> (2 pII333, 128mb, ide) and on this smp machine i now get only about >> 1/4 of the performance of ext2 and reiserfs with xfs ... it's in this >> setup absolutely reproducable (~1.5mb/sec vs. ~5.5mb/sec) ... i'll >> try to check this on another machine too if i find the time on monday >> - but maybe someone else may try it too - any idea? >> t >> p.s.: all this is with 2.4.1-XFS from about a week ago and without >> any kio stuff on ide with udma2 enabled >> -- >> thomas.graichen@innominate.com >> innominate AG >> the linux architects >> tel: +49-30-308806-13 fax: -77 http://www.innominate.com > -- > thomas.graichen@innominate.com > innominate AG > the linux architects > tel: +49-30-308806-13 fax: -77 http://www.innominate.com -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sun Feb 18 09:51:43 2001 Received: by oss.sgi.com id ; Sun, 18 Feb 2001 09:51:32 -0800 Received: from hermes.mixx.net ([212.84.196.2]:30735 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 18 Feb 2001 09:51:09 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id CEC90F81E for ; Sun, 18 Feb 2001 18:51:04 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id B21942CA6F; Sun, 18 Feb 2001 18:51:04 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: mysterious dbench results Date: 18 Feb 2001 17:51:04 GMT Organization: innominate AG, Berlin, Germany Lines: 18 Distribution: local Message-ID: References: <96nvna$goj$1@mate.bln.innominate.de> <96ot5r$ev3$1@mate.bln.innominate.de> Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 982518664 31354 10.0.0.31 (18 Feb 2001 17:51:04 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > ok - now tested it on one machine once in smp and once in up mode > and got the same results (very bad dbench results compared to > ext2 or reiserfs) ... so it's not smp related - i'm right now > updating the kernel and will post again - if the problem is > still there ... ... and it is - so the question: anyone else seing this? - as said dbench results are about 1/4th of ext2 results with the current XFS tree on an ide disk system for smp and nosmp t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sun Feb 18 16:27:45 2001 Received: by oss.sgi.com id ; Sun, 18 Feb 2001 16:27:35 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:46379 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 18 Feb 2001 16:27:27 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA03785 for ; Sun, 18 Feb 2001 16:36:41 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA02725; Mon, 19 Feb 2001 11:25:24 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA41601; Mon, 19 Feb 2001 11:25:21 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102191125.ZM118347@wobbly.melbourne.sgi.com> Date: Mon, 19 Feb 2001 11:25:20 -0400 In-Reply-To: Mike Brancato "undefined reference on xfstools" (Feb 18, 4:28am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Mike Brancato , linux-xfs@oss.sgi.com Subject: libc6-dev changes (was Re: undefined reference on xfstools) Cc: debian-devel@lists.debian.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hello, On Feb 18, 4:28am, Mike Brancato wrote: > Subject: undefined reference on xfstools > /usr/src/linux-2.4-xfs/cmd/xfsprogs/repair/xfs_repair.c:287: undefined > reference to `va_start' > > i've tried patching 2.4.1 with both the patches from Feb 6th, and chcking > out the linux-2.4-xfs tree. all produce an undefined reference to > "va_start" and "va_end" in some files. > > this is a debian unstable/sid machine. any clues? i've been back and > forth ont he project site, can't find it. toss me a URL if you can. I too am using the debian unstable distribution, but I don't have the problem you're seeing. You'll find va_start and va_end come from stdarg.h, which is included via stdio.h, which is included via xfsprogs/include/platform_defs.h, which is included via xfsprogs/include/libxfs.h, which is included by xfs_repair.c directly. 10:47 nathans@troppo ~ 20> dpkg --search /usr/include/stdio.h libc6-dev: /usr/include/stdio.h 10:49 nathans@troppo ~ 21> dpkg --search stdarg.h gcc-2.95: /usr/lib/gcc-lib/i386-linux/2.95.3/include/stdarg.h kgcc: /usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/include/stdarg.h 10:49 nathans@troppo ~ 22> I guess we might have different versions of either libc6-dev or gcc installed? Ahh - I've just done an apt-get upgrade & now things blow up. It looks like stdio.h has changed from something like this... # ifndef __USE_XOPEN # define __need___va_list # endif # include (which unconditionally included stdarg.h), to this... #ifdef __USE_XOPEN # ifdef __GNUC__ # ifndef _VA_LIST_DEFINED typedef _G_va_list va_list; # define _VA_LIST_DEFINED # endif # else # include # endif #endif which no longer includes stdarg.h all the time. oh, well - that's easily fixed - looks like our tools should have been including stdarg.h directly anyway. I'll put a fix in shortly. thanks! ps: I imagine this change might cause breakage in other Debian packages, so I'll CC debian-devel. I'm not sure exactly when this libc6-dev change happened since I hadn't upgraded for a few weeks now. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 18 16:41:35 2001 Received: by oss.sgi.com id ; Sun, 18 Feb 2001 16:41:25 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21036 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 18 Feb 2001 16:41:00 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA05234 for ; Sun, 18 Feb 2001 16:49:50 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA70258 for linux-xfs@oss.sgi.com; Mon, 19 Feb 2001 11:38:43 +1100 (EST) Date: Mon, 19 Feb 2001 11:38:43 +1100 (EST) From: Nathan Scott Message-Id: <200102190038.LAA70258@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Sun Feb 18 16:38:02 PST 2001 Workarea: 134.14.55.149:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:87882a cmd/xfsprogs/include/platform_defs.h.in - 1.2 cmd/dmapi/libdm/dmapi_lib.c - 1.3 - explicitly include stdarg.h for recent glibc 2.2.2 changes to stdio.h. From owner-linux-xfs@oss.sgi.com Mon Feb 19 00:25:11 2001 Received: by oss.sgi.com id ; Mon, 19 Feb 2001 00:25:01 -0800 Received: from bru5-smtp-out1.uunet.be ([194.7.1.5]:23244 "EHLO bru5-smtp-out1.be.uu.net") by oss.sgi.com with ESMTP id ; Mon, 19 Feb 2001 00:24:45 -0800 Received: from gate.vum.be (firewall.vum.be [194.7.240.162]) by bru5-smtp-out1.be.uu.net (8.11.2/8.11.2) with SMTP id f1J8ObS19796; Mon, 19 Feb 2001 09:24:38 +0100 (MET) Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id JAA26714; Mon, 19 Feb 2001 09:24:45 +0100 (MET) Received: from yucom.be (IDENT:kris@localhost.localdomain [127.0.0.1]) by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id JAA25689; Mon, 19 Feb 2001 09:24:02 +0100 Message-ID: <3A90D822.ED3B255@yucom.be> Date: Mon, 19 Feb 2001 09:24:02 +0100 From: kris buggenhout X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: SGI-XFS-RedHat7.0 ISO References: <200102170303.f1H33Df15252@mail15.jump.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing RXJpYyBTYW5kZWVuIHdyb3RlOg0KDQo+IE9uIDE2IEZlYiAyMDAxIDIxOjA0OjQ1IC0wNDAw LCBNaWNoYWVsIEJ1cmdlciB3cm90ZToNCj4gPiBJJ20gcnVubmluZyBpbnRvIGEgYml0IG9m IGEgc25hZywgYW5kIEknbSBob3BpbmcgdGhhdCB0aGlzIGxpc3QgaXMNCj4gPiB0aGUgcGxh Y2UgdG8gYXNrLg0KPg0KPiBJdCBpcy4gIDopDQo+DQo+ID4gVGhlIHByb2JsZW0gSSdtIGhh dmluZyBpcyBpbiBnZXR0aW5nIHRoZSAyLjQuMCBrZXJuZWwgc3VwcGxpZWQgd2l0aA0KPg0K PiA+IFhGUyBhbmQgdGhlIElTTyBpbWFnZSB0byByZWNvZ25pemUgbXkgTklDLi4uYSAzQ29t IDNjNTc1IGNhcmQuICBJZg0KPiA+IGFueW9uZSBoYXMgYW55IGhlbHBmdWwgc3VnZ2VzdGlv bnMsIEknZCBiZSBtb3N0IGFwcHJlY2lhdGl2ZS4NCj4NCg0KSSBoYWQgdGhlIHNhbWUgcHJv YmxlbSBvbiB0aGUgc2FtZSBsYXB0b3AuLi4NCg0KVGhlIHByb2JsZW0gaXMgOiB0aGUgcGNt Y2lhIGNvcmUgaXMgbm90IGk4eHh4IGJ1dCB5ZW50YV9zb2NrZXQgIHNvIGVkaXQNCi9ldGMv c3lzY29uZmlnL3BjbWNpYSBhbmQgY2hhbmdlIHRoZSBsaW5lIFBDSUM9aTgyMzY1IGludG8N ClBDSUM9eWVudGFfc29ja2V0DQoNCnRoaXMgZ2V0J3MgVSBoYWxmIHdheSAuLi4gbm93IHJl aW5zbW9kIHRoZSAzYzU5eCBtb2R1bGUgLi4uIGFuZCBwcmVzdG8NCm5ldHdvcmsNCg0KDQp0 aGUgb3RoZXIgcHJvYmxlbSBpcyBkZXZmcyBzcGVjaWZpYyAuLi4gYXV0b2xvYWRpbmcgb2Yg Y2VydGFpbiBkZXZpY2VzDQpmYWlscyAobGlrZSBjZHJvbSAuLi4pDQoNCmp1c3QgZG8gYSBt b2Rwcm9iZSBjZHJvbTttb2Rwcm9iZSBpZGUtY2QNCnRoZW4gdGhlIC9kZXYvaGRjIGRldmlj ZSBmaWxlIHdpbGwgYmUgdGhlcmUuDQoNCmZvciB0aGUgbW91c2UgLi4uIHRoYXRzIGFub3Ro ZXIgcHJvYiAuLi4NCml0IHdvcmtzIHVuZGVyIFggdGhvdWdoLi4uLiAgIGdwbSAtdCBwczIg LW0gL2Rldi9wc2F1eCAgIHNob3VsZCBkbyB0aGUNCnRyaWNrDQoNCg0K From owner-linux-xfs@oss.sgi.com Mon Feb 19 02:43:21 2001 Received: by oss.sgi.com id ; Mon, 19 Feb 2001 02:43:11 -0800 Received: from mail.ureach.com ([63.150.151.36]:6162 "EHLO ureach.com") by oss.sgi.com with ESMTP id ; Mon, 19 Feb 2001 02:43:03 -0800 Received: from www21.ureach.com (IDENT:root@www21.ureach.com [172.16.2.49]) by ureach.com (8.9.1/8.8.5) with ESMTP id FAA26832 for ; Mon, 19 Feb 2001 05:43:02 -0500 Received: (from nobody@localhost) by www21.ureach.com (8.9.3/8.9.1) id FAA16029; Mon, 19 Feb 2001 05:43:02 -0500 Date: Mon, 19 Feb 2001 05:43:02 -0500 Message-Id: <200102191043.FAA16029@www21.ureach.com> To: linux-xfs@oss.sgi.com From: Alfred Nutile Reply-to: Subject: Does it work with samba on it as a server? Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ignore this message if this is not your area but just wondering if I can set up a samba server using this instead of rieserfs since XFS has been around longer? Thanks Al From owner-linux-xfs@oss.sgi.com Mon Feb 19 04:50:11 2001 Received: by oss.sgi.com id ; Mon, 19 Feb 2001 04:50:01 -0800 Received: from linux.CompuComIS.net ([207.8.143.10]:14086 "HELO linux.compucomis.net") by oss.sgi.com with SMTP id ; Mon, 19 Feb 2001 04:49:39 -0800 Received: by linux.compucomis.net (Postfix, from userid 501) id 711CEFB0D; Mon, 19 Feb 2001 07:49:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 6D878BC56; Mon, 19 Feb 2001 07:49:28 -0500 (EST) Date: Mon, 19 Feb 2001 07:49:28 -0500 (EST) From: Mike Burger To: Alfred Nutile Cc: Subject: Re: Does it work with samba on it as a server? In-Reply-To: <200102191043.FAA16029@www21.ureach.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I'm not on the dev team or anything like that, but I don't believe Samba cares what filesystem you're using. As far as I know, you can use any filesystem you like on your system, and Samba will serve it up just fine. On Mon, 19 Feb 2001, Alfred Nutile wrote: > Ignore this message if this is not your area but just wondering > if I can set up a samba server using this instead of rieserfs > since XFS has been around longer? Thanks > Al > From owner-linux-xfs@oss.sgi.com Mon Feb 19 04:52:41 2001 Received: by oss.sgi.com id ; Mon, 19 Feb 2001 04:52:22 -0800 Received: from linux.CompuComIS.net ([207.8.143.10]:14598 "HELO linux.compucomis.net") by oss.sgi.com with SMTP id ; Mon, 19 Feb 2001 04:52:10 -0800 Received: by linux.compucomis.net (Postfix, from userid 501) id ED7EBFB0D; Mon, 19 Feb 2001 07:51:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id E98B1BC56; Mon, 19 Feb 2001 07:51:59 -0500 (EST) Date: Mon, 19 Feb 2001 07:51:59 -0500 (EST) From: Mike Burger To: kris buggenhout Cc: Eric Sandeen , "linux-xfs@oss.sgi.com" Subject: Re: SGI-XFS-RedHat7.0 ISO In-Reply-To: <3A90D822.ED3B255@yucom.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ok...I got the yenta_socket entry in there and rebooted. It got a little farther. When I reran "insmod 3c59x" though, it told me that the module was already installed. I've got a line in my /etc/modules.conf that reads 'alias eth0 3c59x"...but the card still isn't being initialized properly. Any more ideas? I'll tackle the CD and such after this. And thanks for the great suggestion. On Mon, 19 Feb 2001, kris buggenhout wrote: > Eric Sandeen wrote: > > > On 16 Feb 2001 21:04:45 -0400, Michael Burger wrote: > > > I'm running into a bit of a snag, and I'm hoping that this list is > > > the place to ask. > > > > It is. :) > > > > > The problem I'm having is in getting the 2.4.0 kernel supplied with > > > > > XFS and the ISO image to recognize my NIC...a 3Com 3c575 card. If > > > anyone has any helpful suggestions, I'd be most appreciative. > > > > I had the same problem on the same laptop... > > The problem is : the pcmcia core is not i8xxx but yenta_socket so edit > /etc/sysconfig/pcmcia and change the line PCIC=i82365 into > PCIC=yenta_socket > > this get's U half way ... now reinsmod the 3c59x module ... and presto > network > > > the other problem is devfs specific ... autoloading of certain devices > fails (like cdrom ...) > > just do a modprobe cdrom;modprobe ide-cd > then the /dev/hdc device file will be there. > > for the mouse ... thats another prob ... > it works under X though.... gpm -t ps2 -m /dev/psaux should do the > trick > > > From owner-linux-xfs@oss.sgi.com Mon Feb 19 05:08:41 2001 Received: by oss.sgi.com id ; Mon, 19 Feb 2001 05:08:22 -0800 Received: from garnet.sover.net ([209.198.87.53]:60097 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Mon, 19 Feb 2001 05:07:59 -0800 Received: from [192.168.1.3] (pm1a11.stj.sover.net [209.198.94.11]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id IAA26370; Mon, 19 Feb 2001 08:07:47 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from pm1a11.stj.sover.net [209.198.94.11] 209.198.94.11 Mon, 19 Feb 2001 08:07:47 -0500 (EST) Date: Mon, 19 Feb 2001 07:55:38 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Mike Burger cc: SGI XFS Mailing List Subject: Re: Does it work with samba on it as a server? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, 19 Feb 2001, Mike Burger wrote: I know NFS can be problematic, and kinda dependant on the underlying filesystem. I dunno about Samba. THa'ts just what I have heard. RegEx > I'm not on the dev team or anything like that, but I don't believe Samba > cares what filesystem you're using. As far as I know, you can use any > filesystem you like on your system, and Samba will serve it up just fine. > > On Mon, 19 Feb 2001, Alfred Nutile wrote: > > > Ignore this message if this is not your area but just wondering > > if I can set up a samba server using this instead of rieserfs > > since XFS has been around longer? Thanks > > Al > > > From owner-linux-xfs@oss.sgi.com Mon Feb 19 06:19:02 2001 Received: by oss.sgi.com id ; Mon, 19 Feb 2001 06:18:42 -0800 Received: from skl1.ukl.uni-freiburg.de ([193.196.199.1]:56023 "HELO skl1.ukl.uni-freiburg.de") by oss.sgi.com with SMTP id ; Mon, 19 Feb 2001 06:18:22 -0800 Received: (qmail 10542 invoked by alias); 19 Feb 2001 14:18:18 -0000 Received: (qmail 10534 invoked from network); 19 Feb 2001 14:18:18 -0000 Received: from msm138.ukl.uni-freiburg.de (HELO ukl.uni-freiburg.de) (193.196.218.138) by skl1.ukl.uni-freiburg.de with SMTP; 19 Feb 2001 14:18:18 -0000 Message-ID: <3A912B50.AE0ABD2B@ukl.uni-freiburg.de> Date: Mon, 19 Feb 2001 15:18:56 +0100 From: "Manfred W. Baumstark" Organization: Medizinische Universitaetsklink Freiburg X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" CC: Mike Burger Subject: Re: SGI-XFS-RedHat7.0 ISO References: Content-Type: multipart/mixed; boundary="------------0FE287ACE0DD59D01CC2F12C" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------0FE287ACE0DD59D01CC2F12C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I had to switch pnp-support in the bios off (operating system other) in order to make my integrated rtl8139 network card work. A symptom is generally that the card is detected with a ff:ff:ff:ff:ff:ff station address (ifconfig). For more on this see: http://www.scyld.com/expert/modules.html Manfred Mike Burger wrote: > > Ok...I got the yenta_socket entry in there and rebooted. It got a little > farther. When I reran "insmod 3c59x" though, it told me that the module > was already installed. > > I've got a line in my /etc/modules.conf that reads 'alias eth0 > 3c59x"...but the card still isn't being initialized properly. > > Any more ideas? > > I'll tackle the CD and such after this. > > And thanks for the great suggestion. > > On Mon, 19 Feb 2001, kris buggenhout wrote: > > > Eric Sandeen wrote: > > > > > On 16 Feb 2001 21:04:45 -0400, Michael Burger wrote: > > > > I'm running into a bit of a snag, and I'm hoping that this list is > > > > the place to ask. > > > > > > It is. :) > > > > > > > The problem I'm having is in getting the 2.4.0 kernel supplied with > > > > > > > XFS and the ISO image to recognize my NIC...a 3Com 3c575 card. If > > > > anyone has any helpful suggestions, I'd be most appreciative. > > > > > > > I had the same problem on the same laptop... > > > > The problem is : the pcmcia core is not i8xxx but yenta_socket so edit > > /etc/sysconfig/pcmcia and change the line PCIC=i82365 into > > PCIC=yenta_socket > > > > this get's U half way ... now reinsmod the 3c59x module ... and presto > > network > > > > > > the other problem is devfs specific ... autoloading of certain devices > > fails (like cdrom ...) > > > > just do a modprobe cdrom;modprobe ide-cd > > then the /dev/hdc device file will be there. > > > > for the mouse ... thats another prob ... > > it works under X though.... gpm -t ps2 -m /dev/psaux should do the > > trick > > > > > > --------------0FE287ACE0DD59D01CC2F12C Content-Type: text/x-vcard; charset=us-ascii; name="maba.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Manfred W. Baumstark Content-Disposition: attachment; filename="maba.vcf" begin:vcard n:Baumstark;Manfred tel;fax:+49 761 270 7470 tel;work:+49 761 270 7496 x-mozilla-html:TRUE org:University Hospital Freiburg;Rehabilitative and Preventive Sportsmedicine adr:;;Hugstetter Str. 55;Freiburg;;D-79106;Germany version:2.1 email;internet:manfred.baumstark@uni-freiburg.de title:Dr. x-mozilla-cpt:;29056 fn:Manfred Baumstark end:vcard --------------0FE287ACE0DD59D01CC2F12C-- From owner-linux-xfs@oss.sgi.com Mon Feb 19 13:54:47 2001 Received: by oss.sgi.com id ; Mon, 19 Feb 2001 13:54:37 -0800 Received: from skl1.ukl.uni-freiburg.de ([193.196.199.1]:23270 "HELO skl1.ukl.uni-freiburg.de") by oss.sgi.com with SMTP id ; Mon, 19 Feb 2001 13:54:30 -0800 Received: (qmail 25275 invoked by alias); 19 Feb 2001 21:54:27 -0000 Received: (qmail 25270 invoked from network); 19 Feb 2001 21:54:27 -0000 Received: from msm205.ukl.uni-freiburg.de (HELO ukl.uni-freiburg.de) (193.196.218.205) by skl1.ukl.uni-freiburg.de with SMTP; 19 Feb 2001 21:54:27 -0000 Message-ID: <3A919586.A4AAEA29@ukl.uni-freiburg.de> Date: Mon, 19 Feb 2001 22:52:06 +0100 From: "Manfred W. Baumstark" Organization: Medizinische Universitaetsklink Freiburg X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-SGI_XFS_MB01 i686) X-Accept-Language: en,de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: /dev/mouse /dev/cdrom (was: PCMCIA and devfs) References: <3A8BE135.9294EBC7@ukl.uni-freiburg.de> Content-Type: multipart/mixed; boundary="------------8D11DCE9954CA05A658AA43A" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------8D11DCE9954CA05A658AA43A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Now I can answer my own questions, maybe this saves other newbies some hours... > > No device entry is generated for my ide-cd. If I manually execute "modprobe > ide-cd" I get /dev/cdroms/cdrom* and /dev/hdb but not /dev/cdrom. How can I > generate this entry? > > The same with /dev/mouse. I would like to have a symlink /dev/mouse --> > /dev/psaux. > I load the cdrom modules by "modprobe ide-cd" in rc.local (not elegant, but works). To get your favourate links in /dev you have to add lines like this to /etc/devfsd.conf: REGISTER mydir/mydev CFUNCTION GLOBAL symlink $devname mydev UNREGISTER mydir/mydev CFUNCTION GLOBAL unlink mydev Examples: REGISTER ide/host0/bus0/target1/lun0/cd CFUNCTION GLOBAL symlink $devname cdrom UNREGISTER ide/host0/bus0/target1/lun0/cd CFUNCTION GLOBAL unlink cdrom REGISTER misc/psaux CFUNCTION GLOBAL symlink $devname mouse UNREGISTER misc/psaux CFUNCTION GLOBAL unlink mouse I think mydir/mydev has to be the actual device not a link, i.e. cdroms/cdrom0 did not work. Manfred --------------8D11DCE9954CA05A658AA43A Content-Type: text/x-vcard; charset=us-ascii; name="maba.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Manfred W. Baumstark Content-Disposition: attachment; filename="maba.vcf" begin:vcard n:Baumstark;Manfred tel;fax:+49 761 270 7470 tel;work:+49 761 270 7496 x-mozilla-html:TRUE org:University Hospital Freiburg;Rehabilitative and Preventive Sportsmedicine adr:;;Hugstetter Str. 55;Freiburg;;D-79106;Germany version:2.1 email;internet:manfred.baumstark@uni-freiburg.de title:Dr. x-mozilla-cpt:;29056 fn:Manfred Baumstark end:vcard --------------8D11DCE9954CA05A658AA43A-- From owner-linux-xfs@oss.sgi.com Tue Feb 20 00:22:03 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 00:21:53 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:18491 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 00:21:41 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA16752 for ; Tue, 20 Feb 2001 00:20:36 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA08246 for linux-xfs@oss.sgi.com; Tue, 20 Feb 2001 19:20:22 +1100 (EST) Date: Tue, 20 Feb 2001 19:20:22 +1100 (EST) From: Timothy Shimmin Message-Id: <200102200820.TAA08246@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acls Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Change QA test for ACLs (thanks to Marcelo) so that we use "fork/exec" instead of "system" to test execute permission validation for a program. This uncovered a bug in the ACL code which should be fixed by the change to posix_acl.c. Basically, we need to sync up the Linux inode's i_mode bits with the IRIX inode's di_mode bits after we set the acl. Otherwise, execute permission won't be granted until we do an operation which causes the revalidate to occur. There is some strange code in linux/fs/exec.c: int prepare_binprm(struct linux_binprm *bprm) { int mode; struct inode * inode = bprm->file->f_dentry->d_inode; mode = inode->i_mode; /* Huh? We had already checked for MAY_EXEC, WTF do we check this? */ if (!(mode & 0111)) /* with at least _one_ execute bit set */ return -EACCES; ... which does a 2nd execute permission check. It is strange because it is called from do_execve() which previously called open_exec() which calls the permission() function. The permission() function can be overridden like we do for ACLs. However, even if access is granted by the permission function, if the mode bits don't grant access then you are stuffed. I would have thought that access should be left to the permission function. --Tim Date: Tue Feb 20 00:07:09 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:87920a cmd/xfstests/src/runas.c - 1.2 - Take Marcelo Magallo's diff/suggestion and use fork/exec instead of system. cmd/xfstests/051.out - 1.3 - Update as no longer uses system but fork/exec. cmd/xfstests/051 - 1.4 - tidy up a bit linux/fs/posix_acl.c - 1.2 - Need to do a revalidate after we call acl_set so that the Linux inode bits are copied over from the xfs inode. Specifically we need Linux' i_mode to have XFS' di_mode. It becomes important for this to happen as do_execve() which calls prepare_binprm() seems to have a crazy test which checks the permission bits again - after calling the permission function earlier. So we need the mode bits sync'ed with the acl permission bits. From owner-linux-xfs@oss.sgi.com Tue Feb 20 08:37:45 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 08:37:36 -0800 Received: from [65.100.85.34] ([65.100.85.34]:20870 "EHLO roujin.gargoylecc.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 08:37:25 -0800 Received: from [65.100.85.35] (IDENT:ringram@gargoyle.gargoylecc.com [65.100.85.35]) by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id AAA24216 for ; Wed, 21 Feb 2001 00:49:09 -0700 Date: Tue, 20 Feb 2001 09:41:10 -0700 (MST) From: Russel Ingram X-Sender: To: Subject: not xfs related - just hoping someone here has a better understanding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is completely not related to XFS other than that I am using devfs because it was installed with the RH7.0-SGI-XFS_PR and I would like to understand it and use it. I'm hoping someone here has a better understanding of the devfsd and its config file that I have been able to accomplish. Does anyone know why the commented lines at the very bottom of this config make my devfsd puke? # Sample /etc/devfsd.conf configuration file. # Richard Gooch 3-JUL-2000 # # Enable full compatibility mode for old device names. You may comment these # out if you don't use the old device names. Make sure you know what you're # doing! REGISTER .* MKOLDCOMPAT UNREGISTER .* RMOLDCOMPAT # You may comment out the above and uncomment the following if you've # configured your system to use the original "new" devfs names or the really # new names #REGISTER vc/.* MKOLDCOMPAT #UNREGISTER vc/.* RMOLDCOMPAT #REGISTER pty/.* MKOLDCOMPAT #UNREGISTER pty/.* RMOLDCOMPAT #REGISTER misc MKOLDCOMPAT #UNREGISTER misc RMOLDCOMPAT # You may comment these out if you don't use the original "new" names REGISTER .* MKNEWCOMPAT UNREGISTER .* RMNEWCOMPAT # Enable module autoloading. You may comment this out if you don't use # autoloading LOOKUP .* MODLOAD # # Uncomment this if you want permissions to be saved and restored #REGISTER .* COPY /dev-state/$devname $devpath #CHANGE .* COPY $devpath /dev-state/$devname #CREATE .* COPY $devpath /dev-state/$devname REGISTER scsi/host.*/bus.*/target.*/lun.*/generic PERMISSIONS 0.0 644 REGISTER scsi/host.*/bus.*/target.*/lun.*/cd PERMISSIONS 0.0 666 #REGISTER scsi/host0/bus0/target0/lun0/cd CFUNCTION GLOBAL symlink $devname cdrom #UNREGISTER scsi/host0/bus0/target0/lun0/cd CFUNCTION GLOBAL unlink cdrom #REGISTER misc/psaux CFUNCTION GLOBAL symlink $devname mouse #UNREGISTER misc/psaux CFUNCTION GLOBAL unlink mouse #REGISTER v4l/video0 CFUNCTION GLOBAL symlink $devname video #UNREGISTER v4l/video0 CFUNCTION GLOBAL unlink video Any suggestions from anyone are greatly appreciated. The online docs haven't been much help so far (insufficient examples makes it difficult when you don't fully understand what the docs are saying in the first place). Thanx, Russ -- --------------------------------------------------------------- "Bill Gates and Microsoft have ruined the computer industry for a long time to come by creating a class of ignorant and lazy computer users." --Russel Ingram "Mommy ... can I go out and ... KILL TONIGHT!?" --Glen Danzig, The Misfits --------------------------------------------------------------- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Tue Feb 20 11:07:56 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 11:07:46 -0800 Received: from mail11.jump.net ([206.196.91.11]:6073 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 11:07:33 -0800 Received: from Porter (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f1KJ7NT05656; Tue, 20 Feb 2001 13:07:23 -0600 (CST) Message-Id: <200102201907.f1KJ7NT05656@mail11.jump.net> Subject: Re: not xfs related - just hoping someone here has a better understanding From: Eric Sandeen To: Russel Ingram Cc: linux-xfs@oss.sgi.com In-Reply-To: Content-Type: text/plain X-Mailer: Evolution (0.8/+cvs.2001.02.15.08.59 - Preview Release) Date: 20 Feb 2001 13:07:57 -0600 Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 20 Feb 2001 09:41:10 -0700, Russel Ingram wrote: > Does anyone know why the commented lines at the very bottom of this config > make my devfsd puke? Do you get a segfault? Are you using an updated GLIBC 2.2? There's some incompatibility there with the GLOBAL keyword... Hopefully it's fixed in the most recent devfsd, if not, look in Red Hat's bugzilla, there's a patch posted there, I believe. -Eric > #REGISTER scsi/host0/bus0/target0/lun0/cd CFUNCTION GLOBAL symlink $devname cdrom > #UNREGISTER scsi/host0/bus0/target0/lun0/cd CFUNCTION GLOBAL unlink cdrom > #REGISTER misc/psaux CFUNCTION GLOBAL symlink $devname mouse > #UNREGISTER misc/psaux CFUNCTION GLOBAL unlink mouse > #REGISTER v4l/video0 CFUNCTION GLOBAL symlink $devname video > #UNREGISTER v4l/video0 CFUNCTION GLOBAL unlink video From owner-linux-xfs@oss.sgi.com Tue Feb 20 11:33:36 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 11:33:27 -0800 Received: from eagle.oceana.com ([208.17.123.12]:29449 "EHLO eagle.oceana.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 11:33:18 -0800 Received: from ken.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id f1KJXBI12142 for ; Tue, 20 Feb 2001 14:33:11 -0500 Message-ID: <3A92C656.46C5A86F@oceana.com> Date: Tue, 20 Feb 2001 14:32:38 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Problem with SGI XFS for Red Hat 7.0 Installer on SGI 1200 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I am trying to install the XFS pre-release on a stock SGI 1200. Installation goes fine, and on the initial reboot, I receive the following kernel error: VFS: Unable to mount root fs on 08:05 What's the deal with this? The root XFS filesystem IS on sda5. Is this a problem with the initrd image, the kernel, devfs, missing /dev entries? Thanks, Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-linux-xfs@oss.sgi.com Tue Feb 20 12:02:47 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 12:02:37 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:29303 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 12:02:22 -0800 Received: from nodin.corp.sgi.com ([192.26.51.193]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07951 for ; Tue, 20 Feb 2001 12:02:22 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA43303 for ; Tue, 20 Feb 2001 12:01:51 -0800 (PST) Received: from dbear.engr.sgi.com (IDENT:tduffy@dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA47345; Tue, 20 Feb 2001 11:59:17 -0800 (PST) Date: Tue, 20 Feb 2001 11:59:29 -0800 (PST) From: Tom Duffy To: Ken Murchison cc: Subject: Re: Problem with SGI XFS for Red Hat 7.0 Installer on SGI 1200 In-Reply-To: <3A92C656.46C5A86F@oceana.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing this is most likely a problem with the initrd. probably did not complete or that it could not find the appropriate module to use for scsi controller. did you install the latest mkinitrd that we have with mods to work with xfs? -tduffy On Tue, 20 Feb 2001, Ken Murchison wrote: > I am trying to install the XFS pre-release on a stock SGI 1200. > Installation goes fine, and on the initial reboot, I receive the > following kernel error: > > VFS: Unable to mount root fs on 08:05 > > What's the deal with this? The root XFS filesystem IS on sda5. Is this > a problem with the initrd image, the kernel, devfs, missing /dev > entries? > > Thanks, > Ken > From owner-linux-xfs@oss.sgi.com Tue Feb 20 12:07:16 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 12:07:07 -0800 Received: from eagle.oceana.com ([208.17.123.12]:30732 "EHLO eagle.oceana.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 12:07:03 -0800 Received: from ken.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id f1KK6tI13783; Tue, 20 Feb 2001 15:06:55 -0500 Message-ID: <3A92CE3E.95D70C32@oceana.com> Date: Tue, 20 Feb 2001 15:06:22 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Duffy CC: linux-xfs@oss.sgi.com Subject: Re: Problem with SGI XFS for Red Hat 7.0 Installer on SGI 1200 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Tom Duffy wrote: > > this is most likely a problem with the initrd. probably did not complete > or that it could not find the appropriate module to use for scsi > controller. > > did you install the latest mkinitrd that we have with mods to work with > xfs? I don't know. Is this independent of the SGI XFS ISO image? BTW, the /boot partition is also XFS, so how could it access sda1 and not sda5? Thanks, Ken > On Tue, 20 Feb 2001, Ken Murchison wrote: > > > I am trying to install the XFS pre-release on a stock SGI 1200. > > Installation goes fine, and on the initial reboot, I receive the > > following kernel error: > > > > VFS: Unable to mount root fs on 08:05 > > > > What's the deal with this? The root XFS filesystem IS on sda5. Is this > > a problem with the initrd image, the kernel, devfs, missing /dev > > entries? > > > > Thanks, > > Ken > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-linux-xfs@oss.sgi.com Tue Feb 20 12:59:38 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 12:59:29 -0800 Received: from mail15.jump.net ([206.196.91.15]:5559 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 12:59:10 -0800 Received: from Porter (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f1KKx7Q19888; Tue, 20 Feb 2001 14:59:07 -0600 (CST) Message-Id: <200102202059.f1KKx7Q19888@mail15.jump.net> Subject: Re: Problem with SGI XFS for Red Hat 7.0 Installer on SGI 1200 From: Eric Sandeen To: Ken Murchison Cc: Tom Duffy , linux-xfs@oss.sgi.com In-Reply-To: <3A92CE3E.95D70C32@oceana.com> References: <3A92CE3E.95D70C32@oceana.com> Content-Type: text/plain X-Mailer: Evolution (0.8/+cvs.2001.02.15.08.59 - Preview Release) Date: 20 Feb 2001 14:59:41 -0600 Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 20 Feb 2001 15:06:22 -0500, Ken Murchison wrote: > Tom Duffy wrote: > > > > this is most likely a problem with the initrd. probably did not complete > > or that it could not find the appropriate module to use for scsi > > controller. I agree that the initrd is the likely culprit... Have you tried the recovery method on the installer caveats page? (http://216.32.174.192/projects/xfs/installcavs.html) ============== Some systems with particular ide chip sets are known to have problems at install time that prevent the initial ram disk from being generated. The fix for this problem is to reboot the system into rescue mode from the install CD by typing "linux rescue" at the boot prompt, and then executing the following commands. (If your / and /boot are on the same partition, simply ignore the lines pertaining to /boot.) cd /tmp mknod hda b 3 mknod hda b 3 mount -t xfs hda /mnt/A mount -t xfs hda /mnt/A/boot chroot /mnt/A /sbin/mkinitrd /boot/initrd-2.4.0-SGI_XFS_PR.img 2.4.0-SGI_XFS_PR vi /etc/lilo.conf add to the correct kernel entry: initrd=/boot/initrd-2.4.0-SGI_XFS_PR.img /sbin/lilo -v exit (out of chrooted shell) umount /mnt/A/boot umount /mnt/A Reboot the system. From owner-linux-xfs@oss.sgi.com Tue Feb 20 13:06:58 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 13:06:38 -0800 Received: from eagle.oceana.com ([208.17.123.12]:57872 "EHLO eagle.oceana.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 13:06:32 -0800 Received: from ken.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id f1KL6OI18744; Tue, 20 Feb 2001 16:06:24 -0500 Message-ID: <3A92DC2E.FCD45A50@oceana.com> Date: Tue, 20 Feb 2001 16:05:50 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Tom Duffy , linux-xfs@oss.sgi.com Subject: Re: Problem with SGI XFS for Red Hat 7.0 Installer on SGI 1200 References: <3A92CE3E.95D70C32@oceana.com> <200102202059.f1KKx7Q19888@mail15.jump.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Eric Sandeen wrote: > > On 20 Feb 2001 15:06:22 -0500, Ken Murchison wrote: > > > Tom Duffy wrote: > > > > > > > this is most likely a problem with the initrd. probably did not complete > > > or that it could not find the appropriate module to use for scsi > > > controller. > > I agree that the initrd is the likely culprit... > > Have you tried the recovery method on the installer caveats page? > (http://216.32.174.192/projects/xfs/installcavs.html) I saw this, but ignored it since I don't have any IDE drives (other than the cdrom). Should I apply the same technique to make the devices files for my / and /boot? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-linux-xfs@oss.sgi.com Tue Feb 20 13:27:59 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 13:27:40 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47634 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 13:27:20 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA07467 for ; Tue, 20 Feb 2001 13:36:47 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA28639; Tue, 20 Feb 2001 13:21:37 -0800 (PST) Message-ID: <3A92E0A3.8592B42E@sgi.com> Date: Tue, 20 Feb 2001 13:24:51 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: mysterious dbench results References: <96nvna$goj$1@mate.bln.innominate.de> <96ot5r$ev3$1@mate.bln.innominate.de> Content-Type: multipart/mixed; boundary="------------01373F4CDDB45C4CD6DD8C2F" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------01373F4CDDB45C4CD6DD8C2F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Thomas, One reason for these problems could be that XFS pages are not balanced properly in memory. I've been experimenting with attaching buffers to all XFS pages & then let the flush_dirty_buffers methods take care of the write-outs. Attached is an experimental patch that might improve the situation. Please note that this code is work-in-progress so use it only on a test system. Also, can you summarize the machine configs & the number of dbench clients that you used? thanks, ananth. -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- --------------01373F4CDDB45C4CD6DD8C2F Content-Type: text/plain; charset=us-ascii; name="delay-buffer-2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="delay-buffer-2.patch" diff -Naur ../../xfs-orig/linux/drivers/block/ll_rw_blk.c drivers/block/ll_rw_blk.c --- ../../xfs-orig/linux/drivers/block/ll_rw_blk.c Mon Feb 12 14:20:41 2001 +++ drivers/block/ll_rw_blk.c Sat Feb 17 08:35:52 2001 @@ -806,7 +806,7 @@ blkdev_release_request(next); } -static inline void attempt_back_merge(request_queue_t * q, +static void attempt_back_merge(request_queue_t * q, struct request *req, int max_sectors, int max_segments) @@ -816,7 +816,7 @@ attempt_merge(q, req, max_sectors, max_segments); } -static inline void attempt_front_merge(request_queue_t * q, +static void attempt_front_merge(request_queue_t * q, struct list_head * head, struct request *req, int max_sectors, @@ -888,6 +888,23 @@ } +#ifdef REQ_DEBUG +#define CHECK_REQ(req, i) \ + do { \ + if ((req->bh == req->bhtail && req->bh->b_reqnext) || \ + (req->bh != req->bhtail && !req->bh->b_reqnext)) \ + req_foo(req, el_ret, 1); \ + } while (0); + +void +req_foo(struct request *req, int el_ret, int i) +{ + printk("reqest 0x%p inconsistent (elret %d i %d)\n", req, el_ret, i); +} +#else +#define CHECK_REQ(a, b) +#endif + static int __make_request(request_queue_t * q, int rw, struct buffer_head * bh, struct kiobuf * kiobuf, kdev_t dev, unsigned int sector, unsigned int count) @@ -960,22 +977,30 @@ switch (el_ret) { case ELEVATOR_BACK_MERGE: + CHECK_REQ(req, 1); if (!q->back_merge_fn(q, req, bh, max_segments)) break; + CHECK_REQ(req, 2); elevator->elevator_merge_cleanup_fn(q, req, count); + CHECK_REQ(req, 3); req->bhtail->b_reqnext = bh; req->bhtail = bh; req->nr_sectors = req->hard_nr_sectors += count; blk_started_io(count); drive_stat_acct(req->rq_dev, req->cmd, count, 0); req_new_io(req, 1, count); + CHECK_REQ(req, 4); attempt_back_merge(q, req, max_sectors, max_segments); + CHECK_REQ(req, 5); goto out; case ELEVATOR_FRONT_MERGE: + CHECK_REQ(req, 6); if (!q->front_merge_fn(q, req, bh, max_segments)) break; + CHECK_REQ(req, 7); elevator->elevator_merge_cleanup_fn(q, req, count); + CHECK_REQ(req, 8); bh->b_reqnext = req->bh; req->bh = bh; req->buffer = bh->b_data; @@ -986,7 +1011,9 @@ blk_started_io(count); drive_stat_acct(req->rq_dev, req->cmd, count, 0); req_new_io(req, 1, count); + CHECK_REQ(req, 9); attempt_front_merge(q, head, req, max_sectors, max_segments); + CHECK_REQ(req, 10); goto out; /* @@ -1043,7 +1070,9 @@ req_new_io(req, 0, count); blk_started_io(count); add_request(q, req, insert_here); + CHECK_REQ(req, 11); out: + CHECK_REQ(req, 12); if (freereq) blkdev_release_request(freereq); if (!q->plugged) @@ -1255,6 +1284,9 @@ if (!nr) return; + + if (test_bit(BH_Delay, &bhs[0]->b_state) || bhs[0]->b_blocknr < 0) + BUG(); major = MAJOR(bhs[0]->b_dev); diff -Naur ../../xfs-orig/linux/drivers/scsi/scsi_merge.c drivers/scsi/scsi_merge.c --- ../../xfs-orig/linux/drivers/scsi/scsi_merge.c Mon Feb 12 14:20:43 2001 +++ drivers/scsi/scsi_merge.c Sat Feb 17 08:36:46 2001 @@ -92,7 +92,7 @@ printk("counted segments is %x\n", segments); printk("Flags %d %d\n", use_clustering, dma_host); if (req->bh != NULL) { - for (bh = req->bh; bh->b_reqnext != NULL; bh = bh->b_reqnext) { + for (bh = req->bh; bh != NULL; bh = bh->b_reqnext) { printk("Segment 0x%p, blocks %d, addr 0x%lx\n", bh, bh->b_size >> 9, diff -Naur ../../xfs-orig/linux/fs/buffer.c fs/buffer.c --- ../../xfs-orig/linux/fs/buffer.c Mon Feb 12 14:21:30 2001 +++ fs/buffer.c Sat Feb 17 08:33:56 2001 @@ -161,6 +161,31 @@ atomic_dec(&bh->b_count); } +#define buffer_delay_busy(bh) \ + (test_bit(BH_Delay, &bh->b_state) && bh->b_page && PageLocked(bh->b_page)) + +void +write_buffer(struct buffer_head *bh) +{ + struct page *page; + + if ((page = bh->b_page) != 0 && DelallocPage(page)) { + if (TryLockPage(page)) + return; + if (!buffer_dirty(bh)) { + if (DelallocPage(page)) + BUG(); + UnlockPage(page); + return; + } + page->mapping->a_ops->writepage(page); + if (DelallocPage(page)) + BUG(); + } else + ll_rw_block(WRITE, 1, &bh); +} + + /* Call sync_buffers with wait!=0 to ensure that the call does not * return until all buffer writes have completed. Sync() may return * before the writes have finished; fsync() may not. @@ -232,7 +257,7 @@ atomic_inc(&bh->b_count); spin_unlock(&lru_list_lock); - ll_rw_block(WRITE, 1, &bh); + write_buffer(bh); atomic_dec(&bh->b_count); retry = 1; goto repeat; @@ -507,6 +532,8 @@ struct bh_free_head *head = &free_list[BUFSIZE_INDEX(bh->b_size)]; struct buffer_head **bhp = &head->list; + if (test_bit(BH_Delay, &bh->b_state)) + BUG(); bh->b_state = 0; spin_lock(&head->lock); @@ -879,7 +906,7 @@ if (buffer_dirty(bh)) { atomic_inc(&bh->b_count); spin_unlock(&lru_list_lock); - ll_rw_block(WRITE, 1, &bh); + write_buffer(bh); brelse(bh); spin_lock(&lru_list_lock); } @@ -1103,6 +1130,7 @@ } } + /* * A buffer may need to be moved from one buffer list to another * (e.g. in case it is not shared any more). Handle this. @@ -1121,6 +1149,8 @@ bh->b_list = dispose; if (dispose == BUF_CLEAN) remove_inode_queue(bh); + if (dispose == BUF_DIRTY && bh->b_blocknr == -6) + BUG(); __insert_into_lru_list(bh, dispose); } } @@ -1395,8 +1425,18 @@ head = page->buffers; bh = head; + if (DelallocPage(page)) { + page->mapping->a_ops->writepage(page); + lock_page(page); // XXX + if (bh != page->buffers) { + printk("Page 0x%p buffers bh 0x%p changed to 0x%p\n", + page, bh, page->buffers); + return 1; + } + } if (DelallocPage(page)) BUG(); + do { unsigned int next_off = curr_off + bh->b_size; next = bh->b_this_page; @@ -2381,7 +2421,7 @@ if (wait > 1) __wait_on_buffer(p); } else if (buffer_dirty(p)) - ll_rw_block(WRITE, 1, &p); + write_buffer(p); } while (tmp != bh); } @@ -2408,6 +2448,18 @@ int index = BUFSIZE_INDEX(bh->b_size); int loop = 0; + if (DelallocPage(page)) { + page->mapping->a_ops->writepage(page); + lock_page(page); // XXX + if (bh != page->buffers) { + printk("Page 0x%p buffers bh 0x%p changed to 0x%p\n", + page, bh, page->buffers); + return 1; + } + } + if (DelallocPage(page)) + BUG(); + cleaned_buffers_try_again: spin_lock(&lru_list_lock); write_lock(&hash_table_lock); @@ -2609,7 +2661,7 @@ __refile_buffer(bh); continue; } - if (buffer_locked(bh)) + if (buffer_locked(bh) || buffer_delay_busy(bh)) continue; if (check_flushtime) { @@ -2627,7 +2679,8 @@ /* OK, now we are committed to write it out. */ atomic_inc(&bh->b_count); spin_unlock(&lru_list_lock); - ll_rw_block(WRITE, 1, &bh); + + write_buffer(bh); atomic_dec(&bh->b_count); if (current->need_resched) diff -Naur ../../xfs-orig/linux/fs/pagebuf/page_buf.c fs/pagebuf/page_buf.c --- ../../xfs-orig/linux/fs/pagebuf/page_buf.c Sat Feb 17 18:31:59 2001 +++ fs/pagebuf/page_buf.c Fri Feb 16 19:02:40 2001 @@ -1314,7 +1314,7 @@ struct buffer_head *bh; off_t blk_offset; size_t blk_length; - int err=0; + int err=0, retry = 0; int concat_ok = ((MAJOR(dev) != LVM_BLK_MAJOR) && (MAJOR(dev) != MD_MAJOR)); /* Calculate the block offsets and length we will be using */ @@ -1340,12 +1340,17 @@ * Call generic_make_request */ +retry_alloc: psync = (pagesync_t *) kmalloc(sizeof(pagesync_t) + - blk_length * sizeof(struct buffer_head *), GFP_BUFFER); + blk_length * sizeof(struct buffer_head *), GFP_ATOMIC); /* Ugh - out of memory condition here */ - if (psync == NULL) - BUG(); + if (psync == NULL) { + if (retry++ < 16) + goto retry_alloc; + else + BUG(); + } psync->pb = pb; psync->count = blk_length; @@ -2120,6 +2125,7 @@ spin_unlock_irqrestore(¤t->sigmask_lock, flags); strcpy(current->comm, "pagebuf_daemon"); + current->flags |= PF_MEMALLOC; do { if (pb_daemon->active == 1) { diff -Naur ../../xfs-orig/linux/fs/pagebuf/page_buf_io.c fs/pagebuf/page_buf_io.c --- ../../xfs-orig/linux/fs/pagebuf/page_buf_io.c Sat Feb 17 18:31:59 2001 +++ fs/pagebuf/page_buf_io.c Fri Feb 16 19:06:56 2001 @@ -101,7 +101,6 @@ /* * Globals */ -static int pcd_active; int PB_MAX_DIRTY_FACTOR = 4; static DECLARE_WAIT_QUEUE_HEAD(pcd_waitq); @@ -163,13 +162,29 @@ __pb_block_commit_write_async(inode, page, mp, 0); } -static inline void -_unmark_delalloc(struct page *page) +static void +_unmark_delalloc(struct page *page, int toss) { + struct buffer_head *bh = page->buffers; + if (!PageLocked(page)) PAGE_BUG(page); - if (test_and_clear_bit(PG_delalloc, &page->flags)) - atomic_dec(&pb_delalloc_pages); + if (!DelallocPage(page)) + PAGE_BUG(page); + if (!bh) + BUG(); + clear_bit(BH_Delay, &bh->b_state); + atomic_dec(&pb_delalloc_pages); + if (!toss && bh->b_blocknr == -8) + printk("warning: unmarking unmapped buffer page 0x%p\n", page); + if (toss && bh->b_blocknr == -8) { + if (!buffer_dirty(bh)) + BUG(); + bh->b_blocknr = -6; + mark_buffer_clean(bh); + if (bh->b_list != BUF_CLEAN) + printk("buffer bh 0x%p not clean\n", bh); + } } /* @@ -528,27 +543,19 @@ return (-ENOMEM); } assert(((csize + cpoff) <= PAGE_CACHE_SIZE)); + lock_page(page); memset((void *) (kmap(page) + cpoff), 0, csize); kunmap(page); SetPageUptodate(page); if (pb->pb_bn == PAGE_BUF_DADDR_NULL) { - if (test_and_set_bit(PG_delalloc, &page->flags) == 0) { - atomic_inc(&pb_delalloc_pages); - } + __pb_block_commit_write_async(pb->pb_target, page, NULL, 0); } + UnlockPage(page); } pb->pb_flags &= ~(PBF_READ | PBF_WRITE); pb->pb_flags &= ~(_PBF_SOME_INVALID_PAGES | PBF_PARTIAL | PBF_NONE); - if (!pcd_active && (pb->pb_bn == PAGE_BUF_DADDR_NULL)) { - unsigned int np = atomic_read(&pb_delalloc_pages); - - if (np > pb_params.p_un.max_dirty_pages) - wake_up_interruptible(&pcd_waitq); - } - - return (0); } @@ -1016,15 +1023,13 @@ PAGE_CACHE_SIZE, &map, 1, &nmaps, PBF_READ); - hook_buffers_to_page(inode, page, &map, PAGE_CACHE_SHIFT); - bh = page->buffers; if (map.pbm_bn > 0) { + hook_buffers_to_page(inode, page, &map, PAGE_CACHE_SHIFT); bh = head = page->buffers; } else if (map.pbm_flags & (PBMF_HOLE|PBMF_DELAY)) { memset(kmap(page), 0, PAGE_CACHE_SIZE); flush_dcache_page(page); kunmap(page); - set_bit(BH_Uptodate, &bh->b_state); goto page_done; } else { printk("pagebuf_read_full_page: page 0x%p map 0x%p\n", @@ -1096,6 +1101,8 @@ count = pagebuf_delalloc_convert(page, pb_flags, cpages); do_write_pages += count; + if (DelallocPage(page)) + BUG(); if (cpages) kfree(cpages); @@ -1119,10 +1126,11 @@ return __pagebuf_write_full_page(inode, page); /* things got complicated... */ - offset = inode->i_size & PAGE_CACHE_MASK_LL; + offset = inode->i_size & (~PAGE_CACHE_MASK_LL); /* OK, are we completely out? */ if ((page->index >= end_index+1) || !offset) { UnlockPage(page); + printk("Bad write on page 0x%p\n", page); return -EIO; } @@ -1139,6 +1147,8 @@ __pb_block_commit_write_async(inode, page, NULL, 0); } + if (DelallocPage(page)) + BUG(); kunmap(page); UnlockPage(page); return err; @@ -1146,12 +1156,33 @@ STATIC void +hook_buffers_to_page_delay(struct inode *inode, struct page *page) +{ + struct buffer_head *bh; + + if (page->buffers) + BUG(); + create_empty_buffers(page, inode->i_dev, PAGE_CACHE_SIZE); + bh = page->buffers; + bh->b_state = (1 << BH_Delay); + atomic_inc(&pb_delalloc_pages); + bh->b_blocknr = -8; + __mark_buffer_dirty(bh); + balance_dirty(bh->b_dev); +} + +STATIC void hook_buffers_to_page(struct inode *inode, struct page *page, page_buf_bmap_t *mp, ulong bshift) { struct buffer_head *bh; page_buf_daddr_t bn; + if (mp->pbm_bn < 0) { + printk("hook_buffers_to_page: bad bn page 0x%p mp 0x%p\n", + page, mp); + BUG(); + } if (!page->buffers) create_empty_buffers(page, inode->i_dev, PAGE_CACHE_SIZE); @@ -1160,21 +1191,13 @@ bh->b_end_io = end_pb_buffer_io_async; bh->b_private = (void *) 0; - if (mp->pbm_flags & (PBMF_HOLE|PBMF_DELAY)) { - bh->b_blocknr = 0; - bh->b_state = (1 << BH_Req) | (1 << BH_End_io); - return; - } - if (mp->pbm_bn < 0) { - printk("hook_buffers_to_page: bad bn page 0x%p mp 0x%p\n", - page, mp); - BUG(); - } bn = mp->pbm_bn >> (bshift - inode->i_sb->s_blocksize_bits); bn += (mp->pbm_delta >> bshift); bh->b_blocknr = bn; - bh->b_state = (1 << BH_Mapped) | (1 << BH_Req) | (1 << BH_End_io); + if (buffer_locked(bh) || buffer_req(bh)) + BUG(); + bh->b_state |= (1 << BH_Mapped) | (1 << BH_Req) | (1 << BH_End_io); } @@ -1190,6 +1213,7 @@ set_bit(BH_Uptodate, &bh->b_state); if (!buffer_dirty(bh)) { bh->b_end_io = end_pb_buffer_io_async; + bh->b_state |= (1 << BH_End_io); need_balance_dirty = 1; } __mark_buffer_dirty(bh); @@ -1205,7 +1229,7 @@ { struct buffer_head *bh; int err = 0; - int nmaps; + int nmaps, dp = DelallocPage(page); char *kaddr = kmap(page); page_buf_bmap_t map; @@ -1218,7 +1242,8 @@ * go get some space. */ bh = page->buffers; - if ((!bh || !buffer_mapped(bh)) && !DelallocPage(page)) { + if ((!bh || !buffer_mapped(bh)) && (!dp || (flags & PBF_FILE_ALLOCATE))) + { if (!mp) { mp = ↦ err = inode->i_op->pagebuf_bmap(inode, @@ -1233,6 +1258,8 @@ } if (mp->pbm_bn > 0) { hook_buffers_to_page(inode, page, mp, PAGE_CACHE_SHIFT); + if (dp) + _unmark_delalloc(page, 0); bh = page->buffers; } } @@ -1247,7 +1274,7 @@ /* * Partial write. Is the page valid anyway? */ - if (Page_Uptodate(page) || DelallocPage(page)) { + if (Page_Uptodate(page) || dp) { goto out; } /* @@ -1348,7 +1375,6 @@ int partial) { struct buffer_head *bh; - unsigned int np; /* * Prepare write took care of reading/zero-out @@ -1358,15 +1384,8 @@ SetPageUptodate(page); if ((bh = page->buffers) && buffer_mapped(bh)) { set_buffer_dirty_uptodate(page->buffers, partial); - } else if (test_and_set_bit(PG_delalloc, &page->flags) == 0) { - atomic_inc(&pb_delalloc_pages); - if (!pcd_active) { - np = atomic_read(&pb_delalloc_pages); - if (np > pb_params.p_un.max_dirty_pages) - wake_up_interruptible(&pcd_waitq); - } - if (!partial) - balance_dirty(inode->i_rdev); + } else if (!DelallocPage(page)) { + hook_buffers_to_page_delay(inode, page); } /* Advance though extent no matter what */ @@ -1737,21 +1756,11 @@ page_cache_release(page); return NULL; } - /* In the case where we probe a page - push it back down the LRU - * so we do not hit it on the next pass. - */ - - spin_lock(&pagemap_lru_lock); - if (PageInactiveDirty(page)) { - list_del(&page->lru); - list_add(&page->lru, &inactive_dirty_list); - } - spin_unlock(&pagemap_lru_lock); - _unmark_delalloc(page); return page; } +#if 0 /* * Convert & write out a cluster of pages in the same extent as defined * by mp and surrounding "startpage". startpage is locked & has an extra @@ -1822,16 +1831,35 @@ return count; } +#endif + /* * Allocate & map buffers for page given the extent map. */ STATIC void convert_page(struct inode *inode, struct page *page, page_buf_bmap_t *mp) { - mp->pbm_delta = (page->index << PAGE_CACHE_SHIFT) - mp->pbm_offset; - hook_buffers_to_page(inode, page, mp, PAGE_CACHE_SHIFT); - set_buffer_dirty_uptodate(page->buffers, 0); + struct buffer_head *bh = page->buffers; + int dp = DelallocPage(page); + + if (!bh || dp) { + mp->pbm_delta = (page->index << PAGE_CACHE_SHIFT) - mp->pbm_offset; + hook_buffers_to_page(inode, page, mp, PAGE_CACHE_SHIFT); + if (dp) + _unmark_delalloc(page, 0); + } + bh = page->buffers; + /* + * 1 == don't balance dirty, we are doing I/O just below here. + * otherwise causes nasty recursions. + */ + set_buffer_dirty_uptodate(bh, 1); UnlockPage(page); + + atomic_inc(&bh->b_count); + ll_rw_block(WRITE, 1, &bh); + atomic_dec(&bh->b_count); + page_cache_release(page); } @@ -1879,7 +1907,7 @@ if (!PageLocked(page)) BUG(); - _unmark_delalloc(page); + _unmark_delalloc(page, 1); } @@ -1891,7 +1919,7 @@ { page_buf_bmap_t maps[PBF_MAX_MAPS]; struct inode *inode; - int maps_returned, error, count; + int maps_returned, error; u_long pb_flags; loff_t rounded_offset; @@ -1901,7 +1929,8 @@ * anything. */ if (!inode->i_nlink && (inode->i_state & I_FREEING)) { - _unmark_delalloc(page); + BUG(); + _unmark_delalloc(page, 1); UnlockPage(page); return 0; } @@ -1941,18 +1970,12 @@ } page_cache_get(page); - _unmark_delalloc(page); /* * page needs to be setup as though find_page(...) returned it, * which is a locked page with an extra reference. */ - if (cpages) { - count = kio_cluster_write(inode, page, &maps[0], cpages); - } else { - cluster_write(inode, page, &maps[0]); - count = 1; - } - return count; + cluster_write(inode, page, &maps[0]); + return 1; } /* @@ -2002,6 +2025,7 @@ STATIC int page_cleaner_daemon(void *data) { +#if 0 struct page *page; u_long flags; struct buffer_head *bh; @@ -2072,7 +2096,7 @@ */ spin_unlock(&pagemap_lru_lock); - _unmark_delalloc(page); + _unmark_delalloc(page, 0); set_buffer_dirty_uptodate(bh, 0); UnlockPage(page); spin_lock(&pagemap_lru_lock); @@ -2123,6 +2147,7 @@ pcd_active = 1; } kfree(cpages); +#endif return 0; } diff -Naur ../../xfs-orig/linux/fs/xfs/xfs_log.c fs/xfs/xfs_log.c --- ../../xfs-orig/linux/fs/xfs/xfs_log.c Tue Jan 9 18:20:23 2001 +++ fs/xfs/xfs_log.c Fri Feb 16 16:58:54 2001 @@ -1342,6 +1342,7 @@ uint count; /* byte count of bwrite */ int split = 0; /* split write into two regions */ int error; + unsigned long save_flags = current->flags; XFS_STATS_INC(xs_log_writes); ASSERT(iclog->ic_refcnt == 0); @@ -1351,6 +1352,8 @@ xlog_panic("xlog_sync: illegal flag"); #endif + current->flags |= PF_MEMALLOC; + xlog_pack_data(log, iclog); /* put cycle number in every block */ INT_SET(iclog->ic_header.h_len, ARCH_CONVERT, iclog->ic_offset); /* real byte length */ @@ -1409,6 +1412,7 @@ if (error = XFS_bwrite(bp)) { xfs_ioerror_alert("xlog_sync", log->l_mp, XFS_BUF_TARGET(bp), XFS_BUF_ADDR(bp)); + current->flags = save_flags; return (error); } if (split) { @@ -1445,9 +1449,11 @@ if (error = XFS_bwrite(bp)) { xfs_ioerror_alert("xlog_sync (split)", log->l_mp, XFS_BUF_TARGET(bp), XFS_BUF_ADDR(bp)); + current->flags = save_flags; return (error); } } + current->flags = save_flags; return (0); } /* xlog_sync */ diff -Naur ../../xfs-orig/linux/include/linux/fs.h include/linux/fs.h --- ../../xfs-orig/linux/include/linux/fs.h Mon Feb 12 14:21:30 2001 +++ include/linux/fs.h Mon Feb 12 17:38:59 2001 @@ -212,6 +212,8 @@ #define BH_New 5 /* 1 if the buffer is new and not yet written out */ #define BH_Protected 6 /* 1 if the buffer is protected */ #define BH_End_io 7 /* 1 End io function defined don't remap it */ +#define BH_Delay 8 /* disk mapping is delayed */ + /* * Try to keep the most commonly used fields in single cache lines (16 diff -Naur ../../xfs-orig/linux/include/linux/mm.h include/linux/mm.h --- ../../xfs-orig/linux/include/linux/mm.h Sat Feb 17 18:31:59 2001 +++ include/linux/mm.h Fri Feb 16 19:01:31 2001 @@ -182,7 +182,7 @@ #define PageLocked(page) test_bit(PG_locked, &(page)->flags) #define LockPage(page) set_bit(PG_locked, &(page)->flags) #define TryLockPage(page) test_and_set_bit(PG_locked, &(page)->flags) -#define DelallocPage(page) test_bit(PG_delalloc, &(page)->flags) +#define DelallocPage(page) (page->buffers && test_bit(BH_Delay, &(page)->buffers->b_state)) extern void __set_page_dirty(struct page *); diff -Naur ../../xfs-orig/linux/kdb/modules/kdbm_pg.c kdb/modules/kdbm_pg.c --- ../../xfs-orig/linux/kdb/modules/kdbm_pg.c Sat Feb 17 18:31:59 2001 +++ kdb/modules/kdbm_pg.c Fri Feb 16 19:01:31 2001 @@ -28,7 +28,7 @@ static char *bh_state_vals[] = { "Uptodate", "Dirty", "Lock", "Req", "Mapped", "New", - "Protected", NULL }; + "Protected", "End_io", "Delay", NULL }; static char *map_flags(unsigned long flags, char *mapping[]) { @@ -88,9 +88,9 @@ kdb_printf(" next 0x%p bno %ld rsec %ld size %d dev 0x%x rdev 0x%x\n", bh.b_next, bh.b_blocknr, bh.b_rsector, bh.b_size, bh.b_dev, bh.b_rdev); - kdb_printf(" count %d state 0x%lx [%s] ftime 0x%lx\n", + kdb_printf(" count %d state 0x%lx [%s] ftime 0x%lx b_list %d b_reqnext 0x%p b_data 0x%p\n", bh.b_count.counter, bh.b_state, map_flags(bh.b_state, bh_state_vals), - bh.b_flushtime); + bh.b_flushtime, bh.b_list, bh.b_reqnext, bh.b_data); kdb_printf(" b_page 0x%p b_this_page 0x%p b_private 0x%p\n", bh.b_page, bh.b_this_page, bh.b_private); diff -Naur ../../xfs-orig/linux/mm/swap.c mm/swap.c --- ../../xfs-orig/linux/mm/swap.c Mon Feb 12 14:20:46 2001 +++ mm/swap.c Tue Feb 13 11:55:49 2001 @@ -255,7 +255,7 @@ } else if (PageInactiveClean(page)) { del_page_from_inactive_clean_list(page); } else { - printk("VM: __lru_cache_del, found unknown page ?!\n"); + printk("VM: __lru_cache_del, found unknown page 0x%p?!\n", page); } DEBUG_ADD_PAGE } diff -Naur ../../xfs-orig/linux/mm/vmscan.c mm/vmscan.c --- ../../xfs-orig/linux/mm/vmscan.c Mon Feb 12 14:20:46 2001 +++ mm/vmscan.c Sat Feb 10 08:56:13 2001 @@ -364,10 +364,8 @@ continue; } if (DelallocPage(page)) { - del_page_from_inactive_clean_list(page); - add_page_to_inactive_dirty_list(page); - UnlockPage(page); - continue; + printk("delalloc page 0x%p in clean list\n", page); + BUG(); } /* OK, remove the page from the caches. */ @@ -481,7 +479,7 @@ * Dirty swap-cache page or delayed allocate page? * Write it out if last copy.. */ - if (PageDirty(page) || DelallocPage(page)) { + if (PageDirty(page)) { int (*writepage)(struct page *) = page->mapping->a_ops->writepage; if (!writepage) --------------01373F4CDDB45C4CD6DD8C2F-- From owner-linux-xfs@oss.sgi.com Tue Feb 20 13:54:18 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 13:54:09 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:61729 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 13:53:47 -0800 Received: from nodin.corp.sgi.com ([192.26.51.193]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA02282 for ; Tue, 20 Feb 2001 13:53:46 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA63925 for ; Tue, 20 Feb 2001 13:53:11 -0800 (PST) Received: from dbear.engr.sgi.com (IDENT:tduffy@dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA80736; Tue, 20 Feb 2001 13:51:54 -0800 (PST) Date: Tue, 20 Feb 2001 13:52:05 -0800 (PST) From: Tom Duffy To: Ken Murchison cc: Subject: Re: Problem with SGI XFS for Red Hat 7.0 Installer on SGI 1200 In-Reply-To: <3A92DC2E.FCD45A50@oceana.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > I saw this, but ignored it since I don't have any IDE drives (other than > the cdrom). Should I apply the same technique to make the devices files > for my / and /boot? you should not ignore this because it does not matter if you have ide hard drives or not...if you have a particular chipset, it will not create the initrd properly, scsi root or ide root. -tduffy From owner-linux-xfs@oss.sgi.com Tue Feb 20 14:00:29 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 14:00:19 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:18436 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 14:00:04 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.22 #4) id 14VKos-0004MK-00; Tue, 20 Feb 2001 22:59:38 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14VKol-00006z-00; Tue, 20 Feb 2001 22:59:31 +0100 Date: Tue, 20 Feb 2001 22:59:31 +0100 From: Jens Axboe To: Rajagopal Ananthanarayanan Cc: Thomas Graichen , linux-xfs@oss.sgi.com Subject: Re: mysterious dbench results Message-ID: <20010220225931.B32634@suse.de> References: <96nvna$goj$1@mate.bln.innominate.de> <96ot5r$ev3$1@mate.bln.innominate.de> <3A92E0A3.8592B42E@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A92E0A3.8592B42E@sgi.com>; from ananth@sgi.com on Tue, Feb 20, 2001 at 01:24:51PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Feb 20 2001, Rajagopal Ananthanarayanan wrote: > One reason for these problems could be that > XFS pages are not balanced properly in memory. > I've been experimenting with attaching buffers > to all XFS pages & then let the flush_dirty_buffers > methods take care of the write-outs. Attached is > an experimental patch that might improve the situation. > Please note that this code is work-in-progress so use > it only on a test system. Another reason could be that because xfs ships kio writes, the elevator is effectively a noop. You don't do the merge check of course, but then the insertion scan is also skipped. So xfs ends up being a fifo request queueing. > +#ifdef REQ_DEBUG > +#define CHECK_REQ(req, i) \ > + do { \ > + if ((req->bh == req->bhtail && req->bh->b_reqnext) || \ > + (req->bh != req->bhtail && !req->bh->b_reqnext)) \ > + req_foo(req, el_ret, 1); \ > + } while (0); > + > +void > +req_foo(struct request *req, int el_ret, int i) > +{ > + printk("reqest 0x%p inconsistent (elret %d i %d)\n", req, el_ret, i); > +} To be honest, this looks very worthless. If we get the above wrong, the machine will very quickly corrupt data and go down. end_that_request_first would also complain about destroyed buffer list, which is enough of a checkup. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Tue Feb 20 14:01:18 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 14:00:58 -0800 Received: from eagle.oceana.com ([208.17.123.12]:28933 "EHLO eagle.oceana.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 14:00:49 -0800 Received: from ken.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id f1KM0LI23621; Tue, 20 Feb 2001 17:00:21 -0500 Message-ID: <3A92E8D3.92F809EF@oceana.com> Date: Tue, 20 Feb 2001 16:59:47 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Duffy CC: linux-xfs@oss.sgi.com Subject: Re: Problem with SGI XFS for Red Hat 7.0 Installer on SGI 1200 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Tom Duffy wrote: > > > I saw this, but ignored it since I don't have any IDE drives (other than > > the cdrom). Should I apply the same technique to make the devices files > > for my / and /boot? > > you should not ignore this because it does not matter if you have ide hard > drives or not...if you have a particular chipset, it will not create the > initrd properly, scsi root or ide root. Yup. I just figured this out. I used the instructions in the installtion caveats to mount up / and /boot (by creating sda1 and sda5 block devs with major #8) and do a mkinitrd. I am now able to boot my machine, but I can't access my CDROM because there are no 'sdc' devices. Is this fixed by using the 'modules.devfs' file? Thanks, Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-linux-xfs@oss.sgi.com Tue Feb 20 16:31:39 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 16:31:20 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:3432 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 16:31:05 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA10924 for ; Tue, 20 Feb 2001 16:30:01 -0800 (PST) mail_from (chait@getafix.engr.sgi.com) Received: from getafix.engr.sgi.com (IDENT:root@getafix.engr.sgi.com [163.154.5.110]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id QAA65305; Tue, 20 Feb 2001 16:29:47 -0800 (PST) Received: from localhost (chait@localhost) by getafix.engr.sgi.com (8.9.3/8.9.3) with ESMTP id QAA06687; Tue, 20 Feb 2001 16:26:09 -0500 Date: Tue, 20 Feb 2001 16:26:09 -0500 (EST) From: Chaitanya Tumuluri To: Jens Axboe cc: Thomas Graichen , Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: mysterious dbench results] In-Reply-To: <3A9308B8.34D66FB3@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1700565499-1359072450-982704369=:6587" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1700565499-1359072450-982704369=:6587 Content-Type: TEXT/PLAIN; charset=US-ASCII > On Tue, Feb 20 2001, Rajagopal Ananthanarayanan wrote: > > One reason for these problems could be that > > XFS pages are not balanced properly in memory. > > I've been experimenting with attaching buffers > > to all XFS pages & then let the flush_dirty_buffers > > methods take care of the write-outs. Attached is > > an experimental patch that might improve the situation. > > Please note that this code is work-in-progress so use > > it only on a test system. > > Another reason could be that because xfs ships kio writes, > the elevator is effectively a noop. You don't do the merge > check of course, but then the insertion scan is also skipped. > So xfs ends up being a fifo request queueing. True. So, how about trying out the following patch which is a first cut at inserting the kiobuf requests in LBA-ordered fashion in the elevator? At the very least, it reduces the seek times which might've been affecting kiobuf I/O performance adversely. Cheers, -Chait. ---1700565499-1359072450-982704369=:6587 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="kiobuf_elev.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="kiobuf_elev.patch" LS0tIHhmc3Rlc3QvbGludXgvaW5jbHVkZS9saW51eC9lbGV2YXRvci5oCVdl ZCBGZWIgMTQgMTY6NTU6NTUgMjAwMQ0KKysrIDIuNHhmcy1wdXJlL2xpbnV4 L2luY2x1ZGUvbGludXgvZWxldmF0b3IuaAlUdWUgRmViICA2IDE5OjMyOjU2 IDIwMDENCkBAIC04LDcgKzgsOCBAQA0KIAkJCSAgICBzdHJ1Y3QgbGlzdF9o ZWFkICosIGludCk7DQogDQogdHlwZWRlZiBpbnQgKGVsZXZhdG9yX21lcmdl X2ZuKSAocmVxdWVzdF9xdWV1ZV90ICosIHN0cnVjdCByZXF1ZXN0ICoqLCBz dHJ1Y3QgbGlzdF9oZWFkICosDQotCQkJCSBzdHJ1Y3QgYnVmZmVyX2hlYWQg KiwgaW50LCBpbnQsIGludCk7DQorCQkJCSBzdHJ1Y3QgYnVmZmVyX2hlYWQg KiwgaW50LCBpbnQsIGludCwgc3RydWN0IGtpb2J1ZiAqLA0KKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGtkZXZfdCwgdW5zaWduZWQgaW50 KTsNCiANCiB0eXBlZGVmIHZvaWQgKGVsZXZhdG9yX21lcmdlX2NsZWFudXBf Zm4pIChyZXF1ZXN0X3F1ZXVlX3QgKiwgc3RydWN0IHJlcXVlc3QgKiwgaW50 KTsNCiANCkBAIC0yNiwxMSArMjcsMTEgQEANCiAJdW5zaWduZWQgaW50IHF1 ZXVlX0lEOw0KIH07DQogDQotaW50IGVsZXZhdG9yX25vb3BfbWVyZ2UocmVx dWVzdF9xdWV1ZV90ICosIHN0cnVjdCByZXF1ZXN0ICoqLCBzdHJ1Y3QgbGlz dF9oZWFkICosIHN0cnVjdCBidWZmZXJfaGVhZCAqLCBpbnQsIGludCwgaW50 KTsNCitpbnQgZWxldmF0b3Jfbm9vcF9tZXJnZShyZXF1ZXN0X3F1ZXVlX3Qg Kiwgc3RydWN0IHJlcXVlc3QgKiosIHN0cnVjdCBsaXN0X2hlYWQgKiwgc3Ry dWN0IGJ1ZmZlcl9oZWFkICosIGludCwgaW50LCBpbnQsIHN0cnVjdCBraW9i dWYgKiwga2Rldl90LCB1bnNpZ25lZCBpbnQpOw0KIHZvaWQgZWxldmF0b3Jf bm9vcF9tZXJnZV9jbGVhbnVwKHJlcXVlc3RfcXVldWVfdCAqLCBzdHJ1Y3Qg cmVxdWVzdCAqLCBpbnQpOw0KIHZvaWQgZWxldmF0b3Jfbm9vcF9tZXJnZV9y ZXEoc3RydWN0IHJlcXVlc3QgKiwgc3RydWN0IHJlcXVlc3QgKik7DQogDQot aW50IGVsZXZhdG9yX2xpbnVzX21lcmdlKHJlcXVlc3RfcXVldWVfdCAqLCBz dHJ1Y3QgcmVxdWVzdCAqKiwgc3RydWN0IGxpc3RfaGVhZCAqLCBzdHJ1Y3Qg YnVmZmVyX2hlYWQgKiwgaW50LCBpbnQsIGludCk7DQoraW50IGVsZXZhdG9y X2xpbnVzX21lcmdlKHJlcXVlc3RfcXVldWVfdCAqLCBzdHJ1Y3QgcmVxdWVz dCAqKiwgc3RydWN0IGxpc3RfaGVhZCAqLCBzdHJ1Y3QgYnVmZmVyX2hlYWQg KiwgaW50LCBpbnQsIGludCwgc3RydWN0IGtpb2J1ZiAqLCBrZGV2X3QsIHVu c2lnbmVkIGludCk7DQogdm9pZCBlbGV2YXRvcl9saW51c19tZXJnZV9jbGVh bnVwKHJlcXVlc3RfcXVldWVfdCAqLCBzdHJ1Y3QgcmVxdWVzdCAqLCBpbnQp Ow0KIHZvaWQgZWxldmF0b3JfbGludXNfbWVyZ2VfcmVxKHN0cnVjdCByZXF1 ZXN0ICosIHN0cnVjdCByZXF1ZXN0ICopOw0KIA0KLS0tIHhmc3Rlc3QvbGlu dXgvZHJpdmVycy9ibG9jay9lbGV2YXRvci5jCVdlZCBGZWIgMTQgMTY6NTQ6 MTQgMjAwMQ0KKysrIDIuNHhmcy1wdXJlL2xpbnV4L2RyaXZlcnMvYmxvY2sv ZWxldmF0b3IuYwlUdWUgRmViICA2IDE5OjMyOjE0IDIwMDENCkBAIC0zMCwx MSArMzAsMTcgQEANCiBpbnQgZWxldmF0b3JfbGludXNfbWVyZ2UocmVxdWVz dF9xdWV1ZV90ICpxLCBzdHJ1Y3QgcmVxdWVzdCAqKnJlcSwNCiAJCQkgc3Ry dWN0IGxpc3RfaGVhZCAqIGhlYWQsDQogCQkJIHN0cnVjdCBidWZmZXJfaGVh ZCAqYmgsIGludCBydywNCi0JCQkgaW50IG1heF9zZWN0b3JzLCBpbnQgbWF4 X3NlZ21lbnRzKQ0KKwkJCSBpbnQgbWF4X3NlY3RvcnMsIGludCBtYXhfc2Vn bWVudHMsDQorICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBraW9i dWYgKiBraW9idWYsIGtkZXZfdCBkZXYsDQorICAgICAgICAgICAgICAgICAg ICAgICAgIHVuc2lnbmVkIGludCBrZW5kc2VjdG9yKQ0KIHsNCiAJc3RydWN0 IGxpc3RfaGVhZCAqZW50cnkgPSAmcS0+cXVldWVfaGVhZDsNCi0JdW5zaWdu ZWQgaW50IGNvdW50ID0gYmgtPmJfc2l6ZSA+PiA5LCByZXQgPSBFTEVWQVRP Ul9OT19NRVJHRTsNCisJdW5zaWduZWQgaW50IGNvdW50LCByZXQgPSBFTEVW QVRPUl9OT19NRVJHRTsNCisgICAgICAgIHVuc2lnbmVkIGludCB0bXBkaXN0 LCBjdXJyZGlzdCA9IElOVF9NQVg7DQogDQorICAgICAgICBpZiAoYmgpIA0K KyAgICAgICAgICAgICAgICBjb3VudCA9IGJoLT5iX3NpemUgPj4gOTsNCisg ICAgICAgIA0KIAl3aGlsZSAoKGVudHJ5ID0gZW50cnktPnByZXYpICE9IGhl YWQpIHsNCiAJCXN0cnVjdCByZXF1ZXN0ICpfX3JxID0gYmxrZGV2X2VudHJ5 X3RvX3JlcXVlc3QoZW50cnkpOw0KIA0KQEAgLTQ1LDMyICs1MSwzOCBAQA0K IAkJCSpyZXEgPSBfX3JxOw0KIAkJCWJyZWFrOw0KIAkJfQ0KLQ0KLQkJaWYg KF9fcnEtPmtpb2J1ZikNCi0JCQljb250aW51ZTsNCi0JCWlmIChfX3JxLT5z ZW0pDQotCQkJY29udGludWU7DQotCQlpZiAoX19ycS0+Y21kICE9IHJ3KQ0K LQkJCWNvbnRpbnVlOw0KLQkJaWYgKF9fcnEtPnJxX2RldiAhPSBiaC0+Yl9y ZGV2KQ0KLQkJCWNvbnRpbnVlOw0KLQkJaWYgKF9fcnEtPm5yX3NlY3RvcnMg KyBjb3VudCA+IG1heF9zZWN0b3JzKQ0KLQkJCWNvbnRpbnVlOw0KLQkJaWYg KF9fcnEtPmVsZXZhdG9yX3NlcXVlbmNlIDwgY291bnQpDQotCQkJYnJlYWs7 DQotCQlpZiAoX19ycS0+c2VjdG9yICsgX19ycS0+bnJfc2VjdG9ycyA9PSBi aC0+Yl9yc2VjdG9yKSB7DQotCQkJcmV0ID0gRUxFVkFUT1JfQkFDS19NRVJH RTsNCi0JCQkqcmVxID0gX19ycTsNCi0JCQlicmVhazsNCi0JCX0gZWxzZSBp ZiAoX19ycS0+c2VjdG9yIC0gY291bnQgPT0gYmgtPmJfcnNlY3Rvcikgew0K LQkJCXJldCA9IEVMRVZBVE9SX0ZST05UX01FUkdFOw0KLQkJCV9fcnEtPmVs ZXZhdG9yX3NlcXVlbmNlIC09IGNvdW50Ow0KLQkJCSpyZXEgPSBfX3JxOw0K LQkJCWJyZWFrOw0KLQkJfSBlbHNlIGlmICghKnJlcSAmJiBCSFJRX0lOX09S REVSKGJoLCBfX3JxKSkNCi0JCQkqcmVxID0gX19ycTsNCi0JfQ0KLQ0KKyAg ICAgICAgICAgICAgICBpZiAoYmgpIHsNCisgICAgICAgICAgICAgICAgICAg ICAgICBpZiAoX19ycS0+c2VtKQ0KKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29udGludWU7DQorICAgICAgICAgICAgICAgICAgICAgICAg aWYgKF9fcnEtPmNtZCAhPSBydykNCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNvbnRpbnVlOw0KKyAgICAgICAgICAgICAgICAgICAgICAg IGlmIChfX3JxLT5ycV9kZXYgIT0gYmgtPmJfcmRldikNCisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOw0KKyAgICAgICAgICAg ICAgICAgICAgICAgIGlmIChfX3JxLT5ucl9zZWN0b3JzICsgY291bnQgPiBt YXhfc2VjdG9ycykNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnRpbnVlOw0KKyAgICAgICAgICAgICAgICAgICAgICAgIGlmIChfX3Jx LT5lbGV2YXRvcl9zZXF1ZW5jZSA8IGNvdW50KQ0KKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgYnJlYWs7DQorICAgICAgICAgICAgICAgICAg ICAgICAgaWYgKF9fcnEtPmJoICYmIF9fcnEtPnNlY3RvciArIF9fcnEtPm5y X3NlY3RvcnMgPT0gYmgtPmJfcnNlY3Rvcikgew0KKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcmV0ID0gRUxFVkFUT1JfQkFDS19NRVJHRTsN CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICpyZXEgPSBfX3Jx Ow0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQor ICAgICAgICAgICAgICAgICAgICAgICAgfSBlbHNlIGlmIChfX3JxLT5iaCAm JiBfX3JxLT5zZWN0b3IgLSBjb3VudCA9PSBiaC0+Yl9yc2VjdG9yKSB7DQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXQgPSBFTEVWQVRP Ul9GUk9OVF9NRVJHRTsNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIF9fcnEtPmVsZXZhdG9yX3NlcXVlbmNlIC09IGNvdW50Ow0KKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKnJlcSA9IF9fcnE7DQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBicmVhazsNCisgICAgICAg ICAgICAgICAgICAgICAgICB9IGVsc2UgaWYgKCEqcmVxICYmIEJIUlFfSU5f T1JERVIoYmgsIF9fcnEpKSB7DQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAqcmVxID0gX19ycTsNCisgICAgICAgICAgICAgICAgICAgICAg ICB9IA0KKyAgICAgICAgICAgICAgICB9IGVsc2UgaWYgKGRldiA9PSBfX3Jx LT5ycV9kZXYgJiYga2VuZHNlY3RvciA8IF9fcnEtPnNlY3Rvcikgew0KKyAg ICAgICAgICAgICAgICAgICAgICAgIHRtcGRpc3QgPSBfX3JxLT5zZWN0b3Ig LSBrZW5kc2VjdG9yOw0KKyAgICAgICAgICAgICAgICAgICAgICAgIGlmICh0 bXBkaXN0IDwgY3VycmRpc3QpIHsNCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICpyZXEgPSBfX3JxOw0KKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY3VycmRpc3QgPSB0bXBkaXN0Ow0KKyAgICAgICAgICAg ICAgICAgICAgICAgIH0NCisgICAgICAgICAgICAgICAgfQ0KKyAgICAgICAg fQ0KKyAgICAgICAgDQogCXJldHVybiByZXQ7DQogfQ0KIA0KQEAgLTk5LDcg KzExMSw5IEBADQogaW50IGVsZXZhdG9yX25vb3BfbWVyZ2UocmVxdWVzdF9x dWV1ZV90ICpxLCBzdHJ1Y3QgcmVxdWVzdCAqKnJlcSwNCiAJCQlzdHJ1Y3Qg bGlzdF9oZWFkICogaGVhZCwNCiAJCQlzdHJ1Y3QgYnVmZmVyX2hlYWQgKmJo LCBpbnQgcncsDQotCQkJaW50IG1heF9zZWN0b3JzLCBpbnQgbWF4X3NlZ21l bnRzKQ0KKwkJCWludCBtYXhfc2VjdG9ycywgaW50IG1heF9zZWdtZW50cywN CisgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qga2lvYnVmICoga2lv YnVmLCBrZGV2X3QgZGV2LA0KKyAgICAgICAgICAgICAgICAgICAgICAgIHVu c2lnbmVkIGludCBrZW5kc2VjdG9yKQ0KIHsNCiAJc3RydWN0IGxpc3RfaGVh ZCAqZW50cnk7DQogCXVuc2lnbmVkIGludCBjb3VudCA9IGJoLT5iX3NpemUg Pj4gOTsNCi0tLSB4ZnN0ZXN0L2xpbnV4L2RyaXZlcnMvYmxvY2svbGxfcndf YmxrLmMJV2VkIEZlYiAxNCAxNjo1NDoxNCAyMDAxDQorKysgMi40eGZzLXB1 cmUvbGludXgvZHJpdmVycy9ibG9jay9sbF9yd19ibGsuYwlXZWQgRmViICA3 IDE2OjMxOjIwIDIwMDENCkBAIC05NTIsMTEgKzk1Miw5IEBADQogCX0gZWxz ZSBpZiAocS0+aGVhZF9hY3RpdmUgJiYgIXEtPnBsdWdnZWQpDQogCQloZWFk ID0gaGVhZC0+bmV4dDsNCiANCi0JaWYgKGtpb2J1ZikNCi0gICAgICAgICAg ICAgICAgZ290byBnZXRfcnE7DQotDQogCWVsX3JldCA9IGVsZXZhdG9yLT5l bGV2YXRvcl9tZXJnZV9mbihxLCAmcmVxLCBoZWFkLCBiaCwgcncsDQotCQkJ CQkgICAgIG1heF9zZWN0b3JzLCBtYXhfc2VnbWVudHMpOw0KKwkJCQkJICAg ICBtYXhfc2VjdG9ycywgbWF4X3NlZ21lbnRzLA0KKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGtpb2J1ZiwgZGV2LCBz ZWN0b3IrY291bnQpOw0KIAlzd2l0Y2ggKGVsX3JldCkgew0KIA0KIAkJY2Fz ZSBFTEVWQVRPUl9CQUNLX01FUkdFOg0KQEAgLTE0MDEsMTQgKzEzOTksMjQg QEANCiAJCWdvdG8gZW5kX2lvOw0KIAl9DQogDQorICAgICAgICAvKg0KKyAg ICAgICAgICogZG9uJ3QgaW5pdGlhdGUgSS9PIGlmIHdlJ3JlIGFscmVhZHkg YWJvdmUgdGhlIGhpZ2gNCisgICAgICAgICAqIHdhdGVyIG1hcmsuIGluc3Rl YWQgc3RhcnQgSS9PIG9uIHRoZSBxdWV1ZWQgc3R1ZmYuDQorICAgICAgICAg Ki8NCisgICAgICAgIGlmIChhdG9taWNfcmVhZCgmcXVldWVkX3NlY3RvcnMp ID49IGhpZ2hfcXVldWVkX3NlY3RvcnMpIHsNCisgICAgICAgICAgICAgICAg cnVuX3Rhc2tfcXVldWUoJnRxX2Rpc2spOw0KKyAgICAgICAgICAgICAgICB3 YWl0X2V2ZW50KGJsa19idWZmZXJzX3dhaXQsDQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgYXRvbWljX3JlYWQoJnF1ZXVlZF9zZWN0b3JzKSA8IGxv d19xdWV1ZWRfc2VjdG9ycyk7DQorICAgICAgICB9DQorICAgICAgICANCiAJ c3dpdGNoKHJ3KSB7DQogCWNhc2UgV1JJVEU6DQotCQlrc3RhdC5wZ3Bnb3V0 Kys7DQorCQlrc3RhdC5wZ3Bnb3V0ICs9IChraW9idWYtPmxlbmd0aCA+PiA5 KTsNCiAJCWJyZWFrOw0KIA0KIAljYXNlIFJFQURBOg0KIAljYXNlIFJFQUQ6 DQotCQlrc3RhdC5wZ3BnaW4rKzsNCisJCWtzdGF0LnBncGdpbiArPSAoa2lv YnVmLT5sZW5ndGggPj4gOSk7DQogCQlicmVhazsNCiAJZGVmYXVsdDoNCiAJ CUJVRygpOw0K ---1700565499-1359072450-982704369=:6587-- From owner-linux-xfs@oss.sgi.com Tue Feb 20 16:40:30 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 16:40:10 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:5 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 16:40:04 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.22 #4) id 14VNJr-00055O-00; Wed, 21 Feb 2001 01:39:47 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14VNJj-0000fv-00; Wed, 21 Feb 2001 01:39:39 +0100 Date: Wed, 21 Feb 2001 01:39:39 +0100 From: Jens Axboe To: Chaitanya Tumuluri Cc: Thomas Graichen , Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: mysterious dbench results] Message-ID: <20010221013939.G1447@suse.de> References: <3A9308B8.34D66FB3@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from chait@getafix.engr.sgi.com on Tue, Feb 20, 2001 at 04:26:09PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Feb 20 2001, Chaitanya Tumuluri wrote: > True. So, how about trying out the following patch which is a > first cut at inserting the kiobuf requests in LBA-ordered > fashion in the elevator? > > At the very least, it reduces the seek times which might've been > affecting kiobuf I/O performance adversely. You just further extend what I really don't like about the current approach to kiobuf I/O ;-). It's on huge clamp-on to ll_rw_blk... How about something that doesn't do merges on kiobufs, but just searches for an insertion point exactly like a buffer_head would do? And please don't make elevator_merge_fn even bigger than it already is, within limits of course. BTW, the max_segments is gone from the current tree. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Tue Feb 20 16:53:10 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 16:53:00 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:31346 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 16:52:38 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA08047 for ; Tue, 20 Feb 2001 16:52:38 -0800 (PST) mail_from (mann@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA883301 for ; Tue, 20 Feb 2001 18:51:22 -0600 (CST) Received: (from mann@localhost) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) id AAA35989 for linux-xfs@oss.sgi.com; Wed, 21 Feb 2001 00:51:22 GMT Date: Wed, 21 Feb 2001 00:51:22 GMT From: Mark Nordstrand Message-Id: <200102210051.AAA35989@daisy-e185.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Feb 20 16:50:22 PST 2001 Workarea: daisy.americas.sgi.com:/home/daisy32/mann/work/fsd1 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88000a linux/fs/xfs/xfs_log.c - 1.226 - Need to set done flag linux/fs/xfs/xfs_buf.h - 1.64 - Set up bdstrat linux/fs/xfs/xfs_buf_item.c - 1.111 - Call xfs_buf_relse() if not async. linux/fs/xfs/xfs_vnodeops.c - 1.488 - inode should be unlocked before reclaim linux/fs/xfs/xfs_vfsops.c - 1.307 - intialize the error test linux/fs/xfs/xfs_mount.c - 1.247 - Should use SHUTDOWN macro linux/fs/xfs/xfs_error.c - 1.30 - This is not were XFS_MOUNT_FS_SHUTDOWN should be set linux/fs/xfs/xfs_error.h - 1.20 - error test init. prototype linux/include/linux/page_buf.h - 1.74 - add bdstrat linux/fs/xfs/linux/xfs_ioctl.c - 1.30 - Remove shutdown check, since it's how the error injection is removed...... linux/fs/pagebuf/page_buf.c - 1.55 - Add bdstrat and move to pagebuf_iorequest wrapper linux/fs/pagebuf/page_buf_io.c - 1.53 - Drop messages clogging log From owner-linux-xfs@oss.sgi.com Tue Feb 20 16:59:39 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 16:59:29 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:48245 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 16:59:11 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA01955 for ; Tue, 20 Feb 2001 16:59:10 -0800 (PST) mail_from (chait@getafix.engr.sgi.com) Received: from getafix.engr.sgi.com (IDENT:root@getafix.engr.sgi.com [163.154.5.110]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id QAA58767; Tue, 20 Feb 2001 16:57:53 -0800 (PST) Received: from localhost (chait@localhost) by getafix.engr.sgi.com (8.9.3/8.9.3) with ESMTP id QAA07042; Tue, 20 Feb 2001 16:54:15 -0500 Date: Tue, 20 Feb 2001 16:54:15 -0500 (EST) From: Chaitanya Tumuluri To: Jens Axboe cc: Thomas Graichen , Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: mysterious dbench results] In-Reply-To: <20010221013939.G1447@suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 21 Feb 2001, Jens Axboe wrote: > On Tue, Feb 20 2001, Chaitanya Tumuluri wrote: > > True. So, how about trying out the following patch which is a > > first cut at inserting the kiobuf requests in LBA-ordered > > fashion in the elevator? > > > > At the very least, it reduces the seek times which might've been > > affecting kiobuf I/O performance adversely. > > You just further extend what I really don't like about the > current approach to kiobuf I/O ;-). It's on huge clamp-on > to ll_rw_blk... Hi, Its not a "clamp-on"; its an alternative code-path that is being maintained as independantly as possible from the buffer-head path. Easy surgery being the motivation. Yes, the intrusions into __make_request() (if that is what you're actually referring to) are obvious. But, given the kiobuf data structure as it currently exists, I can't see any other alternative! If there are other alternatives (of which I think several are being implemented as I write this)...I'd love to see the actual code. I'm perfectly willing to trash the current implementation if there is a viable data-structure that permits it. :^) > How about something that doesn't do merges on kiobufs, but > just searches for an insertion point exactly like a buffer_head > would do? And please don't make elevator_merge_fn even bigger > than it already is, within limits of course. For starters, this patch does _NOT_ try to merge kiobufs. Next, it _DOES_ try to find the insertion point for the kiobuf request in the device queue; based on the trying to find a request (bh or kiobuf) whose first sector aligns with the last sector of I/O in the incoming kiobuf. >BTW, the max_segments is gone from the current tree. Ooooh! kiobuf-sized buffer-head requests are now allowed? Cool! :^) Thanks for the heads-up. Cheers, -Chait. From owner-linux-xfs@oss.sgi.com Tue Feb 20 17:28:00 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 17:27:39 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:6405 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 17:27:14 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.22 #4) id 14VO3g-0005FF-00; Wed, 21 Feb 2001 02:27:08 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14VO3Y-0000mu-00; Wed, 21 Feb 2001 02:27:00 +0100 Date: Wed, 21 Feb 2001 02:27:00 +0100 From: Jens Axboe To: Chaitanya Tumuluri Cc: Thomas Graichen , Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: mysterious dbench results] Message-ID: <20010221022700.H1447@suse.de> References: <20010221013939.G1447@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from chait@getafix.engr.sgi.com on Tue, Feb 20, 2001 at 04:54:15PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Feb 20 2001, Chaitanya Tumuluri wrote: > Its not a "clamp-on"; its an alternative code-path that is > being maintained as independantly as possible from the buffer-head > path. Easy surgery being the motivation. It is so much a clamp-on! Just look for all the if (bh) /* do bh stuff */ else /* do kio stuff */ that is all over ll_rw_blk.c. I'm not blaming anyone, and of course this will be removed once 2.5 hits. And of course I understand SGI's general need for keeping SGI code separated makes maintenance and kernel merges easier. > Yes, the intrusions into __make_request() (if that is what you're > actually referring to) are obvious. But, given the kiobuf data > structure as it currently exists, I can't see any other alternative! > If there are other alternatives (of which I think several are being > implemented as I write this)...I'd love to see the actual code. > I'm perfectly willing to trash the current implementation if there is > a viable data-structure that permits it. :^) Not just __make_request, but lots of other places. That's not all I mean by being clamped on, interfaces have been extended arbitrarily to support kiobuf stuff. But as I said, as the block stuff grows in 2.5 we can support this much better. > > How about something that doesn't do merges on kiobufs, but > > just searches for an insertion point exactly like a buffer_head > > would do? And please don't make elevator_merge_fn even bigger > > than it already is, within limits of course. > > For starters, this patch does _NOT_ try to merge kiobufs. For christ sake, calm down :-). Of course it doesn't, in fact it would be quite a feat if you did that in that small a patch. > Next, it _DOES_ try to find the insertion point for the kiobuf > request in the device queue; based on the trying to find a > request (bh or kiobuf) whose first sector aligns with the last > sector of I/O in the incoming kiobuf. Yeah I can read the code. And I guess you are right, for now you will have to (again) make kiobuf special cases. > >BTW, the max_segments is gone from the current tree. > > Ooooh! kiobuf-sized buffer-head requests are now allowed? Cool! :^) They can grow arbitrarily big, only limited by limitations of the low level driver. But the reason max_segments is gone is because we don't actually need it for the merging anymore, if we can't extend another segments we won't try to do merges anyway. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Tue Feb 20 20:21:21 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 20:21:11 -0800 Received: from agile-50.OntheNet.com.au ([203.144.13.50]:3334 "EHLO surfers.oz.agile.tv") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 20:20:53 -0800 Received: from oz.agile.tv (IDENT:ksingh@budds.oz.agile.tv [192.168.16.7]) by surfers.oz.agile.tv (8.11.0/8.11.0) with ESMTP id f1L4KpV30497 for ; Wed, 21 Feb 2001 14:20:51 +1000 Message-ID: <3A9343EA.2040404@oz.agile.tv> Date: Wed, 21 Feb 2001 14:28:26 +1000 From: Kalvinder Singh User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS and SW RAID Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I am looking at using XFS and RAID 5, I am trying to decide between the 'extremely' hard to get hardware RAID (long story), or the easier to obtain software RAID. I did read the FAQ, and from the sounds of it XFS will not work with software RAID, however I went through the archive and noticed that some people are working on it. Is this correct? And how much extra work needs to be done to get it working? Any help is appreciated. Thanks, Kal. From owner-linux-xfs@oss.sgi.com Tue Feb 20 20:40:41 2001 Received: by oss.sgi.com id ; Tue, 20 Feb 2001 20:40:33 -0800 Received: from tux.mkp.net ([130.225.60.11]:2829 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Tue, 20 Feb 2001 20:40:13 -0800 Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.16 #1) id 14VR4P-00038a-00; Wed, 21 Feb 2001 05:40:06 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id SAA06233; Tue, 20 Feb 2001 18:39:58 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Kalvinder Singh Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and SW RAID References: <3A9343EA.2040404@oz.agile.tv> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 20 Feb 2001 18:39:58 -0500 In-Reply-To: <3A9343EA.2040404@oz.agile.tv> Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --=-=-= >>>>> "Kalvinder" == Kalvinder Singh writes: Kalvinder> I did read the FAQ, and from the sounds of it XFS will not Kalvinder> work with software RAID, however I went through the archive Kalvinder> and noticed that some people are working on it. Kalvinder> Is this correct? Kalvinder> And how much extra work needs to be done to get it working? We believe we have fixed the RAID5 corruption problems. However, the resync workaround hurts performance badly and I'll have to fix this properly. I've attached the current patch below. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=raid5.patch =========================================================================== Index: linux/drivers/md/md.c =========================================================================== --- /usr/tmp/TmpDir.3925-0/linux/drivers/md/md.c_1.6 Thu Feb 15 21:45:48 2001 +++ linux/drivers/md/md.c Thu Feb 15 13:46:59 2001 @@ -2033,65 +2033,69 @@ struct { int set; int noautodetect; -} raid_setup_args md__initdata; -void md_setup_drive (void) md__init; +} raid_setup_args md__initdata = { 0, 0 }; + +void md_setup_drive(void) md__init; /* * Searches all registered partitions for autorun RAID arrays * at boot time. */ -static int detected_devices[128] md__initdata; -static int dev_cnt; - +#define CONFIG_AUTODETECT_RAID +#ifdef CONFIG_AUTODETECT_RAID +static int detected_devices[128] md__initdata = { 0, }; +static int dev_cnt=0; void md_autodetect_dev(kdev_t dev) { if (dev_cnt >= 0 && dev_cnt < 127) detected_devices[dev_cnt++] = dev; } +#endif - -static void autostart_arrays (void) +int md__init md_run_setup(void) { +#ifdef CONFIG_AUTODETECT_RAID mdk_rdev_t *rdev; int i; - printk(KERN_INFO "autodetecting RAID arrays\n"); + if (raid_setup_args.noautodetect) + printk(KERN_INFO "skipping autodetection of RAID arrays\n"); + else { - for (i=0; ifaulty) { - MD_BUG(); - continue; + for (i=0; ifaulty) { + MD_BUG(); + continue; + } + md_list_add(&rdev->pending, &pending_raid_disks); } - md_list_add(&rdev->pending, &pending_raid_disks); - } - autorun_devices(-1); -} + autorun_devices(-1); + } -int md__init md_run_setup(void) -{ - if (raid_setup_args.noautodetect) - printk(KERN_INFO "skipping autodetection of RAID arrays\n"); - else - autostart_arrays(); dev_cnt = -1; /* make sure further calls to md_autodetect_dev are ignored */ +#endif +#ifdef CONFIG_MD_BOOT md_setup_drive(); +#endif return 0; } @@ -2555,11 +2559,6 @@ md_print_devices(); goto done_unlock; - case RAID_AUTORUN: - err = 0; - autostart_arrays(); - goto done; - case BLKGETSIZE: /* Return device size */ if (!arg) { err = -EINVAL; @@ -2713,6 +2712,7 @@ case BLKSETSIZE: set_blocksize (mddev, (int *) arg); goto done_unlock; + /* * We have a problem here : there is no easy way to give a CHS @@ -3056,9 +3056,11 @@ int sz = 0; unsigned long max_blocks, resync, res, dt, db, rt; - resync = mddev->curr_resync - atomic_read(&mddev->recovery_active); + resync = (mddev->curr_resync - atomic_read(&mddev->recovery_active)) >> 1; max_blocks = mddev->sb->size; + printk ("Res: %ld, Max Blocks: %ld\n", resync, max_blocks); + /* * Should not happen. */ @@ -3103,7 +3105,7 @@ if (!dt) dt++; db = resync - mddev->resync_mark_cnt; rt = (dt * ((max_blocks-resync) / (db/100+1)))/100; - + sz += sprintf(page + sz, " finish=%lu.%lumin", rt / 60, (rt % 60)/6); sz += sprintf(page + sz, " speed=%ldK/sec", db/dt); @@ -3274,10 +3276,10 @@ MD_DECLARE_WAIT_QUEUE_HEAD(resync_wait); -void md_done_sync(mddev_t *mddev, int blocks, int ok) +void md_done_sync(mddev_t *mddev, int sectors, int ok) { - /* another "blocks" (1K) blocks have been synced */ - atomic_sub(blocks, &mddev->recovery_active); + /* another chunk of sectors has been synced */ + atomic_sub(sectors, &mddev->recovery_active); wake_up(&mddev->recovery_wait); if (!ok) { // stop recovery, signal do_sync .... @@ -3289,7 +3291,7 @@ int md_do_sync(mddev_t *mddev, mdp_disk_t *spare) { mddev_t *mddev2; - unsigned int max_blocks, currspeed, + unsigned int max_sectors, currspeed, j, window, err, serialize; kdev_t read_disk = mddev_to_kdev(mddev); unsigned long mark[SYNC_MARKS]; @@ -3326,7 +3328,7 @@ mddev->curr_resync = 1; - max_blocks = mddev->sb->size; + max_sectors = mddev->sb->size << 1; printk(KERN_INFO "md: syncing RAID array md%d\n", mdidx(mddev)); printk(KERN_INFO "md: minimum _guaranteed_ reconstruction speed: %d KB/sec/disc.\n", @@ -3351,22 +3353,22 @@ * Tune reconstruction: */ window = MAX_READAHEAD*(PAGE_SIZE/1024); - printk(KERN_INFO "md: using %dk window, over a total of %d blocks.\n",window,max_blocks); + printk(KERN_INFO "md: using %dk window, over a total of %d sectors.\n",window, max_sectors); atomic_set(&mddev->recovery_active, 0); init_waitqueue_head(&mddev->recovery_wait); last_check = 0; - for (j = 0; j < max_blocks;) { - int blocks; + for (j = 0; j < max_sectors;) { + int sectors; - blocks = mddev->pers->sync_request(mddev, j); + sectors = mddev->pers->sync_request(mddev, j); - if (blocks < 0) { - err = blocks; + if (sectors < 0) { + err = sectors; goto out; } - atomic_add(blocks, &mddev->recovery_active); - j += blocks; + atomic_add(sectors, &mddev->recovery_active); + j += sectors; mddev->curr_resync = j; if (last_check + window > j) @@ -3384,7 +3386,7 @@ mark_cnt[next] = j - atomic_read(&mddev->recovery_active); last_mark = next; } - + if (md_signal_pending(current)) { /* @@ -3626,7 +3628,7 @@ &md_fops, NULL); /* forward all md request to md_make_request */ - blk_queue_make_request(BLK_DEFAULT_QUEUE(MAJOR_NR), md_make_request); + blk_queue_make_request(BLK_DEFAULT_QUEUE(MAJOR_NR), (void *) md_make_request); read_ahead[MAJOR_NR] = INT_MAX; @@ -3645,12 +3647,14 @@ return (0); } -static struct { - char device_set [MAX_MD_DEVS]; - int pers[MAX_MD_DEVS]; - int chunk[MAX_MD_DEVS]; - kdev_t devices[MAX_MD_DEVS][MD_SB_DISKS]; -} md_setup_args md__initdata; +#ifdef CONFIG_MD_BOOT +#define MAX_MD_BOOT_DEVS 8 +struct { + unsigned long set; + int pers[MAX_MD_BOOT_DEVS]; + int chunk[MAX_MD_BOOT_DEVS]; + kdev_t devices[MAX_MD_BOOT_DEVS][MD_SB_DISKS]; +} md_setup_args md__initdata = { 0, }; /* * Parse the command-line parameters given our kernel, but do not @@ -3680,10 +3684,10 @@ printk("md: Too few arguments supplied to md=.\n"); return 0; } - if (minor >= MAX_MD_DEVS) { + if (minor >= MAX_MD_BOOT_DEVS) { printk ("md: Minor device number too high.\n"); return 0; - } else if (md_setup_args.device_set[minor]) { + } else if (md_setup_args.set & (1 << minor)) { printk ("md: Warning - md=%d,... has been specified twice;\n" " will discard the first definition.\n", minor); } @@ -3741,7 +3745,7 @@ printk ("md: Will configure md%d (%s) from %s, below.\n", minor, pername, devnames); md_setup_args.devices[minor][i] = (kdev_t) 0; - md_setup_args.device_set[minor] = 1; + md_setup_args.set |= (1 << minor); return 1; } @@ -3751,11 +3755,10 @@ kdev_t dev; mddev_t*mddev; - for (minor = 0; minor < MAX_MD_DEVS; minor++) { + for (minor = 0; minor < MAX_MD_BOOT_DEVS; minor++) { mdu_disk_info_t dinfo; - - int err = 0; - if (!md_setup_args.device_set[minor]) + int err=0; + if (!(md_setup_args.set & (1 << minor))) continue; printk("md: Loading md%d.\n", minor); if (mddev_map[minor].mddev) { @@ -3781,7 +3784,7 @@ ainfo.layout = 0; ainfo.chunk_size = md_setup_args.chunk[minor]; err = set_array_info(mddev, &ainfo); - for (i = 0; !err && (dev = md_setup_args.devices[minor][i]); i++) { + for (i=0; !err && (dev = md_setup_args.devices[minor][i]); i++) { dinfo.number = i; dinfo.raid_disk = i; dinfo.state = (1< %d\n", oldsize, size); + printk("raid5: conf->buffer_size = %d\n", conf->buffer_size); shrink_stripe_cache(conf); if (size==0) BUG(); conf->buffer_size = size; @@ -714,16 +715,19 @@ break; } spin_unlock_irq(&conf->device_lock); - if (count>1) { - xor_block(count, bh_ptr); - count = 1; - } - + if (count>1) { + xor_block(count, bh_ptr); + count = 1; + } for (i = disks; i--;) if (chosen[i]) { struct buffer_head *bh = sh->bh_cache[i]; char *bdata; - mark_buffer_clean(chosen[i]); /* NO FIXME */ + if(!(test_bit(BH_End_io, &(chosen[i]->b_state)) + || chosen[i]->b_next_free == NULL + || chosen[i]->b_prev_free == NULL )){ + mark_buffer_clean(chosen[i]); + } bdata = bh_kmap(chosen[i]); memcpy(bh->b_data, bdata,sh->size); @@ -888,7 +892,7 @@ } spin_unlock_irq(&conf->device_lock); if (syncing) { - md_done_sync(conf->mddev, (sh->size>>10) - sh->sync_redone,0); + md_done_sync(conf->mddev, (sh->size>>9) - sh->sync_redone, 0); clear_bit(STRIPE_SYNCING, &sh->state); syncing = 0; } @@ -1063,7 +1067,7 @@ } } if (syncing && locked == 0 && test_bit(STRIPE_INSYNC, &sh->state)) { - md_done_sync(conf->mddev, (sh->size>>10) - sh->sync_redone,1); + md_done_sync(conf->mddev, (sh->size>>9) - sh->sync_redone, 1); clear_bit(STRIPE_SYNCING, &sh->state); } @@ -1159,13 +1163,13 @@ return correct_size; } -static int raid5_sync_request (mddev_t *mddev, unsigned long block_nr) +static int raid5_sync_request (mddev_t *mddev, unsigned long sector) { raid5_conf_t *conf = (raid5_conf_t *) mddev->private; struct stripe_head *sh; int sectors_per_chunk = conf->chunk_size >> 9; - unsigned long stripe = (block_nr<<1)/sectors_per_chunk; - int chunk_offset = (block_nr<<1) % sectors_per_chunk; + unsigned long stripe = sector/sectors_per_chunk; + int chunk_offset = sector % sectors_per_chunk; int dd_idx, pd_idx; unsigned long first_sector; int raid_disks = conf->raid_disks; @@ -1173,9 +1177,9 @@ int redone = 0; int bufsize; - sh = get_active_stripe(conf, block_nr<<1, 0, 0); + sh = get_active_stripe(conf, sector, 0, 0); bufsize = sh->size; - redone = block_nr-(sh->sector>>1); + redone = sector - sh->sector; first_sector = raid5_compute_sector(stripe*data_disks*sectors_per_chunk + chunk_offset, raid_disks, data_disks, &dd_idx, &pd_idx, conf); sh->pd_idx = pd_idx; @@ -1188,7 +1192,7 @@ handle_stripe(sh); release_stripe(sh); - return (bufsize>>10)-redone; + return (bufsize >> 9) - redone; } /* --=-=-=-- From owner-linux-xfs@oss.sgi.com Wed Feb 21 01:46:22 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 01:46:13 -0800 Received: from ns.suse.de ([213.95.15.193]:4868 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Wed, 21 Feb 2001 01:45:53 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 814401E1CE; Wed, 21 Feb 2001 10:45:51 +0100 (MET) Date: Wed, 21 Feb 2001 10:45:22 +0100 From: Andi Kleen To: Jens Axboe Cc: Chaitanya Tumuluri , Thomas Graichen , Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: mysterious dbench results] Message-ID: <20010221104522.A10722@gruyere.muc.suse.de> References: <20010221013939.G1447@suse.de> <20010221022700.H1447@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010221022700.H1447@suse.de>; from axboe@suse.de on Wed, Feb 21, 2001 at 02:27:00AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Feb 21, 2001 at 02:27:00AM +0100, Jens Axboe wrote: > On Tue, Feb 20 2001, Chaitanya Tumuluri wrote: > > Its not a "clamp-on"; its an alternative code-path that is > > being maintained as independantly as possible from the buffer-head > > path. Easy surgery being the motivation. > > It is so much a clamp-on! Just look for all the > > if (bh) > /* do bh stuff */ > else > /* do kio stuff */ > > that is all over ll_rw_blk.c. I'm not blaming anyone, and of course > this will be removed once 2.5 hits. And of course I understand > SGI's general need for keeping SGI code separated makes > maintenance and kernel merges easier. > > > Yes, the intrusions into __make_request() (if that is what you're > > actually referring to) are obvious. But, given the kiobuf data > > structure as it currently exists, I can't see any other alternative! > > If there are other alternatives (of which I think several are being > > implemented as I write this)...I'd love to see the actual code. > > I'm perfectly willing to trash the current implementation if there is > > a viable data-structure that permits it. :^) > > Not just __make_request, but lots of other places. That's not > all I mean by being clamped on, interfaces have been extended > arbitrarily to support kiobuf stuff. But as I said, as the block > stuff grows in 2.5 we can support this much better. > > > > How about something that doesn't do merges on kiobufs, but > > > just searches for an insertion point exactly like a buffer_head > > > would do? And please don't make elevator_merge_fn even bigger > > > than it already is, within limits of course. > > > > For starters, this patch does _NOT_ try to merge kiobufs. > > For christ sake, calm down :-). Of course it doesn't, in fact > it would be quite a feat if you did that in that small a patch. > > > Next, it _DOES_ try to find the insertion point for the kiobuf > > request in the device queue; based on the trying to find a > > request (bh or kiobuf) whose first sector aligns with the last > > sector of I/O in the incoming kiobuf. > > Yeah I can read the code. And I guess you are right, for now > you will have to (again) make kiobuf special cases. > > > >BTW, the max_segments is gone from the current tree. > > > > Ooooh! kiobuf-sized buffer-head requests are now allowed? Cool! :^) > > They can grow arbitrarily big, only limited by limitations of the > low level driver. But the reason max_segments is gone is because Just there seem to be lots of drivers that cannot deal with big requests. -Andi From owner-linux-xfs@oss.sgi.com Wed Feb 21 06:08:04 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 06:07:45 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:30727 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 06:07:24 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.22 #4) id 14VZv9-0008Mq-00; Wed, 21 Feb 2001 15:07:07 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14VZv5-00026y-00; Wed, 21 Feb 2001 15:07:03 +0100 Date: Wed, 21 Feb 2001 15:07:03 +0100 From: Jens Axboe To: Andi Kleen Cc: Chaitanya Tumuluri , Thomas Graichen , Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: mysterious dbench results] Message-ID: <20010221150703.S1447@suse.de> References: <20010221013939.G1447@suse.de> <20010221022700.H1447@suse.de> <20010221104522.A10722@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010221104522.A10722@gruyere.muc.suse.de>; from ak@suse.de on Wed, Feb 21, 2001 at 10:45:22AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Feb 21 2001, Andi Kleen wrote: > > > Ooooh! kiobuf-sized buffer-head requests are now allowed? Cool! :^) > > > > They can grow arbitrarily big, only limited by limitations of the > > low level driver. But the reason max_segments is gone is because > > Just there seem to be lots of drivers that cannot deal with big requests. This is only a problem for the kiobufs, the buffer_head requests can be limited to whatever the driver wants. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Feb 21 06:38:55 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 06:38:35 -0800 Received: from 66-2-81-26.customer.algx.net ([66.2.81.26]:6958 "EHLO wiley.ceo.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 06:38:14 -0800 Received: from mindspring.com (IDENT:danny@localhost [127.0.0.1]) by wiley.ceo.com (8.9.3/8.9.3) with ESMTP id JAA02865 for ; Wed, 21 Feb 2001 09:49:52 -0500 Message-ID: <3A93D590.F8A3D505@mindspring.com> Date: Wed, 21 Feb 2001 09:49:52 -0500 From: Danny Reply-To: dcox@connex.com Organization: Connex Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-XFS Subject: Pagebuf Buf: Don't Call 'buffer_IO_error()' Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing All, A small patch follows. _pagebuf_page_io allocates buffer_heads, but on any error loops through them, calling 'buffer_IO_error()' on each. This is wrong, since buffer_IO_error calls 'refile_buffer()' which deletes the bh from one list, and places it on another. Since these bhs were never part of the internal lists, the next/prev pointers are NULL, thereby corrupting the [to] list. The attached patch performs the same steps as 'buffer_IO_error()', but without the 'refile_buffer()' call. Enjoy! ========================================================================== --- linux.sgi/fs/pagebuf/page_buf.c Wed Feb 14 09:34:15 2001 +++ linux.hacked/fs/pagebuf/page_buf.c Wed Feb 21 09:17:54 2001 @@ -455,7 +455,6 @@ struct page **pages) { loff_t next_buffer_offset; - loff_t next_desired_offset; unsigned long page_count; int rval; struct kiobuf *kp; @@ -1319,6 +1318,7 @@ int cnt,itr; pagesync_t *psync; struct buffer_head *bh; + struct buffer_head **bhp; off_t blk_offset; size_t blk_length; int err=0; @@ -1424,8 +1424,9 @@ return err; error: /* If we ever do get here then clean up what we already did */ - for (itr=0; itr < cnt; itr++) { - buffer_IO_error(psync->bh[itr]); + for (bhp = psync->bh; bhp < psync->bh + cnt; ++bhp) { + atomic_set_buffer_clean (*bhp); + (*bhp)->b_end_io (*bhp, 0); } return err; } ============================================================================== -- "Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill Danny From owner-linux-xfs@oss.sgi.com Wed Feb 21 09:14:47 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 09:14:37 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40469 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 09:14:12 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA08097 for ; Wed, 21 Feb 2001 09:23:40 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA19589; Wed, 21 Feb 2001 11:12:55 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1LHBpq26449; Wed, 21 Feb 2001 12:11:51 -0500 Message-ID: <3A93F6D6.69E55794@thebarn.com> Date: Wed, 21 Feb 2001 17:11:50 +0000 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: dcox@connex.com CC: Linux-XFS Subject: Re: Pagebuf Buf: Don't Call 'buffer_IO_error()' References: <3A93D590.F8A3D505@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Danny wrote: Yup... keep meaning to get to this one. I don't think the error ever occurs since we never hit the bug. > All, > > A small patch follows. _pagebuf_page_io allocates buffer_heads, but on > any error loops through them, calling 'buffer_IO_error()' on each. This > is wrong, since buffer_IO_error calls 'refile_buffer()' which deletes > the bh from one list, and places it on another. Since these bhs were > never part of the internal lists, the next/prev pointers are NULL, > thereby corrupting the [to] list. > > The attached patch performs the same steps as 'buffer_IO_error()', but > without the 'refile_buffer()' call. > > Enjoy! > > ========================================================================== > --- linux.sgi/fs/pagebuf/page_buf.c Wed Feb 14 09:34:15 2001 > +++ linux.hacked/fs/pagebuf/page_buf.c Wed Feb 21 09:17:54 2001 > @@ -455,7 +455,6 @@ > struct page **pages) > { > loff_t next_buffer_offset; > - loff_t next_desired_offset; > unsigned long page_count; > int rval; > struct kiobuf *kp; > @@ -1319,6 +1318,7 @@ > int cnt,itr; > pagesync_t *psync; > struct buffer_head *bh; > + struct buffer_head **bhp; > off_t blk_offset; > size_t blk_length; > int err=0; > @@ -1424,8 +1424,9 @@ > return err; > error: > /* If we ever do get here then clean up what we already did */ > - for (itr=0; itr < cnt; itr++) { > - buffer_IO_error(psync->bh[itr]); > + for (bhp = psync->bh; bhp < psync->bh + cnt; ++bhp) { > + atomic_set_buffer_clean (*bhp); > + (*bhp)->b_end_io (*bhp, 0); > } > return err; > } > ============================================================================== > > -- > "Men occasionally stumble over the truth, but most of them pick > themselves up and hurry off as if nothing had happened." > -- Winston Churchill > > Danny -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Feb 21 09:18:57 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 09:18:47 -0800 Received: from south.orl-pub.theseus.com ([12.108.42.66]:56352 "EHLO thor.theseus.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 09:18:34 -0800 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id MAA17033; Wed, 21 Feb 2001 12:21:31 -0500 Message-ID: <3A93F851.56D591F4@theseus.com> Date: Wed, 21 Feb 2001 12:18:09 -0500 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-XFS CC: elug-eluglist@elug.org Subject: [New subscriber] RPM release "road map"? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing [New subscriber] RPM release "road map"? Hi all, new subscriber. I hit the list archives and didn't see anyone talking about this directly, so I might as well bring it up. Feel free to comment, rebuke or flat-out smack me for asking ... ;-PPP Right now I'm running kernel 2.2 + Ext3 (thanx to HJL@VALinux's RPMs) on most of my production systems (most have a RedHat 6.2 base). I'm even working on modifying Anaconda and repackaging a "6.3" RPM release for production use since people I know have been bothering me for it (I've been running Ext3 for 9 months at home, 6 months on my main file server at work). Unfortunately Tweedie@RedHat (the Ext3 maintainer) doesn't seem to be working on Ext3 for kernel 2.4 right now (at least that's what I've heard -- I _could_ be wrong), and ReiserFS (which runs on 2.4) is not a desirable JFS for kNFSd file servers IMHO (yes, I know about the NFS patches, but I still don't trust it for _production_kNFSd_servers_ yet ;-). I have always been impressed with XFS and, after reading the docs (including the extensive Linux utility support like "xfsdump"), I recently downloaded and played with the XFS 0.9 release for RedHat 7.0. I am extremely impressed with the RPMs produced as well as the replacement Anaconda installer. Plus, I heard it works perfectly with kNFSd under 2.4.x, correct? If so, that is _exactly_ what corporate sysadmins who run their enterprise on NFSf are looking for. And most of us maintain a box we "roll-our-own" RPM sets/updates on (for NFS-based installs), which makes the XFS RPM/Anaconda release very, very sweet indeed! As such, although it is hard to "tell the future," when does it look like next RPMest/Anaconda replacement will be released? >From what I've read in the mailing list archives, it looks like most XFS "issues" on Linx have been with the 2.4.0 kernel itself (largely the unified IDE code?). And others have had much better success with the CVS builds against 2.4.1 as well as 2.4.2-pre3? Again, XFS looks to be the best JFS for production NFS servers given its proven track record on Irix, and its capabilities with large files and overall volume (even on Linux). With both the RedHat 7.1 and kernel 2.4.2 releases around the corner, I'm starting to get the feeling that that the "potential" RPM release "road map" would include a new RPMset/Anaconda release for RedHat 7.1 with the 2.4.2 kernel? Is that where it looks like were headed (assuming 2.4.2 comes out shortly after RedHat 7.1)? Just curious. I'm going to dig into the CVS tree and look at using it XFS on my home workstation regardless. But I'm trying to look towards the future, especially given the most excellent RPM/Anaconda set produced for RedHat 7.0 / kernel 2.4.0. -- TheBS CC: ELUG -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Wed Feb 21 11:19:17 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 11:19:07 -0800 Received: from [204.191.16.3] ([204.191.16.3]:37035 "EHLO dkp.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 11:18:49 -0800 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id OAA01122 for linux-xfs@oss.sgi.com; Wed, 21 Feb 2001 14:18:33 -0500 Date: Wed, 21 Feb 2001 14:18:33 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: RAID5 + XFS Message-ID: <20010221141826.A1062@key.dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Greetings. I've consistently been getting "Unable to handle kernel NULL pointer dereference" errors when unmounting an XFS filesystem which I had created on a RAID5 device. This occurs with both the beta XFS and the latest CVS. Is this a known bug? Would more information be useful for you? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Feb 21 11:39:56 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 11:39:37 -0800 Received: from 66-2-81-26.customer.algx.net ([66.2.81.26]:19762 "EHLO wiley.ceo.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 11:39:04 -0800 Received: from mindspring.com (IDENT:danny@localhost [127.0.0.1]) by wiley.ceo.com (8.9.3/8.9.3) with ESMTP id OAA04231; Wed, 21 Feb 2001 14:50:00 -0500 Message-ID: <3A941BE8.7C31EC19@mindspring.com> Date: Wed, 21 Feb 2001 14:50:00 -0500 From: Danny Reply-To: dcox@connex.com Organization: Connex Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Klaassen CC: linux-xfs@oss.sgi.com Subject: Re: RAID5 + XFS References: <20010221141826.A1062@key.dkp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Andrew, Andrew Klaassen wrote: > I've consistently been getting "Unable to handle kernel NULL > pointer dereference" errors when unmounting an XFS filesystem > which I had created on a RAID5 device. This occurs with both > the beta XFS and the latest CVS. > > Is this a known bug? Would more information be useful for you? This sounds suspiciously like something I had to track down. The easy answer is: look for the raid5 patch posted last week by Russell Cattelan. Another easy answer is to look for 'mark_buffer_clean()' in raid5.c, and remove the line. That should fix you up. -- "Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill Danny From owner-linux-xfs@oss.sgi.com Wed Feb 21 11:40:26 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 11:40:06 -0800 Received: from 66-2-81-26.customer.algx.net ([66.2.81.26]:22066 "EHLO wiley.ceo.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 11:40:01 -0800 Received: from mindspring.com (IDENT:danny@localhost [127.0.0.1]) by wiley.ceo.com (8.9.3/8.9.3) with ESMTP id OAA04205 for ; Wed, 21 Feb 2001 14:13:23 -0500 Message-ID: <3A941353.6B88C8C9@mindspring.com> Date: Wed, 21 Feb 2001 14:13:23 -0500 From: Danny Reply-To: dcox@connex.com Organization: Connex Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-XFS Subject: Repeatable Panics with XFS and RAID1 (long) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing All, In my testing, I can produce various problems with XFS and RAID1. I'll reproduce three scenarios below. First, my test configuration is: Intel Celeron @ 566 MHz, 64 MB RAM, 4 45 GB IDE drives, two of which form a RAID1 (mirror) of about 40 GB (I don't believe partition size has any bearing on this). While the RAID array is still resyncing, I build an XFS fs on it, mount it, and run Bonnie (1.2) "./Bonnie -s 128 -d /share", in an infinite loop. After some time (usually 5 to 20 minutes), an error results. I posted a patch for one of those this AM. I don't know if the resync is necessary, but it sure stresses things! First, here is an edited typescript file, showing a deadlock situation: ================================================================================ Script started on Wed Feb 21 07:50:08 2001 [danny@dsc_proto_1 danny]$ ps -axlww F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 100 0 1 0 8 0 1120 68 do_sel S ? 0:03 init [3] 040 0 2 1 9 0 0 0 contex SW ? 0:00 [keventd] 040 0 3 1 9 0 0 0 apm_ma SW ? 0:00 [kapm-idled] 040 0 4 1 9 0 0 0 raid1_ DW ? 0:06 [kswapd] 040 0 5 1 9 0 0 0 krecla SW ? 0:00 [kreclaimd] 040 0 6 1 9 0 0 0 raid1_ DW ? 0:09 [bdflush] 040 0 7 1 9 0 0 0 kupdat SW ? 0:00 [kupdate] 040 0 8 1 -1 -20 0 0 md_thr SW< ? 0:00 [mdrecoveryd] 040 0 9 1 -1 -20 0 0 md_thr SW< ? 0:00 [raid1d] 140 0 510 1 8 0 2444 168 do_sel S ? 0:00 smbd -D 140 0 519 1 9 0 2024 656 do_sel S ? 0:00 nmbd -D 040 0 645 1 -1 -20 0 0 md_thr SW< tty1 0:11 [raid1d] 040 0 646 1 19 19 0 0 md_thr SWN tty1 0:09 [raid1syncd] 040 0 703 1 9 0 0 0 pagebu SW tty1 0:00 [pagebuf_daemon] 040 0 704 1 9 0 0 0 raid1_ DW tty1 0:28 [page_daemon] 000 0 723 623 9 0 1648 84 wait4 S tty1 0:00 /bin/sh ./torture 100 0 729 616 10 0 1740 552 read_c S tty2 0:00 -bash 000 0 1238 723 9 0 1340 328 pipe_w S tty1 1:20 Bonnie -s 256 -d /share -y 140 500 1264 510 9 0 3824 1148 raid1_ D ? 0:01 smbd -D 040 0 1265 1238 9 0 1404 60 lock_p D tty1 0:00 Bonnie -s 256 -d /share -y 040 0 1266 1238 9 0 1404 60 mracce D tty1 0:00 Bonnie -s 256 -d /share -y 040 0 1267 1238 9 0 1404 68 mracce D tty1 0:00 Bonnie -s 256 -d /share -y 000 500 1757 1737 14 0 2748 1100 - R pts/0 0:00 ps -axlww [danny@dsc_proto_1 danny]$ grep -A2 __alloc_page /var/log/messages.1 | tail -3 Feb 20 12:51:38 dsc_proto_1 kernel: __alloc_pages: 0-order allocation failed. Feb 20 12:51:41 dsc_proto_1 last message repeated 21 times Feb 20 13:51:52 dsc_proto_1 kernel: md: md1: sync done. [danny@dsc_proto_1 danny]$ exit Script done on Wed Feb 21 07:55:22 2001 ============================================================================= Note the Bonnie processes: #1238 is the parent. #s 1265, 1266, and 1267 are the seekers it creates as it's last measurement. #1265 is in "lock_page", while the others are in "mraccessf". Just before the hang, the kernel spouted the "0-order alocation failed." messages. Last week, I changed the __alloc_pages function to panic() after that printk, and traced the stack back to raid1_alloc_rlbh() in raid1.c. This function does the Right Thing, checking the pointer for NULL, and if so, calls "wait_event". Well, this causes a schedule(), while waiting for mem to be freed, but obviously something was locked when that happened. I'd suspect something in the XFS code isn't expecting down-stream drivers to call schedule(). Item next: in page_buf.c, line 1369, the BUG() macro is called if psync is NULL after the kmalloc() call. I've hit this several times with the above setup. Item final: I've seen the messages: cluster_write: can't get pb (page_buf_io.c:1839) cluster_write: pb_lookup_pages failed! (page_buf_io.c:1844) and the process hung. The only out was a reboot, and that filesystem refused to be unmounted. ps(1) showed the process status as 'D', uninterruptable sleep :-(. I'd love to help with this, but I'm at my limit of what I know. For example, with the BUG() at page_buf.c:1369, can you set up for a wait_event()? Can you simply return with a status of try_again? I don't know what might need to be unrolled by this point, so am at a loss of how to proceed. Help! Thanks in advance! -- "Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill Danny From owner-linux-xfs@oss.sgi.com Wed Feb 21 11:45:26 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 11:45:07 -0800 Received: from [204.191.16.3] ([204.191.16.3]:685 "EHLO dkp.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 11:45:00 -0800 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id OAA01481 for linux-xfs@oss.sgi.com; Wed, 21 Feb 2001 14:44:58 -0500 Date: Wed, 21 Feb 2001 14:44:58 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: RAID5 + XFS Message-ID: <20010221144455.D1062@key.dkp.com> References: <20010221141826.A1062@key.dkp.com> <3A941BE8.7C31EC19@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A941BE8.7C31EC19@mindspring.com>; from danscox@mindspring.com on Wed, Feb 21, 2001 at 02:50:00PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell has sent me the patch. I'll try it when I get a chance. Thanks. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Feb 21 13:07:17 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 13:06:57 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16460 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 13:06:37 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05799 for ; Wed, 21 Feb 2001 13:15:08 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA47251; Wed, 21 Feb 2001 15:04:20 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1LL3Gq28878; Wed, 21 Feb 2001 16:03:16 -0500 Message-ID: <3A942D14.DEE58F31@thebarn.com> Date: Wed, 21 Feb 2001 21:03:16 +0000 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: dcox@connex.com CC: Linux-XFS Subject: Re: Repeatable Panics with XFS and RAID1 (long) References: <3A941353.6B88C8C9@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Danny wrote: > > > I'd love to help with this, but I'm at my limit of what I know. For > example, with the BUG() at page_buf.c:1369, can you set up for a > wait_event()? Can you simply return with a status of try_again? I > don't know what might need to be unrolled by this point, so am at a loss > of how to proceed. > > Help! I'm sure these problems are due to the flag change in kmalloc: GFP_KERNEL -> GFP_BUFFER. Changing the flag has cleaned up some deadlock situations but apparently has exposed some out of memory situations that has not occurred in the past. I'm not sure what the best approach is yet. XFS/pagebuf should handle out of memory situation better, (this has been an item on our todo list for quite some time) You could try changing the flag back to GFP_KERNEL and see what happens. I see if what I can do about convincing pagbug_page_io to do retries. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Feb 21 13:55:47 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 13:55:37 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:22564 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 13:55:17 -0800 Received: from nodin.corp.sgi.com ([192.26.51.193]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05098; Wed, 21 Feb 2001 13:55:16 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA44216; Wed, 21 Feb 2001 13:54:46 -0800 (PST) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA64065; Wed, 21 Feb 2001 13:54:45 -0800 (PST) Date: Wed, 21 Feb 2001 13:54:45 -0800 (PST) Message-Id: <200102212154.NAA64065@info.engr.sgi.com> X-Pv-Incident: 811526 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@odin.corp.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 811526 - assert trip with kiocluster & loopback To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=811526 *Status : closed Priority : 3 Assigned Engineer : nb Submitter : dxm Opened Date : 01/02/01 *Closed Date : 02/21/01 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 02/21/01 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Feb 21 2001 01:54:45PM ========================== This seems to have been fixed somehow. I'm now running QA with kiocluster again. From owner-linux-xfs@oss.sgi.com Wed Feb 21 13:59:07 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 13:58:47 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:4389 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 13:58:34 -0800 Received: from madurai.engr.sgi.com ([163.154.5.75]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08315 for ; Wed, 21 Feb 2001 13:58:27 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA29942; Wed, 21 Feb 2001 13:52:38 -0800 (PST) Message-ID: <3A943966.8F27E502@sgi.com> Date: Wed, 21 Feb 2001 13:55:50 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: dcox@connex.com CC: Linux-XFS Subject: Re: Repeatable Panics with XFS and RAID1 (long) References: <3A941353.6B88C8C9@mindspring.com> Content-Type: multipart/mixed; boundary="------------F990E1D412DE4CDDD6635F2B" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------F990E1D412DE4CDDD6635F2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Danny wrote: > Feb 20 12:51:38 dsc_proto_1 kernel: __alloc_pages: 0-order allocation > failed. For those seeing __alloc_pages failing, can you please try this patch? With recent code changes, writepage() is used for flushing dirty pages, and this typically happens under memory pressure. So, doing anything expensive to allocate memory under these conditions is bad. cheers, ananth. -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- --------------F990E1D412DE4CDDD6635F2B Content-Type: text/plain; charset=us-ascii; name="atomic-alloc.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="atomic-alloc.patch" --- /usr/tmp/TmpDir.25971-0/linux/fs/pagebuf/page_buf_io.c_1.53 Wed Feb 21 13:50:08 2001 +++ linux/fs/pagebuf/page_buf_io.c Wed Feb 21 13:49:03 2001 @@ -261,7 +261,7 @@ * since this can be in kswapd's path ... */ cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * sizeof(struct page *), - GFP_BUFFER); + GFP_ATOMIC); spin_lock(&pagecache_lock); _pagebuf_flush(ip, &ip->i_mapping->clean_pages, ioff, cpages); @@ -1084,7 +1084,7 @@ current->flags |= PF_MEMALLOC; cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * sizeof(struct page *), - GFP_BUFFER); + GFP_ATOMIC); do_write_full_page++; --------------F990E1D412DE4CDDD6635F2B-- From owner-linux-xfs@oss.sgi.com Wed Feb 21 14:35:07 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 14:34:57 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:95 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 14:34:33 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA06198 for ; Wed, 21 Feb 2001 14:33:28 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA46635 for ; Wed, 21 Feb 2001 16:33:16 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.2/8.11.2) id f1LMWC230727 for linux-xfs@oss.sgi.com; Wed, 21 Feb 2001 17:32:12 -0500 Date: Wed, 21 Feb 2001 17:32:12 -0500 From: Russell Cattelan Message-Id: <200102212232.f1LMWC230727@gibble.americas.sgi.com> Subject: TAKE - Couple of minor fixes. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Feb 21 14:31:45 PST 2001 Workarea: 128.162.195.80:/export/extra/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88101a linux/fs/xfs/xfs_log.c - 1.227 - Remove direct call to pagebuf_iorequest, use abstraction macro. linux/fs/xfs/xfs_buf.h - 1.65 - Add abstraction macro linux/fs/pagebuf/page_buf.c - 1.56 - Fix error handling of private buffer_heads so they don't end up being refiled. From owner-linux-xfs@oss.sgi.com Wed Feb 21 15:36:57 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 15:36:47 -0800 Received: from [204.191.16.3] ([204.191.16.3]:45390 "EHLO dkp.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 15:36:29 -0800 Received: (from ak@localhost) by dkp.com (8.9.3/8.9.3) id TAA03087 for linux-xfs@oss.sgi.com; Wed, 21 Feb 2001 19:32:14 -0500 Date: Wed, 21 Feb 2001 19:32:14 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: RAID5 + XFS Message-ID: <20010221193211.C2544@key.dkp.com> References: <20010221141826.A1062@key.dkp.com> <3A9416F9.28D2A634@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A9416F9.28D2A634@thebarn.com>; from cattelan@thebarn.com on Wed, Feb 21, 2001 at 07:28:57PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Feb 21, 2001 at 07:28:57PM +0000, Russell Cattelan wrote: > Andrew Klaassen wrote: > > I've consistently been getting "Unable to handle kernel NULL > > pointer dereference" errors when unmounting an XFS > > filesystem which I had created on a RAID5 device. This > > occurs with both the beta XFS and the latest CVS. > > > > Is this a known bug? Would more information be useful for you? > yes... try this patch The patch seems to have done the trick. Thanks. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Wed Feb 21 18:11:18 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 18:11:08 -0800 Received: from mail2.mia.bellsouth.net ([205.152.144.14]:18076 "EHLO mail2.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 18:10:56 -0800 Received: from bellsouth.net (adsl-61-4-147.mia.bellsouth.net [208.61.4.147]) by mail2.mia.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id VAA19130; Wed, 21 Feb 2001 21:10:53 -0500 (EST) Message-ID: <3A947AA9.F12C2572@bellsouth.net> Date: Wed, 21 Feb 2001 21:34:17 -0500 From: Juan Casero X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-SGI_XFS_PRsmp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, casero@bellsouth.net Subject: RedHat Linux 7.0 with SGI XFS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi - I have installed the modified version of RedHat 7.0 downloaded from your web site that uses the SGI XFS driver. I have been anxious to test the XFS for a long time so I made all of my linux partitions to be XFS file systems. There are some problems that I am experiencing though and I thought maybe you could help me with them. 1. For some reason when the system boots there is no device file for my IDE cdrom. This unit is the slave device on the secondary IDE channel. Browsing through the contents of the /dev directory I was able to figure out how the device files are laid out in this distribution. Further I am able to use the mknod command to create the /dev/cdrom (/dev/hdd) file and then I can mount the cdrom just fine but a reboot of the machine clears out /dev/cdrom. This tells me that the /dev entries are being dynamically created when the system boots and for some reason the kernel doesn't see my cdrom hardware. Any ideas how I can fix this? 2. If I download a plain vanilla 2.4.0 kernel and then apply the XFS patch available the kernel compile will die with an error. In fact I even tried to generate the kernel binaries that came on the cdrom you provide using the source rpms but the compile process also died. If you like I can send you a copy of the error output from my attempt to compile the plain vanilla 2.4.0 kernel with the patch applied. 3. Trying to compile the NVIDIA_kernel-0.9-6 driver from RPMS succeeds on this modified redhat 7.0 distribution but trying to load the modules fails and I get an error message about unresolved symbol irq_stat. After much fiddling I was finally able to integrate this installation using XFS into my multi boot SMP system. Right now what concerns me most is being able to compile a plain vanilla 2.4.0 kernel with the XFS patch applied. If I could do this then I am pretty sure the other problems would go away or I can at least make them go away by working around them. Could you help me out with this? Thanks, Juan Casero By the way.....when do you expect that the source code for XFS will integrated into the mainstream kernel sources? That is when is it likely that we will be able to download a plain vanilla linux kernel source and compile it with native support for XFS without having to apply patches? From owner-linux-xfs@oss.sgi.com Wed Feb 21 18:31:38 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 18:31:28 -0800 Received: from mail11.jump.net ([206.196.91.11]:5583 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 18:31:18 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f1M2VFo13695; Wed, 21 Feb 2001 20:31:15 -0600 (CST) Message-ID: <3A947A20.6E79C8BF@sgi.com> Date: Wed, 21 Feb 2001 20:32:00 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Juan Casero CC: linux-xfs@oss.sgi.com Subject: Re: RedHat Linux 7.0 with SGI XFS References: <3A947AA9.F12C2572@bellsouth.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Juan Casero wrote: > > Hi - > 1. For some reason when the system boots there is no device file for my > IDE cdrom. Nothing to fix - the installed system is using devfs and nodes do not show up until the appropriate driver is loaded. /dev is a virtual filesystem like /proc so changes are not consistent. If you turn off devfs you will need to get updated kernel sources from CVS or you will encounter a bug which is masked by devfs. Read our installer caveats page, and search google for "devfs faq" > 2. If I download a plain vanilla 2.4.0 kernel and then apply the XFS > patch available the kernel compile will die with an error. In fact > I even tried to generate the kernel binaries that came on the cdrom > you provide using the source rpms but the compile process also died. > If you like I can send you a copy of the error output from my attempt > to compile the plain vanilla 2.4.0 kernel with the patch > applied. You didn't say what the error is but odds are you need to use kgcc instead of the gcc snapshot redhat provides. If it dies almost immediately then that's likely the case. Search the patched top level Makefile for "kgcc" and follow the instructions in the comments. > 3. Trying to compile the NVIDIA_kernel-0.9-6 driver from RPMS succeeds > on this modified redhat 7.0 distribution but trying to load the modules > fails and I get an error message about unresolved symbol irq_stat. I get that too, I haven't looked at it closely - not sure what the problem is, except that binary kernel modules can't really be supported and will eventually break. > By the way.....when do you expect that the source code for XFS will > integrated into the mainstream kernel sources? That is when is it > likely that we will be able to download a plain vanilla linux kernel > source and > compile it with native support for XFS without having to apply patches? That's up to Linus... :-) Good luck, -Eric From owner-linux-xfs@oss.sgi.com Wed Feb 21 19:52:29 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 19:52:19 -0800 Received: from [65.100.85.34] ([65.100.85.34]:45190 "EHLO roujin.gargoylecc.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 19:52:01 -0800 Received: from [65.100.85.35] (IDENT:ringram@gargoyle.gargoylecc.com [65.100.85.35]) by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id MAA26002; Thu, 22 Feb 2001 12:03:32 -0700 Date: Wed, 21 Feb 2001 20:55:20 -0700 (MST) From: Russel Ingram X-Sender: To: Eric Sandeen cc: Juan Casero , Subject: Re: RedHat Linux 7.0 with SGI XFS In-Reply-To: <3A947A20.6E79C8BF@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 21 Feb 2001, Eric Sandeen wrote: > Juan Casero wrote: > > > > Hi - > > > 2. If I download a plain vanilla 2.4.0 kernel and then apply the XFS > > patch available the kernel compile will die with an error. In fact > > I even tried to generate the kernel binaries that came on the cdrom > > you provide using the source rpms but the compile process also died. > > If you like I can send you a copy of the error output from my attempt > > to compile the plain vanilla 2.4.0 kernel with the patch > > applied. > > You didn't say what the error is but odds are you need to use kgcc > instead of the gcc snapshot redhat provides. If it dies almost > immediately then that's likely the case. > > Search the patched top level Makefile for "kgcc" and follow the > instructions in the comments. > Just sort of a me too kind of thing. With my most recent installation of this thing, the kernel source that was installed from rpm also wouldn't compile and it wasn't because it was trying to use gcc instead of kgcc. When I tried it the /usr/src/linux/kdb directory was missing. I don't know if that was just a fluke in the way the rpm installed on my system or if it is just plain missing in the rpm. Juan is experiencing a problem compiling the vanilla 2.4.0 kernels as well so I suspect you are right about his problem being the compiler confusion, but if anyone else has the same compile problem I had, I just ended up blowing away the source directory and grabbing the beta kernel tree from cvs. -- --------------------------------------------------------------- "Bill Gates and Microsoft have ruined the computer industry for a long time to come by creating a class of ignorant and lazy computer users." --Russel Ingram "Mommy ... can I go out and ... KILL TONIGHT!?" --Glen Danzig, The Misfits --------------------------------------------------------------- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Wed Feb 21 21:18:09 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 21:17:59 -0800 Received: from mail4.mia.bellsouth.net ([205.152.144.16]:52414 "EHLO mail4.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 21:17:47 -0800 Received: from bellsouth.net (adsl-61-4-147.mia.bellsouth.net [208.61.4.147]) by mail4.mia.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id AAA27905; Thu, 22 Feb 2001 00:23:37 -0500 (EST) Message-ID: <3A94A67D.35BFD64C@bellsouth.net> Date: Thu, 22 Feb 2001 00:41:17 -0500 From: Juan Casero X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-SGI_XFS_PRsmp i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: RedHat Linux 7.0 with SGI XFS References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ok. I did what you told me to do below and I ran into another problem possibly a bug. I downloaded a plain vanilla 2.4.0 kernel. Applied the Feb062001prerelease.patch and configured the kernel. I checked to make sure that the kgcc line was uncommented in the top level Makefile of the kernel source tree and went ahed and installed the kgcc package from the RedHat CD. I configured the kernel and just to be safe decided to send a binary image to the floppy disk in the dive rather than muck around with the kernel images on the disk. So here is the commands I issued: # make dep;make clean;make bzdisk Well the compile seem to go ok but when the make file started to copy the kernel image to the floppy disk in the drive suddenly the system rebooted! I did this twice and each time before the kernel image dump could complete the system spontaneously rebooted. The upside of this is that I was able to see the journaling features of the XFS in action or should I say not see them! The reboot went smooth as a whistle. It was almost as if the system had been properly shutdown and restarted. It rebooted without even a hiccup! The down side of this though is that this might be indicative of a bug in the code. Any ideas? I currently use an SMP Pentium III system with 2 processors. The motherboard is a Tyan Tiger 100 Rev B. Well I guess if I insist on tinkering with beta code then there are some inconveniences I will have to live with. It is worth it though to be able to use XFS. Even so if you have any suggestions I will gladly try them. I don't think it would be too much trouble to recreate the scenario on a similar system in your lab. I will say though that I did install the update glibc-2.2 rpms from redhat's update pages. Thanks, Juan. Eric Sandeen wrote: > Juan Casero wrote: > > > > Hi - > > > 1. For some reason when the system boots there is no device file for my > > IDE cdrom. > > Nothing to fix - the installed system is using devfs and nodes do not > show up until the appropriate driver is loaded. /dev is a virtual > filesystem like /proc so changes are not consistent. If you turn off > devfs you will need to get updated kernel sources from CVS or you will > encounter a bug which is masked by devfs. Read our installer caveats > page, and search google for "devfs faq" > > > 2. If I download a plain vanilla 2.4.0 kernel and then apply the XFS > > patch available the kernel compile will die with an error. In fact > > I even tried to generate the kernel binaries that came on the cdrom > > you provide using the source rpms but the compile process also died. > > If you like I can send you a copy of the error output from my attempt > > to compile the plain vanilla 2.4.0 kernel with the patch > > applied. > > You didn't say what the error is but odds are you need to use kgcc > instead of the gcc snapshot redhat provides. If it dies almost > immediately then that's likely the case. > > Search the patched top level Makefile for "kgcc" and follow the > instructions in the comments. > > > 3. Trying to compile the NVIDIA_kernel-0.9-6 driver from RPMS succeeds > > on this modified redhat 7.0 distribution but trying to load the modules > > fails and I get an error message about unresolved symbol irq_stat. > > I get that too, I haven't looked at it closely - not sure what the > problem is, except that binary kernel modules can't really be supported > and will eventually break. > > > By the way.....when do you expect that the source code for XFS will > > integrated into the mainstream kernel sources? That is when is it > > likely that we will be able to download a plain vanilla linux kernel > > source and > > compile it with native support for XFS without having to apply patches? > > That's up to Linus... :-) > > Good luck, > -Eric From owner-linux-xfs@oss.sgi.com Wed Feb 21 21:30:29 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 21:30:19 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39968 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 21:29:56 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA02225 for ; Wed, 21 Feb 2001 21:38:54 -0800 (PST) mail_from (kaos@melbourne.sgi.com) Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id VAA36881 for ; Wed, 21 Feb 2001 21:28:51 -0800 (PST) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id QAA02048; Thu, 22 Feb 2001 16:27:30 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Juan Casero cc: linux-xfs@oss.sgi.com Subject: Re: RedHat Linux 7.0 with SGI XFS In-reply-to: Your message of "Thu, 22 Feb 2001 00:41:17 CDT." <3A94A67D.35BFD64C@bellsouth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Feb 2001 16:27:30 +1100 Message-ID: <3323.982819650@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 22 Feb 2001 00:41:17 -0500, Juan Casero wrote: ># make dep;make clean;make bzdisk > >Well the compile seem to go ok but when the make file started to copy the >kernel image >to the floppy disk in the drive suddenly the system rebooted! Your message lines are strangely formatted, it looks like you type long lines and something is wrapping them. For make bzdisk, try this patch. Index: 2.2/arch/i386/boot/Makefile --- 2.2/arch/i386/boot/Makefile Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/T/c/44_Makefile 1.1 644) +++ 2.2(w)/arch/i386/boot/Makefile Thu, 22 Feb 2001 16:26:33 +1100 kaos (linux-2.4/T/c/44_Makefile 1.1 644) @@ -27,7 +27,7 @@ @$(MAKE) -C compressed bvmlinux zdisk: $(BOOTIMAGE) - dd bs=8192 if=$(BOOTIMAGE) of=/dev/fd0 + dd conv=notrunc bs=8192 if=$(BOOTIMAGE) of=/dev/fd0 zlilo: $(CONFIGURE) $(BOOTIMAGE) if [ -f $(INSTALL_PATH)/vmlinuz ]; then mv $(INSTALL_PATH)/vmlinuz $(INSTALL_PATH)/vmlinuz.old; fi From owner-linux-xfs@oss.sgi.com Wed Feb 21 21:39:20 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 21:39:00 -0800 Received: from mail4.mia.bellsouth.net ([205.152.144.16]:52684 "EHLO mail4.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 21:38:56 -0800 Received: from bellsouth.net (adsl-61-4-147.mia.bellsouth.net [208.61.4.147]) by mail4.mia.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id AAA05687; Thu, 22 Feb 2001 00:44:45 -0500 (EST) Message-ID: <3A94AB71.F1FCFAEE@bellsouth.net> Date: Thu, 22 Feb 2001 01:02:25 -0500 From: Juan Casero X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-SGI_XFS_PRsmp i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: RedHat Linux 7.0 with SGI XFS References: <3323.982819650@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Sorry about the formatting issue. It's this bloody Netscape mail client. I normally use the the KDE desktop but I decided to give GNOME a try for this install with XFS. There doesn't seem to be a mail client with GNOME that I feel comfortable with. Communicator's mail client is a temporary fix until I find something better. I tried to apply the patch you gave me but it don't work. I am using the 2.4.0 kernel patched with the XFS code. Here is the output when I try to apply your patch. [root@cedar linux]# patch -p1 < /home/juan/floppy.patch patching file arch/i386/boot/Makefile Hunk #1 FAILED at 27. 1 out of 1 hunk FAILED -- saving rejects to file arch/i386/boot/Makefile.rej I tried from different locations in the source tree to no avail. Any ideas? Thanks, Juan. Keith Owens wrote: > On Thu, 22 Feb 2001 00:41:17 -0500, > Juan Casero wrote: > ># make dep;make clean;make bzdisk > > > >Well the compile seem to go ok but when the make file started to copy the > >kernel image > >to the floppy disk in the drive suddenly the system rebooted! > > Your message lines are strangely formatted, it looks like you type long > lines and something is wrapping them. > > For make bzdisk, try this patch. > > Index: 2.2/arch/i386/boot/Makefile > --- 2.2/arch/i386/boot/Makefile Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/T/c/44_Makefile 1.1 644) > +++ 2.2(w)/arch/i386/boot/Makefile Thu, 22 Feb 2001 16:26:33 +1100 kaos (linux-2.4/T/c/44_Makefile 1.1 644) > @@ -27,7 +27,7 @@ > @$(MAKE) -C compressed bvmlinux > > zdisk: $(BOOTIMAGE) > - dd bs=8192 if=$(BOOTIMAGE) of=/dev/fd0 > + dd conv=notrunc bs=8192 if=$(BOOTIMAGE) of=/dev/fd0 > > zlilo: $(CONFIGURE) $(BOOTIMAGE) > if [ -f $(INSTALL_PATH)/vmlinuz ]; then mv $(INSTALL_PATH)/vmlinuz $(INSTALL_PATH)/vmlinuz.old; fi From owner-linux-xfs@oss.sgi.com Wed Feb 21 21:43:50 2001 Received: by oss.sgi.com id ; Wed, 21 Feb 2001 21:43:30 -0800 Received: from nic-31-c12-219.mn.mediaone.net ([24.31.12.219]:26888 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Wed, 21 Feb 2001 21:43:22 -0800 Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130]) by lupo.thebarn.com (8.11.2/8.11.0) with ESMTP id f1M5guf25420; Wed, 21 Feb 2001 23:42:56 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <3A94A6DA.37B2AC49@thebarn.com> Date: Wed, 21 Feb 2001 23:42:50 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Juan Casero CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: RedHat Linux 7.0 with SGI XFS References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> <3A94A67D.35BFD64C@bellsouth.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Juan Casero wrote: > Ok. I did what you told me to do below and I ran into another problem > possibly a bug. > > I downloaded a plain vanilla 2.4.0 kernel. Applied the > Feb062001prerelease.patch > and configured the kernel. I checked to make sure that the kgcc line was > uncommented > in the top level Makefile of the kernel source tree and went ahed and > installed the kgcc > package from the RedHat CD. I configured the kernel and just to be safe > decided to send > a binary image to the floppy disk in the dive rather than muck around with > the kernel images > on the disk. So here is the commands I issued: > > # make dep;make clean;make bzdisk Umm well that isn't going to work :-( The kernel with XFS compiled in will be to large to fit on a floppy. If you are concerned about kernel versions simply modify the flag EXTRAVERSION in the top level Makefile to some unique name. Add the new kernel name to /etc/lilo.conf Then run: make clean depend bzImage modules install modules_install The reset is odd... probably a general linux bug rather than an XFS specific bug. > > Well the compile seem to go ok but when the make file started to copy the > kernel image > to the floppy disk in the drive suddenly the system rebooted! I did this > twice and each time > before the kernel image dump could complete the system spontaneously > rebooted. The upside > of this is that I was able to see the journaling features of the XFS in > action or should I say not see > them! The reboot went smooth as a whistle. It was almost as if the system > had been properly shutdown > and restarted. It rebooted without even a hiccup! The down side of this > though is that this might be indicative > of a bug in the code. Any ideas? > > I currently use an SMP Pentium III system with 2 processors. The motherboard > is a Tyan Tiger 100 Rev B. > > Well I guess if I insist on tinkering with beta code then there are some > inconveniences I will have to live with. > It is worth it though to be able to use XFS. Even so if you have any > suggestions I will gladly try them. I don't > think it would be too much trouble to recreate the scenario on a similar > system in your lab. I will say though that > I did install the update glibc-2.2 rpms from redhat's update pages. > > Thanks, > Juan. > > Eric Sandeen wrote: > > > Juan Casero wrote: > > > > > > Hi - > > > > > 1. For some reason when the system boots there is no device file for my > > > IDE cdrom. > > > > Nothing to fix - the installed system is using devfs and nodes do not > > show up until the appropriate driver is loaded. /dev is a virtual > > filesystem like /proc so changes are not consistent. If you turn off > > devfs you will need to get updated kernel sources from CVS or you will > > encounter a bug which is masked by devfs. Read our installer caveats > > page, and search google for "devfs faq" > > > > > 2. If I download a plain vanilla 2.4.0 kernel and then apply the XFS > > > patch available the kernel compile will die with an error. In fact > > > I even tried to generate the kernel binaries that came on the cdrom > > > you provide using the source rpms but the compile process also died. > > > If you like I can send you a copy of the error output from my attempt > > > to compile the plain vanilla 2.4.0 kernel with the patch > > > applied. > > > > You didn't say what the error is but odds are you need to use kgcc > > instead of the gcc snapshot redhat provides. If it dies almost > > immediately then that's likely the case. > > > > Search the patched top level Makefile for "kgcc" and follow the > > instructions in the comments. > > > > > 3. Trying to compile the NVIDIA_kernel-0.9-6 driver from RPMS succeeds > > > on this modified redhat 7.0 distribution but trying to load the modules > > > fails and I get an error message about unresolved symbol irq_stat. > > > > I get that too, I haven't looked at it closely - not sure what the > > problem is, except that binary kernel modules can't really be supported > > and will eventually break. > > > > > By the way.....when do you expect that the source code for XFS will > > > integrated into the mainstream kernel sources? That is when is it > > > likely that we will be able to download a plain vanilla linux kernel > > > source and > > > compile it with native support for XFS without having to apply patches? > > > > That's up to Linus... :-) > > > > Good luck, > > -Eric From owner-linux-xfs@oss.sgi.com Thu Feb 22 01:16:53 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 01:16:43 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:40204 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Thu, 22 Feb 2001 01:16:25 -0800 Received: (qmail 19058 invoked from network); 22 Feb 2001 09:16:19 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 22 Feb 2001 09:16:19 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Juan Casero cc: linux-xfs@oss.sgi.com Subject: Re: RedHat Linux 7.0 with SGI XFS In-reply-to: Your message of "Thu, 22 Feb 2001 01:02:25 CDT." <3A94AB71.F1FCFAEE@bellsouth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Feb 2001 20:16:18 +1100 Message-ID: <4673.982833378@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 22 Feb 2001 01:02:25 -0500, Juan Casero wrote: >[root@cedar linux]# patch -p1 < /home/juan/floppy.patch >patching file arch/i386/boot/Makefile >Hunk #1 FAILED at 27. >1 out of 1 hunk FAILED -- saving rejects to file arch/i386/boot/Makefile.rej Probably some mail system has converted the patch from tabs to spaces. It is only a one line change, add 'conv=notrunc' to the zdisk dd command in arch/i386/boot/Makefile. But as Russell pointed out, an XFS enabled kernel is too big for a floppy anyway. From owner-linux-xfs@oss.sgi.com Thu Feb 22 03:31:54 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 03:31:44 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:2827 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 03:31:26 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id IAA10171; Thu, 22 Feb 2001 08:31:01 -0300 Date: Thu, 22 Feb 2001 07:44:33 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Rajagopal Ananthanarayanan cc: dcox@connex.com, Linux-XFS Subject: Re: Repeatable Panics with XFS and RAID1 (long) In-Reply-To: <3A943966.8F27E502@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 21 Feb 2001, Rajagopal Ananthanarayanan wrote: > Danny wrote: > > > Feb 20 12:51:38 dsc_proto_1 kernel: __alloc_pages: 0-order allocation > > failed. > > For those seeing __alloc_pages failing, can you please try this patch? > With recent code changes, writepage() is used for flushing dirty pages, > and this typically happens under memory pressure. So, doing anything > expensive to allocate memory under these conditions is bad. Ananth, I think allocating memory from the atomic queue (used mainly by in interrupt context) to generate dirty data may cause problems. From owner-linux-xfs@oss.sgi.com Thu Feb 22 03:43:33 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 03:43:24 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:4875 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 03:43:09 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id IAA10227; Thu, 22 Feb 2001 08:42:45 -0300 Date: Thu, 22 Feb 2001 07:56:17 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Rajagopal Ananthanarayanan cc: dcox@connex.com, Linux-XFS Subject: Re: Repeatable Panics with XFS and RAID1 (long) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 22 Feb 2001, Marcelo Tosatti wrote: > > > On Wed, 21 Feb 2001, Rajagopal Ananthanarayanan wrote: > > > Danny wrote: > > > > > Feb 20 12:51:38 dsc_proto_1 kernel: __alloc_pages: 0-order allocation > > > failed. > > > > For those seeing __alloc_pages failing, can you please try this patch? > > With recent code changes, writepage() is used for flushing dirty pages, > > and this typically happens under memory pressure. So, doing anything > > expensive to allocate memory under these conditions is bad. > > Ananth, > > I think allocating memory from the atomic queue (used mainly by in > interrupt context) to generate dirty data may cause problems. I'll write the GFP_PAGE_IO thing we talked about RSN to avoid having to use GFP_ATOMIC. From owner-linux-xfs@oss.sgi.com Thu Feb 22 04:00:54 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 04:00:34 -0800 Received: from jeremi.jeremi.pl ([212.160.232.2]:34747 "EHLO jeremi.jeremi.pl") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 04:00:13 -0800 Received: from jeremi.pl (nobody@localhost [127.0.0.1]) by jeremi.jeremi.pl (8.10.1/8.10.1) with SMTP id f1MDvM007190 for ; Thu, 22 Feb 2001 14:57:22 +0100 Received: from 212.160.232.6 (SquirrelMail authenticated user linux-xfs) by mail.jeremi.pl with HTTP; Thu, 22 Feb 2001 14:57:22 +0100 (CET) Message-ID: <1460.212.160.232.6.982850242.squirrel@mail.jeremi.pl> Date: Thu, 22 Feb 2001 14:57:22 +0100 (CET) Subject: Hardware fault intolerance... From: "Irresponsible & Crazy" To: linux-xfs@oss.sgi.com X-Mailer: SquirrelMail (version 1.0pre2) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Does anybody know how xfs handles "just appeared" badblocks? If even... How to inform xfs about badblocks (if that's possible) to let xfs avoid them or just kiss hdd goodbye I took latest cvs snapshot (21.02.2001 18:00CET), made kernel and set vga=9 to see whole Oops output and I think I know where exactly those bads hide on my hdd, I should have Oops in my next post if anybody interested... Filip -- "Oh shit! o shit! o shit! I'm gonna die! I'm gonna die!" - Rincewind From owner-linux-xfs@oss.sgi.com Thu Feb 22 04:55:54 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 04:55:44 -0800 Received: from 66-2-81-26.customer.algx.net ([66.2.81.26]:21543 "EHLO wiley.ceo.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 04:55:31 -0800 Received: from mindspring.com (IDENT:danny@localhost [127.0.0.1]) by wiley.ceo.com (8.9.3/8.9.3) with ESMTP id IAA06731 for ; Thu, 22 Feb 2001 08:07:22 -0500 Message-ID: <3A950F0A.77EA2CCC@mindspring.com> Date: Thu, 22 Feb 2001 08:07:22 -0500 From: Danny Reply-To: dcox@connex.com Organization: Connex Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-XFS Subject: xfs_buf.h patch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing All, A small addendum to last night's CVS addition: --- linux.sgi/fs/xfs/xfs_buf.h Thu Feb 22 07:49:11 2001 +++ linux.hacked/fs/xfs/xfs_buf.h Thu Feb 22 08:02:24 2001 @@ -299,7 +299,7 @@ #define xfs_bdwrite(mp, bp) XFS_bdwrite(bp) -#define XFS_bdstrat(bp) pagbuf_iorequest(bp) +#define XFS_bdstrat(bp) pagebuf_iorequest(bp) #define xfs_iowait(pb) \ pagebuf_iowait(pb) -- "Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill Danny From owner-linux-xfs@oss.sgi.com Thu Feb 22 05:11:44 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 05:11:35 -0800 Received: from [212.216.176.239] ([212.216.176.239]:40905 "EHLO fep03-svc.tin.it") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 05:11:19 -0800 Received: from tin.it ([212.171.41.183]) by fep03-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with ESMTP id <20010222131111.COIT5943.fep03-svc.tin.it@tin.it> for ; Thu, 22 Feb 2001 14:11:11 +0100 Message-ID: <3A9511E2.3927D392@tin.it> Date: Thu, 22 Feb 2001 14:19:30 +0100 From: Giuseppe Zompatori X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i586) X-Accept-Language: it, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Kernel 2.4.2 Released Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi there, You are probably happy to know 2.4.2 has just been released... It seems like the elevator bug has been fixed finally :-) http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.2 From owner-linux-xfs@oss.sgi.com Thu Feb 22 05:13:54 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 05:13:44 -0800 Received: from garnet.sover.net ([209.198.87.53]:32229 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 05:13:35 -0800 Received: from [192.168.1.3] (pm1a14.stj.sover.net [209.198.94.14]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id IAA15041 for ; Thu, 22 Feb 2001 08:13:22 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from pm1a14.stj.sover.net [209.198.94.14] 209.198.94.14 Thu, 22 Feb 2001 08:13:22 -0500 (EST) Date: Thu, 22 Feb 2001 07:51:01 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: SGI XFS Mailing List Subject: misc mount/umount errors Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Greetings all, I have been running XFS for a few months now, and have notices a few errors while mounting/umounting drives. I am running the CVS kernel on a debian/unstable box. I have reiser, XFS and devfs running on my system as well. On bootup, I get this: read_super_block: can't find a reiserfs filesystem on dev 03:06 read_old_super_block: try to find super block in old location read_old_super_block: can't find a reiserfs filesystem on dev 03:06. Start mounting filesystem: ide0(3,6) Ending clean XFS mount for filesystem: ide0(3,6) VFS: Mounted root (xfs filesystem) readonly. Now, I know that is a reiser error, but I can't figure out why that is happening. ide0(3,6) is my root partition, here's the line from my fstab: /dev/hda6 / xfs defaults 0 1 so why is it attempting to mount it as reiser? This is just an error, everything *works* fine. Could this be because of devfs? i.e. devfs is not running when my root partition is mounted so it comes up with that error? The other issue I have run into is when I shutdown, it seems to take a *long* time to umount everything. not sure if it's reiser or XFS causeing the hangup...I am going to edit my init scripts and make them more verbose so I can see where it hangs. it takes about 10 seconds to umount all my local filesystems..which is just a 20gb drive (about 6 partitions I believe) Last item is RAID/LVM compatibility. I understand that there are/were issues with software RAID and XFS. I am getting a hardware RAID card and will be using it in a RAID0 configuration. I just wanted to be sure that won't be a problem. I also intend on using LVM with it. Are there any known issues with LVM and XFS? Or even reiser and LVM, for that matter (doesn't hurt to ask :) Thank you in advance for the time. Jason Walker/RegEx From owner-linux-xfs@oss.sgi.com Thu Feb 22 05:19:54 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 05:19:45 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:9483 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 05:19:28 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id KAA11016; Thu, 22 Feb 2001 10:19:16 -0300 Date: Thu, 22 Feb 2001 09:32:48 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: dcox@connex.com cc: Linux-XFS Subject: Re: Repeatable Panics with XFS and RAID1 (long) In-Reply-To: <3A941353.6B88C8C9@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 21 Feb 2001, Danny wrote: > Item final: I've seen the messages: > > cluster_write: can't get pb (page_buf_io.c:1839) > cluster_write: pb_lookup_pages failed! (page_buf_io.c:1844) > > and the process hung. The only out was a reboot, and that filesystem > refused to be unmounted. ps(1) showed the process status as 'D', > uninterruptable sleep :-(. Hi, Could you please try the following patch against current XFS tree and report results? You still need the pagbuf -> pagebuf typo patch you just sent on top of this to make it compile. Thanks. Index: mm/vmscan.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/mm/vmscan.c,v retrieving revision 1.48 diff -u -r1.48 vmscan.c --- mm/vmscan.c 2001/02/09 20:44:34 1.48 +++ mm/vmscan.c 2001/02/22 12:22:15 @@ -427,7 +427,7 @@ #define MAX_LAUNDER (4 * (1 << page_cluster)) int page_launder(int gfp_mask, int sync) { - int launder_loop, maxscan, cleaned_pages, maxlaunder; + int launder_loop, maxscan, cleaned_pages, maxlaunder, can_queue_buffers; int can_get_io_locks; struct list_head * page_lru; struct page * page; @@ -437,6 +437,7 @@ * buffers to disk) if __GFP_IO is set. */ can_get_io_locks = gfp_mask & __GFP_IO; + can_queue_buffers = gfp_mask & __GFP_PAGE_IO; launder_loop = 0; maxlaunder = 0; @@ -488,7 +489,7 @@ goto page_active; /* First time through? Move it to the back of the list */ - if (!launder_loop) { + if (!launder_loop || !can_get_io_locks) { list_del(page_lru); list_add(page_lru, &inactive_dirty_list); UnlockPage(page); @@ -618,7 +619,8 @@ * loads, flush out the dirty pages before we have to wait on * IO. */ - if (can_get_io_locks && !launder_loop && free_shortage()) { + if ((can_get_io_locks || can_queue_buffers) && !launder_loop + && free_shortage()) { launder_loop = 1; /* If we cleaned pages, never do synchronous IO. */ if (cleaned_pages) Index: fs/pagebuf/page_buf.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/pagebuf/page_buf.c,v retrieving revision 1.56 diff -u -r1.56 page_buf.c --- fs/pagebuf/page_buf.c 2001/02/21 22:31:45 1.56 +++ fs/pagebuf/page_buf.c 2001/02/22 12:22:46 @@ -497,7 +497,7 @@ */ if (flags & PBF_MAPPABLE) { - gfp_mask = GFP_BUFFER; + gfp_mask = GFP_PAGE_IO; } else { gfp_mask = GFP_HIGHUSER; } @@ -1341,7 +1341,7 @@ */ psync = (pagesync_t *) kmalloc(sizeof(pagesync_t) + - blk_length * sizeof(struct buffer_head *), GFP_BUFFER); + blk_length * sizeof(struct buffer_head *), GFP_PAGE_IO); /* Ugh - out of memory condition here */ if (psync == NULL) @@ -1354,7 +1354,7 @@ for (cnt = 0; blk_length > 0; blk_length--, blk_offset++, pg_offset += sector) { - bh = kmem_cache_alloc(bh_cachep, SLAB_BUFFER); + bh = kmem_cache_alloc(bh_cachep, SLAB_PAGE_IO); if (bh == NULL){ err = -ENOMEM; goto error; Index: fs/pagebuf/page_buf_io.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/pagebuf/page_buf_io.c,v retrieving revision 1.53 diff -u -r1.53 fs/pagebuf/page_buf_io.c --- fs/pagebuf/page_buf_io.c 2001/02/21 00:50:22 1.53 +++ fs/pagebuf/page_buf_io.c 2001/02/22 12:23:27 @@ -261,7 +261,7 @@ * since this can be in kswapd's path ... */ cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * sizeof(struct page *), - GFP_BUFFER); + GFP_PAGE_IO); spin_lock(&pagecache_lock); _pagebuf_flush(ip, &ip->i_mapping->clean_pages, ioff, cpages); @@ -1084,7 +1084,7 @@ current->flags |= PF_MEMALLOC; cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * sizeof(struct page *), - GFP_BUFFER); + GFP_PAGE_IO); do_write_full_page++; Index: include/linux/slab.h =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/include/linux/slab.h,v retrieving revision 1.12 diff -u -r1.12 slab.h --- include/linux/slab.h 2001/01/03 01:43:05 1.12 +++ include/linux/slab.h 2001/02/22 12:25:32 @@ -21,8 +21,9 @@ #define SLAB_KERNEL GFP_KERNEL #define SLAB_NFS GFP_NFS #define SLAB_DMA GFP_DMA +#define SLAB_PAGE_IO GFP_PAGE_IO -#define SLAB_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO) +#define SLAB_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_PAGE_IO) #define SLAB_NO_GROW 0x00001000UL /* don't grow a cache */ /* flags to pass to kmem_cache_create(). Index: include/linux/mm.h =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/include/linux/mm.h,v retrieving revision 1.48 diff -u -r1.48 mm.h --- include/linux/mm.h 2001/02/14 23:54:41 1.48 +++ include/linux/mm.h 2001/02/22 12:25:50 @@ -468,8 +468,9 @@ #define __GFP_HIGHMEM 0x0 /* noop */ #endif #define __GFP_VM 0x20 +#define __GFP_PAGE_IO 0x40 - +#define GFP_PAGE_IO (__GFP_HIGH | __GFP_WAIT | __GFP_PAGE_IO) #define GFP_BUFFER (__GFP_HIGH | __GFP_WAIT) #define GFP_ATOMIC (__GFP_HIGH) #define GFP_USER ( __GFP_WAIT | __GFP_IO) From owner-linux-xfs@oss.sgi.com Thu Feb 22 06:17:45 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 06:17:36 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:27149 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 06:17:21 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.22 #4) id 14VwYR-0006QV-00; Thu, 22 Feb 2001 15:17:11 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14VwYN-0007IU-00; Thu, 22 Feb 2001 15:17:07 +0100 Date: Thu, 22 Feb 2001 15:17:07 +0100 From: Jens Axboe To: Giuseppe Zompatori Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.2 Released Message-ID: <20010222151707.F17276@suse.de> References: <3A9511E2.3927D392@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A9511E2.3927D392@tin.it>; from mailus@tin.it on Thu, Feb 22, 2001 at 02:19:30PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, Feb 22 2001, Giuseppe Zompatori wrote: > It seems like the elevator bug has been fixed finally :-) There are no known cases of people being hit by this bug, so it was in no way crucial. Machines have run for days doing heavy I/O, specweb99 tests etc, no problems noticed. Maybe you are confusing this bug with some discussed here earlier? Still, it's nice to have it fixed :-) -- Jens Axboe From owner-linux-xfs@oss.sgi.com Thu Feb 22 06:43:16 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 06:42:56 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:18003 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 06:42:33 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA05301 for ; Thu, 22 Feb 2001 06:50:50 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA901741; Thu, 22 Feb 2001 08:38:29 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA35415; Thu, 22 Feb 2001 08:38:28 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1MEcUw19960; Thu, 22 Feb 2001 08:38:30 -0600 Message-Id: <200102221438.f1MEcUw19960@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jason Walker cc: SGI XFS Mailing List , mason@suse.com (Chris Mason) Subject: Re: misc mount/umount errors In-Reply-To: Message from Jason Walker of "Thu, 22 Feb 2001 07:51:01 EST." Date: Thu, 22 Feb 2001 08:38:30 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This error message is because the way the root mount works is it keeps trying different filesystem types until it succeeds, reiserfs is in there before XFS. I saw someone float a patch which specified the rootfs type as a kernel boot option, I do not know if this will make it into Linus's tree or not. Maybe reiserfs (and XFS) should not be so chatty on a failed mount in this case. I added Chris Mason to the cc list, he may have some input on cleaning up failed mount output and the other reiserfs question you had. XFS should have no problems with hardware raid, lvm works to I think, but I am not sure performance is the best right now. The unmount stuff is mostly the root filesystem unmount, on Irix there is no option to remount a filesstem readonly which is the standard Linux shutdown procedure, we added code to make this functionality in Linux, but it is not the fastest it could be (there are some sleeps in there at the moment!). Steve > Greetings all, > > I have been running XFS for a few months now, and have notices a few er > rors while mounting/umounting drives. I am > running the CVS kernel on a debian/unstable box. I have reiser, XFS and devf > s running on my system as well. > On bootup, I get this: > > read_super_block: can't find a reiserfs filesystem on dev 03:06 > read_old_super_block: try to find super block in old location > read_old_super_block: can't find a reiserfs filesystem on dev 03:06. > Start mounting filesystem: ide0(3,6) > Ending clean XFS mount for filesystem: ide0(3,6) > VFS: Mounted root (xfs filesystem) readonly. > > Now, I know that is a reiser error, but I can't figure out why that is > happening. ide0(3,6) is my root partition, > here's the line from my fstab: > > /dev/hda6 / xfs defaults 0 1 > > so why is it attempting to mount it as reiser? This is just an error, e > verything *works* fine. Could this be because > of devfs? i.e. devfs is not running when my root partition is mounted so it c > omes up with that error? > The other issue I have run into is when I shutdown, it seems to take a > *long* time to umount everything. not sure if > it's reiser or XFS causeing the hangup...I am going to edit my init scripts a > nd make them more verbose so I can see where > it hangs. it takes about 10 seconds to umount all my local filesystems..whic > h is just a 20gb drive (about 6 partitions I > believe) > Last item is RAID/LVM compatibility. I understand that there are/were > issues with software RAID and XFS. I am getting > a hardware RAID card and will be using it in a RAID0 configuration. I just w > anted to be sure that won't be a problem. > I also intend on using LVM with it. Are there any known issues with L > VM and XFS? Or even reiser and LVM, for that > matter (doesn't hurt to ask :) > Thank you in advance for the time. > > Jason Walker/RegEx > > From owner-linux-xfs@oss.sgi.com Thu Feb 22 07:06:36 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 07:06:16 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29783 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 07:06:10 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08352 for ; Thu, 22 Feb 2001 07:15:27 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA901858; Thu, 22 Feb 2001 09:04:00 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA21736; Thu, 22 Feb 2001 09:04:00 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1MF41r20047; Thu, 22 Feb 2001 09:04:01 -0600 Message-Id: <200102221504.f1MF41r20047@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Thomas Graichen , thomas.graichen@innominate.com cc: linux-xfs@oss.sgi.com Subject: Re: mysterious dbench results In-Reply-To: Message from Thomas Graichen of "18 Feb 2001 17:51:04 GMT." Date: Thu, 22 Feb 2001 09:04:01 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have been out for a while, or I would have posted something on this earlier. The default mkfs options for xfs are not optimal for heavy I/O load, they are somewhat historical and should probably be changed. On mkfs try some options like this: mkfs -t xfs -f -l size=32768b /dev/xxx on mount use these extra options: logbufs=4,logbsize=32768 The first will make the on disk log bigger which helps metadata intensive loads not become purely log bound - every request for log space ends up having to flush metadata to disk. The mount options allow more log writes to be in progress at once. These should help XFS performance here, I suspect, but have not tried that this will also help: echo 5000 > /proc/sys/vm/pagebuf/flush_int This will make the interval between dirtying file data and flushing it to disk closer to that used by ext2. One of the issues with dbench is files getting removed shortly after they are created, you can get mush better performance if the removal happens before the data goes out to disk. In the long run Ananth's development direction is probably the correct fix for this, we would end up using the same mechanisms as other filesystems for controlling flushing file data to disk. Steve > Thomas Graichen wrote: > > ok - now tested it on one machine once in smp and once in up mode > > and got the same results (very bad dbench results compared to > > ext2 or reiserfs) ... so it's not smp related - i'm right now > > updating the kernel and will post again - if the problem is > > still there ... > > ... and it is - so the question: anyone else seing this? - as said > dbench results are about 1/4th of ext2 results with the current > XFS tree on an ide disk system for smp and nosmp > > t > From owner-linux-xfs@oss.sgi.com Thu Feb 22 07:50:16 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 07:50:06 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:64274 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 07:49:59 -0800 Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.2/8.10.1) with ESMTP id f1MFnYb45575; Thu, 22 Feb 2001 09:49:54 -0600 (CST) Message-ID: <3A953508.B0640014@thebarn.com> Date: Thu, 22 Feb 2001 09:49:29 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: dcox@connex.com CC: Linux-XFS Subject: Re: xfs_buf.h patch References: <3A950F0A.77EA2CCC@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Danny wrote: I did build the tree before I checked this in! really! :-) Sorry folks... will fix. > All, > > A small addendum to last night's CVS addition: > > --- linux.sgi/fs/xfs/xfs_buf.h Thu Feb 22 07:49:11 2001 > +++ linux.hacked/fs/xfs/xfs_buf.h Thu Feb 22 08:02:24 2001 > @@ -299,7 +299,7 @@ > > #define xfs_bdwrite(mp, bp) XFS_bdwrite(bp) > > -#define XFS_bdstrat(bp) pagbuf_iorequest(bp) > +#define XFS_bdstrat(bp) pagebuf_iorequest(bp) > > #define xfs_iowait(pb) \ > pagebuf_iowait(pb) > > -- > "Men occasionally stumble over the truth, but most of them pick > themselves up and hurry off as if nothing had happened." > -- Winston Churchill > > Danny -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Thu Feb 22 07:53:15 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 07:53:06 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:25696 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 07:52:59 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA05485 for ; Thu, 22 Feb 2001 08:01:01 -0800 (PST) mail_from (lord@sgi.com) Received: from zeus-fddi.americas.sgi.com ([128.162.8.103]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA50763 for ; Thu, 22 Feb 2001 07:50:53 -0800 (PST) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA903275; Thu, 22 Feb 2001 09:49:37 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA18271; Thu, 22 Feb 2001 09:49:36 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1MFnbB14072; Thu, 22 Feb 2001 09:49:37 -0600 Message-Id: <200102221549.f1MFnbB14072@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marcelo Tosatti cc: linux-xfs@oss.sgi.com Subject: Re: _pagebuf_lookup_pages() allocation flags In-Reply-To: Message from Marcelo Tosatti of "Fri, 16 Feb 2001 18:11:17 -0200." Date: Thu, 22 Feb 2001 09:49:36 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Hi, > > I noticed that _pagebuf_lookup_pages() may use two different allocation > flags to allocate invalid pages depending on PBF_MAPPABLE flag: > > /* For pagebufs where we want to map an address, do not use > * highmem pages - so that we do not need to use kmap resources > * to access the data. > */ > > if (flags & PBF_MAPPABLE) { > gfp_mask = GFP_BUFFER; > } else { > gfp_mask = GFP_HIGHUSER; > } > > > My question is if only when the caller sets PBF_MAPPABLE it may hold some > fs lock? (thats why GFP_BUFFER was used, I suppose) > > If callers which do not set PBF_MAPPABLE may have locks which are used on > the ->writepage() codepath, it may be a problem (deadlock). > > I tried to track down the callers, but I want to read pagebuf code for now > and the whole XFS code :) > > The background here is that most metadata requests for a buffer in xfs use the PBF_MAPPABLE flag, it is intended to mean that we will be manipulating the buffer contents directly from kernel space, so must have non-highmem pages. There are actually a couple of cases where we also remap the pages to be contiguous in kernel space - this would be nice to get rid of, it is on my todo list. File data buffers are usually requested with the xfs iolock held on the inode, this does not cause any problems for page_launder coming back into the filesystem and asking us to remove other pages from the cache. Metadata buffers are often requested with filesystem locks held, sometimes on other metadata buffers, other times the xfs ilock on an inode, all of these can potentially cause deadlocks if we get a request to flush a delalloc page out to disk as the conversion from delalloc to real disk space may use the same locks. We did originally use GFP_KERNEL, but deadlocks arose, which is why it is GFP_BUFFER now. Other kernel changes may have removed this requirement now, but I doubt it. The reason this works in Irix is that the memory reclaim path there will recognize delalloc data and hand it off to xfs to convert and flush to disk, it does not expect it to become clean immediately. Irix also recognizes metadata objects which are not in a flushable state and skips them in this path. Note also that Irix does these operations on buffers (which can be variable size), not on individual pages of memory. Steve From owner-linux-xfs@oss.sgi.com Thu Feb 22 08:15:47 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 08:15:36 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42341 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 08:15:24 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA06936 for ; Thu, 22 Feb 2001 08:23:33 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA11285 for ; Thu, 22 Feb 2001 10:12:43 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.2/8.11.2) id f1MGBdR03772 for linux-xfs@oss.sgi.com; Thu, 22 Feb 2001 11:11:39 -0500 Date: Thu, 22 Feb 2001 11:11:39 -0500 From: Russell Cattelan Message-Id: <200102221611.f1MGBdR03772@gibble.americas.sgi.com> Subject: TAKE - fix typo To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Feb 22 08:11:18 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88148a linux/fs/xfs/xfs_buf.h - 1.66 - fix typo From owner-linux-xfs@oss.sgi.com Thu Feb 22 08:17:57 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 08:17:36 -0800 Received: from mail11.jump.net ([206.196.91.11]:33451 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 08:17:22 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f1MGHI806302; Thu, 22 Feb 2001 10:17:18 -0600 (CST) Message-ID: <3A953BC2.FCB08847@sgi.com> Date: Thu, 22 Feb 2001 10:18:10 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Jens Axboe CC: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.2 Released References: <3A9511E2.3927D392@tin.it> <20010222151707.F17276@suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jens, I don't see anything about the loop fixes in the changelog... did that make it in? -Eric Jens Axboe wrote: > > On Thu, Feb 22 2001, Giuseppe Zompatori wrote: > > It seems like the elevator bug has been fixed finally :-) > > There are no known cases of people being hit by this bug, so > it was in no way crucial. Machines have run for days doing > heavy I/O, specweb99 tests etc, no problems noticed. Maybe > you are confusing this bug with some discussed here earlier? > > Still, it's nice to have it fixed :-) > > -- > Jens Axboe From owner-linux-xfs@oss.sgi.com Thu Feb 22 08:55:27 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 08:55:07 -0800 Received: from lucy.physik.TU-Cottbus.De ([141.43.75.1]:7701 "HELO lucy.physik.tu-cottbus.de") by oss.sgi.com with SMTP id ; Thu, 22 Feb 2001 08:54:55 -0800 Received: (qmail 40629 invoked from network); 22 Feb 2001 16:54:52 -0000 Received: from high.physik.tu-cottbus.de (george@141.43.75.18) by lucy.physik.tu-cottbus.de with SMTP; 22 Feb 2001 16:54:52 -0000 Date: Thu, 22 Feb 2001 17:54:52 +0100 From: Ionut Georgescu To: SGI XFS Mailing List Subject: Re: misc mount/umount errors In-Reply-To: <200102221438.f1MEcUw19960@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Speaking of very long shutdown times. I have here some Indy's which need 5 min to unmount some nfs filesystems (Irix and Linux servers). Do you have any idea why ? This makes rebooting a pane on these machines. Thabks a lot, Ionut *************** * Ionut Georgescu * http://www.physik.tu-cottbus.de/~george/ * ICQ: 38973105 * "In Windows you can do everything Microsoft wants you to do; in Unix you * can do anything the computer is able to do." From owner-linux-xfs@oss.sgi.com Thu Feb 22 10:14:58 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 10:14:41 -0800 Received: from mta23-acc.tin.it ([212.216.176.76]:53403 "EHLO fep23-svc.tin.it") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 10:14:25 -0800 Received: from kamikaze ([212.171.41.183]) by fep23-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with SMTP id <20010222181411.TLXM29673.fep23-svc.tin.it@kamikaze> for ; Thu, 22 Feb 2001 19:14:11 +0100 From: Pino Z. To: linux-xfs@oss.sgi.com Subject: Kernel 2.4.2ac1 Released Date: Thu, 22 Feb 2001 19:22:26 +0100 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="us-ascii" References: <3A9511E2.3927D392@tin.it> <20010222151707.F17276@suse.de> <3A953BC2.FCB08847@sgi.com> In-Reply-To: <3A953BC2.FCB08847@sgi.com> MIME-Version: 1.0 Message-Id: <01022219222600.22673@kamikaze> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Changes: Linus' 2.4.2 tree was merged. A change to sr.c was backed out. The moxa smartio driver was fixed. More i2o config time is now allowed for slow calls. Aty128fb updates were made. *The "loop" name was added to the root dev names.* Further spelling cleanups were done. Bogus warning emissions from aha1740 were removed, as well as surplus assignment in vmalloc, and an unneeded ifdef in i386/kernel/irq.c. Ad oor-locking ioctl was added to ide-floppy. SCSI disk opening O_NDELAY is now allowed for removables. Cosa compile warnings were fixed. Dumpable/setuid write ordering was cleaned up. The 3ware crashes were hopefully fixed. License: GNU General Public License (GPL) - Release focus: Minor bugfixes On Thursday 22 February 2001 17:18, you wrote: > Jens, I don't see anything about the loop fixes in the changelog... did > that make it in? > > -Eric > > Jens Axboe wrote: > > On Thu, Feb 22 2001, Giuseppe Zompatori wrote: > > > It seems like the elevator bug has been fixed finally :-) > > > > There are no known cases of people being hit by this bug, so > > it was in no way crucial. Machines have run for days doing > > heavy I/O, specweb99 tests etc, no problems noticed. Maybe > > you are confusing this bug with some discussed here earlier? > > > > Still, it's nice to have it fixed :-) > > > > -- > > Jens Axboe From owner-linux-xfs@oss.sgi.com Thu Feb 22 11:30:20 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 11:30:10 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:29807 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 11:29:54 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA23291 for ; Thu, 22 Feb 2001 11:28:50 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA30944; Thu, 22 Feb 2001 11:23:46 -0800 (PST) Message-ID: <3A956800.A11C4AE3@sgi.com> Date: Thu, 22 Feb 2001 11:26:56 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Marcelo Tosatti CC: dcox@connex.com, Linux-XFS Subject: Re: Repeatable Panics with XFS and RAID1 (long) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Marcelo Tosatti wrote: > > On Thu, 22 Feb 2001, Marcelo Tosatti wrote: > > > > I think allocating memory from the atomic queue (used mainly by in > > interrupt context) to generate dirty data may cause problems. > > I'll write the GFP_PAGE_IO thing we talked about RSN to avoid having to > use GFP_ATOMIC. Hi Marcelo, The particular allocation in question, the kmalloc in __pagebuf_write_full_page, is needed only to perform clustering. So, what's needed is a really cheap allocation; the code doesn't care if the allocation fails. I think the patch you sent avoids calling writepage out of page_launder() on GFP_PAGE_IO. This should work also. cheers, ananth. -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Feb 22 11:36:10 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 11:35:50 -0800 Received: from mail3.mia.bellsouth.net ([205.152.144.15]:39618 "EHLO mail3.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 11:35:45 -0800 Received: from bellsouth.net (adsl-61-4-147.mia.bellsouth.net [208.61.4.147]) by mail3.mia.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id OAA25777; Thu, 22 Feb 2001 14:35:36 -0500 (EST) Message-ID: <3A956F91.598AB28@bellsouth.net> Date: Thu, 22 Feb 2001 14:59:13 -0500 From: Juan Casero X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-SGI_XFS_PRsmp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Pino Z." CC: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.2ac1 Released References: <3A9511E2.3927D392@tin.it> <20010222151707.F17276@suse.de> <3A953BC2.FCB08847@sgi.com> <01022219222600.22673@kamikaze> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Pardon me if the question seems elementary. Has the XFS code been integrated into the 2.4.2 kernel? If so where may I obtain a patch or a copy of the patched sources? So far I have experienced alot of istability with the 2.4.0 kernel and I am anxious to move on the something more stable. Thanks.... Juan Casero casero@bellsouth.net "Pino Z." wrote: > Changes: Linus' 2.4.2 tree was merged. A change to sr.c was backed out. > > The moxa smartio driver was fixed. More i2o config time is now allowed for > slow calls. Aty128fb updates were made. > *The "loop" name was added to the root dev names.* > > Further spelling cleanups were done. > Bogus warning emissions from aha1740 were removed, as well as surplus > assignment in vmalloc, and an unneeded ifdef in i386/kernel/irq.c. Ad > oor-locking ioctl was added to ide-floppy. > SCSI disk opening O_NDELAY is now allowed for removables. Cosa compile > warnings were > fixed. Dumpable/setuid write ordering was cleaned up. The 3ware crashes > were hopefully fixed. > License: GNU General Public License (GPL) - Release focus: Minor bugfixes > > On Thursday 22 February 2001 17:18, you wrote: > > Jens, I don't see anything about the loop fixes in the changelog... did > > that make it in? > > > > -Eric > > > > Jens Axboe wrote: > > > On Thu, Feb 22 2001, Giuseppe Zompatori wrote: > > > > It seems like the elevator bug has been fixed finally :-) > > > > > > There are no known cases of people being hit by this bug, so > > > it was in no way crucial. Machines have run for days doing > > > heavy I/O, specweb99 tests etc, no problems noticed. Maybe > > > you are confusing this bug with some discussed here earlier? > > > > > > Still, it's nice to have it fixed :-) > > > > > > -- > > > Jens Axboe From owner-linux-xfs@oss.sgi.com Thu Feb 22 11:39:20 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 11:39:09 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:47986 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 11:38:59 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA24902 for ; Thu, 22 Feb 2001 11:37:54 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA883722; Thu, 22 Feb 2001 13:37:41 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA42309; Thu, 22 Feb 2001 13:37:41 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1MJbec02167; Thu, 22 Feb 2001 13:37:40 -0600 Message-Id: <200102221937.f1MJbec02167@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Juan Casero cc: "Pino Z." , linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.2ac1 Released In-Reply-To: Message from Juan Casero of "Thu, 22 Feb 2001 14:59:13 EST." <3A956F91.598AB28@bellsouth.net> Date: Thu, 22 Feb 2001 13:37:40 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Pardon me if the question seems elementary. Has the XFS code been integrate > d > into the 2.4.2 > kernel? If so where may I obtain a patch or a copy of the patched sources? > So far I have experienced > alot of istability with the 2.4.0 kernel and I am anxious to move on the > something more stable. > > > Thanks.... > > Juan Casero > casero@bellsouth.net I am running tests right now, if things hold together it should show up in cvs later today or tomorrow. Steve From owner-linux-xfs@oss.sgi.com Thu Feb 22 12:47:01 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 12:46:41 -0800 Received: from 66-2-81-26.customer.algx.net ([66.2.81.26]:16179 "EHLO wiley.ceo.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 12:46:17 -0800 Received: from mindspring.com (IDENT:danny@localhost [127.0.0.1]) by wiley.ceo.com (8.9.3/8.9.3) with ESMTP id PAA03239; Thu, 22 Feb 2001 15:57:55 -0500 Message-ID: <3A957D53.6A63BEA7@mindspring.com> Date: Thu, 22 Feb 2001 15:57:55 -0500 From: Danny Organization: Connex Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Rajagopal Ananthanarayanan CC: Linux-XFS Subject: Re: Repeatable Panics with XFS and RAID1 (long) References: <3A956800.A11C4AE3@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ananth, Rajagopal Ananthanarayanan wrote: > > Hi Marcelo, > > The particular allocation in question, the kmalloc in > __pagebuf_write_full_page, is needed only to perform > clustering. So, what's needed is a really cheap allocation; > the code doesn't care if the allocation fails. > > I think the patch you sent avoids calling writepage out of > page_launder() on GFP_PAGE_IO. This should work also. Well, as I reported earlier, it still fails on my machine. The failure is not a panic, the kernel produces one-to-many '__alloc_pages: 0-order allocation failed' messages, and the process stops, in uninterruptible sleep. Using the ps -o wchan feature, I can see one process with 'raid1_grow_bh' or 'raid1_alloc_bh' as it's wchan value, if that's a clue. I *do* have to stress it (memory pressure), and I'm seeing swap activity (via top(1)) before it occurs. By the way, I turned on DEBUG in raid1.c, and saw it produce one message just before it hung: "waiting for 1 bh". -- "Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill Danny From owner-linux-xfs@oss.sgi.com Thu Feb 22 13:31:20 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 13:31:10 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:24188 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 13:31:03 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA01522 for ; Thu, 22 Feb 2001 13:31:02 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA907269 for ; Thu, 22 Feb 2001 15:29:46 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA86596 for ; Thu, 22 Feb 2001 15:29:46 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f1MLTjU09176; Thu, 22 Feb 2001 15:29:45 -0600 Message-Id: <200102222129.f1MLTjU09176@jen.americas.sgi.com> Date: Thu, 22 Feb 2001 15:29:45 -0600 Subject: TAKE - woops, ptools and patch do not always mix well To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing These were missed from the 2.4.2 merge Date: Thu Feb 22 13:29:07 PST 2001 Workarea: jen.americas.sgi.com:/src/lord/merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88193a linux/mm/vmscan.c - 1.49 linux/include/linux/slab.h - 1.13 - Add SLAB_PAGE_IO definition From owner-linux-xfs@oss.sgi.com Thu Feb 22 15:44:53 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 15:44:43 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:51782 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 15:44:26 -0800 Received: from nodin.corp.sgi.com ([192.26.51.193]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA08981 for ; Thu, 22 Feb 2001 15:44:26 -0800 (PST) mail_from (lord@sgi.com) Received: from pneumatic-tube.sgi.com (etube.sgi.com [192.26.71.46]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA55559 for ; Thu, 22 Feb 2001 15:43:54 -0800 (PST) Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00910 for ; Thu, 22 Feb 2001 15:49:26 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA909644 for ; Thu, 22 Feb 2001 17:38:37 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA57596 for ; Thu, 22 Feb 2001 17:38:36 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1MNcYI25107; Thu, 22 Feb 2001 17:38:34 -0600 Message-Id: <200102222338.f1MNcYI25107@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: XFS tree bumped to 2.4.2 base Date: Thu, 22 Feb 2001 17:38:34 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing My original message on this appears to have gone missing. This afternoon I updated the xfs development tree to 2.4.2, it should be out on the cvs site now. Steve From owner-linux-xfs@oss.sgi.com Thu Feb 22 16:19:32 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 16:19:22 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:48225 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 16:19:13 -0800 Received: from chuckle.americas.sgi.com (root@chuckle.americas.sgi.com [128.162.184.123]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA16181 for ; Thu, 22 Feb 2001 16:18:08 -0800 (PST) mail_from (cattelan@chuckle.americas.sgi.com) Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.11.0/8.11.0) id f1N0IaI25128 for linux-xfs@oss.sgi.com; Thu, 22 Feb 2001 18:18:36 -0600 Date: Thu, 22 Feb 2001 18:18:36 -0600 From: Russell Cattelan Message-Id: <200102230018.f1N0IaI25128@chuckle.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Feb 22 16:18:50 PST 2001 Workarea: chuckle.americas.sgi.com:/export/xfs1/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88241a linux/kernel/ksyms.c - 1.76 linux/include/linux/fs.h - 1.80 linux/fs/pagebuf/page_buf_io.c - 1.55 - Fix XFS module biuld From owner-linux-xfs@oss.sgi.com Thu Feb 22 17:02:32 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 17:02:13 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42043 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 17:02:08 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA01639 for ; Thu, 22 Feb 2001 17:10:47 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (IDENT:tduffy@dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id QAA34175; Thu, 22 Feb 2001 16:59:51 -0800 (PST) Date: Thu, 22 Feb 2001 16:59:57 -0800 (PST) From: Tom Duffy To: Eric Sandeen cc: Juan Casero , Subject: Re: RedHat Linux 7.0 with SGI XFS In-Reply-To: <3A947A20.6E79C8BF@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > 3. Trying to compile the NVIDIA_kernel-0.9-6 driver from RPMS succeeds > > on this modified redhat 7.0 distribution but trying to load the modules > > fails and I get an error message about unresolved symbol irq_stat. > > I get that too, I haven't looked at it closely - not sure what the > problem is, except that binary kernel modules can't really be supported > and will eventually break. I got the nvidia rpm to work fine under the 2.4.x tree. you need to make sure that /usr/src/linux points to the kernel source tree (which it is not by default because the 2.4 kernel link is /usr/src/linux-2.4). make sure to get the latest 0.9-6 driver from NVidia...they have a pesky habbit of updating the code without changing the version number...the only way to tell they did this is to check out the timestamp on the rpm... the 0.9-7 works great under 2.4 and xfree 4.0.2 so you could just wait til that is publicly available...probably very soon. -tduffy From owner-linux-xfs@oss.sgi.com Thu Feb 22 19:59:12 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 19:58:52 -0800 Received: from mail4.mia.bellsouth.net ([205.152.144.16]:37007 "EHLO mail4.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 19:58:32 -0800 Received: from spruce (adsl-61-4-147.mia.bellsouth.net [208.61.4.147]) by mail4.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id XAA26817; Thu, 22 Feb 2001 23:03:54 -0500 (EST) From: "Juan Casero" To: "Steve Lord" , Subject: RE: XFS tree bumped to 2.4.2 base Date: Thu, 22 Feb 2001 22:50:00 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200102222338.f1MNcYI25107@jen.americas.sgi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing So if we login to the cvs server using the instructions on your web site we should download the new 2.4.2 XFS patche kernel sources right? I ask because not too long ago this afternoon I did that and the source tree I downloaded didn't seem to be different from the 2.4.0 source. Thanks, Juan Casero casero@bellsouth.net -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On Behalf Of Steve Lord Sent: Thursday, February 22, 2001 6:39 PM To: linux-xfs@oss.sgi.com Subject: XFS tree bumped to 2.4.2 base My original message on this appears to have gone missing. This afternoon I updated the xfs development tree to 2.4.2, it should be out on the cvs site now. Steve From owner-linux-xfs@oss.sgi.com Thu Feb 22 20:08:12 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 20:08:03 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:20762 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 20:07:56 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA11528 for ; Thu, 22 Feb 2001 20:06:51 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19886; Fri, 23 Feb 2001 15:06:38 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA54449; Fri, 23 Feb 2001 15:06:36 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102231506.ZM143652@wobbly.melbourne.sgi.com> Date: Fri, 23 Feb 2001 15:06:35 -0400 In-Reply-To: "Juan Casero" "RE: XFS tree bumped to 2.4.2 base" (Feb 22, 10:50pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Juan Casero" Subject: Re: XFS tree bumped to 2.4.2 base Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Juan, On Feb 22, 10:50pm, Juan Casero wrote: > Subject: RE: XFS tree bumped to 2.4.2 base > So if we login to the cvs server using the instructions on your web site > we should download the new 2.4.2 XFS patche kernel sources right? I ask > because not too long ago this afternoon I did that and the source tree I > downloaded didn't seem to be different from the 2.4.0 source. > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/Makefile would suggest Steve's merge is now on oss. Are you updating from the beta tree perhaps? The development tree has been at 2.4.1 for awhile now, and is now 2.4.2, but the beta tree is based on the 2.4.0 code. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 22 21:44:03 2001 Received: by oss.sgi.com id ; Thu, 22 Feb 2001 21:43:53 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:26687 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 21:43:49 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA07402 for ; Thu, 22 Feb 2001 21:43:12 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA33604; Fri, 23 Feb 2001 16:41:44 +1100 (EST) Date: Fri, 23 Feb 2001 16:41:44 +1100 (EST) From: Nathan Scott Message-Id: <200102230541.QAA33604@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: ulfc@engr.sgi.com Subject: TAKE - support Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Feb 22 21:40:55 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/quota-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88268a linux/fs/xfs/support/debug.c - 1.2 linux/fs/xfs/support/kmem.h - 1.4 linux/fs/xfs/support/kmem.c - 1.6 - make a little more compatible with IRIX to help folk on other projects using this code. From owner-linux-xfs@oss.sgi.com Fri Feb 23 04:56:45 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 04:56:36 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:64842 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 04:56:26 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA07285 for ; Fri, 23 Feb 2001 04:56:27 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA914369 for ; Fri, 23 Feb 2001 06:55:10 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA74869 for ; Fri, 23 Feb 2001 06:55:09 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f1NCsst29890; Fri, 23 Feb 2001 06:54:54 -0600 Message-Id: <200102231254.f1NCsst29890@jen.americas.sgi.com> Date: Fri, 23 Feb 2001 06:54:54 -0600 Subject: TAKE - fix a couple of small merge issues To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing No effect really, just cleanup. Date: Fri Feb 23 04:54:33 PST 2001 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:88277a linux/drivers/ide/ide-disk.c - 1.12 - Fix up a couple of small merge issues From owner-linux-xfs@oss.sgi.com Fri Feb 23 05:05:56 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 05:05:36 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:10249 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 05:05:31 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA29196 for ; Fri, 23 Feb 2001 05:04:27 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA913664; Fri, 23 Feb 2001 07:04:08 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA00081; Fri, 23 Feb 2001 07:04:03 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1ND3mW29942; Fri, 23 Feb 2001 07:03:48 -0600 Message-Id: <200102231303.f1ND3mW29942@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Irresponsible & Crazy" cc: linux-xfs@oss.sgi.com Subject: Re: Hardware fault intolerance... In-Reply-To: Message from "Irresponsible & Crazy" of "Thu, 22 Feb 2001 14:57:22 +0100." <1460.212.160.232.6.982850242.squirrel@mail.jeremi.pl> Date: Fri, 23 Feb 2001 07:03:48 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Does anybody know how xfs handles "just appeared" badblocks? If even... > How to inform xfs about badblocks (if that's possible) to let xfs avoid them > or just kiss hdd goodbye > > I took latest cvs snapshot (21.02.2001 18:00CET), made kernel and set vga=9 > to see whole Oops output and I think I know where exactly those bads hide on > my hdd, I should have Oops in my next post if anybody interested... > > Filip > -- > "Oh shit! o shit! o shit! I'm gonna die! I'm gonna die!" - Rincewind > A feature just went into XFS which is shutdown on error, which basically means that if we get a metadata I/O error the filesystem gets shutdown, all processes in the filesystem get errored out of their system calls, and you get to type unmount somewhere. This is all there is really, however, if the timing was correct, you have that code, so clearly you found a case which is not covered by it. Oops output would be useful, ideally building in kdb and using a serial console line to capture the output would be even more useful (use the bt command to get a stack trace). However, I realize setting up a serial console is not always an option. Steve From owner-linux-xfs@oss.sgi.com Fri Feb 23 05:25:26 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 05:25:06 -0800 Received: from dahende3.dasc.vt.edu ([128.173.64.62]:4247 "HELO dahende3.dasc.vt.edu") by oss.sgi.com with SMTP id ; Fri, 23 Feb 2001 05:24:39 -0800 Received: from VT.Edu (dahende3.dasc.vt.edu [128.173.64.62]) by dahende3.dasc.vt.edu (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 28CE274872 for ; Fri, 23 Feb 2001 08:28:48 -0500 (EST) Message-ID: <3A96658F.6080700@VT.Edu> Date: Fri, 23 Feb 2001 08:28:47 -0500 From: David Henderson User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.1 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: egcs-2.91.66 Content-Type: multipart/mixed; boundary="------------080004070008020405010703" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------080004070008020405010703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Attached is a file containing the output from a "make modules" command in the latest (as of yesterday) cvs of the linux-2.4-xfs tree. I am wondering if the error at the bottom of the file is related to the problem of using gcc-2.95 vs egcs-2.91.66? If not, how can I fix this problem? Thanks!! Dave H -- David A. Henderson, M.Sc. G. Cunningham Fellow Interdepartmental Genetics Program Department of Dairy Science 2010 Litton Reaves Hall Virginia Polytechnic Institute and State University Blacksburg, VA 24061 USA Phone: (540)231-4773 Fax: (540)231-5014 mailto://DHenders@VT.Edu http://www.dasc.vt.edu/henderson/dhenderson.html --------------080004070008020405010703 Content-Type: text/plain; name="make.out" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="make.out" make -C kernel CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4-xfs/linux/include/linux/modversions.h" MAKING_MODULES=1 modules make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/kernel' make[1]: Nothing to be done for `modules'. make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/kernel' make -C drivers CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4-xfs/linux/include/linux/modversions.h" MAKING_MODULES=1 modules make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers' make -C block modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/block' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/block' make -C cdrom modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/cdrom' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/cdrom' make -C char modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/char' make -C drm modules make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/char/drm' make[3]: Nothing to be done for `modules'. make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/char/drm' make -C joystick modules make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/char/joystick' make[3]: Nothing to be done for `modules'. make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/char/joystick' make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/char' make -C ide modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/ide' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/ide' make -C input modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/input' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/input' make -C media modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/media' make -C radio modules make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/media/radio' make[3]: Nothing to be done for `modules'. make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/media/radio' make -C video modules make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/media/video' make[3]: Nothing to be done for `modules'. make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/media/video' make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/media' make -C misc modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/misc' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/misc' make -C net modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/net' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/net' make -C parport modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/parport' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/parport' make -C pnp modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/pnp' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/pnp' make -C scsi modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/scsi' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/scsi' make -C sound modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/sound' make -C emu10k1 modules make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/sound/emu10k1' make[3]: Nothing to be done for `modules'. make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/sound/emu10k1' make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/sound' make -C usb modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/usb' make -C storage modules make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/usb/storage' ld -m elf_i386 -r -o usb-storage.o scsiglue.o protocol.o transport.o usb.o initializers.o make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/usb/storage' make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/usb' make -C video modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/video' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/video' make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers' make -C mm CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4-xfs/linux/include/linux/modversions.h" MAKING_MODULES=1 modules make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/mm' make[1]: Nothing to be done for `modules'. make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/mm' make -C fs CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4-xfs/linux/include/linux/modversions.h" MAKING_MODULES=1 modules make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs' make -C autofs modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/autofs' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/autofs' make -C fat modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/fat' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/fat' make -C minix modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/minix' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/minix' make -C msdos modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/msdos' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/msdos' make -C nls modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/nls' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/nls' make -C ntfs modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/ntfs' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/ntfs' make -C pagebuf modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/pagebuf' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/pagebuf' make -C reiserfs modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/reiserfs' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/reiserfs' make -C umsdos modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/umsdos' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/umsdos' make -C vfat modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/vfat' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/vfat' make -C xfs modules make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' kgcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4-xfs/linux/include/linux/modversions.h -Wno-unused -Wno-parentheses -Wno-uninitialized -I. -funsigned-char -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG -c -o xfs_bmap.o xfs_bmap.c xfs_bmap.c: In function `xfs_bmap_del_extent': xfs_bmap.c:3130: internal error--unrecognizable insn: (insn/i 528 527 2191 (parallel[ (set (reg:SI 0 %eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 %edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 266)) (set (reg:SI 1 %edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 %edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 266)) ] ) -1 (insn_list 495 (nil)) (nil)) cpp: output pipe has been closed make[2]: *** [xfs_bmap.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' make[1]: *** [_modsubdir_xfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' make: *** [_mod_fs] Error 2 --------------080004070008020405010703-- From owner-linux-xfs@oss.sgi.com Fri Feb 23 07:09:46 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 07:09:27 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33905 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 07:09:01 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA01249 for ; Fri, 23 Feb 2001 07:18:32 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA910586; Fri, 23 Feb 2001 09:07:43 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA58435; Fri, 23 Feb 2001 09:07:43 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1NF7R503175; Fri, 23 Feb 2001 09:07:27 -0600 Message-Id: <200102231507.f1NF7R503175@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: David Henderson cc: linux-xfs@oss.sgi.com Subject: Re: egcs-2.91.66 In-Reply-To: Message from David Henderson of "Fri, 23 Feb 2001 08:28:47 EST." <3A96658F.6080700@VT.Edu> Date: Fri, 23 Feb 2001 09:07:26 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is coming from our use of the do_div macro - which we wrap in an inline function in fs/xfs/linux/xfs_linux.h XFS has a number of 64 bit divide and modulus operations, rather than import the compiler intrinsic from the gcc support library, we chose to use this existing kernel macro. Unfortunately, later compilers do not like the way we use it, and I have never figured out why. It is possible that moving xfs_do_div and xfs_do_mod to be true functions somewhere in a .c file rather than an inline would fix the problem, but no guarantees. Steve > This is a multi-part message in MIME format. > --------------080004070008020405010703 > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > > Attached is a file containing the output from a "make modules" command > in the latest (as of yesterday) cvs of the linux-2.4-xfs tree. I am > wondering if the error at the bottom of the file is related to the > problem of using gcc-2.95 vs egcs-2.91.66? If not, how can I fix this > problem? Thanks!! > > Dave H > > -- > > David A. Henderson, M.Sc. > G. Cunningham Fellow > Interdepartmental Genetics Program > Department of Dairy Science > 2010 Litton Reaves Hall > Virginia Polytechnic Institute and State University > Blacksburg, VA 24061 USA > Phone: (540)231-4773 > Fax: (540)231-5014 > mailto://DHenders@VT.Edu > http://www.dasc.vt.edu/henderson/dhenderson.html > > --------------080004070008020405010703 > Content-Type: text/plain; > name="make.out" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="make.out" > > make -C kernel CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include - > Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe > -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr > /src/linux-2.4-xfs/linux/include/linux/modversions.h" MAKING_MODULES=1 module > s > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/kernel' > make[1]: Nothing to be done for `modules'. > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/kernel' > make -C drivers CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include > -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe > -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /us > r/src/linux-2.4-xfs/linux/include/linux/modversions.h" MAKING_MODULES=1 modul > es > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers' > make -C block modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/block' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/block' > make -C cdrom modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/cdrom' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/cdrom' > make -C char modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/char' > make -C drm modules > make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/char/drm' > make[3]: Nothing to be done for `modules'. > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/char/drm' > make -C joystick modules > make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/char/joysti > ck' > make[3]: Nothing to be done for `modules'. > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/char/joystic > k' > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/char' > make -C ide modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/ide' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/ide' > make -C input modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/input' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/input' > make -C media modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/media' > make -C radio modules > make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/media/radio > ' > make[3]: Nothing to be done for `modules'. > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/media/radio' > make -C video modules > make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/media/video > ' > make[3]: Nothing to be done for `modules'. > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/media/video' > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/media' > make -C misc modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/misc' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/misc' > make -C net modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/net' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/net' > make -C parport modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/parport' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/parport' > make -C pnp modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/pnp' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/pnp' > make -C scsi modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/scsi' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/scsi' > make -C sound modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/sound' > make -C emu10k1 modules > make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/sound/emu10 > k1' > make[3]: Nothing to be done for `modules'. > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/sound/emu10k > 1' > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/sound' > make -C usb modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/usb' > make -C storage modules > make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/usb/storage > ' > ld -m elf_i386 -r -o usb-storage.o scsiglue.o protocol.o transport.o usb.o in > itializers.o > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/usb/storage' > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/usb' > make -C video modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/drivers/video' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers/video' > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/drivers' > make -C mm CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall > -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -mpr > eferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src > /linux-2.4-xfs/linux/include/linux/modversions.h" MAKING_MODULES=1 modules > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/mm' > make[1]: Nothing to be done for `modules'. > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/mm' > make -C fs CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall > -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -mpr > eferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src > /linux-2.4-xfs/linux/include/linux/modversions.h" MAKING_MODULES=1 modules > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs' > make -C autofs modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/autofs' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/autofs' > make -C fat modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/fat' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/fat' > make -C minix modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/minix' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/minix' > make -C msdos modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/msdos' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/msdos' > make -C nls modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/nls' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/nls' > make -C ntfs modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/ntfs' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/ntfs' > make -C pagebuf modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/pagebuf' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/pagebuf' > make -C reiserfs modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/reiserfs' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/reiserfs' > make -C umsdos modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/umsdos' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/umsdos' > make -C vfat modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/vfat' > make[2]: Nothing to be done for `modules'. > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/vfat' > make -C xfs modules > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' > kgcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prot > otypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -mpreferred-stack- > boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4-xfs > /linux/include/linux/modversions.h -Wno-unused -Wno-parentheses -Wno-uniniti > alized -I. -funsigned-char -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG -c -o xf > s_bmap.o xfs_bmap.c > xfs_bmap.c: In function `xfs_bmap_del_extent': > xfs_bmap.c:3130: internal error--unrecognizable insn: > (insn/i 528 527 2191 (parallel[ > (set (reg:SI 0 %eax) > (asm_operands ("") ("=a") 0[ > (reg:DI 1 %edx) > ] > [ > (asm_input:DI ("A")) > ] ("linux/xfs_linux.h") 266)) > (set (reg:SI 1 %edx) > (asm_operands ("") ("=d") 1[ > (reg:DI 1 %edx) > ] > [ > (asm_input:DI ("A")) > ] ("linux/xfs_linux.h") 266)) > ] ) -1 (insn_list 495 (nil)) > (nil)) > cpp: output pipe has been closed > make[2]: *** [xfs_bmap.o] Error 1 > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' > make[1]: *** [_modsubdir_xfs] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' > make: *** [_mod_fs] Error 2 > > --------------080004070008020405010703-- From owner-linux-xfs@oss.sgi.com Fri Feb 23 08:14:48 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 08:14:38 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:11353 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 08:14:22 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA05900 for ; Fri, 23 Feb 2001 08:13:17 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA913939 for ; Fri, 23 Feb 2001 10:13:05 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA68254 for ; Fri, 23 Feb 2001 10:13:04 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f1NGEs303105; Fri, 23 Feb 2001 10:14:54 -0600 Message-Id: <200102231614.f1NGEs303105@jen.americas.sgi.com> Date: Fri, 23 Feb 2001 10:14:54 -0600 Subject: TAKE - one more memory allocation tweak To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Feb 23 08:12:42 PST 2001 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:88289a linux/fs/xfs/support/kmem.c - 1.7 - Use GFP_PAGE_IO rather than GFP_BUFFER as out allocation option. From owner-linux-xfs@oss.sgi.com Fri Feb 23 08:34:48 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 08:34:28 -0800 Received: from mta43-acc.tin.it ([212.216.176.96]:37098 "EHLO fep43-svc.tin.it") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 08:34:13 -0800 Received: from kamikaze ([212.171.41.183]) by fep43-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with SMTP id <20010223163235.CZKE1270.fep43-svc.tin.it@kamikaze> for ; Fri, 23 Feb 2001 17:32:35 +0100 From: G.Z. To: linux-xfs@oss.sgi.com Subject: Re: mysterious dbench results Date: Fri, 23 Feb 2001 17:42:17 +0100 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" References: <200102221504.f1MF41r20047@jen.americas.sgi.com> In-Reply-To: <200102221504.f1MF41r20047@jen.americas.sgi.com> MIME-Version: 1.0 Message-Id: <01022317421700.17554@kamikaze> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thursday 22 February 2001 16:04, Steve Lord wrote: > I have been out for a while, or I would have posted something on this > earlier. The default mkfs options for xfs are not optimal for heavy I/O > load, they are somewhat historical and should probably be changed. > > On mkfs try some options like this: > > mkfs -t xfs -f -l size=32768b /dev/xxx > > on mount use these extra options: > > logbufs=4,logbsize=32768 Is there any way I can change those parameters on a premadf filesystem? thanks in advance -Giuseppe > > The first will make the on disk log bigger which helps metadata intensive > loads not become purely log bound - every request for log space ends up > having to flush metadata to disk. The mount options allow more log writes > to be in progress at once. > > These should help XFS performance here, I suspect, but have not tried that > this will also help: > > echo 5000 > /proc/sys/vm/pagebuf/flush_int > > This will make the interval between dirtying file data and flushing it to > disk closer to that used by ext2. One of the issues with dbench is files > getting removed shortly after they are created, you can get mush better > performance if the removal happens before the data goes out to disk. > > In the long run Ananth's development direction is probably the correct fix > for this, we would end up using the same mechanisms as other filesystems > for controlling flushing file data to disk. > > Steve > > > Thomas Graichen wrote: > > > ok - now tested it on one machine once in smp and once in up mode > > > and got the same results (very bad dbench results compared to > > > ext2 or reiserfs) ... so it's not smp related - i'm right now > > > updating the kernel and will post again - if the problem is > > > still there ... > > > > ... and it is - so the question: anyone else seing this? - as said > > dbench results are about 1/4th of ext2 results with the current > > XFS tree on an ide disk system for smp and nosmp > > > > t From owner-linux-xfs@oss.sgi.com Fri Feb 23 08:40:28 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 08:40:18 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:11853 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 08:40:08 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08187 for ; Fri, 23 Feb 2001 08:39:51 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA916783; Fri, 23 Feb 2001 10:38:27 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA71413; Fri, 23 Feb 2001 10:38:27 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1NGeGv05364; Fri, 23 Feb 2001 10:40:16 -0600 Message-Id: <200102231640.f1NGeGv05364@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "G.Z." cc: linux-xfs@oss.sgi.com Subject: Re: mysterious dbench results In-Reply-To: Message from "G.Z." of "Fri, 23 Feb 2001 17:42:17 +0100." <01022317421700.17554@kamikaze> Date: Fri, 23 Feb 2001 10:40:16 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > On Thursday 22 February 2001 16:04, Steve Lord wrote: > > I have been out for a while, or I would have posted something on this > > earlier. The default mkfs options for xfs are not optimal for heavy I/O > > load, they are somewhat historical and should probably be changed. > > > > On mkfs try some options like this: > > > > mkfs -t xfs -f -l size=32768b /dev/xxx > > > > on mount use these extra options: > > > > logbufs=4,logbsize=32768 > > > Is there any way I can change those parameters on a premadf filesystem? > > thanks in advance > > -Giuseppe > > Unfortunately, you cannot change the log size on an existing filesystem, the mount options are of course available to you. Steve From owner-linux-xfs@oss.sgi.com Fri Feb 23 10:27:49 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 10:27:39 -0800 Received: from mail0.mia.bellsouth.net ([205.152.144.12]:24256 "EHLO mail0.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 10:27:22 -0800 Received: from spruce (adsl-61-4-147.mia.bellsouth.net [208.61.4.147]) by mail0.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id NAA22882; Fri, 23 Feb 2001 13:27:04 -0500 (EST) From: "Juan Casero" To: "Nathan Scott" Cc: Subject: RE: XFS tree bumped to 2.4.2 base Date: Fri, 23 Feb 2001 13:19:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <10102231506.ZM143652@wobbly.melbourne.sgi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thanks for the info. Last night I logged into the CVS server and downloaded the code. For good measure I also performed an update to make sure I got the latest and greatest kernel source. A recompile of the kernel source (that by the way went without a hitch) installed the 2.4.2-xfs kernel on my boxen. The new kernel is at least an order of magniture more stable and seems to perform slightly faster also. Thanks to the SGI folks for their wonderful efforts! It would be a real shame if Linus needlessly delayed the integration of the XFS code into the mainstream kernel tree. XFS will henceforth be my default file system for all my Linux partitions. Ciao... Juan Casero casero@bellsouth.net By the way I am very excited and happy to see how enthuthiastic SGI is about Linux. I really enjoy reading the articles on SGI's Linux web pages. I have a question for you foks though. When are the first SGI ccNUMA servers based on Intel Itanium and Linux scheduled to debut? It seems to me you folks are right on the money in your market analyses. If SGI can bring to Linux the kind of reliability and performance that IRIX delivers on those massive servers everyone really benefits tremendously. I am in the IT business and if I have anything to say about it Linux and SGI will feature prominently in our agenda for server acquisitions in the near future. It doesn't make any sense to depend on a closed Microsoft code base when you have available an army of developers world wide alreay working to make Linux a top notch OS. When I started with Linux back in late 1994 I expected that it might develop into a medium range business server platform. I am stunned and rather pleased to see the direction it is taking though with the help of SGI and other corporate partners. -----Original Message----- From: Nathan Scott [mailto:nathans@wobbly.melbourne.sgi.com] Sent: Friday, February 23, 2001 2:07 PM To: Juan Casero Cc: linux-xfs@oss.sgi.com Subject: Re: XFS tree bumped to 2.4.2 base hi Juan, On Feb 22, 10:50pm, Juan Casero wrote: > Subject: RE: XFS tree bumped to 2.4.2 base > So if we login to the cvs server using the instructions on your web site > we should download the new 2.4.2 XFS patche kernel sources right? I ask > because not too long ago this afternoon I did that and the source tree I > downloaded didn't seem to be different from the 2.4.0 source. > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/Makefile would suggest Steve's merge is now on oss. Are you updating from the beta tree perhaps? The development tree has been at 2.4.1 for awhile now, and is now 2.4.2, but the beta tree is based on the 2.4.0 code. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Feb 23 10:51:09 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 10:51:00 -0800 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:57543 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 10:50:38 -0800 Received: from techno.informatik.uni-stuttgart.de (techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id TAA00829 for ; Fri, 23 Feb 2001 19:48:39 +0100 (MET) Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.11.0/2.2) id f1NIoYD24761 for linux-xfs@oss.sgi.com; Fri, 23 Feb 2001 19:50:34 +0100 Date: Fri, 23 Feb 2001 19:50:34 +0100 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: xfstest 030 fails Message-ID: <20010223195034.A24640@techno.informatik.uni-stuttgart.de> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.1.14i X-Operating-System: Linux techno 2.4.1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, 030 - output mismatch (see 030.out.bad) 17,18d16 < sb root inode value INO inconsistent with calculated value INO < resetting superblock root inode pointer to INO 158,159d155 < sb root inode value INO inconsistent with calculated value INO < resetting superblock root inode pointer to INO This has been failing for sometime now, but I don't remember reporting this. The first log I have that shows this is dated 2000-12-08. The one from today also fails. 030.out.bad is attached. -- Marcelo --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="030.out.bad" QA output created by 030 meta-data=DDEV isize=XXX agcount=N, agsize=XXX blks data = bsize=XXX blocks=XXX, imaxpct=PCT = sunit=XXX swidth=XXX, unwritten=X naming =VERN bsize=XXX log =LDEV bsize=XXX blocks=XXX realtime =RDEV extsz=XXX blocks=XXX, rtextents=XXX Corrupting sb 0 - setting bits to 0 Wrote 0.50Kb (value 0x0) Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... found candidate secondary superblock... verified secondary superblock... writing modified primary superblock sb realtime bitmap inode INO inconsistent with calculated value INO resetting superblock realtime bitmap ino pointer to INO sb realtime summary inode INO inconsistent with calculated value INO resetting superblock realtime summary ino pointer to INO Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Note - stripe unit (0) and width (0) fields have been reset. Please set with mount -o sunit=,swidth= done Corrupting agf 0 - setting bits to 0 Wrote 0.50Kb (value 0x0) Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad magic # 0x0 for agf 0 bad version # 0 for agf 0 bad length 0 for agf 0, should be LENGTH reset bad agf for ag 0 bad agbno AGBNO for btbno root, agno 0 bad agbno AGBNO for btbcnt root, agno 0 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Corrupting agi 0 - setting bits to 0 Wrote 0.50Kb (value 0x0) Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad magic # 0x0 for agi 0 bad version # 0 for agi 0 bad length # 0 for agi 0, should be LENGTH reset bad agi for ag 0 bad agbno AGBNO for inobt root, agno 0 root inode chunk not found Phase 3 - for each AG... - scan and clear agi unlinked lists... error following ag 0 unlinked list - process known inodes and perform inode discovery... imap claims in-use inode 131 is free, correcting imap - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Corrupting agfl 0 - setting bits to 0 Wrote 0.50Kb (value 0x0) Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Corrupting sb 0 - setting bits to -1 Wrote 0.50Kb (value 0xffffffff) Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... found candidate secondary superblock... verified secondary superblock... writing modified primary superblock sb realtime bitmap inode INO inconsistent with calculated value INO resetting superblock realtime bitmap ino pointer to INO sb realtime summary inode INO inconsistent with calculated value INO resetting superblock realtime summary ino pointer to INO Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Note - stripe unit (0) and width (0) fields have been reset. Please set with mount -o sunit=,swidth= done Corrupting agf 0 - setting bits to -1 Wrote 0.50Kb (value 0xffffffff) Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad magic # 0xffffffff for agf 0 bad version # -1 for agf 0 bad sequence # -1 for agf 0 bad length -1 for agf 0, should be LENGTH flfirst -1 in agf 0 too large (max = MAX) fllast -1 in agf 0 too large (max = MAX) reset bad agf for ag 0 freeblk count 1 != flcount -1 in ag 0 bad agbno AGBNO for btbno root, agno 0 bad agbno AGBNO for btbcnt root, agno 0 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Corrupting agi 0 - setting bits to -1 Wrote 0.50Kb (value 0xffffffff) Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad magic # 0xffffffff for agi 0 bad version # -1 for agi 0 bad sequence # -1 for agi 0 bad length # -1 for agi 0, should be LENGTH reset bad agi for ag 0 bad agbno AGBNO for inobt root, agno 0 root inode chunk not found Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... imap claims in-use inode 131 is free, correcting imap - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Corrupting agfl 0 - setting bits to -1 Wrote 0.50Kb (value 0xffffffff) Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done --BXVAT5kNtrzKuDFl-- From owner-linux-xfs@oss.sgi.com Fri Feb 23 11:05:09 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 11:04:59 -0800 Received: from roc-24-95-203-215.rochester.rr.com ([24.95.203.215]:12549 "EHLO d185fcbd7.rochester.rr.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 11:04:48 -0800 Received: from localhost ([127.0.0.1] helo=tiny) by d185fcbd7.rochester.rr.com with esmtp (Exim 3.16 #4) id 14WNVc-0005uj-00; Fri, 23 Feb 2001 14:04:04 -0500 Date: Fri, 23 Feb 2001 14:04:04 -0500 From: Chris Mason To: Steve Lord , Jason Walker cc: SGI XFS Mailing List Subject: Re: misc mount/umount errors Message-ID: <580530000.982955044@tiny> In-Reply-To: <200102221438.f1MEcUw19960@jen.americas.sgi.com> X-Mailer: Mulberry/2.0.6b4 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thursday, February 22, 2001 08:38:30 AM -0600 Steve Lord wrote: > > This error message is because the way the root mount works is it keeps > trying different filesystem types until it succeeds, reiserfs is in there > before XFS. I saw someone float a patch which specified the rootfs type > as a kernel boot option, I do not know if this will make it into Linus's > tree or not. Maybe reiserfs (and XFS) should not be so chatty on a failed > mount in this case. Yes, the reiserfs messages could be compressed into a single line... > > I added Chris Mason to the cc list, he may have some input on cleaning up > failed mount output and the other reiserfs question you had. > There are no known lvm problems specific to reiserfs. But, the lvm guys have a number of patches out, it would be a good idea to grab their latest beta. -chris From owner-linux-xfs@oss.sgi.com Fri Feb 23 11:11:59 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 11:11:39 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:51010 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 11:11:24 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA22567 for ; Fri, 23 Feb 2001 11:10:19 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA919205 for ; Fri, 23 Feb 2001 13:10:07 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA48520 for ; Fri, 23 Feb 2001 13:10:07 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f1NJBt005839; Fri, 23 Feb 2001 13:11:55 -0600 Message-Id: <200102231911.f1NJBt005839@jen.americas.sgi.com> Date: Fri, 23 Feb 2001 13:11:55 -0600 Subject: TAKE - get xfs working with 8 logbuffers To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Irix allows logbufs=8 as a mount option, linux was pruned back to 4 due to kmalloc limitations. This gets the 8 buffer case working again. Date: Fri Feb 23 11:08:48 PST 2001 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:88300a linux/fs/xfs/xfs_log_priv.h - 1.77 - Bump max iclogs to 8 linux/fs/xfs/xfs_log_recover.c - 1.200 - Deal with too large a log buffer during mount/recovery better. The current code for falling back to a small buffer will get hit more often now, this fixes up the common case (clean mount) to ask for decreasing powers of 2 sized buffers rather than dropping down to 1 block immediately. linux/fs/pagebuf/page_buf.c - 1.58 - Do not call kmalloc with a size which will fail, return an error instead. This is necessary since kmalloc will call BUG if you ask for too much memory. From owner-linux-xfs@oss.sgi.com Fri Feb 23 12:00:58 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 12:00:49 -0800 Received: from pipt.oz.cc.utah.edu ([155.99.2.7]:12430 "EHLO pipt.oz.cc.utah.edu") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 12:00:24 -0800 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id NAA15944; Fri, 23 Feb 2001 13:00:08 -0700 (MST) Date: Fri, 23 Feb 2001 13:00:07 -0700 (MST) From: james rich To: linux-kernel@vger.kernel.org cc: linux-xfs@oss.sgi.com Subject: building 2.4.2 (with XFS) fails Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing When building 2.4.2 with XFS patches the build fails with errors that don't seem related to XFS (that's why the crosspost): gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686 -c -o dec_and_lock.o dec_and_lock.c rm -f lib.a ar rcs lib.a checksum.o old-checksum.o delay.o usercopy.o getuser.o putuser.o iodebug.o memcpy.o dec_and_lock.o make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib' make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib' make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/parport/driver.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o drivers/i2c/i2c.o drivers/md/mddev.o net/network.o /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a --end-group -o vmlinux drivers/char/char.o: In function `vt_ioctl': drivers/char/char.o(.text+0x96fb): undefined reference to `key_maps' drivers/char/char.o(.text+0x97cd): undefined reference to `key_maps' drivers/char/char.o(.text+0x97ed): undefined reference to `key_maps' drivers/char/char.o(.text+0x9808): undefined reference to `keymap_count' drivers/char/char.o(.text+0x9877): undefined reference to `key_maps' drivers/char/char.o(.text+0x9889): undefined reference to `keymap_count' drivers/char/char.o(.text+0x98df): undefined reference to `key_maps' drivers/char/char.o(.text+0x990a): undefined reference to `keymap_count' drivers/char/char.o(.text+0x9a2e): undefined reference to `func_table' drivers/char/char.o(.text+0x9ad7): undefined reference to `funcbufsize' drivers/char/char.o(.text+0x9ae5): undefined reference to `funcbufleft' drivers/char/char.o(.text+0x9afa): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9b09): undefined reference to `func_table' drivers/char/char.o(.text+0x9b22): undefined reference to `func_table' drivers/char/char.o(.text+0x9b46): undefined reference to `func_table' drivers/char/char.o(.text+0x9b57): undefined reference to `func_table' drivers/char/char.o(.text+0x9c0b): undefined reference to `func_table' drivers/char/char.o(.text+0x9c40): more undefined references to `func_table' follow drivers/char/char.o: In function `vt_ioctl': drivers/char/char.o(.text+0x9c4a): undefined reference to `funcbufleft' drivers/char/char.o(.text+0x9cc2): undefined reference to `func_table' drivers/char/char.o(.text+0x9cc8): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9d19): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9d25): undefined reference to `func_table' drivers/char/char.o(.text+0x9d69): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9dc0): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9dc9): undefined reference to `func_table' drivers/char/char.o(.text+0x9dfb): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9e01): undefined reference to `func_buf' drivers/char/char.o(.text+0x9e15): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9e1b): undefined reference to `funcbufleft' drivers/char/char.o(.text+0x9e29): undefined reference to `funcbufsize' drivers/char/char.o(.text+0x9e2f): undefined reference to `funcbufleft' drivers/char/char.o(.text+0x9e39): undefined reference to `funcbufsize' drivers/char/char.o(.text+0x9e43): undefined reference to `func_table' drivers/char/char.o(.text+0x9e76): undefined reference to `accent_table_size' drivers/char/char.o(.text+0x9e89): undefined reference to `accent_table_size' drivers/char/char.o(.text+0x9e92): undefined reference to `accent_table' drivers/char/char.o(.text+0x9edd): undefined reference to `accent_table_size' drivers/char/char.o(.text+0x9eea): undefined reference to `accent_table' drivers/char/char.o: In function `handle_scancode': drivers/char/char.o(.text+0x164c1): undefined reference to `key_maps' drivers/char/char.o(.text+0x1651a): undefined reference to `key_maps' drivers/char/char.o: In function `handle_diacr': drivers/char/char.o(.text+0x16c28): undefined reference to `accent_table_size' drivers/char/char.o(.text+0x16c49): undefined reference to `accent_table' drivers/char/char.o(.text+0x16c5b): undefined reference to `accent_table' drivers/char/char.o(.text+0x16ca7): undefined reference to `accent_table' drivers/char/char.o: In function `do_fn': drivers/char/char.o(.text+0x16d1f): undefined reference to `func_table' drivers/char/char.o: In function `compute_shiftstate': drivers/char/char.o(.text+0x16f99): undefined reference to `plain_map' drivers/char/char.o: In function `do_slock': drivers/char/char.o(.text+0x170ef): undefined reference to `key_maps' make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' make: *** [vmlinux] Error 2 Any ideas what is wrong? James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Fri Feb 23 12:17:28 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 12:17:19 -0800 Received: from relais.videotron.ca ([24.201.245.36]:19703 "EHLO VL-MS-MR003.sc1.videotron.ca") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 12:16:56 -0800 Received: from videotron.ca ([24.203.121.201]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15) with ESMTP id G9887C01.QSY for ; Fri, 23 Feb 2001 15:14:00 -0500 Message-ID: <3A96D3F2.ACDCDE11@videotron.ca> Date: Fri, 23 Feb 2001 16:19:46 -0500 From: xavier oriol X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-XFS-test11 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Looking for Programing guide on XFS/Dmapi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, I've try using DMAPI based on the samples include with the Xfs package ( Linux 2.4.0 test 11 with XFS.) and I'm terribly missing a good Programing user guide for the XFS Dmapi , does anybody knows where I could get a good one ? Rebuilding the sample I've been unable to get back the DM_EVENT_WRITE event using print_event or migin ? Thank's for the help, Xavier From owner-linux-xfs@oss.sgi.com Fri Feb 23 13:58:09 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 13:57:49 -0800 Received: from esparrall.udg.es ([130.206.124.16]:65152 "EHLO esparrall.udg.es") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 13:57:37 -0800 Received: from gcs by esparrall.udg.es with local (Exim 3.22 #1 (Debian)) id 14WQOX-0000Et-00 for ; Fri, 23 Feb 2001 23:08:57 +0100 Date: Fri, 23 Feb 2001 23:08:57 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: Kernel 2.4.2 support Message-ID: <20010223230857.A871@esparrall.udg.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, As there were some bugs in the kernel which can cause filesystem corruption, will you release a patch for 2.4.2? I have tried to modify the patch (0206) and integrate it into version 2.4.2. Virtualy I succeded, but when I tried to boot with the new kernel, the kernel crashed, somewhere in fs/partition/check.c if (hd->de_arr) de = hd->de_arr[MINOR(dev) >> hd->minor_shift]; # I think this is the function: i = devfs_generate_path (de, buf, sizeof buf); if (i >= 0) printk(KERN_INFO " /dev/%s:", buf + i); else printk(KERN_INFO " %s:", disk_name(hd, MINOR(dev), buf)); Thanks your reply in advance, Laszlo Boszormenyi From owner-linux-xfs@oss.sgi.com Fri Feb 23 14:02:49 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 14:02:39 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:27914 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 14:02:30 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA24932 for ; Fri, 23 Feb 2001 14:01:26 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA921891; Fri, 23 Feb 2001 16:01:12 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA46741; Fri, 23 Feb 2001 16:01:12 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1NM2xP10468; Fri, 23 Feb 2001 16:02:59 -0600 Message-Id: <200102232202.f1NM2xP10468@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: GCS cc: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.2 support In-Reply-To: Message from GCS of "Fri, 23 Feb 2001 23:08:57 +0100." <20010223230857.A871@esparrall.udg.es> Date: Fri, 23 Feb 2001 16:02:59 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Hello, > > As there were some bugs in the kernel which can cause filesystem corruption, > will you release a patch for 2.4.2? I have tried to modify the patch (0206) > and integrate it into version 2.4.2. Virtualy I succeded, but when I tried to > boot with the new kernel, the kernel crashed, somewhere in fs/partition/check > .c > if (hd->de_arr) > de = hd->de_arr[MINOR(dev) >> hd->minor_shift]; > # I think this is the function: > i = devfs_generate_path (de, buf, sizeof buf); > if (i >= 0) > printk(KERN_INFO " /dev/%s:", buf + i); > else > printk(KERN_INFO " %s:", disk_name(hd, MINOR(dev), buf)); > > Thanks your reply in advance, Laszlo Boszormenyi The cvs tree is upto 2.4.2 now, and there is a patch out there for 2.4.2 as well, but earlier today the patch had build problems. I am not sure if it has been updated yet. Steve From owner-linux-xfs@oss.sgi.com Fri Feb 23 14:11:40 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 14:11:21 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:3450 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 14:11:12 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA07816 for ; Fri, 23 Feb 2001 14:11:11 -0800 (PST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA921215; Fri, 23 Feb 2001 16:07:21 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.184.30]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA73739; Fri, 23 Feb 2001 16:07:21 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id QAA02144; Fri, 23 Feb 2001 16:07:21 -0600 (CST) Message-Id: <200102232207.QAA02144@slobber.americas.sgi.com> To: xavier oriol cc: linux-xfs@oss.sgi.com Subject: Re: Looking for Programing guide on XFS/Dmapi Date: Fri, 23 Feb 2001 16:07:21 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >From: xavier oriol >Hello, > >I've try using DMAPI based on the samples include with the Xfs >package ( Linux 2.4.0 test 11 with XFS.) and I'm terribly missing >a good Programing user guide for the XFS Dmapi , does anybody knows >where I could get a good one ? > >Rebuilding the sample I've been unable to get back the DM_EVENT_WRITE >event using print_event or migin ? Under sample_hsm I think the only piece working on Linux is migls. Use the print_event from suite1. (No, I don't have a list of what does or doesn't work.) I don't know of a programming manual, but the DMAPI spec is at: http://www.opengroup.org/onlinepubs/9657099/toc.htm Here are some notes I use when I need to do something basic, such as get a read event for a file: --------- D=/data/clink/a/roehrich/dmapi_tests/suites $D/simple/dm_create_session -i dean1 $D/suite1/bin/set_disp -s $newsid /mnts/s0/P1 DM_EVENT_READ $D/suite1/bin/set_region -s $newsid /mnts/s0/P1 DM_REGION_READ $D/suite1/bin/get_events $newsid $D/suite1/bin/respond_event $newsid $token_num 1 0 $D/simple/dm_destroy_session -s $newsid ---------- Then, from another window, I cat(1) the file between the set_region and get_events commands. It's possible that print_event could be used instead of get_events/respond_event. Dean From owner-linux-xfs@oss.sgi.com Fri Feb 23 14:15:50 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 14:15:41 -0800 Received: from hermes.mixx.net ([212.84.196.2]:8979 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 23 Feb 2001 14:15:19 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 4A0A0F81D for ; Fri, 23 Feb 2001 23:15:12 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id EE8102CA6F; Fri, 23 Feb 2001 23:15:10 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: mysterious dbench results Date: 23 Feb 2001 22:15:10 GMT Organization: innominate AG, Berlin, Germany Lines: 46 Distribution: local Message-ID: References: <200102221504.f1MF41r20047@jen.americas.sgi.com> X-Trace: mate.bln.innominate.de 982966510 11342 10.0.0.31 (23 Feb 2001 22:15:10 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > I have been out for a while, or I would have posted something on this earlier. > The default mkfs options for xfs are not optimal for heavy I/O load, they are > somewhat historical and should probably be changed. > On mkfs try some options like this: > mkfs -t xfs -f -l size=32768b /dev/xxx > on mount use these extra options: > logbufs=4,logbsize=32768 > The first will make the on disk log bigger which helps metadata intensive > loads not become purely log bound - every request for log space ends up > having to flush metadata to disk. The mount options allow more log writes > to be in progress at once. ok - retried with those options (16384 in my case because 32k was too big for my small 700m test partition) and the dbench results got back to normal ... how about increasing those numbers by default a bit? - would there be any negative side-effects from doing so? > These should help XFS performance here, I suspect, but have not tried that > this will also help: > echo 5000 > /proc/sys/vm/pagebuf/flush_int > This will make the interval between dirtying file data and flushing it to > disk closer to that used by ext2. One of the issues with dbench is files > getting removed shortly after they are created, you can get mush better > performance if the removal happens before the data goes out to disk. will try this too now lots of thanks t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Fri Feb 23 14:54:10 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 14:53:51 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:50202 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 14:53:46 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA02627 for ; Fri, 23 Feb 2001 14:52:38 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA922008; Fri, 23 Feb 2001 16:52:25 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA60195; Fri, 23 Feb 2001 16:52:25 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1NMsBo12374; Fri, 23 Feb 2001 16:54:11 -0600 Message-Id: <200102232254.f1NMsBo12374@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Thomas Graichen cc: linux-xfs@oss.sgi.com Subject: Re: mysterious dbench results In-Reply-To: Message from Thomas Graichen of "23 Feb 2001 22:15:10 GMT." Date: Fri, 23 Feb 2001 16:54:11 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > > ok - retried with those options (16384 in my case because 32k was > too big for my small 700m test partition) and the dbench results > got back to normal ... how about increasing those numbers by > default a bit? - would there be any negative side-effects > from doing so? It is being looked into for internal sgi reasons too, yes the default could be larger, it is just a matter of working out the numbers to use. By the way, you can now use -o logbufs=8 at mount time, but this is somewhat overkill. > > > These should help XFS performance here, I suspect, but have not tried that > > this will also help: > > > echo 5000 > /proc/sys/vm/pagebuf/flush_int > > > This will make the interval between dirtying file data and flushing it to > > disk closer to that used by ext2. One of the issues with dbench is files > > getting removed shortly after they are created, you can get mush better > > performance if the removal happens before the data goes out to disk. > > will try this too now This will not really help - I tried it. Other changes coming down the pipeline - probably next week will help too, we have better dbench and bonnie numbers on some internal code right now. Steve From owner-linux-xfs@oss.sgi.com Fri Feb 23 17:18:21 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 17:18:03 -0800 Received: from mail.ima.pl ([195.117.13.5]:44807 "EHLO mail.ima.pl") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 17:17:31 -0800 Received: from blizbor.ima.pl (blizbor.ima.pl [195.117.13.88]) by dns.ima.pl ESMTP server with ESMTP id f1O1H1B23137 for ; Sat, 24 Feb 2001 02:17:02 +0100 Posted-Date: Sat, 24 Feb 2001 02:17:02 +0100 Message-Id: <5.0.0.25.0.20010224020655.01b79e70@195.117.13.2> X-Sender: blizbor@195.117.13.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 24 Feb 2001 02:15:20 +0100 To: linux-xfs@oss.sgi.com From: Blizbor Subject: Boot from floppy with XFS root on hd (sample config) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, As I found, two peoples wrote that isn't possible to make kernel small enaugh to fit on floppy. I'm agreeing that - complete kernel is to big, however it's not required to have all functionality compiled in to the kernel. Compiling less important (for boot process) part of the kernel as a modules and most important things into the kernel is possible to get compressed image around 1MB big. It can have compiled even two scsi controllers (even rather big compaq array driver). I have compiled, configured using rdev and put on the diskette using cat image > /dev/floppy. Don't forget to make 'modprobe -v floppy' before copying. Cheers, Blizbor # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_KMOD=y # # Processor type and features # CONFIG_M686FXSR=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y CONFIG_PCI_GOBIOS=y CONFIG_PCI_BIOS=y CONFIG_PCI_NAMES=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_PM=y CONFIG_APM=y # # Memory Technology Devices (MTD) # # # Parallel port support # # # Plug and Play configuration # CONFIG_PNP=y # # Block devices # CONFIG_BLK_DEV_FD=m CONFIG_BLK_CPQ_DA=y # # Multi-device support (RAID and LVM) # # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_COMPAT_IPCHAINS=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IPX=m # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NET_SCH_CBQ=m # # Telephony Support # # # ATA/IDE/MFM/RLL support # # # SCSI support # CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=8 CONFIG_BLK_DEV_SR=m CONFIG_SR_EXTRA_DEVS=4 CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI low-level drivers # CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 CONFIG_AIC7XXX_PROC_STATS=y CONFIG_AIC7XXX_RESET_DELAY=5 # # IEEE 1394 (FireWire) support # # # I2O device support # # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m # # Ethernet (1000 Mbit) # # # Wireless LAN (non-hamradio) # # # Token Ring devices # # # Wan interfaces # # # Amateur Radio support # # # IrDA (infrared) support # # # ISDN subsystem # # # Old CD-ROM drivers (not SCSI, not IDE) # # # Input core support # # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # # Mice # # # Joysticks # # # Watchdog Cards # # # Ftape, the floppy tape device driver # # # Multimedia devices # # # File systems # CONFIG_QUOTA=y CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_PAGE_BUF=y CONFIG_XFS_FS=y CONFIG_XFS_QUOTA=y CONFIG_XFS_SUPPORT=y # # Network File Systems # CONFIG_SMB_FS=m CONFIG_NCP_FS=m CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_NLS=y # # Partition Types # CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-2" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_UTF8=m # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_VIDEO_IGNORE_BAD_MODE=y # # Frame-buffer support # # # Sound # # # USB support # # # Kernel hacking # . ________________________________________________ Contrary to popular opinion, Unix is quite easy and gives you power that before now you have only dreamed of. From owner-linux-xfs@oss.sgi.com Fri Feb 23 20:42:13 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 20:42:04 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:5188 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 20:41:48 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id UAA03040 for ; Fri, 23 Feb 2001 20:51:18 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28266; Sat, 24 Feb 2001 15:40:30 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA59369; Sat, 24 Feb 2001 15:40:28 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102241540.ZM160743@wobbly.melbourne.sgi.com> Date: Sat, 24 Feb 2001 15:40:26 -0400 In-Reply-To: "Marcelo E. Magallon" "xfstest 030 fails" (Feb 23, 7:50pm) References: <20010223195034.A24640@techno.informatik.uni-stuttgart.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Marcelo E. Magallon" Subject: Re: xfstest 030 fails Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Marcelo, I'm seeing some intermittent trouble with 030 producing: 030 - output mismatch (see 030.out.bad) 272a273,276 > bad agbno AGBNO in agfl, agno 0 > bad agbno AGBNO in agfl, agno 0 > bad agbno AGBNO in agfl, agno 0 > bad agbno AGBNO in agfl, agno 0 but haven't seen the problem you describe as yet. I'll be tinkering with test 030 &/ xfs_repair next week - I'll get back to you once I've got more of a handle on it. thanks. On Feb 23, 7:50pm, Marcelo E. Magallon wrote: > Subject: xfstest 030 fails > > Hi, > > 030 - output mismatch (see 030.out.bad) > 17,18d16 > < sb root inode value INO inconsistent with calculated value INO > < resetting superblock root inode pointer to INO > 158,159d155 > < sb root inode value INO inconsistent with calculated value INO > < resetting superblock root inode pointer to INO > ... >-- End of excerpt from Marcelo E. Magallon -- Nathan From owner-linux-xfs@oss.sgi.com Fri Feb 23 21:38:33 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 21:38:15 -0800 Received: from mail1.mia.bellsouth.net ([205.152.144.13]:3264 "EHLO mail1.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 21:37:43 -0800 Received: from mail.mia.bellsouth.net (imw03pdc.bellsouth.net [205.152.0.183]) by mail1.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id AAA29331; Sat, 24 Feb 2001 00:37:40 -0500 (EST) From: casero@bellsouth.net Message-Id: <200102240537.AAA29331@mail1.mia.bellsouth.net> X-Priority: To: Blizbor , linux-xfs@oss.sgi.com Subject: Re: Boot from floppy with XFS root on hd (sample config) Date: Sat, 24 Feb 2001 0:37:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Yes I agree. It was my particular question on the list that generated the response you mention about not being able to fit the kernel image on a floppy. Long before that statement was made I had succeeded in putting an XFS enabled kernel image on floppy. Obviously this was a custom kernel and since I know exactly what hardware I have I was able to leave out most of the drivers in the kernel source that I don't need. Even so however, I liked the suggestion of modifying a stanza on the /etc/lilo.conf file to include the new kernel image. You may be aware that when a kernel is compiled and installed from source the binary image gets sent to /vmlinuz. In contrast all RedHat distros put the binary kernel images under /boot. So it was trivial really to modify the lilo.conf file to include an entry to the /vmlinuz kernel and leave the other stanzas and kernels in place on the disk. This way I can always fall back to the kernel image that came by default if I encounter a problem. My one gripe (I haven't mentioned it before because I th! ought it was kind of petty and I am grateful to the SGI folks for even making a modified RedHat distro available) is that during the installation the master boot record of my primary IDE drive gets wiped out and lilo put on it. Since my linux partitions are on the second IDE disk and another 9 Gig IBM Ultra SCSI drive it took a lot of fiddling to get my system back so I could multiboot into Win2k, Linux, and BeOS. For the record I use Win2k only to do some general office stuff and resume preparations. Nearly all of my time is spent in Linux. Ciao... > > From: Blizbor > Date: 2001/02/24 Sat AM 02:15:20 EST > To: linux-xfs@oss.sgi.com > Subject: Boot from floppy with XFS root on hd (sample config) > > Hi, > > As I found, two peoples wrote that isn't possible to make kernel > small enaugh to fit on floppy. > I'm agreeing that - complete kernel is to big, however it's not required > to have all functionality compiled in to the kernel. Compiling less > important (for boot process) part of the kernel as a modules and most > important things into the kernel is possible to get compressed image around > 1MB big. It can have compiled even two scsi controllers (even rather big > compaq array driver). > > I have compiled, configured using rdev and put on the diskette > using cat image > /dev/floppy. > Don't forget to make 'modprobe -v floppy' before copying. > > Cheers, > Blizbor > > # > # Automatically generated by make menuconfig: don't edit > # > CONFIG_X86=y > CONFIG_ISA=y > CONFIG_UID16=y > > # > # Code maturity level options > # > CONFIG_EXPERIMENTAL=y > > # > # Loadable module support > # > CONFIG_MODULES=y > CONFIG_KMOD=y > > # > # Processor type and features > # > CONFIG_M686FXSR=y > CONFIG_X86_WP_WORKS_OK=y > CONFIG_X86_INVLPG=y > CONFIG_X86_CMPXCHG=y > CONFIG_X86_BSWAP=y > CONFIG_X86_POPAD_OK=y > CONFIG_X86_L1_CACHE_SHIFT=5 > CONFIG_X86_TSC=y > CONFIG_X86_GOOD_APIC=y > CONFIG_X86_PGE=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_X86_FXSR=y > CONFIG_X86_XMM=y > CONFIG_NOHIGHMEM=y > CONFIG_MTRR=y > CONFIG_SMP=y > CONFIG_HAVE_DEC_LOCK=y > > # > # General setup > # > CONFIG_NET=y > CONFIG_X86_IO_APIC=y > CONFIG_X86_LOCAL_APIC=y > CONFIG_PCI=y > CONFIG_PCI_GOBIOS=y > CONFIG_PCI_BIOS=y > CONFIG_PCI_NAMES=y > CONFIG_SYSVIPC=y > CONFIG_SYSCTL=y > CONFIG_KCORE_ELF=y > CONFIG_BINFMT_ELF=y > CONFIG_PM=y > CONFIG_APM=y > > # > # Memory Technology Devices (MTD) > # > > # > # Parallel port support > # > > # > # Plug and Play configuration > # > CONFIG_PNP=y > > # > # Block devices > # > CONFIG_BLK_DEV_FD=m > CONFIG_BLK_CPQ_DA=y > > # > # Multi-device support (RAID and LVM) > # > > # > # Networking options > # > CONFIG_PACKET=y > CONFIG_PACKET_MMAP=y > CONFIG_NETLINK=y > CONFIG_RTNETLINK=y > CONFIG_NETLINK_DEV=y > CONFIG_NETFILTER=y > CONFIG_NETFILTER_DEBUG=y > CONFIG_FILTER=y > CONFIG_UNIX=y > CONFIG_INET=y > CONFIG_SYN_COOKIES=y > > # > # IP: Netfilter Configuration > # > CONFIG_IP_NF_IPTABLES=m > CONFIG_IP_NF_MATCH_LIMIT=m > CONFIG_IP_NF_MATCH_MAC=m > CONFIG_IP_NF_MATCH_MARK=m > CONFIG_IP_NF_MATCH_MULTIPORT=m > CONFIG_IP_NF_MATCH_TOS=m > CONFIG_IP_NF_MATCH_UNCLEAN=m > CONFIG_IP_NF_MATCH_OWNER=m > CONFIG_IP_NF_FILTER=m > CONFIG_IP_NF_TARGET_REJECT=m > CONFIG_IP_NF_TARGET_MIRROR=m > CONFIG_IP_NF_MANGLE=m > CONFIG_IP_NF_TARGET_TOS=m > CONFIG_IP_NF_TARGET_MARK=m > CONFIG_IP_NF_TARGET_LOG=m > CONFIG_IP_NF_COMPAT_IPCHAINS=m > CONFIG_IP_NF_NAT_NEEDED=y > CONFIG_IPX=m > > # > # QoS and/or fair queueing > # > CONFIG_NET_SCHED=y > CONFIG_NETLINK=y > CONFIG_RTNETLINK=y > CONFIG_NET_SCH_CBQ=m > > # > # Telephony Support > # > > # > # ATA/IDE/MFM/RLL support > # > > # > # SCSI support > # > CONFIG_SCSI=y > CONFIG_BLK_DEV_SD=y > CONFIG_SD_EXTRA_DEVS=8 > CONFIG_BLK_DEV_SR=m > CONFIG_SR_EXTRA_DEVS=4 > CONFIG_SCSI_CONSTANTS=y > CONFIG_SCSI_LOGGING=y > > # > # SCSI low-level drivers > # > CONFIG_SCSI_AIC7XXX=y > CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 > CONFIG_AIC7XXX_PROC_STATS=y > CONFIG_AIC7XXX_RESET_DELAY=5 > > # > # IEEE 1394 (FireWire) support > # > > # > # I2O device support > # > > # > # Network device support > # > CONFIG_NETDEVICES=y > > # > # ARCnet devices > # > > # > # Ethernet (10 or 100Mbit) > # > CONFIG_NET_ETHERNET=y > CONFIG_NET_VENDOR_3COM=y > CONFIG_VORTEX=m > > # > # Ethernet (1000 Mbit) > # > > # > # Wireless LAN (non-hamradio) > # > > # > # Token Ring devices > # > > # > # Wan interfaces > # > > # > # Amateur Radio support > # > > # > # IrDA (infrared) support > # > > # > # ISDN subsystem > # > > # > # Old CD-ROM drivers (not SCSI, not IDE) > # > > # > # Input core support > # > > # > # Character devices > # > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_SERIAL=y > CONFIG_UNIX98_PTYS=y > CONFIG_UNIX98_PTY_COUNT=256 > > # > # I2C support > # > > # > # Mice > # > > # > # Joysticks > # > > # > # Watchdog Cards > # > > # > # Ftape, the floppy tape device driver > # > > # > # Multimedia devices > # > > # > # File systems > # > CONFIG_QUOTA=y > CONFIG_ISO9660_FS=m > CONFIG_JOLIET=y > CONFIG_PROC_FS=y > CONFIG_DEVFS_FS=y > CONFIG_DEVFS_MOUNT=y > CONFIG_DEVPTS_FS=y > CONFIG_EXT2_FS=y > CONFIG_PAGE_BUF=y > CONFIG_XFS_FS=y > CONFIG_XFS_QUOTA=y > CONFIG_XFS_SUPPORT=y > > # > # Network File Systems > # > CONFIG_SMB_FS=m > CONFIG_NCP_FS=m > CONFIG_NCPFS_NFS_NS=y > CONFIG_NCPFS_OS2_NS=y > CONFIG_NCPFS_NLS=y > > # > # Partition Types > # > CONFIG_MSDOS_PARTITION=y > CONFIG_SMB_NLS=y > CONFIG_NLS=y > > # > # Native Language Support > # > CONFIG_NLS_DEFAULT="iso8859-2" > CONFIG_NLS_CODEPAGE_437=m > CONFIG_NLS_CODEPAGE_850=m > CONFIG_NLS_CODEPAGE_852=m > CONFIG_NLS_ISO8859_1=m > CONFIG_NLS_ISO8859_2=m > CONFIG_NLS_UTF8=m > > # > # Console drivers > # > CONFIG_VGA_CONSOLE=y > CONFIG_VIDEO_SELECT=y > CONFIG_VIDEO_IGNORE_BAD_MODE=y > > # > # Frame-buffer support > # > > # > # Sound > # > > # > # USB support > # > > # > # Kernel hacking > # > > . > ________________________________________________ > Contrary to popular opinion, Unix is quite easy and gives you > power that before now you have only dreamed of. > > > From owner-linux-xfs@oss.sgi.com Fri Feb 23 21:58:34 2001 Received: by oss.sgi.com id ; Fri, 23 Feb 2001 21:58:24 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:65038 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Fri, 23 Feb 2001 21:57:58 -0800 Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.2/8.10.1) with ESMTP id f1O5vvb61006 for ; Fri, 23 Feb 2001 23:57:57 -0600 (CST) Message-ID: <3A974D5F.9D605B80@thebarn.com> Date: Fri, 23 Feb 2001 23:57:51 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4.2 patch avaiable Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The original patch Dated Feb22 was incorrectly generated. It was based on a 2.4.0 vanilla linux tree rather than a 2.4.2 tree. A new patch was put out on oss earlier today. Feb232001devel.patch.gz Feb232001devel-cvs.patch.gz As always the best way to stay current is via cvs. http://linux-xfs.sgi.com/projects/xfs/cvs_download.html Also for anybody who has recently joined the list this little procmail rule and perl script is quite useful. :0 Hf * ^Subject.*TAKE | $HOME/bin/take2.pl take2:pl #!/usr/bin/perl #use Data::Dumper; $baseoss = "http://oss.sgi.com/cgi-bin/cvsweb.cgi"."/linux-2.4-xfs"; del"; $base = $map.$base; while(<>){ print $_; if ((($file,$revB,$revM) = /(.+)\ -\ ([0-9]+)\.([0-9]+)/)){ $revP = $revM - 1; # print "$file $revB $revM $revP\n"; $url1 = "r1=text&tr1=$revB.$revM&"; $fullurl = $base."/".$file.".diff?".$url1.$url2."f=h"; print "$fullurl\n"; } } This will convert normal TAKE messages to Modid: 2.4.x-xfs:slinx:88300a linux/fs/xfs/xfs_log_priv.h - 1.77 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_priv.h.diff?r1=text&tr1=1.77&r2=text&tr2=1.76&f=h - Bump max iclogs to 8 Which is quite useful for viewing changes. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sat Feb 24 06:24:07 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 06:23:57 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:27148 "HELO postfix.conectiva.com.br") by oss.sgi.com with SMTP id ; Sat, 24 Feb 2001 06:23:43 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by postfix.conectiva.com.br (Postfix) with ESMTP id 0665A16B5C; Sat, 24 Feb 2001 11:23:39 -0300 (EST) Date: Sat, 24 Feb 2001 10:37:19 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Rajagopal Ananthanarayanan , Steve Lord Cc: Linux-XFS Subject: Re: Repeatable Panics with XFS and RAID1 (long) In-Reply-To: <3A956800.A11C4AE3@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 22 Feb 2001, Rajagopal Ananthanarayanan wrote: > Marcelo Tosatti wrote: > > > > On Thu, 22 Feb 2001, Marcelo Tosatti wrote: > > > > > > > I think allocating memory from the atomic queue (used mainly by in > > > interrupt context) to generate dirty data may cause problems. > > > > I'll write the GFP_PAGE_IO thing we talked about RSN to avoid having to > > use GFP_ATOMIC. > > Hi Marcelo, > > The particular allocation in question, the kmalloc in > __pagebuf_write_full_page, is needed only to perform > clustering. So, what's needed is a really cheap allocation; > the code doesn't care if the allocation fails. Ananth, Steve, I think that using kmalloc() for allocations of memory which purpose is clustering is not very interesting. The code is currently allocating 4k to hold the page pointers on the cluster each time __pagebuf_write_full_page() is called. For some users it may be better to allocate the maximum amount of memory which is possible without blocking instead failing the 4k allocation and not do clustering at all. Now other users may want to _reserve_ memory for the clustering, I suppose. If memory reservation is done, we avoid getting to a state were you do not write clusters anymore because you cannot get memory for the page pointers (or any other data which is needed by the writeout path), which makes some users unhappy. (it looks like the amount of reserved memory could be autotuned with, for example, per-file sequential write detection but thats another story). And another user may want a different method of memory allocation... We may want to hide the allocation methods for clustering and delayed allocation from the writeout codepaths in pagebuf. It (the writeout path) should not ask for _that_ amount of memory for clustering, but instead accept the amount of memory which the allocator allowed it to. For example I think the page pointer memory allocation should look something like: struct cluster_list { struct page **cpages; int nr_pointers; }; int __pagebuf_write_full_page( struct inode *inode, struct page *page) { ... struct cluster_list *cpagelist = pagebuf_alloc_cluster(page, inode, ...); ... } And then make all the code which uses hardcoded "MAX_CLUSTER" right now use "cpagelist->nr_pointers". Of course it would be a bit more of work to do that for all kind of allocations pagebuf does when trying to cluster/allocated delayed data (for example the buffer_head allocations are using the generic create_empty_buffers() which does not fit this, etc..). Actually I'm not sure the real amount of work which must be done to get that right. How IRIX deals with that and what you think about this? TIA From owner-linux-xfs@oss.sgi.com Sat Feb 24 10:38:07 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 10:37:47 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:57606 "HELO postfix.conectiva.com.br") by oss.sgi.com with SMTP id ; Sat, 24 Feb 2001 10:37:27 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by postfix.conectiva.com.br (Postfix) with ESMTP id D1BFB16B66; Sat, 24 Feb 2001 15:37:15 -0300 (EST) Date: Sat, 24 Feb 2001 14:50:56 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Steve Lord Cc: Thomas Graichen , linux-xfs@oss.sgi.com Subject: Re: mysterious dbench results In-Reply-To: <200102232254.f1NMsBo12374@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 23 Feb 2001, Steve Lord wrote: > Other changes coming down the pipeline - probably next week will help too, > we have better dbench and bonnie numbers on some internal code right now. It looks we're allocating the page to hold the page pointers for the cluster unconditionally in __pagebuf_write_full_page (my last message talks a bit more about that kind of stuff). This page, as far as I can see, is not used at all without kiobuf io. (Thomas is not using kiobuf IO IIRC). From owner-linux-xfs@oss.sgi.com Sat Feb 24 12:20:28 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 12:20:18 -0800 Received: from hermes.mixx.net ([212.84.196.2]:25609 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sat, 24 Feb 2001 12:20:04 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id CDB6EF830 for ; Sat, 24 Feb 2001 21:19:56 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 809D32CA6F; Sat, 24 Feb 2001 21:19:56 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: mysterious dbench results Date: 24 Feb 2001 20:19:56 GMT Organization: innominate AG, Berlin, Germany Lines: 26 Distribution: local Message-ID: References: <200102232254.f1NMsBo12374@jen.americas.sgi.com> X-Trace: mate.bln.innominate.de 983045996 16528 10.0.0.31 (24 Feb 2001 20:19:56 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Marcelo Tosatti wrote: > On Fri, 23 Feb 2001, Steve Lord wrote: > >> Other changes coming down the pipeline - probably next week will help too, >> we have better dbench and bonnie numbers on some internal code right now. > It looks we're allocating the page to hold the page pointers for the > cluster unconditionally in __pagebuf_write_full_page (my last message > talks a bit more about that kind of stuff). This page, as far as I can > see, is not used at all without kiobuf io. (Thomas is not using kiobuf IO > IIRC). correct - all my testing was without kio btw. does the kiobuf stuff now work again without any risk in 2.4.2? (i remember there was a problem which was i think somehow related to the multiblock think in pio mode which steve wanted to fix for 2.4.2 ... somewhat in that direction i think it was) t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sat Feb 24 13:34:18 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 13:34:09 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:610 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 13:33:47 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA04470 for ; Sat, 24 Feb 2001 13:42:48 -0800 (PST) mail_from (chait@getafix.engr.sgi.com) Received: from getafix.engr.sgi.com (IDENT:root@getafix.engr.sgi.com [163.154.5.110]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA29969; Sat, 24 Feb 2001 13:31:42 -0800 (PST) Received: from localhost (chait@localhost) by getafix.engr.sgi.com (8.9.3/8.9.3) with ESMTP id NAA06141; Sat, 24 Feb 2001 13:27:40 -0500 Date: Sat, 24 Feb 2001 13:27:40 -0500 (EST) From: Chaitanya Tumuluri To: Thomas Graichen cc: linux-xfs@oss.sgi.com Subject: Re: mysterious dbench results In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 24 Feb 2001, Thomas Graichen wrote: > Marcelo Tosatti wrote: > > On Fri, 23 Feb 2001, Steve Lord wrote: > > > >> Other changes coming down the pipeline - probably next week will help too, > >> we have better dbench and bonnie numbers on some internal code right now. > > > It looks we're allocating the page to hold the page pointers for the > > cluster unconditionally in __pagebuf_write_full_page (my last message > > talks a bit more about that kind of stuff). This page, as far as I can > > see, is not used at all without kiobuf io. (Thomas is not using kiobuf IO > > IIRC). > > correct - all my testing was without kio > > btw. does the kiobuf stuff now work again without any risk in 2.4.2? > (i remember there was a problem which was i think somehow related to > the multiblock think in pio mode which steve wanted to fix for 2.4.2 > ... somewhat in that direction i think it was) Yes; there was an issue with doing kiobuf I/O via multwrite PIO to IDE disks. That has been fixed, AFAICT in the 2.4.2 XFS tree. Testers are always welcome! :^) Cheers, -Chait. From owner-linux-xfs@oss.sgi.com Sat Feb 24 14:16:20 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 14:16:09 -0800 Received: from pipt.oz.cc.utah.edu ([155.99.2.7]:3000 "EHLO pipt.oz.cc.utah.edu") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 14:15:46 -0800 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id PAA11020 for ; Sat, 24 Feb 2001 15:15:31 -0700 (MST) Date: Sat, 24 Feb 2001 15:15:30 -0700 (MST) From: james rich To: linux-xfs@oss.sgi.com Subject: Re: building 2.4.2 (with XFS) fails In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I built a stock kernel 2.4.2 with no problems so the failure below is definately something related to the XFS patches. Unfortunately I don't know the cause of the build failure. Is everyone here building on RH7? I'm using Slackware 7.1. It seems that these patches would need to build on most distros before reaching release level. Let me know if I can do something (happy to test stuff). On Fri, 23 Feb 2001, james rich wrote: > When building 2.4.2 with XFS patches the build fails with errors that > don't seem related to XFS (that's why the crosspost): > > gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux/include -Wall > -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe > -march=i686 -c -o dec_and_lock.o dec_and_lock.c > rm -f lib.a > ar rcs lib.a checksum.o old-checksum.o delay.o usercopy.o getuser.o > putuser.o iodebug.o memcpy.o dec_and_lock.o > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib' > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib' > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' > ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext > arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o > init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o > kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/block/block.o > drivers/char/char.o drivers/misc/misc.o drivers/net/net.o > drivers/media/media.o drivers/parport/driver.o drivers/char/drm/drm.o > drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o > drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o > drivers/i2c/i2c.o drivers/md/mddev.o net/network.o > /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a > /usr/src/linux/arch/i386/lib/lib.a --end-group -o vmlinux > drivers/char/char.o: In function `vt_ioctl': > drivers/char/char.o(.text+0x96fb): undefined reference to `key_maps' > drivers/char/char.o(.text+0x97cd): undefined reference to `key_maps' > drivers/char/char.o(.text+0x97ed): undefined reference to `key_maps' > drivers/char/char.o(.text+0x9808): undefined reference to `keymap_count' > drivers/char/char.o(.text+0x9877): undefined reference to `key_maps' > drivers/char/char.o(.text+0x9889): undefined reference to `keymap_count' > drivers/char/char.o(.text+0x98df): undefined reference to `key_maps' > drivers/char/char.o(.text+0x990a): undefined reference to `keymap_count' > drivers/char/char.o(.text+0x9a2e): undefined reference to `func_table' > drivers/char/char.o(.text+0x9ad7): undefined reference to `funcbufsize' > drivers/char/char.o(.text+0x9ae5): undefined reference to `funcbufleft' > drivers/char/char.o(.text+0x9afa): undefined reference to `funcbufptr' > drivers/char/char.o(.text+0x9b09): undefined reference to `func_table' > drivers/char/char.o(.text+0x9b22): undefined reference to `func_table' > drivers/char/char.o(.text+0x9b46): undefined reference to `func_table' > drivers/char/char.o(.text+0x9b57): undefined reference to `func_table' > drivers/char/char.o(.text+0x9c0b): undefined reference to `func_table' > drivers/char/char.o(.text+0x9c40): more undefined references to > `func_table' follow > drivers/char/char.o: In function `vt_ioctl': > drivers/char/char.o(.text+0x9c4a): undefined reference to `funcbufleft' > drivers/char/char.o(.text+0x9cc2): undefined reference to `func_table' > drivers/char/char.o(.text+0x9cc8): undefined reference to `funcbufptr' > drivers/char/char.o(.text+0x9d19): undefined reference to `funcbufptr' > drivers/char/char.o(.text+0x9d25): undefined reference to `func_table' > drivers/char/char.o(.text+0x9d69): undefined reference to `funcbufptr' > drivers/char/char.o(.text+0x9dc0): undefined reference to `funcbufptr' > drivers/char/char.o(.text+0x9dc9): undefined reference to `func_table' > drivers/char/char.o(.text+0x9dfb): undefined reference to `funcbufptr' > drivers/char/char.o(.text+0x9e01): undefined reference to `func_buf' > drivers/char/char.o(.text+0x9e15): undefined reference to `funcbufptr' > drivers/char/char.o(.text+0x9e1b): undefined reference to `funcbufleft' > drivers/char/char.o(.text+0x9e29): undefined reference to `funcbufsize' > drivers/char/char.o(.text+0x9e2f): undefined reference to `funcbufleft' > drivers/char/char.o(.text+0x9e39): undefined reference to `funcbufsize' > drivers/char/char.o(.text+0x9e43): undefined reference to `func_table' > drivers/char/char.o(.text+0x9e76): undefined reference to > `accent_table_size' > drivers/char/char.o(.text+0x9e89): undefined reference to > `accent_table_size' > drivers/char/char.o(.text+0x9e92): undefined reference to `accent_table' > drivers/char/char.o(.text+0x9edd): undefined reference to > `accent_table_size' > drivers/char/char.o(.text+0x9eea): undefined reference to `accent_table' > drivers/char/char.o: In function `handle_scancode': > drivers/char/char.o(.text+0x164c1): undefined reference to `key_maps' > drivers/char/char.o(.text+0x1651a): undefined reference to `key_maps' > drivers/char/char.o: In function `handle_diacr': > drivers/char/char.o(.text+0x16c28): undefined reference to > `accent_table_size' > drivers/char/char.o(.text+0x16c49): undefined reference to `accent_table' > drivers/char/char.o(.text+0x16c5b): undefined reference to `accent_table' > drivers/char/char.o(.text+0x16ca7): undefined reference to `accent_table' > drivers/char/char.o: In function `do_fn': > drivers/char/char.o(.text+0x16d1f): undefined reference to `func_table' > drivers/char/char.o: In function `compute_shiftstate': > drivers/char/char.o(.text+0x16f99): undefined reference to `plain_map' > drivers/char/char.o: In function `do_slock': > drivers/char/char.o(.text+0x170ef): undefined reference to `key_maps' > make[1]: *** [kallsyms] Error 1 > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' > make: *** [vmlinux] Error 2 > > > Any ideas what is wrong? > > James Rich > james.rich@m.cc.utah.edu > > > From owner-linux-xfs@oss.sgi.com Sat Feb 24 15:05:40 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 15:05:20 -0800 Received: from south.orl-pub.theseus.com ([12.108.42.66]:43029 "EHLO thor.theseus.com") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 15:04:47 -0800 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id SAA01998; Sat, 24 Feb 2001 18:07:47 -0500 Message-ID: <3A983E26.359F09A1@theseus.com> Date: Sat, 24 Feb 2001 18:05:10 -0500 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: james rich CC: linux-xfs@oss.sgi.com Subject: Re: building 2.4.2 (with XFS) fails <- Is GLibC 2.2 required? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Re: building 2.4.2 (with XFS) fails <- Is GLibC 2.2 required? james rich wrote: > I built a stock kernel 2.4.2 with no problems so the failure below is > definately something related to the XFS patches. Unfortunately I don't > know the cause of the build failure. Is everyone here building on RH7? > I'm using Slackware 7.1. It seems that these patches would need to build > on most distros before reaching release level. Let me know if I can do > something (happy to test stuff). Totally coming at this from a different angle, I don't think its going to be so much of a "distro" issue. I think it will be a GLibC issue. Am I safe in assuming that XFS is not well supported (nor will be well supported) on GLibC releases prior to 2.2? This is due to GLibC 2.2 having a number of new capabilities like LFS (>2GB file support on 32-bit architectures) in the VFS, among other details? If so, then that doesn't make it a "RedHat 7.x"-only 'thang, it makes it a GLibC 2.2 'thang. I've heard from many people (largely because I am already running Ext3 on my kernel 2.2 systems and there was a thread on this over on the SourceForge NFS list) that LFS is not well supported (and utility support varies) unless binaries are built against GLibC 2.2. So be it Slack, Mandrake or even RedHat 6.x users, if GLibC is the issue, your'all in the same boat. Again, please correct me if I am wrong? DISCLAIMER: I just joined the XFS list about a week ago. I have been running Ext3 for over 9 months (6 months in heavy production use) and am admist integrating XFS into a test RedHat 7.0.90 (soon to be 7.0.91) + kernel 2.4.2 installation. This move is largely due to the fact that A) Ext3 is 2.2-only right now, B) ReiserFS has kNFSd issues (let alone not quite as proven) C) XFS is one of the most advanced JFS of the lot and D) the success rate seems to be good with XFS (unless software RAID or IDE is used, although both are due to the 2.4.x kernel itself). -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Sat Feb 24 15:18:09 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 15:17:53 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14438 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 15:17:25 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09310 for ; Sat, 24 Feb 2001 15:26:58 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA33849; Sat, 24 Feb 2001 15:11:08 -0800 (PST) Message-ID: <3A98405B.EB6C32B1@sgi.com> Date: Sat, 24 Feb 2001 15:14:35 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Marcelo Tosatti CC: Steve Lord , Thomas Graichen , linux-xfs@oss.sgi.com Subject: Re: mysterious dbench results References: Content-Type: multipart/mixed; boundary="------------7DAFBB5921244692E64C7D6D" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------7DAFBB5921244692E64C7D6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Marcelo Tosatti wrote: > > On Fri, 23 Feb 2001, Steve Lord wrote: > > > > > Other changes coming down the pipeline - probably next week will help too, > > we have better dbench and bonnie numbers on some internal code right now. > > It looks we're allocating the page to hold the page pointers for the > cluster unconditionally in __pagebuf_write_full_page (my last message > talks a bit more about that kind of stuff). This page, as far as I can > see, is not used at all without kiobuf io. (Thomas is not using kiobuf IO > IIRC). Yeah, the allocation of cpages is unnecessary for non-kiocluster. The following patch (delay-buffer-6.patch) contains several key changes & cleanups. The fundamental change is to employ core linux daemons and codepaths for handling delayed allocation. Comments, feedback (stability & performance) appreciated! -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- --------------7DAFBB5921244692E64C7D6D Content-Type: text/plain; charset=us-ascii; name="delay-buffer-6.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="delay-buffer-6.patch" diff -Naur ../../xfs-orig/linux/drivers/block/ll_rw_blk.c drivers/block/ll_rw_blk.c --- ../../xfs-orig/linux/drivers/block/ll_rw_blk.c Thu Feb 22 14:36:01 2001 +++ drivers/block/ll_rw_blk.c Sat Feb 24 12:10:07 2001 @@ -1250,6 +1250,7 @@ if (!nr) return; + major = MAJOR(bhs[0]->b_dev); /* Determine correct block size for this device. */ @@ -1270,6 +1271,8 @@ correct_size, bh->b_size); goto sorry; } + if (test_bit(BH_Delay, &bh->b_state) || !buffer_mapped(bh)) + BUG(); } if ((rw & WRITE) && is_read_only(bhs[0]->b_dev)) { diff -Naur ../../xfs-orig/linux/drivers/scsi/scsi_merge.c drivers/scsi/scsi_merge.c --- ../../xfs-orig/linux/drivers/scsi/scsi_merge.c Thu Feb 22 14:36:21 2001 +++ drivers/scsi/scsi_merge.c Thu Feb 22 14:12:35 2001 @@ -92,7 +92,7 @@ printk("counted segments is %x\n", segments); printk("Flags %d %d\n", use_clustering, dma_host); if (req->bh != NULL) { - for (bh = req->bh; bh->b_reqnext != NULL; bh = bh->b_reqnext) { + for (bh = req->bh; bh != NULL; bh = bh->b_reqnext) { printk("Segment 0x%p, blocks %d, addr 0x%lx\n", bh, bh->b_size >> 9, diff -Naur ../../xfs-orig/linux/fs/buffer.c fs/buffer.c --- ../../xfs-orig/linux/fs/buffer.c Thu Feb 22 14:36:27 2001 +++ fs/buffer.c Sat Feb 24 12:04:12 2001 @@ -161,6 +161,38 @@ atomic_dec(&bh->b_count); } + +#define buffer_delay_busy(bh) \ + (test_bit(BH_Delay, &bh->b_state) && bh->b_page && PageLocked(bh->b_page)) + +void +_write_buffer(struct buffer_head *bh) +{ + struct page *page = bh->b_page; + + if (!page || TryLockPage(page)) + return; + if (!buffer_delay(bh) || !buffer_dirty(bh)) { + if (buffer_delay(bh)) + BUG(); + UnlockPage(page); + return; + } + page->mapping->a_ops->writepage(page); + if (DelallocPage(page)) + BUG(); +} + +static inline void +write_buffer(struct buffer_head *bh) +{ + if (!buffer_delay(bh)) + ll_rw_block(WRITE, 1, &bh); + else + _write_buffer(bh); +} + + /* Call sync_buffers with wait!=0 to ensure that the call does not * return until all buffer writes have completed. Sync() may return * before the writes have finished; fsync() may not. @@ -232,7 +264,7 @@ atomic_inc(&bh->b_count); spin_unlock(&lru_list_lock); - ll_rw_block(WRITE, 1, &bh); + write_buffer(bh); atomic_dec(&bh->b_count); retry = 1; goto repeat; @@ -507,6 +539,8 @@ struct bh_free_head *head = &free_list[BUFSIZE_INDEX(bh->b_size)]; struct buffer_head **bhp = &head->list; + if (test_bit(BH_Delay, &bh->b_state)) + BUG(); bh->b_state = 0; spin_lock(&head->lock); @@ -879,7 +913,7 @@ if (buffer_dirty(bh)) { atomic_inc(&bh->b_count); spin_unlock(&lru_list_lock); - ll_rw_block(WRITE, 1, &bh); + write_buffer(bh); brelse(bh); spin_lock(&lru_list_lock); } @@ -1395,8 +1429,10 @@ head = page->buffers; bh = head; - if (DelallocPage(page)) - BUG(); + if (buffer_delay(bh)) { + page->mapping->a_ops->writepage_nounlock(page); + return 0; /* just started I/O ... likely didn't complete */ + } do { unsigned int next_off = curr_off + bh->b_size; next = bh->b_this_page; @@ -2381,7 +2417,7 @@ if (wait > 1) __wait_on_buffer(p); } else if (buffer_dirty(p)) - ll_rw_block(WRITE, 1, &p); + write_buffer(p); } while (tmp != bh); } @@ -2408,6 +2444,11 @@ int index = BUFSIZE_INDEX(bh->b_size); int loop = 0; + if (buffer_delay(bh)) { + if (wait) + page->mapping->a_ops->writepage_nounlock(page); + return 0; /* just started I/O ... likely didn't complete */ + } cleaned_buffers_try_again: spin_lock(&lru_list_lock); write_lock(&hash_table_lock); @@ -2609,7 +2650,7 @@ __refile_buffer(bh); continue; } - if (buffer_locked(bh)) + if (buffer_locked(bh) || buffer_delay_busy(bh)) continue; if (check_flushtime) { @@ -2627,7 +2668,7 @@ /* OK, now we are committed to write it out. */ atomic_inc(&bh->b_count); spin_unlock(&lru_list_lock); - ll_rw_block(WRITE, 1, &bh); + write_buffer(bh); atomic_dec(&bh->b_count); if (current->need_resched) diff -Naur ../../xfs-orig/linux/fs/pagebuf/page_buf.c fs/pagebuf/page_buf.c --- ../../xfs-orig/linux/fs/pagebuf/page_buf.c Fri Feb 23 11:23:14 2001 +++ fs/pagebuf/page_buf.c Fri Feb 23 18:54:46 2001 @@ -152,8 +152,6 @@ * External pagebuf I/O functions */ -extern int _page_cleaner_daemon_start(void); -extern void _page_cleaner_daemon_stop(void); extern void _pb_zero_out_delay(struct inode *, struct page *, page_buf_bmap_t *); @@ -177,10 +175,10 @@ * /proc/sys/vm/pagebuf */ -unsigned long pagebuf_min[P_PARAM] = { HZ/2, 1*HZ, HZ/2, 1, 0, 0 }; -unsigned long pagebuf_max[P_PARAM] = { HZ*30, HZ*300, HZ*30, 1024, 4096, 1 }; +unsigned long pagebuf_min[P_PARAM] = { HZ/2, 1*HZ, 1, 0 }; +unsigned long pagebuf_max[P_PARAM] = { HZ*30, HZ*300, 1024, 1 }; -pagebuf_param_t pb_params = {{ HZ, 15 * HZ, HZ, 512, 1024, 0 }}; +pagebuf_param_t pb_params = {{ HZ, 15 * HZ, 512, 0 }}; /* * Pagebuf statistics variables @@ -455,14 +453,13 @@ struct page **pages) { loff_t next_buffer_offset; - loff_t next_desired_offset; unsigned long page_count; int rval; struct kiobuf *kp; unsigned long pi; unsigned long index; off_t start_off, end_off; - int all_mapped, good_pages, sectors, count; + int all_mapped, good_pages, sectors; struct page *cp, **hash, *cached_page; int gfp_mask; @@ -2082,6 +2079,7 @@ spin_unlock_irqrestore(¤t->sigmask_lock, flags); strcpy(current->comm, "pagebuf_daemon"); + current->flags |= PF_MEMALLOC; do { if (pb_daemon->active == 1) { @@ -2367,8 +2365,7 @@ return -1; /* error */ } } - - return _page_cleaner_daemon_start(); + return 0; } int @@ -2404,18 +2401,12 @@ {PB_FLUSH_AGE, "flush_age", &pb_params.data[1], sizeof(int), 0644, NULL, &proc_doulongvec_ms_jiffies_minmax, &sysctl_intvec, NULL, &pagebuf_min[1], &pagebuf_max[1]}, - {PB_CLEAN_INT, "clean_int", &pb_params.data[2], - sizeof(int), 0644, NULL, &proc_doulongvec_ms_jiffies_minmax, - &sysctl_intvec, NULL, &pagebuf_min[2], &pagebuf_max[2]}, - {PB_CLUSTER_LIMIT, "cluster_limit", &pb_params.data[3], + {PB_CLUSTER_LIMIT, "cluster_limit", &pb_params.data[2], sizeof(int), 0644, NULL, &proc_doulongvec_minmax, &sysctl_intvec, NULL, - &pagebuf_min[3], &pagebuf_max[3]}, - {PB_DELALLOC_LIMIT, "delalloc_count", &pb_params.data[4], - sizeof(int), 0644, NULL, &proc_doulongvec_minmax, &sysctl_intvec, NULL, - &pagebuf_min[4], &pagebuf_max[4]}, - {PB_DEBUG, "debug", &pb_params.data[5], + &pagebuf_min[2], &pagebuf_max[2]}, + {PB_DEBUG, "debug", &pb_params.data[3], sizeof(int), 0644, NULL, &proc_doulongvec_minmax, &sysctl_intvec, NULL, - &pagebuf_min[5], &pagebuf_max[5]}, + &pagebuf_min[3], &pagebuf_max[3]}, {0} }; @@ -2545,7 +2536,6 @@ { if (pagebuf_cache != NULL) kmem_cache_destroy(pagebuf_cache); - _page_cleaner_daemon_stop(); pagebuf_daemon_stop(); pagebuf_locking_terminate(); avl_terminate(); diff -Naur ../../xfs-orig/linux/fs/pagebuf/page_buf_io.c fs/pagebuf/page_buf_io.c --- ../../xfs-orig/linux/fs/pagebuf/page_buf_io.c Fri Feb 23 10:29:09 2001 +++ fs/pagebuf/page_buf_io.c Sat Feb 24 12:03:50 2001 @@ -103,8 +103,6 @@ /* * Globals */ -static int pcd_active; -int PB_MAX_DIRTY_FACTOR = 4; static DECLARE_WAIT_QUEUE_HEAD(pcd_waitq); static atomic_t pb_delalloc_pages = ATOMIC_INIT(0); @@ -114,7 +112,6 @@ extern spinlock_t pagecache_lock; -int page_cleaner_count, page_cleaner_pages; int do_write_full_page, do_write_pages; int flush_convert, flush_convert_pages; @@ -122,8 +119,6 @@ * The minimum size where we will start using pagebuf structures instead * of just working with pages. */ - -#define PAGEBUF_MIN_IOSIZE (4*PAGE_CACHE_SIZE) #define PBF_IO_CHUNKSIZE 65536 #define PBF_MAX_MAPS 1 @@ -165,13 +160,28 @@ __pb_block_commit_write_async(inode, page, mp, 0); } -static inline void -_unmark_delalloc(struct page *page) +static void +_unmark_delalloc(struct page *page, int toss) { + struct buffer_head *bh = page->buffers; + if (!PageLocked(page)) PAGE_BUG(page); - if (test_and_clear_bit(PG_delalloc, &page->flags)) - atomic_dec(&pb_delalloc_pages); + if (!DelallocPage(page)) + PAGE_BUG(page); + if (!bh) + BUG(); + clear_bit(BH_Delay, &bh->b_state); + atomic_dec(&pb_delalloc_pages); + if (!toss && !buffer_mapped(bh)) + printk("warning: unmarking unmapped buffer page 0x%p\n", page); + if (toss && !buffer_mapped(bh)) { + if (!buffer_dirty(bh)) + BUG(); + mark_buffer_clean(bh); + if (bh->b_list != BUF_CLEAN) + printk("buffer bh 0x%p not clean\n", bh); + } } /* @@ -208,7 +218,6 @@ static void _pagebuf_flush( - struct inode *ip, /* used for KIOCLUSTER check */ struct list_head *head, /* list of pages */ loff_t ioff, /* first location in range */ struct page **cpages) /* clustering buffer */ @@ -238,9 +247,8 @@ flush_convert_pages += pagebuf_delalloc_convert(page, PBF_FILE_ALLOCATE, cpages); - } else { - UnlockPage(page); - } + } + UnlockPage(page); page_cache_release(page); spin_lock(&pagecache_lock); goto repeat; @@ -257,6 +265,7 @@ { struct page **cpages = NULL; +#if defined(KIOCLUSTER) /* * If kmalloc fails, no big deal; the lower layers won't * cluster. Also, this allocation has to be non-sleeping @@ -264,11 +273,12 @@ */ cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * sizeof(struct page *), GFP_PAGE_IO); +#endif spin_lock(&pagecache_lock); - _pagebuf_flush(ip, &ip->i_mapping->clean_pages, ioff, cpages); - _pagebuf_flush(ip, &ip->i_mapping->dirty_pages, ioff, cpages); - _pagebuf_flush(ip, &ip->i_mapping->locked_pages, ioff, cpages); + _pagebuf_flush(&ip->i_mapping->clean_pages, ioff, cpages); + _pagebuf_flush(&ip->i_mapping->dirty_pages, ioff, cpages); + _pagebuf_flush(&ip->i_mapping->locked_pages, ioff, cpages); spin_unlock(&pagecache_lock); generic_buffer_fdatasync(ip, (unsigned long) ioff, ~0UL); @@ -507,27 +517,19 @@ return (-ENOMEM); } assert(((csize + cpoff) <= PAGE_CACHE_SIZE)); + lock_page(page); memset((void *) (kmap(page) + cpoff), 0, csize); kunmap(page); SetPageUptodate(page); if (pb->pb_bn == PAGE_BUF_DADDR_NULL) { - if (test_and_set_bit(PG_delalloc, &page->flags) == 0) { - atomic_inc(&pb_delalloc_pages); - } + __pb_block_commit_write_async(pb->pb_target, page, NULL, 0); } + UnlockPage(page); } pb->pb_flags &= ~(PBF_READ | PBF_WRITE); pb->pb_flags &= ~(_PBF_SOME_INVALID_PAGES | PBF_PARTIAL | PBF_NONE); - if (!pcd_active && (pb->pb_bn == PAGE_BUF_DADDR_NULL)) { - unsigned int np = atomic_read(&pb_delalloc_pages); - - if (np > pb_params.p_un.max_dirty_pages) - wake_up_interruptible(&pcd_waitq); - } - - return (0); } @@ -995,15 +997,13 @@ PAGE_CACHE_SIZE, &map, 1, &nmaps, PBF_READ); - hook_buffers_to_page(inode, page, &map, PAGE_CACHE_SHIFT); - bh = page->buffers; if (map.pbm_bn > 0) { + hook_buffers_to_page(inode, page, &map, PAGE_CACHE_SHIFT); bh = head = page->buffers; } else if (map.pbm_flags & (PBMF_HOLE|PBMF_DELAY)) { memset(kmap(page), 0, PAGE_CACHE_SIZE); flush_dcache_page(page); kunmap(page); - set_bit(BH_Uptodate, &bh->b_state); goto page_done; } else { printk("pagebuf_read_full_page: page 0x%p map 0x%p\n", @@ -1056,25 +1056,16 @@ struct inode *inode, struct page *page) { - struct page **cpages; + struct page **cpages = NULL; int pb_flags; int count; unsigned long save_flags = current->flags; - spin_lock(&inode_lock); - if (inode->i_state & I_MAPPING) { - spin_unlock(&inode_lock); - SetPageDirty(page); - UnlockPage(page); - return 0; - } - inode->i_state |= I_MAPPING; - spin_unlock(&inode_lock); - current->flags |= PF_MEMALLOC; +#if defined(KIOCLUSTER) cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * sizeof(struct page *), GFP_PAGE_IO); - +#endif do_write_full_page++; if (DelallocPage(page)) @@ -1085,13 +1076,11 @@ count = pagebuf_delalloc_convert(page, pb_flags, cpages); do_write_pages += count; + if (DelallocPage(page)) + BUG(); if (cpages) kfree(cpages); - spin_lock(&inode_lock); - inode->i_state &= ~I_MAPPING; - spin_unlock(&inode_lock); - current->flags = save_flags; return 0; } @@ -1100,7 +1089,7 @@ * pagebuf_write_full_page */ -int pagebuf_write_full_page(struct page *page) +STATIC int pagebuf_write_full_page(struct page *page) { struct inode *inode = (struct inode*)page->mapping->host; unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT; @@ -1112,11 +1101,12 @@ return __pagebuf_write_full_page(inode, page); /* things got complicated... */ - offset = inode->i_size & PAGE_CACHE_MASK_LL; + offset = inode->i_size & (~PAGE_CACHE_MASK_LL); /* OK, are we completely out? */ if ((page->index >= end_index+1) || !offset) { - UnlockPage(page); - return -EIO; + printk("Bad write on page 0x%p\n", page); + err = -EIO; + goto out; } if (DelallocPage(page)) @@ -1132,11 +1122,39 @@ __pb_block_commit_write_async(inode, page, NULL, 0); } + if (DelallocPage(page)) + BUG(); kunmap(page); - UnlockPage(page); +out: return err; } +int pagebuf_write_full_page_unlock(struct page *page) +{ + int ret = pagebuf_write_full_page(page); + UnlockPage(page); + return ret; +} + +int pagebuf_write_full_page_nounlock(struct page *page) +{ + return pagebuf_write_full_page(page); +} + +STATIC void +hook_buffers_to_page_delay(struct inode *inode, struct page *page) +{ + struct buffer_head *bh; + + if (page->buffers) + BUG(); + create_empty_buffers(page, inode->i_dev, PAGE_CACHE_SIZE); + bh = page->buffers; + bh->b_state = (1 << BH_Delay); + atomic_inc(&pb_delalloc_pages); + __mark_buffer_dirty(bh); + balance_dirty(bh->b_dev); +} STATIC void hook_buffers_to_page(struct inode *inode, @@ -1145,6 +1163,11 @@ struct buffer_head *bh; page_buf_daddr_t bn; + if (mp->pbm_bn < 0) { + printk("hook_buffers_to_page: bad bn page 0x%p mp 0x%p\n", + page, mp); + BUG(); + } if (!page->buffers) create_empty_buffers(page, inode->i_dev, PAGE_CACHE_SIZE); @@ -1153,21 +1176,13 @@ bh->b_end_io = end_pb_buffer_io_async; bh->b_private = (void *) 0; - if (mp->pbm_flags & (PBMF_HOLE|PBMF_DELAY)) { - bh->b_blocknr = 0; - bh->b_state = (1 << BH_Req) | (1 << BH_End_io); - return; - } - if (mp->pbm_bn < 0) { - printk("hook_buffers_to_page: bad bn page 0x%p mp 0x%p\n", - page, mp); - BUG(); - } bn = mp->pbm_bn >> (bshift - inode->i_sb->s_blocksize_bits); bn += (mp->pbm_delta >> bshift); bh->b_blocknr = bn; - bh->b_state = (1 << BH_Mapped) | (1 << BH_Req) | (1 << BH_End_io); + if (buffer_locked(bh) || buffer_req(bh)) + BUG(); + bh->b_state |= (1 << BH_Mapped) | (1 << BH_Req) | (1 << BH_End_io); } @@ -1183,6 +1198,7 @@ set_bit(BH_Uptodate, &bh->b_state); if (!buffer_dirty(bh)) { bh->b_end_io = end_pb_buffer_io_async; + bh->b_state |= (1 << BH_End_io); need_balance_dirty = 1; } __mark_buffer_dirty(bh); @@ -1198,7 +1214,7 @@ { struct buffer_head *bh; int err = 0; - int nmaps; + int nmaps, dp = DelallocPage(page); char *kaddr = kmap(page); page_buf_bmap_t map; @@ -1211,7 +1227,8 @@ * go get some space. */ bh = page->buffers; - if ((!bh || !buffer_mapped(bh)) && !DelallocPage(page)) { + if ((!bh || !buffer_mapped(bh)) && (!dp || (flags & PBF_FILE_ALLOCATE))) + { if (!mp) { mp = ↦ err = inode->i_op->pagebuf_bmap(inode, @@ -1226,6 +1243,8 @@ } if (mp->pbm_bn > 0) { hook_buffers_to_page(inode, page, mp, PAGE_CACHE_SHIFT); + if (dp) + _unmark_delalloc(page, 0); bh = page->buffers; } } @@ -1240,7 +1259,7 @@ /* * Partial write. Is the page valid anyway? */ - if (Page_Uptodate(page) || DelallocPage(page)) { + if (Page_Uptodate(page) || dp) { goto out; } /* @@ -1341,7 +1360,6 @@ int partial) { struct buffer_head *bh; - unsigned int np; /* * Prepare write took care of reading/zero-out @@ -1351,15 +1369,8 @@ SetPageUptodate(page); if ((bh = page->buffers) && buffer_mapped(bh)) { set_buffer_dirty_uptodate(page->buffers, partial); - } else if (test_and_set_bit(PG_delalloc, &page->flags) == 0) { - atomic_inc(&pb_delalloc_pages); - if (!pcd_active) { - np = atomic_read(&pb_delalloc_pages); - if (np > pb_params.p_un.max_dirty_pages) - wake_up_interruptible(&pcd_waitq); - } - if (!partial) - balance_dirty(inode->i_rdev); + } else if (!DelallocPage(page)) { + hook_buffers_to_page_delay(inode, page); } /* Advance though extent no matter what */ @@ -1693,9 +1704,6 @@ return written ? written : status; } -static int page_cleaner_daemon_started = 0; -static int daemon_terminate = 0; - /* * Probe for a given page (index) in the inode & test if it is delayed. * Returns page locked and with an extra reference count. @@ -1730,21 +1738,11 @@ page_cache_release(page); return NULL; } - /* In the case where we probe a page - push it back down the LRU - * so we do not hit it on the next pass. - */ - - spin_lock(&pagemap_lru_lock); - if (PageInactiveDirty(page)) { - list_del(&page->lru); - list_add(&page->lru, &inactive_dirty_list); - } - spin_unlock(&pagemap_lru_lock); - _unmark_delalloc(page); return page; } +#if defined(KIOCLUSTER) /* * Convert & write out a cluster of pages in the same extent as defined * by mp and surrounding "startpage". startpage is locked & has an extra @@ -1815,16 +1813,36 @@ return count; } +#endif /* KIOCLUSTER */ + /* * Allocate & map buffers for page given the extent map. */ STATIC void -convert_page(struct inode *inode, struct page *page, page_buf_bmap_t *mp) +convert_page(struct inode *inode, struct page *page, page_buf_bmap_t *mp, int u) { - mp->pbm_delta = (page->index << PAGE_CACHE_SHIFT) - mp->pbm_offset; - hook_buffers_to_page(inode, page, mp, PAGE_CACHE_SHIFT); - set_buffer_dirty_uptodate(page->buffers, 0); - UnlockPage(page); + struct buffer_head *bh = page->buffers; + int dp = DelallocPage(page); + + if (!bh || dp) { + mp->pbm_delta = (page->index << PAGE_CACHE_SHIFT) - mp->pbm_offset; + hook_buffers_to_page(inode, page, mp, PAGE_CACHE_SHIFT); + if (dp) + _unmark_delalloc(page, 0); + } + bh = page->buffers; + /* + * 1 == don't balance dirty, we are doing I/O just below here. + * otherwise causes nasty recursions. + */ + set_buffer_dirty_uptodate(bh, 1); + if (u) + UnlockPage(page); + + atomic_inc(&bh->b_count); + ll_rw_block(WRITE, 1, &bh); + atomic_dec(&bh->b_count); + page_cache_release(page); } @@ -1849,16 +1867,16 @@ for (tindex = startpage->index-1; tindex >= tlast; tindex--) { if (!(page = probe_page(inode, tindex))) break; - convert_page(inode, page, mp); + convert_page(inode, page, mp, 1); } } - convert_page(inode, startpage, mp); + convert_page(inode, startpage, mp, 0); tlast = PAGE_CACHE_ALIGN_LL(mp->pbm_offset + mp->pbm_bsize) >> PAGE_CACHE_SHIFT; for (tindex = startpage->index + 1; tindex < tlast; tindex++) { if (!(page = probe_page(inode, tindex))) break; - convert_page(inode, page, mp); + convert_page(inode, page, mp, 1); } } @@ -1872,7 +1890,7 @@ if (!PageLocked(page)) BUG(); - _unmark_delalloc(page); + _unmark_delalloc(page, 1); } @@ -1884,7 +1902,7 @@ { page_buf_bmap_t maps[PBF_MAX_MAPS]; struct inode *inode; - int maps_returned, error, count; + int maps_returned, error; u_long pb_flags; loff_t rounded_offset; @@ -1894,8 +1912,8 @@ * anything. */ if (!inode->i_nlink && (inode->i_state & I_FREEING)) { - _unmark_delalloc(page); - UnlockPage(page); + BUG(); + _unmark_delalloc(page, 1); return 0; } @@ -1918,12 +1936,10 @@ if (error != -EIO) printk("PCD: pagebuf_bmap error %d pb_flags 0x%lx\n", error, pb_flags); - UnlockPage(page); return 0; } if (maps[0].pbm_delta % PAGE_CACHE_SIZE) { printk("PCD: pbm_delta not page aligned mp 0x%p\n", &maps[0]); - UnlockPage(page); return 0; } @@ -1935,236 +1951,15 @@ } page_cache_get(page); - _unmark_delalloc(page); /* * page needs to be setup as though find_page(...) returned it, * which is a locked page with an extra reference. */ - if (cpages) { - count = kio_cluster_write(inode, page, &maps[0], cpages); - } else { - cluster_write(inode, page, &maps[0]); - count = 1; - } - return count; + cluster_write(inode, page, &maps[0]); + return 1; } /* - * Walk the active pages list looking for delalloc entries, we need to - * age them out all the time, since they have to be converted before - * being written to disk. If there is no other memory pressure then pages - * on the active list do not get moved, and we do not put them somewhere - * the cleaner can find them. - */ - -void age_delalloc_pages(void) -{ - struct page *page; - struct list_head * page_lru; - int maxscan, page_active; - - maxscan = nr_active_pages; - while (maxscan-- > 0 && (page_lru = active_list.prev) != &active_list) { - page = list_entry(page_lru, struct page, lru); - if (!DelallocPage(page)) { - list_del(page_lru); - list_add(page_lru, &active_list); - continue; - } - - /* Do aging on delalloc pages. */ - if (PageTestandClearReferenced(page)) { - age_page_up_nolock(page); - page_active = 1; - } else { - age_page_down_ageonly(page); - if (page->age == 0 && page_count(page) <= - (page->buffers ? 2 : 1)) { - deactivate_page_nolock(page); - page_active = 0; - } else { - page_active = 1; - } - } - if (page_active || PageActive(page)) { - list_del(page_lru); - list_add(page_lru, &active_list); - } - } -} - -STATIC int -page_cleaner_daemon(void *data) -{ - struct page *page; - u_long flags; - struct buffer_head *bh; - struct page **cpages; - int maxscan, sum; - struct list_head * page_lru; - - /* Set up the thread */ - exit_files(current); - daemonize(); - - spin_lock_irqsave(¤t->sigmask_lock, flags); - flush_signals(current); - sigfillset(¤t->blocked); - recalc_sigpending(current); - spin_unlock_irqrestore(¤t->sigmask_lock, flags); - - sprintf(current->comm, "page_daemon"); - - /* - * If we need more memory to do bmap, - * indicate this thread might really need it. - */ - current->flags |= PF_MEMALLOC; - - cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * sizeof(struct page *), - GFP_KERNEL); - while (1) { - /* - * If we actually get into a low-memory situation, - * the processes needing more memory will wake us - * up on a more timely basis. - */ - - sum = 0; - spin_lock(&pagemap_lru_lock); - - if (atomic_read(&pb_delalloc_pages) > 0) - age_delalloc_pages(); - - - maxscan = nr_inactive_dirty_pages; - while ((page_lru = inactive_dirty_list.prev) != - &inactive_dirty_list && maxscan-- > 0) { - - if (current->need_resched) { - break; - } - - page = list_entry(page_lru, struct page, lru); - /* - * We know this page is going to go somewhere, do not - * bother scanning it again. - */ - list_del(page_lru); - list_add(page_lru, &inactive_dirty_list); - - if (!DelallocPage(page)) - continue; - - if (TryLockPage(page)) - continue; - - bh = page->buffers; - if (bh && buffer_mapped(bh)) { - /* - * delalloc page has buffers refile it. - */ - - spin_unlock(&pagemap_lru_lock); - _unmark_delalloc(page); - set_buffer_dirty_uptodate(bh, 0); - UnlockPage(page); - spin_lock(&pagemap_lru_lock); - continue; - } - -/*---------------- DELALLOC CONVERT --------------------------------*/ -/* since bmap can block, this should be in a different daemon */ -/*---------------- DELALLOC CONVERT --------------------------------*/ - - spin_unlock(&pagemap_lru_lock); - page_cleaner_count++; - { - int cnt; - cnt = pagebuf_delalloc_convert(page, PBF_FILE_ALLOCATE, - cpages); - - sum += cnt; - page_cleaner_pages += cnt; - } - - /* Do not let too many pages get locked up - * waiting for the queue to open in here - */ - if (sum > 256) { - run_task_queue(&tq_disk); - sum = 0; - } - spin_lock(&pagemap_lru_lock); - } - spin_unlock(&pagemap_lru_lock); - run_task_queue(&tq_disk); - pcd_active = 0; - - if (daemon_terminate) { - page_cleaner_daemon_started = 0; - wake_up_interruptible(&pcd_waitq); - break; - } - - /* - * if woken up periodically (nothing else to do) - * convert all the pages, else convert only - * to keep watermarks happy. - */ - interruptible_sleep_on_timeout(&pcd_waitq, - pb_params.p_un.cluster_interval); - pcd_active = 1; - } - kfree(cpages); - return 0; -} - -int -_page_cleaner_daemon_start(void) -{ - extern int pagebuf_max[]; - - if (!page_cleaner_daemon_started) { - page_cleaner_daemon_started = 1; - - /* - * watermarks: at 1/16 of total mem start waking - * the daemon to convert ... at 1/8th kick the - * daemon synchronously ... at 1/4th stop generating - * any more delay pages. Low water before daemon - * normally stops is 1/4th of when the daemon is - * activated. - */ - pb_params.p_un.max_dirty_pages = max_mapnr >> 4; - - MAX_CLUSTER = pb_params.p_un.max_dirty_pages >> 1; - if (MAX_CLUSTER > 1024) /* arbitray max. */ - MAX_CLUSTER = 1024; - CLUSTER_PAGE_LIST_SIZE = ((2*MAX_CLUSTER)+1); - pagebuf_max[4] = MAX_CLUSTER; - - if (0 > kernel_thread(page_cleaner_daemon, (void *)0, - CLONE_FS|CLONE_FILES|CLONE_SIGHAND)) - { - printk("Can't start page cleaner daemon\n"); - return -1; /* error */ - } - } - return 0; /* success */ -} - -void -_page_cleaner_daemon_stop(void) -{ - daemon_terminate = 1; - wake_up_interruptible_sync(&pcd_waitq); - while (page_cleaner_daemon_started) - interruptible_sleep_on(&pcd_waitq); -} - - -/* * Module management */ @@ -2177,7 +1972,8 @@ EXPORT_SYMBOL(pagebuf_generic_file_read); EXPORT_SYMBOL(pagebuf_generic_file_write); EXPORT_SYMBOL(pagebuf_read_full_page); -EXPORT_SYMBOL(pagebuf_write_full_page); +EXPORT_SYMBOL(pagebuf_write_full_page_nounlock); +EXPORT_SYMBOL(pagebuf_write_full_page_unlock); EXPORT_SYMBOL(pagebuf_toss_page); EXPORT_SYMBOL(pagebuf_prepare_write); EXPORT_SYMBOL(pagebuf_commit_write); diff -Naur ../../xfs-orig/linux/fs/xfs/linux/xfs_iops.c fs/xfs/linux/xfs_iops.c --- ../../xfs-orig/linux/fs/xfs/linux/xfs_iops.c Mon Feb 12 14:20:44 2001 +++ fs/xfs/linux/xfs_iops.c Tue Feb 20 21:47:55 2001 @@ -756,7 +756,8 @@ struct address_space_operations linvfs_aops = { readpage: pagebuf_read_full_page, - writepage: pagebuf_write_full_page, + writepage: pagebuf_write_full_page_unlock, + writepage_nounlock: pagebuf_write_full_page_nounlock, sync_page: block_sync_page, bmap: linvfs_bmap, toss_page: pagebuf_toss_page, diff -Naur ../../xfs-orig/linux/fs/xfs/xfs_log.c fs/xfs/xfs_log.c --- ../../xfs-orig/linux/fs/xfs/xfs_log.c Thu Feb 22 12:55:50 2001 +++ fs/xfs/xfs_log.c Thu Feb 22 12:00:31 2001 @@ -1345,6 +1345,7 @@ uint count; /* byte count of bwrite */ int split = 0; /* split write into two regions */ int error; + unsigned long save_flags = current->flags; XFS_STATS_INC(xs_log_writes); ASSERT(iclog->ic_refcnt == 0); @@ -1354,6 +1355,8 @@ xlog_panic("xlog_sync: illegal flag"); #endif + current->flags |= PF_MEMALLOC; + xlog_pack_data(log, iclog); /* put cycle number in every block */ INT_SET(iclog->ic_header.h_len, ARCH_CONVERT, iclog->ic_offset); /* real byte length */ @@ -1412,6 +1415,7 @@ if (error = XFS_bwrite(bp)) { xfs_ioerror_alert("xlog_sync", log->l_mp, XFS_BUF_TARGET(bp), XFS_BUF_ADDR(bp)); + current->flags = save_flags; return (error); } if (split) { @@ -1448,9 +1452,11 @@ if (error = XFS_bwrite(bp)) { xfs_ioerror_alert("xlog_sync (split)", log->l_mp, XFS_BUF_TARGET(bp), XFS_BUF_ADDR(bp)); + current->flags = save_flags; return (error); } } + current->flags = save_flags; return (0); } /* xlog_sync */ diff -Naur ../../xfs-orig/linux/include/linux/fs.h include/linux/fs.h --- ../../xfs-orig/linux/include/linux/fs.h Fri Feb 23 10:33:21 2001 +++ include/linux/fs.h Fri Feb 23 18:38:49 2001 @@ -220,6 +220,8 @@ #define BH_New 5 /* 1 if the buffer is new and not yet written out */ #define BH_Protected 6 /* 1 if the buffer is protected */ #define BH_End_io 7 /* 1 End io function defined don't remap it */ +#define BH_Delay 8 /* disk mapping is delayed */ + /* * Try to keep the most commonly used fields in single cache lines (16 @@ -275,6 +277,7 @@ #define buffer_mapped(bh) __buffer_state(bh,Mapped) #define buffer_new(bh) __buffer_state(bh,New) #define buffer_protected(bh) __buffer_state(bh,Protected) +#define buffer_delay(bh) __buffer_state(bh,Delay) #define bh_offset(bh) ((unsigned long)(bh)->b_data & ~PAGE_MASK) @@ -379,6 +382,7 @@ int (*bmap)(struct address_space *, long); int (*toss_page)(struct page *); + int (*writepage_nounlock)(struct page *); }; @@ -481,8 +485,6 @@ void *generic_ip; } u; }; - -extern spinlock_t inode_lock; struct fown_struct { int pid; /* pid or -pgrp where SIGIO should be sent */ diff -Naur ../../xfs-orig/linux/include/linux/mm.h include/linux/mm.h --- ../../xfs-orig/linux/include/linux/mm.h Fri Feb 23 10:33:21 2001 +++ include/linux/mm.h Fri Feb 23 18:38:49 2001 @@ -167,7 +167,6 @@ #define PG_skip 10 #define PG_inactive_clean 11 #define PG_highmem 12 -#define PG_delalloc 13 /* bits 21-29 unused */ #define PG_arch_1 30 #define PG_reserved 31 @@ -182,7 +181,7 @@ #define PageLocked(page) test_bit(PG_locked, &(page)->flags) #define LockPage(page) set_bit(PG_locked, &(page)->flags) #define TryLockPage(page) test_and_set_bit(PG_locked, &(page)->flags) -#define DelallocPage(page) test_bit(PG_delalloc, &(page)->flags) +#define DelallocPage(page) (page->buffers && test_bit(BH_Delay, &(page)->buffers->b_state)) extern void __set_page_dirty(struct page *); diff -Naur ../../xfs-orig/linux/include/linux/page_buf.h include/linux/page_buf.h --- ../../xfs-orig/linux/include/linux/page_buf.h Fri Feb 23 10:34:56 2001 +++ include/linux/page_buf.h Fri Feb 23 18:40:25 2001 @@ -342,7 +342,7 @@ * Tunable pagebuf parameters */ -#define P_PARAM 6 +#define P_PARAM 4 typedef union pagebuf_param { struct { @@ -350,11 +350,7 @@ * delwri flush daemon. */ ulong age_buffer; /* time for buffer to age before * we flush it. */ - ulong cluster_interval; /* interval between runs of the - * page cleaner daemon. */ ulong max_cluster; /* maximum pages to cluster */ - ulong max_dirty_pages; /* maximum pages allowed to be - * dirty. */ ulong debug; /* debug tracing on or off */ } p_un; ulong data[P_PARAM]; @@ -364,10 +360,8 @@ { PB_FLUSH_INT = 1, PB_FLUSH_AGE = 2, - PB_CLEAN_INT = 3, - PB_CLUSTER_LIMIT = 4, - PB_DELALLOC_LIMIT = 5, - PB_DEBUG = 6 + PB_CLUSTER_LIMIT = 3, + PB_DEBUG = 4 }; extern pagebuf_param_t pb_params; @@ -626,8 +620,11 @@ struct file *, /* file to read */ struct page *); /* page to read */ -extern int pagebuf_write_full_page( /* write a page via pagebuf */ +extern int pagebuf_write_full_page_unlock(/* write a page via pagebuf */ struct page *); /* page to write */ + +extern int pagebuf_write_full_page_nounlock(/* write a page via pagebuf */ + struct page *); /* page to write */ extern void pagebuf_toss_page( /* convertion of a delalloc page */ struct page *); /* page to convert */ diff -Naur ../../xfs-orig/linux/kdb/modules/kdbm_pg.c kdb/modules/kdbm_pg.c --- ../../xfs-orig/linux/kdb/modules/kdbm_pg.c Thu Feb 22 14:36:37 2001 +++ kdb/modules/kdbm_pg.c Thu Feb 22 14:15:56 2001 @@ -28,7 +28,7 @@ static char *bh_state_vals[] = { "Uptodate", "Dirty", "Lock", "Req", "Mapped", "New", - "Protected", NULL }; + "Protected", "End_io", "Delay", NULL }; static char *map_flags(unsigned long flags, char *mapping[]) { @@ -88,9 +88,9 @@ kdb_printf(" next 0x%p bno %ld rsec %ld size %d dev 0x%x rdev 0x%x\n", bh.b_next, bh.b_blocknr, bh.b_rsector, bh.b_size, bh.b_dev, bh.b_rdev); - kdb_printf(" count %d state 0x%lx [%s] ftime 0x%lx\n", + kdb_printf(" count %d state 0x%lx [%s] ftime 0x%lx b_list %d b_reqnext 0x%p b_data 0x%p\n", bh.b_count.counter, bh.b_state, map_flags(bh.b_state, bh_state_vals), - bh.b_flushtime); + bh.b_flushtime, bh.b_list, bh.b_reqnext, bh.b_data); kdb_printf(" b_page 0x%p b_this_page 0x%p b_private 0x%p\n", bh.b_page, bh.b_this_page, bh.b_private); diff -Naur ../../xfs-orig/linux/kernel/ksyms.c kernel/ksyms.c --- ../../xfs-orig/linux/kernel/ksyms.c Fri Feb 23 10:29:09 2001 +++ kernel/ksyms.c Fri Feb 23 18:29:03 2001 @@ -277,7 +277,6 @@ EXPORT_SYMBOL(lock_may_write); EXPORT_SYMBOL(dcache_readdir); - /* for stackable file systems (lofs, wrapfs, cryptfs, etc.) */ EXPORT_SYMBOL(default_llseek); EXPORT_SYMBOL(dentry_open); @@ -285,8 +284,6 @@ EXPORT_SYMBOL(filemap_sync); EXPORT_SYMBOL(lock_page); -EXPORT_SYMBOL(inode_lock); - /* for page_buf cache */ EXPORT_SYMBOL(add_to_page_cache_unique); EXPORT_SYMBOL(bh_cachep); @@ -516,13 +513,6 @@ EXPORT_SYMBOL(file_fsync); EXPORT_SYMBOL(fsync_inode_buffers); EXPORT_SYMBOL(clear_inode); -EXPORT_SYMBOL(inactive_dirty_list); -EXPORT_SYMBOL(nr_active_pages); -EXPORT_SYMBOL(active_list); -EXPORT_SYMBOL(age_page_down_ageonly); -EXPORT_SYMBOL(deactivate_page_nolock); -EXPORT_SYMBOL(age_page_up_nolock); -EXPORT_SYMBOL(nr_inactive_dirty_pages); EXPORT_SYMBOL(nr_async_pages); EXPORT_SYMBOL(___strtok); EXPORT_SYMBOL(init_special_inode); @@ -581,6 +571,3 @@ EXPORT_SYMBOL(tasklist_lock); EXPORT_SYMBOL(pidhash); - -EXPORT_SYMBOL(pagemap_lru_lock); - diff -Naur ../../xfs-orig/linux/mm/page_alloc.c mm/page_alloc.c --- ../../xfs-orig/linux/mm/page_alloc.c Mon Feb 12 14:20:46 2001 +++ mm/page_alloc.c Thu Feb 22 13:17:31 2001 @@ -88,11 +88,6 @@ if (PageInactiveClean(page)) BUG(); - if (DelallocPage(page)) { - printk("Trying to free dirty page 0x%p\n", page); - BUG(); - } - page->flags &= ~((1<age = PAGE_AGE_START; diff -Naur ../../xfs-orig/linux/mm/swap.c mm/swap.c diff -Naur ../../xfs-orig/linux/mm/vmscan.c mm/vmscan.c --- ../../xfs-orig/linux/mm/vmscan.c Thu Feb 22 14:36:37 2001 +++ mm/vmscan.c Fri Feb 23 23:21:29 2001 @@ -51,11 +51,6 @@ if (TryLockPage(page)) return; - if (DelallocPage(page)) { - UnlockPage(page); - return; - } - /* From this point on, the odds are that we're going to * nuke this pte, so read and clear the pte. This hook * is needed on CPUs which update the accessed and dirty @@ -363,12 +358,6 @@ add_page_to_inactive_dirty_list(page); continue; } - if (DelallocPage(page)) { - del_page_from_inactive_clean_list(page); - add_page_to_inactive_dirty_list(page); - UnlockPage(page); - continue; - } /* OK, remove the page from the caches. */ if (PageSwapCache(page)) { @@ -479,10 +468,10 @@ } /* - * Dirty swap-cache page or delayed allocate page? - * Write it out if last copy.. + * Dirty swap-cache page? Write it out if + * last copy.. */ - if (PageDirty(page) || DelallocPage(page)) { + if (PageDirty(page)) { int (*writepage)(struct page *) = page->mapping->a_ops->writepage; if (!writepage) @@ -537,6 +526,9 @@ wait = 1; /* Async IO */ else wait = 0; /* No IO */ + + if (!can_queue_buffers) + wait = 0; /* Try to free the page buffers. */ clearedbuf = try_to_free_buffers(page, wait); --------------7DAFBB5921244692E64C7D6D-- From owner-linux-xfs@oss.sgi.com Sat Feb 24 15:37:09 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 15:37:00 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:43835 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 15:36:46 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA08553 for ; Sat, 24 Feb 2001 15:36:41 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02473; Sun, 25 Feb 2001 10:35:25 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA63452; Sun, 25 Feb 2001 10:35:23 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102251035.ZM156244@wobbly.melbourne.sgi.com> Date: Sun, 25 Feb 2001 10:35:21 -0400 In-Reply-To: james rich "Re: building 2.4.2 (with XFS) fails" (Feb 24, 3:15pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: james rich Subject: Re: building 2.4.2 (with XFS) fails Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Feb 24, 3:15pm, james rich wrote: > Subject: Re: building 2.4.2 (with XFS) fails > I built a stock kernel 2.4.2 with no problems so the failure below is > definately something related to the XFS patches. Unfortunately I don't > know the cause of the build failure. Is everyone here building on RH7? no - I'm not, but according to the survey it seems many folk trying out XFS (and answering the survey) are using one or other version of RedHat though. > I'm using Slackware 7.1. It seems that these patches would need to build according to the survey, there have been a few other people using Slackware (not sure which versions). > on most distros before reaching release level. Let me know if I can do > something (happy to test stuff). > > On Fri, 23 Feb 2001, james rich wrote: > > When building 2.4.2 with XFS patches the build fails with errors that > > don't seem related to XFS (that's why the crosspost): > > > > gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux/include -Wall > > -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe > > -march=i686 -c -o dec_and_lock.o dec_and_lock.c > > rm -f lib.a > > ar rcs lib.a checksum.o old-checksum.o delay.o usercopy.o getuser.o > > putuser.o iodebug.o memcpy.o dec_and_lock.o > > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib' > > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib' > > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' > > ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext > > arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o > > init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o > > kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/block/block.o > > drivers/char/char.o drivers/misc/misc.o drivers/net/net.o > > drivers/media/media.o drivers/parport/driver.o drivers/char/drm/drm.o > > drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o > > drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o > > drivers/i2c/i2c.o drivers/md/mddev.o net/network.o > > /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a > > /usr/src/linux/arch/i386/lib/lib.a --end-group -o vmlinux > > drivers/char/char.o: In function `vt_ioctl': > > drivers/char/char.o(.text+0x96fb): undefined reference to `key_maps' from my build area, it seems I'm picking up the `key_maps' symbol from drivers/char/defkeymap.o... $ nm drivers/char/defkeymap.o | grep key_maps 00000700 D key_maps drivers/char/defkeymap.c should exist and should have been generated by the last line of drivers/char/Makefile. do you have a drivers/char/defkeymap.c file? if so, do you have the drivers/char/defkeymap.o file? if so, does it contain the `key_maps' symbol? if so, my theory is in trouble. ;-) you should also see a line something like this in your make output (would be well before the error I think) ... ld -m elf_i386 -r -o char.o tty_io.o n_tty.o tty_ioctl.o \ ^^^^^^^^ mem.o raw.o pty.o misc.o random.o vt.o vc_screen.o consolemap.o\ consolemap_deftbl.o console.o selection.o serial.o keyboard.o \ defkeymap.o pc_keyb.o sysrq.o ^^^^^^^^^^^ ...that char.o is drivers/char/char.o which seems to not have `key_maps' in your case. > > > > Any ideas what is wrong? > > I have a vague recollection of this .c file being checked into the tree (accidentally) from day1, but it was removed quite some time ago ... perhaps you're using a workarea updated from a while ago & this is somehow permuting your build? (clutching at straws here). If you have a drivers/char/defkeymap.c file, you could try deleting it & allow a fresh build to regenerate it. since your non-XFS 2.4.2 build works, this should too (there are no XFS changes around this code that I'm aware of). hope this helps. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sat Feb 24 16:12:09 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 16:12:00 -0800 Received: from mail2.mia.bellsouth.net ([205.152.144.14]:3528 "EHLO mail2.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 16:11:39 -0800 Received: from bellsouth.net (adsl-61-4-190.mia.bellsouth.net [208.61.4.190]) by mail2.mia.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id TAA08450; Sat, 24 Feb 2001 19:11:34 -0500 (EST) Message-ID: <3A985345.B1FAB6E@bellsouth.net> Date: Sat, 24 Feb 2001 19:35:17 -0500 From: Juan Casero X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: james rich CC: linux-xfs@oss.sgi.com Subject: Re: building 2.4.2 (with XFS) fails References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The messages below seem to indicate there are some references in char.o to functions that have not been defined. These kinds of errors usually occur at the link stage of a compilation. Instead of patching a stock kernel use the instructions available at oss.sgi.com/projects/xfs to login to their CVS server and download the source code that way. After that you can make a sym link /usr/src/linux-2.4-xfs/linux <-- /usr/src/linux and then recompile the code. I am pretty sure you'll have no problems getting it to build. Good Luck..... james rich wrote: > I built a stock kernel 2.4.2 with no problems so the failure below is > definately something related to the XFS patches. Unfortunately I don't > know the cause of the build failure. Is everyone here building on RH7? > I'm using Slackware 7.1. It seems that these patches would need to build > on most distros before reaching release level. Let me know if I can do > something (happy to test stuff). > > On Fri, 23 Feb 2001, james rich wrote: > > When building 2.4.2 with XFS patches the build fails with errors that > > don't seem related to XFS (that's why the crosspost): > > > > gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux/include -Wall > > -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe > > -march=i686 -c -o dec_and_lock.o dec_and_lock.c > > rm -f lib.a > > ar rcs lib.a checksum.o old-checksum.o delay.o usercopy.o getuser.o > > putuser.o iodebug.o memcpy.o dec_and_lock.o > > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib' > > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib' > > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' > > ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext > > arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o > > init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o > > kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/block/block.o > > drivers/char/char.o drivers/misc/misc.o drivers/net/net.o > > drivers/media/media.o drivers/parport/driver.o drivers/char/drm/drm.o > > drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o > > drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o > > drivers/i2c/i2c.o drivers/md/mddev.o net/network.o > > /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a > > /usr/src/linux/arch/i386/lib/lib.a --end-group -o vmlinux > > drivers/char/char.o: In function `vt_ioctl': > > drivers/char/char.o(.text+0x96fb): undefined reference to `key_maps' > > drivers/char/char.o(.text+0x97cd): undefined reference to `key_maps' > > drivers/char/char.o(.text+0x97ed): undefined reference to `key_maps' > > drivers/char/char.o(.text+0x9808): undefined reference to `keymap_count' > > drivers/char/char.o(.text+0x9877): undefined reference to `key_maps' > > drivers/char/char.o(.text+0x9889): undefined reference to `keymap_count' > > drivers/char/char.o(.text+0x98df): undefined reference to `key_maps' > > drivers/char/char.o(.text+0x990a): undefined reference to `keymap_count' > > drivers/char/char.o(.text+0x9a2e): undefined reference to `func_table' > > drivers/char/char.o(.text+0x9ad7): undefined reference to `funcbufsize' > > drivers/char/char.o(.text+0x9ae5): undefined reference to `funcbufleft' > > drivers/char/char.o(.text+0x9afa): undefined reference to `funcbufptr' > > drivers/char/char.o(.text+0x9b09): undefined reference to `func_table' > > drivers/char/char.o(.text+0x9b22): undefined reference to `func_table' > > drivers/char/char.o(.text+0x9b46): undefined reference to `func_table' > > drivers/char/char.o(.text+0x9b57): undefined reference to `func_table' > > drivers/char/char.o(.text+0x9c0b): undefined reference to `func_table' > > drivers/char/char.o(.text+0x9c40): more undefined references to > > `func_table' follow > > drivers/char/char.o: In function `vt_ioctl': > > drivers/char/char.o(.text+0x9c4a): undefined reference to `funcbufleft' > > drivers/char/char.o(.text+0x9cc2): undefined reference to `func_table' > > drivers/char/char.o(.text+0x9cc8): undefined reference to `funcbufptr' > > drivers/char/char.o(.text+0x9d19): undefined reference to `funcbufptr' > > drivers/char/char.o(.text+0x9d25): undefined reference to `func_table' > > drivers/char/char.o(.text+0x9d69): undefined reference to `funcbufptr' > > drivers/char/char.o(.text+0x9dc0): undefined reference to `funcbufptr' > > drivers/char/char.o(.text+0x9dc9): undefined reference to `func_table' > > drivers/char/char.o(.text+0x9dfb): undefined reference to `funcbufptr' > > drivers/char/char.o(.text+0x9e01): undefined reference to `func_buf' > > drivers/char/char.o(.text+0x9e15): undefined reference to `funcbufptr' > > drivers/char/char.o(.text+0x9e1b): undefined reference to `funcbufleft' > > drivers/char/char.o(.text+0x9e29): undefined reference to `funcbufsize' > > drivers/char/char.o(.text+0x9e2f): undefined reference to `funcbufleft' > > drivers/char/char.o(.text+0x9e39): undefined reference to `funcbufsize' > > drivers/char/char.o(.text+0x9e43): undefined reference to `func_table' > > drivers/char/char.o(.text+0x9e76): undefined reference to > > `accent_table_size' > > drivers/char/char.o(.text+0x9e89): undefined reference to > > `accent_table_size' > > drivers/char/char.o(.text+0x9e92): undefined reference to `accent_table' > > drivers/char/char.o(.text+0x9edd): undefined reference to > > `accent_table_size' > > drivers/char/char.o(.text+0x9eea): undefined reference to `accent_table' > > drivers/char/char.o: In function `handle_scancode': > > drivers/char/char.o(.text+0x164c1): undefined reference to `key_maps' > > drivers/char/char.o(.text+0x1651a): undefined reference to `key_maps' > > drivers/char/char.o: In function `handle_diacr': > > drivers/char/char.o(.text+0x16c28): undefined reference to > > `accent_table_size' > > drivers/char/char.o(.text+0x16c49): undefined reference to `accent_table' > > drivers/char/char.o(.text+0x16c5b): undefined reference to `accent_table' > > drivers/char/char.o(.text+0x16ca7): undefined reference to `accent_table' > > drivers/char/char.o: In function `do_fn': > > drivers/char/char.o(.text+0x16d1f): undefined reference to `func_table' > > drivers/char/char.o: In function `compute_shiftstate': > > drivers/char/char.o(.text+0x16f99): undefined reference to `plain_map' > > drivers/char/char.o: In function `do_slock': > > drivers/char/char.o(.text+0x170ef): undefined reference to `key_maps' > > make[1]: *** [kallsyms] Error 1 > > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux' > > make: *** [vmlinux] Error 2 > > > > > > Any ideas what is wrong? > > > > James Rich > > james.rich@m.cc.utah.edu > > > > > > From owner-linux-xfs@oss.sgi.com Sat Feb 24 17:13:39 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 17:13:29 -0800 Received: from esparrall.udg.es ([130.206.124.16]:40320 "EHLO esparrall.udg.es") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 17:13:15 -0800 Received: from gcs by esparrall.udg.es with local (Exim 3.22 #1 (Debian)) id 14Wpk5-0000PD-00 for ; Sun, 25 Feb 2001 02:12:53 +0100 Date: Sun, 25 Feb 2001 02:12:53 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: XFS and Kernel 2.4.2 Message-ID: <20010225021253.A1518@esparrall.udg.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello all, Anyone could make XFS with the newest kernel (2.4.2)? I tried, but the module support is broken. All of the modules give me unresolved symbols (even very basic ones like printk()). Ok, I said compile everything into the kernel, and so I did. I have support for XFS, but I can not use it. When I create the filesystem on /dev/fd0 I get: mkfs.xfs: warning - cannot set blocksize on block device /dev/fd0: Invalid argument meta-data=/dev/fd0 isize=256 agcount=1, agsize=4096 blks data = bsize=4096 blocks=360, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 mkfs.xfs: device_zero write failed: Invalid argument The last line should be a crash, as I can not mount the floppy, the good old message (mount: wrong fs type, ...) shows up. Check with xfs_repair: xfs_repair: warning - cannot set blocksize on block device /dev/fd0: Invalid argument Phase 1 - find and verify superblock... bad primary superblock - filesystem mkfs-in-progress bit set !!! attempting to find secondary superblock... .Sorry, could not find valid secondary superblock Exiting now. So mkfs crash in the middle of the creation. Any workaround maybe? Thanks, Laszlo From owner-linux-xfs@oss.sgi.com Sat Feb 24 18:20:02 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 18:19:52 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41836 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 18:19:35 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA01207 for ; Sat, 24 Feb 2001 18:29:02 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA03030; Sun, 25 Feb 2001 13:18:12 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA63582; Sun, 25 Feb 2001 13:18:11 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102251318.ZM160565@wobbly.melbourne.sgi.com> Date: Sun, 25 Feb 2001 13:18:10 -0400 In-Reply-To: Mike Bernson "Re: building 2.4.2 (with XFS) fails" (Feb 24, 8:53pm) References: <10102251035.ZM156244@wobbly.melbourne.sgi.com> <3A98658A.882949E9@mlb.org> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: mike@mlb.org, kaos@melbourne.sgi.com Subject: Re: building 2.4.2 (with XFS) fails Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Feb 24, 8:53pm, Mike Bernson wrote: > Subject: Re: building 2.4.2 (with XFS) fails > > ... > > If you have a drivers/char/defkeymap.c file, you could try > > deleting it & allow a fresh build to regenerate it. since > > your non-XFS 2.4.2 build works, this should too (there are > > no XFS changes around this code that I'm aware of). > > > > hope this helps. > > > > I have been working for the cvs source. The defkeymap.c is > empty and loadkey command is now where to be found. >-- End of excerpt from Mike Bernson yup, an empty defkeymap.c would cause this same problem I think. you'll need the console-tools package installed which contains loadkeys and /bin will probably need to be in your $PATH. The empty file is probably created by the shell redirect in.. [drivers/char/Makefile, line 202] defkeymap.c: defkeymap.map loadkeys --mktable defkeymap.map | sed -e 's/^static *//' > defkeymap.c (thats broken - the exit status is that of the last command in the pipeline (sed) which succeeds, so make will charge right on not noticing the error - right Keith?) thanks Mike. -- Nathan From owner-linux-xfs@oss.sgi.com Sat Feb 24 18:37:04 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 18:36:54 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:53081 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 18:36:36 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA07987 for ; Sat, 24 Feb 2001 18:35:48 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA03113; Sun, 25 Feb 2001 13:34:19 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA63623; Sun, 25 Feb 2001 13:34:17 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102251334.ZM164151@wobbly.melbourne.sgi.com> Date: Sun, 25 Feb 2001 13:34:16 -0400 In-Reply-To: GCS "XFS and Kernel 2.4.2" (Feb 25, 2:12am) References: <20010225021253.A1518@esparrall.udg.es> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: GCS , linux-xfs@oss.sgi.com Subject: Re: XFS and Kernel 2.4.2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Feb 25, 2:12am, GCS wrote: > Subject: XFS and Kernel 2.4.2 > Hello all, > > Anyone could make XFS with the newest kernel (2.4.2)? I tried, but the module > support is broken. All of the modules give me unresolved symbols (even very > basic ones like printk()). Ok, I said compile everything into the kernel, and > so I did. I have support for XFS, but I can not use it. When I create the not sure about the module problem - I'm using xfs compiled-in at the moment. I'm pretty sure Russell fixed module support the other day though. > filesystem on /dev/fd0 I get: > ... > So mkfs crash in the middle of the creation. Any workaround maybe? quick workaround would be to not use a floppy disk. I don't think its possible to create an xfs filesystem on so small a device. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sat Feb 24 18:49:05 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 18:48:54 -0800 Received: from ubr-95.237.251.indiatlantic.cfl.rr.com ([24.95.237.251]:26863 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 18:48:43 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id VAA00613; Sat, 24 Feb 2001 21:43:14 -0500 Message-ID: <3A987466.4763CEEE@ieee.org> Date: Sat, 24 Feb 2001 21:56:38 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Besides the patched kernel and commands, what else is needed? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Besides the patched kernel and commands, what else is needed? I'm playing with the 2.4.2 kernel (both patched with the Feb 23 patch, and the whole kernel from CVS), as well as the commands (from CVS). What I'm concerned about is the fact that the Pre-Release RPMs on OSS also include modified a "modutils" and "mkinitrd" as well (I looked inside the SRPMS and saw XFS patches). If I'm using updated RedHat 7.0 (or 7.0.90/91 betas) as a base, do I need to modify those RPMs as well? Or have these two packages been "cleaned-up" in the normal RedHat patches for 7.0? Thanx ... -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Sat Feb 24 23:17:36 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 23:17:27 -0800 Received: from mail1.mia.bellsouth.net ([205.152.144.13]:46793 "EHLO mail1.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 23:17:02 -0800 Received: from bellsouth.net (adsl-61-4-190.mia.bellsouth.net [208.61.4.190]) by mail1.mia.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id CAA12264 for ; Sun, 25 Feb 2001 02:17:01 -0500 (EST) Message-ID: <3A98B6FE.1E056F6B@bellsouth.net> Date: Sun, 25 Feb 2001 02:40:47 -0500 From: Juan Casero X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: libxfs.h and the xfsprogs-devel package? References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have gotten the 2.4.2-xfs kernel installed and working well but I have one question. Under the /usr/src/linux-2.4-xfs/cmd tree are a number source dir's for commands to support and maintain XFS file systems. I have been trying compile and install the code in there but I get some errors. The following is a sample: [root@cedar cmd]# cd xfsdump [root@cedar xfsdump]# make rm -f config.cache autoconf ./configure creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for make... /usr/bin/make checking for ld... /usr/bin/ld checking for tar... /bin/tar checking for gzip... /usr/bin/gzip checking for rpm... /bin/rpm checking for makedepend... /usr/X11R6/bin/makedepend checking whether ln -s works... yes checking for awk... /usr/bin/awk checking for sed... /bin/sed checking for echo... /bin/echo checking how to run the C preprocessor... gcc -E checking for uuid/uuid.h... yes checking for uuid_generate in -luuid... yes checking for xfs/libxfs.h... no FATAL ERROR: could not find a valid XFS library header. Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) package. make: *** [include/builddefs] Error 1 I was able to compile and install the code under /usr/src/linux-2.4-xfs/cmd/xfsprogs but aparently the libxfs.h header file was not put in place. Because of this problem several other compile attempts for other utilities that came with the kernel source fail also. The error mentions installing xfsprogs-devel but I don't see that package anywhere. I would have thought also that doing a 'make install' in the xfsprogs-devel tree would have installed all the needed libs and header files also. Anyone know what gives? Thanks, Juan Casero casero@bellsouth.net From owner-linux-xfs@oss.sgi.com Sat Feb 24 23:38:36 2001 Received: by oss.sgi.com id ; Sat, 24 Feb 2001 23:38:27 -0800 Received: from pipt.oz.cc.utah.edu ([155.99.2.7]:9459 "EHLO pipt.oz.cc.utah.edu") by oss.sgi.com with ESMTP id ; Sat, 24 Feb 2001 23:38:07 -0800 Received: from localhost (jdr1529@localhost) by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id AAA28585 for ; Sun, 25 Feb 2001 00:37:53 -0700 (MST) Date: Sun, 25 Feb 2001 00:37:52 -0700 (MST) From: james rich To: linux-xfs@oss.sgi.com Subject: Re: building 2.4.2 (with XFS) fails In-Reply-To: <3A985345.B1FAB6E@bellsouth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sat, 24 Feb 2001, Juan Casero wrote: > The messages below seem to indicate there are some references in char.o to > functions that have not been defined. These kinds of errors usually occur at > the link stage of a compilation. Instead of patching a stock kernel use the > > instructions available at oss.sgi.com/projects/xfs to login to their CVS > server > and download the source code that way. After that you can make a sym link > /usr/src/linux-2.4-xfs/linux <-- /usr/src/linux and then recompile the code. > I am pretty sure you'll have no problems getting it to build. This occurred after pulling the CVS tree last night and tried it again this morning. I'l' try deleting my entire tree and do the CVS pull again (takes a *long* time over my modem :( ). James Rich james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Sun Feb 25 00:24:07 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 00:23:57 -0800 Received: from hermes.mixx.net ([212.84.196.2]:57350 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 25 Feb 2001 00:23:35 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id A49D4F833 for ; Sun, 25 Feb 2001 09:23:28 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 4AF9A2CA6F; Sun, 25 Feb 2001 09:23:28 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: libxfs.h and the xfsprogs-devel package? Date: 25 Feb 2001 08:23:28 GMT Organization: innominate AG, Berlin, Germany Lines: 68 Distribution: local Message-ID: References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> <3A98B6FE.1E056F6B@bellsouth.net> X-Trace: mate.bln.innominate.de 983089408 5202 10.0.0.31 (25 Feb 2001 08:23:28 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing did you really install the xfsprogs-devel rpm too? - for me it works: [root@orange /root]# rpm -qf /usr/include/xfs/libxfs.h xfsprogs-devel-1.1.1-0 [root@orange /root]# t Juan Casero wrote: > I have gotten the 2.4.2-xfs kernel installed and working well but I have one > question. Under the /usr/src/linux-2.4-xfs/cmd tree are > a number source dir's for commands to support and maintain XFS file systems. > I have been trying compile and install the code in > there but I get some errors. The following is a sample: > [root@cedar cmd]# cd xfsdump > [root@cedar xfsdump]# make > rm -f config.cache > autoconf > ./configure > creating cache ./config.cache > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > checking whether the C compiler (gcc ) is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > checking for make... /usr/bin/make > checking for ld... /usr/bin/ld > checking for tar... /bin/tar > checking for gzip... /usr/bin/gzip > checking for rpm... /bin/rpm > checking for makedepend... /usr/X11R6/bin/makedepend > checking whether ln -s works... yes > checking for awk... /usr/bin/awk > checking for sed... /bin/sed > checking for echo... /bin/echo > checking how to run the C preprocessor... gcc -E > checking for uuid/uuid.h... yes > checking for uuid_generate in -luuid... yes > checking for xfs/libxfs.h... no > FATAL ERROR: could not find a valid XFS library header. > Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) package. > make: *** [include/builddefs] Error 1 > I was able to compile and install the code under > /usr/src/linux-2.4-xfs/cmd/xfsprogs but aparently the libxfs.h header file > was not put in place. Because of this problem several other compile attempts > for other utilities that came with the kernel > source fail also. The error mentions installing xfsprogs-devel but I don't > see that package anywhere. I would have thought > also that doing a 'make install' in the xfsprogs-devel tree would have > installed all the needed libs and header files also. > Anyone know what gives? > Thanks, > Juan Casero > casero@bellsouth.net -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 00:31:27 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 00:31:08 -0800 Received: from hermes.mixx.net ([212.84.196.2]:1287 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 25 Feb 2001 00:30:55 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id B558EF833 for ; Sun, 25 Feb 2001 09:30:52 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 68F672CA6F; Sun, 25 Feb 2001 09:30:52 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: Besides the patched kernel and commands, what else is needed? Date: 25 Feb 2001 08:30:52 GMT Organization: innominate AG, Berlin, Germany Lines: 29 Distribution: local Message-ID: References: <3A987466.4763CEEE@ieee.org> X-Trace: mate.bln.innominate.de 983089852 5202 10.0.0.31 (25 Feb 2001 08:30:52 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Bryan J. Smith" wrote: > Besides the patched kernel and commands, what else is needed? > I'm playing with the 2.4.2 kernel (both patched with the Feb 23 > patch, and the whole kernel from CVS), as well as the commands (from > CVS). basically nothing else is needed > What I'm concerned about is the fact that the Pre-Release RPMs on > OSS also include modified a "modutils" and "mkinitrd" as well (I > looked inside the SRPMS and saw XFS patches). If I'm using updated > RedHat 7.0 (or 7.0.90/91 betas) as a base, do I need to modify those > RPMs as well? Or have these two packages been "cleaned-up" in the > normal RedHat patches for 7.0? it's always a good idea to have somewhat fresh modutils for the 2.4.x kernel (you may get src.rpm's from ftp.kernel.org for instance) and if you need mkinitrd you may rebuild it with the trivial XFS patch but i think this is only required if you build your xfs support in as a module t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 03:04:48 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 03:04:28 -0800 Received: from moe.rice.edu ([128.42.5.4]:31391 "EHLO moe.rice.edu") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 03:04:09 -0800 Received: from photino.sid.rice.edu (photino.sid.rice.edu [128.42.162.116]) by moe.rice.edu (8.9.0/8.9.0) with ESMTP id FAA10955 for ; Sun, 25 Feb 2001 05:04:08 -0600 (CST) Received: (from rjain@localhost) by photino.sid.rice.edu (8.11.2/8.11.2/Debian 8.11.2-1) id f1PB48F00443 for linux-xfs@oss.sgi.com; Sun, 25 Feb 2001 05:04:08 -0600 Date: Sun, 25 Feb 2001 05:04:07 -0600 From: Rahul Jain To: linux-xfs@oss.sgi.com Subject: xfs hang Message-ID: <20010225050407.A393@photino.sid.rice.edu> Reply-To: Rahul Jain Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The following is a backtrace I got from kdb's "bt" function during a hang generated by "apt-get update". It's not a character-for-character reproduction, since I had to write down the trace by hand, and didn't want to write down the entire thing. It does contain all the stack frames, however. === do_buffer_fdatasync+0xa3 (0xc50ea714, 0, -1, 0xc01242dc) generic_buffer_fdatasync+0x5b (0xc50ea660, 0, -1) pagebuf_flush+0x79 (0xc50ea660, 0, 0, 0) fl_flush_pages+0x70 (0xc4fe4078, 0, 0, -1, -1) xfs_fsync+0x19c (0xc4fe4078, 5, 0, 0, 0) linvfs_fsync+0x69 (0xc96c1f20, 0xc95bc8a0, 1) msync_interval+0x76 (0xe941de0, 0x40258000, 0x40484000, 4, 0xc7db0000) sys_msync+0xa8 (0x40258000, 0x22b337, 4, 0xbffff47c, 0xbffff4e8) system_call+0x33 === I'm using version 2.4.1 from cvs (I had just completed cvs updating the xfs tree before this happened.) -- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request. From owner-linux-xfs@oss.sgi.com Sun Feb 25 05:17:39 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 05:17:30 -0800 Received: from ubr-95.237.251.indiatlantic.cfl.rr.com ([24.95.237.251]:27378 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 05:17:11 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id IAA17808; Sun, 25 Feb 2001 08:11:36 -0500 Message-ID: <3A9907AC.2ECF6D15@ieee.org> Date: Sun, 25 Feb 2001 08:25:00 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: Besides the patched kernel and commands, what else is needed? References: <3A987466.4763CEEE@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > basically nothing else is needed I'm kinda wondering what all is patched in the linux kernel tree under CVS? I know both RedHat's 2.4.0/1 kernels come with a lot of various patches to the stock kernel tree, and the SGI PR 0.9 2.4.0 did as well. Have these been integrated into the CVS kernel (among other patches?). [ I'm assuming so, along with other post-2.4.2 patches that didn't make it in. ] I just built a set of RPMs based on the contents of CVS last night. I created a custom spec file (based on various ones from RedHat as well as PR 0.9 -- and added an Athlon binary RPM set too). If anyone is interested, E-mail me. [ I'm still testing though -- I'm no RPM expert ;-PPP ] > it's always a good idea to have somewhat fresh modutils for the 2.4.x > kernel (you may get src.rpm's from ftp.kernel.org for instance) and > if you need mkinitrd you may rebuild it with the trivial XFS patch > but i think this is only required if you build your xfs support in > as a module Well, my RPM .config files are based on the PR 0.9 release RPMs (with IDE compiled-in, instead of a module, and SysReq/ksymoops removed). So it's a module (I assume no one will use XFS on their / or /boot partitions at this point). So, I can just rebuild mkinitrd-2.8-1XFS.src.rpm from PR 0.9? Or have there been patches that are newer? FYI, I know RedHat 7.0.91 comes with mkinitrd-3.0.6 (but I assume that is not patched). Again, will just the rebuild mkinitrd-2.8-1XFS from source do? Thanx again ... -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 05:45:00 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 05:44:50 -0800 Received: from ubr-95.237.251.indiatlantic.cfl.rr.com ([24.95.237.251]:37618 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 05:44:28 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id IAA18205; Sun, 25 Feb 2001 08:38:26 -0500 Message-ID: <3A990DF5.18FF893C@ieee.org> Date: Sun, 25 Feb 2001 08:51:49 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: thebs@theseus.com CC: Thomas Graichen , linux-xfs@oss.sgi.com Subject: Re: Besides the patched kernel and commands, what else is needed? References: <3A987466.4763CEEE@ieee.org> <3A9907AC.2ECF6D15@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Bryan J. Smith" wrote: > Well, my RPM .config files are based on the PR 0.9 release RPMs > (with IDE compiled-in, instead of a module, and SysReq/ksymoops > removed). So it's a module (I assume no one will use XFS on their / > or /boot partitions at this point). > > So, I can just rebuild mkinitrd-2.8-1XFS.src.rpm from PR 0.9? Or > have there been patches that are newer? FYI, I know RedHat 7.0.91 > comes with mkinitrd-3.0.6 (but I assume that is not patched). > Again, will just the rebuild mkinitrd-2.8-1XFS from source do? Another thing, my ultimate goal is to use the existing PR 0.9 Ananaconda installer mod to install this new kernel as part of a modified RedHat 7.0 distro. As such, it would be nice to have a spec file that can build the "cmd" tree into a single RPM like "xfs-cmds-1.0.5.*.rpm", instead of the separate acl-, attr-, dmapi-, xfsdump-, xfsprogs-*.rpm(s). I guess I could adapt/piece-together the xfs-cmds-1.0.5 spec and makefiles file and the various directories, or does someone see an easier way? [ Maybe I'm looking at this wrong? ] -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 06:07:59 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 06:07:40 -0800 Received: from hermes.mixx.net ([212.84.196.2]:28173 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 25 Feb 2001 06:07:10 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 43770F829 for ; Sun, 25 Feb 2001 15:07:08 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id EC5782CA6F; Sun, 25 Feb 2001 15:07:07 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: Besides the patched kernel and commands, what else is needed? Date: 25 Feb 2001 14:07:07 GMT Organization: innominate AG, Berlin, Germany Lines: 35 Distribution: local Message-ID: References: <3A987466.4763CEEE@ieee.org> <3A9907AC.2ECF6D15@ieee.org> X-Trace: mate.bln.innominate.de 983110027 1047 10.0.0.31 (25 Feb 2001 14:07:07 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Bryan J. Smith" wrote: > Thomas Graichen wrote: > I'm kinda wondering what all is patched in the linux kernel tree > under CVS? I know both RedHat's 2.4.0/1 kernels come with a lot of > various patches to the stock kernel tree, and the SGI PR 0.9 2.4.0 > did as well. Have these been integrated into the CVS kernel (among > other patches?). [ I'm assuming so, along with other post-2.4.2 > patches that didn't make it in. ] i never used anything else than the CVS tree so i'll leave this for someone else >> it's always a good idea to have somewhat fresh modutils for the 2.4.x >> kernel (you may get src.rpm's from ftp.kernel.org for instance) and >> if you need mkinitrd you may rebuild it with the trivial XFS patch >> but i think this is only required if you build your xfs support in >> as a module > Well, my RPM .config files are based on the PR 0.9 release RPMs > (with IDE compiled-in, instead of a module, and SysReq/ksymoops > removed). So it's a module (I assume no one will use XFS on their / > or /boot partitions at this point). i run my machines at home and at work with all xfs (except /boot - but this is at least possible too) for over half a year now with- out any problems ... just as a postive point here :-) t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 06:18:00 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 06:17:40 -0800 Received: from ubr-95.237.251.indiatlantic.cfl.rr.com ([24.95.237.251]:45298 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 06:17:23 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id JAA18708; Sun, 25 Feb 2001 09:11:51 -0500 Message-ID: <3A9915CA.BD4E266@ieee.org> Date: Sun, 25 Feb 2001 09:25:14 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: Besides the patched kernel and commands, what else is needed? References: <3A987466.4763CEEE@ieee.org> <3A9907AC.2ECF6D15@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > i run my machines at home and at work with all xfs (except /boot - > but this is at least possible too) for over half a year now with- > out any problems ... just as a postive point here :-) If I use mkinitrd to put the XFS module inside and initrd, then I only need /boot to not be XFS, correct? Or since XFS works with LILO, it can be XFS as well??? -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 09:31:31 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 09:31:21 -0800 Received: from mail3.mia.bellsouth.net ([205.152.144.15]:42989 "EHLO mail3.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 09:31:13 -0800 Received: from bellsouth.net (adsl-61-4-190.mia.bellsouth.net [208.61.4.190]) by mail3.mia.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id MAA06818; Sun, 25 Feb 2001 12:29:48 -0500 (EST) Message-ID: <3A99469F.90F883F7@bellsouth.net> Date: Sun, 25 Feb 2001 12:53:35 -0500 From: Juan Casero X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: james rich CC: linux-xfs@oss.sgi.com Subject: Re: building 2.4.2 (with XFS) fails References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing It's hard to understand why you are having this problem. I have not seen anything like it although I will say that there were a couple of occassions a few days ago when a compile of the previous kernel source from the SGI CVS server did fail on my box. I don't recall if the error was like yours though. On a much happier note I will say that I was able to compile the code for the 2.4.2 kernel source that I downloaded from their CVS server. One thing you might be failing to do is update your cvs tree. Make sure you issue the following commands to get the source tree $ cvs -z3 checkout linux-2.4-xfs $ cvs -z3 update -d It is important that you not forget the second of the two commands above. I myself am relatively new to using CVS so I can't explain why but I am almost certain that the update is absolutely important for getting the latest source code. Good Luck.... Juan Casero casero@bellsouth.net james rich wrote: > On Sat, 24 Feb 2001, Juan Casero wrote: > > > The messages below seem to indicate there are some references in char.o to > > functions that have not been defined. These kinds of errors usually occur at > > the link stage of a compilation. Instead of patching a stock kernel use the > > > > instructions available at oss.sgi.com/projects/xfs to login to their CVS > > server > > and download the source code that way. After that you can make a sym link > > /usr/src/linux-2.4-xfs/linux <-- /usr/src/linux and then recompile the code. > > I am pretty sure you'll have no problems getting it to build. > > This occurred after pulling the CVS tree last night and tried it again > this morning. I'l' try deleting my entire tree and do the CVS pull again > (takes a *long* time over my modem :( ). > > James Rich > james.rich@m.cc.utah.edu From owner-linux-xfs@oss.sgi.com Sun Feb 25 09:37:11 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 09:37:01 -0800 Received: from hermes.mixx.net ([212.84.196.2]:43025 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 25 Feb 2001 09:36:54 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 79F5BF833 for ; Sun, 25 Feb 2001 18:36:52 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 2DA3F2CA6F; Sun, 25 Feb 2001 18:36:52 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: Besides the patched kernel and commands, what else is needed? Date: 25 Feb 2001 17:36:52 GMT Organization: innominate AG, Berlin, Germany Lines: 31 Distribution: local Message-ID: References: <3A987466.4763CEEE@ieee.org> <3A9907AC.2ECF6D15@ieee.org> <3A9915CA.BD4E266@ieee.org> X-Trace: mate.bln.innominate.de 983122612 17020 10.0.0.31 (25 Feb 2001 17:36:52 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Bryan J. Smith" wrote: > Thomas Graichen wrote: >> i run my machines at home and at work with all xfs (except /boot - >> but this is at least possible too) for over half a year now with- >> out any problems ... just as a postive point here :-) > > If I use mkinitrd to put the XFS module inside and initrd, then I > only need /boot to not be XFS, correct? Or since XFS works with > LILO, it can be XFS as well??? > yes and yes ... you may also compile it statically into the kernel (which i think is the most simple solution) ... as said - i usually use a small (64M) ext2 /boot because it is simple and does not hurt (you may even mount it ro to avoid the fsck :-) ... you may also have a look at my little stand-alone environment which might migration or "daily care" of such an close to xfs only system a bit simpler http://innominate.org/~graichen/projects/miniroot/ hope that helps t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 09:39:41 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 09:39:32 -0800 Received: from mail5.mia.bellsouth.net ([205.152.144.17]:24009 "EHLO mail5.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 09:39:22 -0800 Received: from bellsouth.net (adsl-61-4-190.mia.bellsouth.net [208.61.4.190]) by mail5.mia.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id MAA19378; Sun, 25 Feb 2001 12:45:20 -0500 (EST) Message-ID: <3A9948DB.993500E2@bellsouth.net> Date: Sun, 25 Feb 2001 13:03:07 -0500 From: Juan Casero X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: libxfs.h and the xfsprogs-devel package? References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> <3A98B6FE.1E056F6B@bellsouth.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Forgive me if the answer seems obvious but where did you get the xfsprogs-devel rpm? I have been looking for this thing and I can't find it. Even so, should a 'make install' from tje xfsprogs source tree have taken care of any header files and library installations? Thanks, Juan Casero casero@bellsouth.net Thomas Graichen wrote: > did you really install the xfsprogs-devel rpm too? - for me it works: > > [root@orange /root]# rpm -qf /usr/include/xfs/libxfs.h > xfsprogs-devel-1.1.1-0 > [root@orange /root]# > > t > > Juan Casero wrote: > > I have gotten the 2.4.2-xfs kernel installed and working well but I have one > > question. Under the /usr/src/linux-2.4-xfs/cmd tree are > > a number source dir's for commands to support and maintain XFS file systems. > > I have been trying compile and install the code in > > there but I get some errors. The following is a sample: > > > [root@cedar cmd]# cd xfsdump > > [root@cedar xfsdump]# make > > rm -f config.cache > > autoconf > > ./configure > > creating cache ./config.cache > > checking for gcc... gcc > > checking whether the C compiler (gcc ) works... yes > > checking whether the C compiler (gcc ) is a cross-compiler... no > > checking whether we are using GNU C... yes > > checking whether gcc accepts -g... yes > > checking for make... /usr/bin/make > > checking for ld... /usr/bin/ld > > checking for tar... /bin/tar > > checking for gzip... /usr/bin/gzip > > checking for rpm... /bin/rpm > > checking for makedepend... /usr/X11R6/bin/makedepend > > checking whether ln -s works... yes > > checking for awk... /usr/bin/awk > > checking for sed... /bin/sed > > checking for echo... /bin/echo > > checking how to run the C preprocessor... gcc -E > > checking for uuid/uuid.h... yes > > checking for uuid_generate in -luuid... yes > > checking for xfs/libxfs.h... no > > > FATAL ERROR: could not find a valid XFS library header. > > Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) package. > > make: *** [include/builddefs] Error 1 > > > I was able to compile and install the code under > > /usr/src/linux-2.4-xfs/cmd/xfsprogs but aparently the libxfs.h header file > > was not put in place. Because of this problem several other compile attempts > > for other utilities that came with the kernel > > source fail also. The error mentions installing xfsprogs-devel but I don't > > see that package anywhere. I would have thought > > also that doing a 'make install' in the xfsprogs-devel tree would have > > installed all the needed libs and header files also. > > Anyone know what gives? > > > Thanks, > > Juan Casero > > casero@bellsouth.net > > -- > thomas.graichen@innominate.com > innominate AG > the linux architects > tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 09:44:51 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 09:44:42 -0800 Received: from ubr-95.237.251.indiatlantic.cfl.rr.com ([24.95.237.251]:22773 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 09:44:31 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id MAA22196; Sun, 25 Feb 2001 12:38:59 -0500 Message-ID: <3A994657.309323E5@ieee.org> Date: Sun, 25 Feb 2001 12:52:23 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: Besides the patched kernel and commands, what else is needed? References: <3A987466.4763CEEE@ieee.org> <3A9907AC.2ECF6D15@ieee.org> <3A9915CA.BD4E266@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > yes and yes ... you may also compile it statically > into the kernel (which i think is the most simple > solution) ... as said - i usually use a small (64M) > ext2 /boot because it is simple and does not hurt > (you may even mount it ro to avoid the fsck :-) Yeah, I usually make a /boot anymore. And I _always_ separate out /tmp, /var and /usr (plus data like /home). > ... you may also have a look at my little stand-alone > environment which might migration or "daily care" of such > an close to xfs only system a bit simpler > http://innominate.org/~graichen/projects/miniroot/ Thanx dude! I'll probably put it to good use soon when I convert my RedHat 7.0 systems from kernel 2.2+Ext3 to 2.4+XFS. [ Speaking of memory, the FAQ might want to address this ... ] What should be the _minimum_ amount of memory for a 2.4.x kernel with XFS? I was going to try a "minimalistic" system of a PPro 180MHz with only 48MB of RAM. Anyone want to warn me against trying? ;-PPP -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 09:45:50 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 09:45:40 -0800 Received: from hermes.mixx.net ([212.84.196.2]:57361 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 25 Feb 2001 09:45:23 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 4E381F83B for ; Sun, 25 Feb 2001 18:45:21 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 318CF2CA71; Sun, 25 Feb 2001 18:45:21 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: libxfs.h and the xfsprogs-devel package? Date: 25 Feb 2001 17:45:21 GMT Organization: innominate AG, Berlin, Germany Lines: 19 Distribution: local Message-ID: References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> <3A98B6FE.1E056F6B@bellsouth.net> <3A9948DB.993500E2@bellsouth.net> X-Trace: mate.bln.innominate.de 983123121 25318 10.0.0.31 (25 Feb 2001 17:45:21 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Juan Casero wrote: > Forgive me if the answer seems obvious but where did you get the xfsprogs-devel > rpm? I have been > looking for this thing and I can't find it. Even so, should a 'make install' from > tje xfsprogs source tree > have taken care of any header files and library installations? i am always using the cvs tree (or better my checked out copy of it :-) ... the xfsprogs-devel rpm you get by going into the cmd/xfsprogs dir and running "Makepgks verbose" (the same for the other rpms and dirs) t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 10:13:10 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 10:13:01 -0800 Received: from ubr-95.237.251.indiatlantic.cfl.rr.com ([24.95.237.251]:27125 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 10:12:47 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id NAA22619; Sun, 25 Feb 2001 13:07:11 -0500 Message-ID: <3A994CF2.6FB00D8F@ieee.org> Date: Sun, 25 Feb 2001 13:20:34 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: libxfs.h and the xfsprogs-devel package? <- Er, clarification ... References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> <3A98B6FE.1E056F6B@bellsouth.net> <3A9948DB.993500E2@bellsouth.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Re: libxfs.h and the xfsprogs-devel package? <- Er, clarification ... Thomas Graichen wrote: > i am always using the cvs tree (or better my checked out copy of it > :-) ... the xfsprogs-devel rpm you get by going into the cmd/xfsprogs > dir and running "Makepgks verbose" (the same for the other rpms and > dirs) No, I'm familiar with that. I already built: acl-1.0.1-0.i386.rpm acl-devel-1.0.1-0.i386.rpm attr-1.0.1-0.i386.rpm attr-devel-1.0.1-0.i386.rpm dmapi-0.1.1-0.i386.rpm dmapi-devel-0.1.1-0.i386.rpm xfsdump-1.0.2-0.i386.rpm xfsprogs-1.1.2-0.i386.rpm xfsprogs-devel-1.1.2-0.i386.rpm What I was talking about was building _unified_ RPM akin to "xfs-cmds-1.0.5-1.i386.rpm" like in Pre-Release 0.9. That way I don't have to modify Anaconda to know that all those RPMs replace that one. As such, I just suggested putting a .spec file in the "cmd" CVS root so you can. I tried merging spec/makefiles in an attempt to create a new "xfs-cmds-*.i386.rpm" to no avail. -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 12:27:21 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 12:27:11 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:2427 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 12:27:00 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id MAA25940 for ; Sun, 25 Feb 2001 12:25:54 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA07352; Mon, 26 Feb 2001 07:25:40 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id HAA60987; Mon, 26 Feb 2001 07:25:38 +1100 (EDT) Date: Mon, 26 Feb 2001 07:25:37 +1100 From: Nathan Scott To: Juan Casero Cc: linux-xfs@oss.sgi.com Subject: Re: libxfs.h and the xfsprogs-devel package? Message-ID: <20010226072537.A138237@wobbly.melbourne.sgi.com> References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> <3A98B6FE.1E056F6B@bellsouth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3A98B6FE.1E056F6B@bellsouth.net>; from casero@bellsouth.net on Sun, Feb 25, 2001 at 02:40:47AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Juan, On Sun, Feb 25, 2001 at 02:40:47AM -0500, Juan Casero wrote: > ... > checking for xfs/libxfs.h... no > > FATAL ERROR: could not find a valid XFS library header. > Install either the xfsprogs-devel (rpm) or the xfslibs-dev (deb) package. > make: *** [include/builddefs] Error 1 > > > ...see that package anywhere. I would have thought > also that doing a 'make install' in the xfsprogs-devel tree would have > installed all the needed libs and header files also. > Anyone know what gives? > You need to do a "make install install-dev" in xfsprogs, you are probably missing the install-dev part. "install" gives binaries, man pages, etc, "install-dev" gives the headers and static libraries. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 25 12:33:51 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 12:33:32 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:13436 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 12:33:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id MAA26570 for ; Sun, 25 Feb 2001 12:32:12 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA07400; Mon, 26 Feb 2001 07:32:00 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id HAA63010; Mon, 26 Feb 2001 07:31:58 +1100 (EDT) Date: Mon, 26 Feb 2001 07:31:57 +1100 From: Nathan Scott To: Juan Casero Cc: linux-xfs@oss.sgi.com Subject: Re: libxfs.h and the xfsprogs-devel package? Message-ID: <20010226073157.B138237@wobbly.melbourne.sgi.com> References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> <3A98B6FE.1E056F6B@bellsouth.net> <3A9948DB.993500E2@bellsouth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3A9948DB.993500E2@bellsouth.net>; from casero@bellsouth.net on Sun, Feb 25, 2001 at 01:03:07PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Sun, Feb 25, 2001 at 01:03:07PM -0500, Juan Casero wrote: > Forgive me if the answer seems obvious but where did you get the xfsprogs-devel > rpm? I have been > looking for this thing and I can't find it. Even so, should a 'make install' from There has not been a release based on the current source as yet, so there are no rpms of these new packages. you'll have to roll your own for now. > tje xfsprogs source tree > have taken care of any header files and library installations? > no, see earlier message re "install-dev" cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 25 12:56:21 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 12:56:12 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58380 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 12:55:54 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id NAA00049 for ; Sun, 25 Feb 2001 13:05:26 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA07487; Mon, 26 Feb 2001 07:54:37 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id HAA53106; Mon, 26 Feb 2001 07:54:35 +1100 (EDT) Date: Mon, 26 Feb 2001 07:54:34 +1100 From: Nathan Scott To: b.j.smith@ieee.org, thebs@theseus.com Cc: linux-xfs@oss.sgi.com Subject: Re: libxfs.h and the xfsprogs-devel package? <- Er, clarification ... Message-ID: <20010226075434.C138237@wobbly.melbourne.sgi.com> References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> <3A98B6FE.1E056F6B@bellsouth.net> <3A9948DB.993500E2@bellsouth.net> <3A994CF2.6FB00D8F@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3A994CF2.6FB00D8F@ieee.org>; from b.j.smith@ieee.org on Sun, Feb 25, 2001 at 01:20:34PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Sun, Feb 25, 2001 at 01:20:34PM -0500, Bryan J. Smith wrote: > Re: libxfs.h and the xfsprogs-devel package? <- Er, clarification > ... > > No, I'm familiar with that. I already built: > > acl-1.0.1-0.i386.rpm > acl-devel-1.0.1-0.i386.rpm > attr-1.0.1-0.i386.rpm > attr-devel-1.0.1-0.i386.rpm > dmapi-0.1.1-0.i386.rpm > dmapi-devel-0.1.1-0.i386.rpm > xfsdump-1.0.2-0.i386.rpm > xfsprogs-1.1.2-0.i386.rpm > xfsprogs-devel-1.1.2-0.i386.rpm > > What I was talking about was building _unified_ RPM akin to > "xfs-cmds-1.0.5-1.i386.rpm" like in Pre-Release 0.9. That way I > don't have to modify Anaconda to know that all those RPMs replace > that one. > These RPMs don't replace that one - there has never been acl and dmapi code in a released package so far, for example, and there were a few other changes at the same time such that this is not a true upgrade but a complete repackaging. Packages like the acl ones (which currently only works for xfs) may disappear entirely once a system call has been finalized (at which point we'll be likely to pick up the acl.bestbits.at packages and replace the current ones with those). The attr packages are in a similar boat - they rely on a custom syscall interface which will change, so we don't want any of the base tools (xfsprogs) to be affected by upheaval in that area. The xfsdump package depends on this attr package as well, so it is no longer part of the base xfsprogs set. And of course, the extended attribute and acl interfaces are not going to be xfs-specific forever, so leaving those tools in with the other xfs-specific ones is the wrong thing to do. And finally, by having smaller focused packages, people can download and install only those components that they need/want. So, there were a number of very good reasons for doing this, but the upshot is the unified xfs-cmds package is history. > As such, I just suggested putting a .spec file in the "cmd" CVS root > so you can. I tried merging spec/makefiles in an attempt to create > a new "xfs-cmds-*.i386.rpm" to no avail. I think you're taking the wrong approach - there wont be any more xfs-cmds packages coming out of sgi, so moving forward its best to track the new packaging scheme. Unfortunately, I didn't have this all working in the 0.9 (beta) timeframe, so we had to leave it for a future release. Hope this helps. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 25 15:04:12 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 15:03:52 -0800 Received: from groucho.maths.monash.edu.au ([130.194.160.211]:19980 "EHLO groucho.maths.monash.edu.au") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 15:03:26 -0800 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id XAA02213 for linux-xfs@oss.sgi.com; Sun, 25 Feb 2001 23:03:24 GMT From: Robin Humble Message-Id: <200102252303.XAA02213@groucho.maths.monash.edu.au> Subject: NFS 0 sizes bug, high nfsd load To: linux-xfs@oss.sgi.com Date: Mon, 26 Feb 2001 10:03:23 +1100 (EDT) Reply-To: rjh_at_pixel.maths.monash.edu.au@groucho.maths.monash.edu.au X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I did some testing with XFS as we're hoping to build an ATA software RAID0 storage box which'll be accessed over NFSv3. Has anyone had success with XFS over software RAID0? Anyway, I encountered a few problems which I thought y'all might like to know about. I compiled up 2.4.2+XFS from friday's cvs and exported an XFS partition from there using NFSv3 to a box running PreRelease0.9 ... On the client, 'du' and 'ls -s' both reported 0 sizes for everything. 'ls -l' worked ok, as did 'df'. Exporting from a pre0.9 box to a pre0.9 box works just fine so this is a new bug. >From a pre0.9 to pre0.9 box I also did dd if=/dev/zero of=bigFile bs=1M count=1000 onto an NFSv3 mounted XFS partition. After the memory cache filled up on the NFS server, the kernel nfsd's started using a LOT of cpu system time - around the 30-50% mark. The network link was slow (~2Mbit) between the client and server, so I didn't expect this. The same write over NFSv3 to an ext2 partition used only about 2-5% cpu load. I was using the default 8 nfsd's. I also ran bonnie++ (www.coker.com.au/bonnie++/) on the 2.4.2-XFS cvs XFS partition (without any NFS this time), and then ran it again on the same partition with ext2 and ReiserFS. XFS had the best bandwidth (up to 30% more than the others when kio was used), but its delete performance was pretty bad - worse even than ext2. Random delete was kinda amazingly slow. ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP ext2 16 365 99 +++++ +++ 9735 98 366 99 +++++ +++ 3119 99 xfs 16 1473 39 +++++ +++ 1360 31 1486 39 +++++ +++ 261 7 reiser 16 8868 100 +++++ +++ 11914 99 8957 100 +++++ +++ 10379 100 this is with the default 16k files/dir, and the +++'s means it was too fast to measure (a good thing! :-) hope this helps... let me know if I can give you more info. The full bonnie++ info is at http://www.cita.utoronto.ca/~rjh/fs.bench.txt, but as always YMMV. It's a datpaoint anyway. cheers, robin -- Robin Humble http://www.cita.utoronto.ca/~rjh/ From owner-linux-xfs@oss.sgi.com Sun Feb 25 15:56:42 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 15:56:32 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:32828 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 15:56:24 -0800 Received: from sydney.sydney.sgi.com ([134.14.48.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA03309 for ; Sun, 25 Feb 2001 15:55:09 -0800 (PST) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id KAA20657; Mon, 26 Feb 2001 10:53:09 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: james rich cc: linux-xfs@oss.sgi.com Subject: Re: building 2.4.2 (with XFS) fails In-reply-to: Your message of "Fri, 23 Feb 2001 13:00:07 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Feb 2001 10:53:10 +1100 Message-ID: <10963.983145190@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 23 Feb 2001 13:00:07 -0700 (MST), james rich wrote: >When building 2.4.2 with XFS patches the build fails with errors that >don't seem related to XFS (that's why the crosspost): l-k removed, XFS build problem. >drivers/char/char.o(.text+0x96fb): undefined reference to `key_maps' Either drivers/char/defkeymap.c is empty or the variables are defined as static, probably the former. Please do ls -l drivers/char/defkeymap.c grep -B 4 -A 4 key_maps drivers/char/defkeymap.c From owner-linux-xfs@oss.sgi.com Sun Feb 25 16:49:32 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 16:49:15 -0800 Received: from ubr-95.237.251.indiatlantic.cfl.rr.com ([24.95.237.251]:10999 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 16:49:06 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id TAA28552; Sun, 25 Feb 2001 19:43:31 -0500 Message-ID: <3A99A9D6.9A99D88D@ieee.org> Date: Sun, 25 Feb 2001 19:56:54 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: New RPMs based on XFS CVS (Feb24) WORK! Anyone got 146MB free somewhere on the 'Net? Content-Type: multipart/mixed; boundary="------------06A56FAAE5A2EF6FFE76281B" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------06A56FAAE5A2EF6FFE76281B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit New RPMs based on XFS CVS (Feb24) WORK! Anyone got 146MB free somewhere on the 'Net? All -- My new RPMs based around XFS from CVS (late Feb 24) seem to work great! I just tried them out, and even made an initrd disk so I could make a root (/) XFS partition. The list of all files in the archive is below (146MB total). I also am attaching my HTML "HOWTO" (which needs some refinement -- please review). I was going to put them on my personal server, with a 256Kbps connection (shared with other co-locaters), but I think that's not going to cut it if more than 2 people download (plus I've got bandwidth limitations). Is there somewhere at SGI or SourceForge where these could go? I'd be interested in cutting them on a weekly basis. Thanx in advance ... (and I hope the HTML attachment doesn't screw up the archives) -- TheBS [ kernel-2.4.2-xfscvs_feb24]$ tree . |-- RCS | `-- SCXFS-HOWTO.lyx,v |-- SCXFS-HOWTO.html |-- SCXFS-HOWTO.lyx |-- SPECS | `-- kernel-2.4.spec |-- SRPMS | |-- acl-1.0.1-0.src.rpm | |-- attr-1.0.1-0.src.rpm | |-- dmapi-0.1.1-0.src.rpm | |-- kernel-2.4.2-xfscvs_feb24.src.rpm | |-- mkinitrd-2.8-1XFS.src.rpm | |-- modutils-2.4.2-3.src.rpm | |-- nfs-utils-0.3.1-1.src.rpm | |-- xfsdump-1.0.2-0.src.rpm | `-- xfsprogs-1.1.2-0.src.rpm |-- athlon | |-- kernel-2.4.2-xfscvs_feb24.athlon.rpm | `-- kernel-smp-2.4.2-xfscvs_feb24.athlon.rpm |-- i386 | |-- acl-1.0.1-0.i386.rpm | |-- acl-devel-1.0.1-0.i386.rpm | |-- attr-1.0.1-0.i386.rpm | |-- attr-devel-1.0.1-0.i386.rpm | |-- devfsd-2.4.2-xfscvs_feb24.i386.rpm | |-- dmapi-0.1.1-0.i386.rpm | |-- dmapi-devel-0.1.1-0.i386.rpm | |-- kernel-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-BOOT-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-doc-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-headers-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-pcmcia-cs-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-smp-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-source-2.4.2-xfscvs_feb24.i386.rpm | |-- mkinitrd-2.8-1XFS.i386.rpm | |-- modutils-2.4.2-3.i386.rpm | |-- nfs-utils-0.3.1-1.i386.rpm | |-- xfsdump-1.0.2-0.i386.rpm | |-- xfsprogs-1.1.2-0.i386.rpm | `-- xfsprogs-devel-1.1.2-0.i386.rpm |-- i586 | |-- kernel-2.4.2-xfscvs_feb24.i586.rpm | `-- kernel-smp-2.4.2-xfscvs_feb24.i586.rpm `-- i686 |-- kernel-2.4.2-xfscvs_feb24.i686.rpm |-- kernel-enterprise-2.4.2-xfscvs_feb24.i686.rpm `-- kernel-smp-2.4.2-xfscvs_feb24.i686.rpm -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com --------------06A56FAAE5A2EF6FFE76281B Content-Type: text/html; charset=us-ascii; name="SCXFS-HOWTO.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="SCXFS-HOWTO.html" 0pt 0pt \textit{SmithConcepts}{\small \( ^{TM} \)} XFS Release\\ for RedHat Linux 7.0\\ HOWTO

SmithConcepts TM XFS Release
for RedHat Linux 7.0
HOWTO

Bryan J. Smith
(mailto:b.j.smith@ieee.org)

$Id: SCXFS-HOWTO.lyx,v 1.2 2001/02/25 22:59:29 bjsmith Exp $

Contents

1  General XFS Information
2  SGI XFS for Linux Release(s)
    2.1  Beta releases
    2.2  Pre-Release version 0.9
    2.3  SGI CVS repository
3  SmithConcepts XFS Release(s)
    3.1  Before you being
    3.2  Release 2.4.2-xfscvs_feb24
    3.3  RPM List
        3.3.1  Binary Kernels Packages
        3.3.2  Kernel Source and Utilities Packages
        3.3.3  XFS Commands and Utilities
        3.3.4  Kernel Support Packages
        3.3.5  Other RPMs
        3.3.6  Source RPMs (SRPMs)
    3.4  Differences from Pre-Release 0.9
4  Installation / Maintenance Issues
    4.1  Installing more than one kernel RPM
        4.1.1  Multiple binaries
        4.1.2  Single source / utilities
        4.1.3  Installing older kernels
    4.2  XFS / (root) Partitions
    4.3  Building your own RPMs
5  Future Roadmap
    5.1  RedHat Linux 7.1
    5.2  Donations
6  Legal
    6.1  SmithConcepts
    6.2  Trademark
    6.3  Copyright and License
    6.4  Warranty
7  Log

1  General XFS Information

XFS is an advanced, enterprise-tested, journaling filesystem (JFS) for Irix and, most recently, Linux. The best source of information on XFS for Linux is SGI's official Open Source Software (OSS) XFS site.

With that said, here are some quick URLs for the XFS ``unfamiliar'':

2  SGI XFS for Linux Release(s)

At this time ($Date: 2001/02/25 22:59:29 $), there has been no ``official, feature complete'' XFS release for Linux. There has been, however, several ``Beta'' releases, one ``Pre-Release'' as well as continued, open, read-only access to the developer CVS (Concurrent Versions System) server where XFS is under constant development.

2.1  Beta releases

SGI has released several Beta XFS releases. At this time ($Date: 2001/02/25 22:59:29 $), all Beta releases have been against either 2.4.0-test or the completed 2.4.0 kernel (which is quite dated in Linux kernel time ;-). Beta XFS releases are available in SGI's ``ProPack'' format, RPMs for RedHat and in source form.

For more information on Beta XFS releases, see:

2.2  Pre-Release version 0.9

In mid-January 2001, SGI released its first XFS for Linux Pre-Release. This Pre-Release version 0.9 targetted the RedHat 7.0 release and an XFS kernel build against the recently completed Linux 2.4.0 kernel release. It included RPMs, Source RPMs (SRPMs) as well as a modified, replacement Anaconda installer with full XFS awareness for CD/Network installs. Unfortunately, like the Beta, releases, several revisions of the 2.4 kernel have followed without an update to Pre-Release version 0.9 (as of $Date: $), and many users have discovered issues with the 2.4.0 release (like IDE and software RAID - attributed to the stock 2.4.0 Linux kernel release itself).

For more information on the Beta XFS release, see:

2.3  SGI CVS repository

So, currently ($Date: 2001/02/25 22:59:29 $), the only means of getting an ``up-to-date'', ``XFS patched'' (among other patches) 2.4 kernel release is via CVS access to SGI's OSS server. SGI has kept its CVS tree very in-sync with offical Linux 2.4 kernel releases as they occur. Using CVS, you can retrieve the entire, patched Linux kernel tree (currently 2.4.2) and XFS command utilities from SGI's OSS server. Unfortunately this requires you to configure, build and install your own kernel (as well as the XFS utilities), which can be daunting for newer administrators.

For more information on SGI CVS Repository access, see:

3  SmithConcepts XFS Release(s)

The purpose of the SmithConcepts XFS Release is to bridge the gap between the dated Pre-Release (currently 0.9, based on Linux kernel 2.4.0 as of $Date: $) and the ``up-to-date'' CVS kernel/utilities (currently based on the lastest Linux kernel 2.4.2 release).

3.1  Before you being

I HIGHLY RECOMMEND that you consider yourself to be an EXPERIENCED KERNEL/LILO SYSADMIN before evem attempting to upgrade your system's kernel to this this EXPERIMENTAL XFS RELEASE. If this is your first time using the XFS kernel, you should only commit TEST SYSTEMS to the trial of this release.

3.2  Release 2.4.2-xfscvs_feb24

The current ($Date: 2001/02/25 22:59:29 $) SmithConcepts XFS release is 2.4.2-xfscvs_feb24. It is based on the XFS patched kernel and command code as of 2001 Feb 24. It builds, it installs, but it may not work for you on your system. I do not even pretend to understand how all the new components and capabilities of kernel 2.4 (let alone XFS) work. Use and install at your discretion.

3.3  RPM List

Below is a list of RPMs (by downloadable URL) and their descriptions for this release.

3.3.1  Binary Kernels Packages

It should be noted that, just like the SGI XFS Pre-Release, XFS itself is configured as a loadable module (and NOT compiled in) in all pre-configured binary kernels. See the following additional sections for more details and issues.

3.3.2  Kernel Source and Utilities Packages

The following RPMs should be upgraded when any of the above binary kernels are installed:

3.3.3  XFS Commands and Utilities

These RPMs are support commands for XFS filesytems. In the Pre-Release, they were a single RPM (xfs-cmds-1.0.5-1.i386.rpm). For now, the CVS tree builds them individually (there will be a single, unified SPEC file in the future):

3.3.4  Kernel Support Packages

The following RPMs are *KEY* in getting the XFS kernel booting in many configurations:

  • ./i386/devfsd-2.4.2-xfscvs_feb24.i386.rpm
    devfs daemon for systems that use the new /dev filesystem (devfs) interface
  • ./i386/mkinitrd-2.8-1XFS.i386.rpm
    A patched mkinitrd package that allows for the creation of root disks with the XFS loadable module (for systems that have a XFS formatted root filesystem)
    [ NOTE: While this mkinitrd is a perfect upgrade for RedHat 7.0 (which has an older version), *IF* you upgrade to newer RedHat betas/releases with mkinitrd-3.0.x, you will *NEED* to patch and rebuild their mkinitrd package to work with XFS! ]
  • ./i386/modutils-2.4.2-3.i386.rpm
    Kernel 2.4-compatible loadable kernel module utility suite (ripped from the RedHat 7.0.91/wolverine beta)

3.3.5  Other RPMs

3.3.6  Source RPMs (SRPMs)

As above for the binary of the same name:

3.4  Differences from Pre-Release 0.9

The pre-built binary kernels are closely based on the existing .config files from the SGI XFS Pre-Release. As such, they're configuration and contents are similiar with the following key differences:

  • The obvious: SmithConcepts releases are based on the Linux 2.4.2 kernel release
  • ATA/IDE is now compiled-in by default. Early stock 2.4.0/2.4.1 kernel releases had issues with these devices (which affected XFS) and the SGI Beta/Pre-Release compiled ATA/IDE only as a loadable module.
  • The ``ksymoops'' package is not included in the current release (2.4.2-xfscvs_feb24). As such, the ``SysReq'' configuration option does not work and there is no ``kernel-utils'' RPM for the current release.
    (NOTE: Please no comments on this. I ran into an issue in the builds which I did not want to address. I will, in all likelihood, put ksymoops/SysReq/kernel-utils back in as standard in a future release. If you don't know what I am talking about then don't worry about it as many RPM kernel binaries have it disabled by default anyway ;-)
  • The kernel tree is a heavily patched/modified kernel tree from SGI's XFS CVS repository
    (NOTE: Do *NOT* assume from the short SRPM file listing that the SmithConcepts/SGI CVS XFS kernel is lacking all the patches of the SGI Pre-Release or RedHat RPM kernels. Instead of using the stock ``linux-2.4.x.tar.bz2'' kernel as a ``base'', the completely modified ``linux-2.4.x-xfscvs_date.tar.bz2'' is used as a base and already has many of these patches integrated)
  • The Athlon processor has its own, specific kernel target RPM
    (Newer RedHat betas now includes the Athlon as a standard kernel target RPM, so it is only natural. Plus, being an engineer, I have several Athlons due to their superior 64-bit/double-precision performance)
  • The IA-64 processor target RPM has been dropped
    (NOTE: I do not have an Itanium to use, nor do I wish to bother with the simulator on x86 given my personal time constraints. Thus, I have also removed the IA-64 target, among all other non-x86 targets, from the SPEC file below (which means the SPEC file is x86-only). This is the same SPEC file in the SRPM as well)

4  Installation / Maintenance Issues

There are several details to installing and maintaining the SmithConcepts XFS Release(s). Please familiarize yourself with them below before installing. E.g., a good time to do this would be while you are downloading the RPM(s). ;->

4.1  Installing more than one kernel RPM

Newer versions of RPM (3.0.4+?) allow more than one RPM to be installed. As such, it is fairly easy to install multiple kernels from RPM, and boot any one of them. Of course, there are limits to this configuration (e.g., only one kernel-source RPM can be installed). And RPM itself cannot address boot/LILO details (i.e., /boot/* and /etc/lilo.conf files).

You should consider keeping your existing 2.2 and/or 2.4 kernel RPM(s) installed when installing (not upgrading) to the SmithConcepts XFS releases. I summarize the details below (sysadmin-level knowledge of RPM highly recommended):

4.1.1  Multiple binaries

You can have multiple kernel binaries installed as their files will not conflict with each other. You should be able to install multiple versions of the following kernel binary RPMs (replace ``ver'' with the kernel version, e.g., 2.2.17.14, 2.4.2-1, and ``arch'' with the processor target, e.g., i686, athlon):

  • kernel-ver.arch.rpm
  • kernel-smp-ver.arch.rpm
  • kernel-enterprise-ver.i686.rpm
  • kernel-BOOT-ver.i386.rpm

In each case, you should install with the ``rpm -i'' command (and NOT ``rpm -U'' which will replace existing kernels). You may additionally need to use the ``-replacefiles'' option on some systems. It is recommended that you do not blindly use the ``-force'' option.

Of course you still need to modify the files in /boot and edit /etc/lilo.conf and install before attempting to reboot after a new kernel version installation.

4.1.2  Single source / utilities

As far as the source code and/or utilities (at least in regards to RedHat 7+ releases) are concerned, you should only have one RPM set. Install only one version of the following RPMs (again, replace "ver" with the kernel version, e.g., 2.2.17.14, 2.4.2-1, and "arch" with the processor target, although it will almost always be i386 RPM for x86 systems):

  • kernel-doc-ver.i386.rpm
  • kernel-headers-ver.i386.rpm
  • kernel-ibcs-ver.i386.rpm
  • kernel-pcmcia-ver.i386.rpm
  • kernel-source-ver.i386.rpm
  • kernel-utils-ver.i386.rpm

Normally, that set should be the latest for maximum compatibility with components (e.g., kernel-headers can affect other, non-kernel elements like GLibC on RedHat systems). So when ``upgrading'' (NOT installing) these components, use the ``rpm -U'' command (and NOT ``rpm -i'' which can lead to multiple copies and dependency frustrations).

4.1.3  Installing older kernels

Numerous issues can arise if you have a newer kernel and source/utility set installed, yet are re-installing or building a custom kernel of an older version. It may require numerous RPM uninstalls (``rpm -e'') and/or re-installs to accomplish. Note that RedHat 7 releases have other components that are based on the kernel-headers-2.4.*.i386.rpm releases and they should not be uninstalled or replaced (except with newer versions).

4.2  XFS / (root) Partitions

As previously mentioned, XFS is compiled as a module in all pre-configured binary kernel RPMs. This is due to sheer size issues with the XFS code. If you are going to make your root (/) filesystem XFS, you must due one of following. Either:

  1. Build and install a custom kernel from source with XFS compiled-in, OR
  2. Use the modified mkinitrd utility suite to make a XFS initial root disk, e.g.:

mkinitrd --with=xfs --with=xfs_support /boot/initrd-2.4.2-xfscvs_feb24.img 2.4.2-xfscvs_feb24

In the case of #2, do NOT forget to add the proper ``initrd'' option to your ``image'' section in /etc/lilo.conf.

[ FYI, the default ramdisk size in the pre-configured binary kernel RPMs is the standard 4096 ]

4.3  Building your own RPMs

If you are maintaining your own working CVS directory of the XFS kernel, doing your own updates, etc..., you can find my reference (i.e. you'll need to modify for yourself) RPM SPEC file below for creating your own RPMs/SRPMs (so you don't have to download my 20GB+ SRPMS just to get that one file ;-). If you don't know what a RPM ``SPEC'' file is, or you don't understand how to use it, then you probably should NOT be building your own RPMs.

RPM SPEC file:

[ NOTE: For reasons of maintaining sanity, I will *NOT* answer questions on how to use SPEC files (unless you are making a suggestion regarding or commenting on a bug in the file itself). Asking my questions directly will put you on my very personal /dev/null E-mail filter. ;-). ]

5  Future Roadmap

I cannot tell or predict the future. I definately cannot tell what direction SGI will take with future RedHat and/or Linux kernel releases.

5.1  RedHat Linux 7.1

If the SGI Pre-Release version 0.9 is any indicator, I expect SGI to release a new Pre-Release (possibly Release version 1?) shortly after (i.e. withing a week or two) the official release of RedHat Linux 7.1. It will most likely be based on the latest stock Linux kernel release (be it the current 2.4.2 release, or future 2.4.3+ releases) with various patches and a modified Anaconda installer in-line with the stock RedHat 7.1 release.

5.2  Donations

It currently takes in excess of 10 hours to build binary kernel RPMs from the RPM .spec file and additional time to reorganize, build and upload the releases themselves (to my sub-standard server and connection). Please be patient with me on updates and fixes. Heck, if my boss (of my normal 60-er, 40 hour/week job) knew I was donating my personal time to something like this, he'd probably find work-related stuff for me to do at home instead. ;-PPP

So, for the impatient ;->, if you would be interested in donating any hardware or capabilities (such as server space on a fast connection) to ``expidite'' the release process, please contact me directly (I've had my eye on an approximately $1K total ServerWorks chipset-based mainboard + 2xCPU and 1GB memory upgrade ;-). Note, at this time ($Date: 2001/02/25 22:59:29 $), I canNOT offer any tax deductions or avenue of legal gift expenditure incentives in any donation.

6  Legal

I am not a lawyer and do not pretend to offer legally accurate statements, although I offer them in the ``goodwill'' of protecting myself and the intellectual property of myself and others. Please do not abuse this ``goodwill.''

6.1  SmithConcepts

SmithConcepts is currently not an incorporate or registered fictious entity (as of $Date: 2001/02/25 22:59:29 $).

6.2  Trademark

SmithConcepts(TM), SmithConcepts.COM and the SmithConcepts(TM) logo are trademarks of Bryan J. Smith. (C) 1992-1995, 1998-2001, all rights reserved.

6.3  Copyright and License

All orginal content contained within this document and directory heirarchy (./kernel-2.4*) is property of Bryan J. Smith, (C) 2001. All rights reserved to the Free Software Foundation (FSF) unless otherwise noted.

Content and other intellectual property of other entities and persons are recognized as property of their respective entities and persons, all rights reserved unless otherwise noted.

This document is licensed under the GNU Free Documentation License, version 1.1 (http://www.gnu.org/copyleft/fdl.html), (C) 2001.

All content and/or code at this directory heirachy (./kernel-2.4*) and below is licensed under the GNU Public License, version 2 (http://www.gnu.org/copyleft/gpl.html), (as of $Date: 2001/02/25 22:59:29 $), or other FSF recognized and applicable GNU license(s) unless otherwise noted and/or reserved by copyright.All rights served to the FSF unless otherwise noted and/or reserved by copyright.

6.4  Warranty

[ Re: Terms and Conditions 11 and 12 from the GPL ]

BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

7  Log

$Log: SCXFS-HOWTO.lyx,v $Revision 1.2  2001/02/25 22:59:29  bjsmithIncorrect mkinitrd syntax in section 4.2 (fixed)Revision 1.1  2001/02/25 22:36:00  bjsmithInitial revision

File translated from TEX by TTH, version 2.51.
On 25 Feb 2001, 17:59. --------------06A56FAAE5A2EF6FFE76281B-- From owner-linux-xfs@oss.sgi.com Sun Feb 25 17:11:14 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 17:11:05 -0800 Received: from ubr-95.237.251.indiatlantic.cfl.rr.com ([24.95.237.251]:18679 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 17:10:47 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id UAA28893; Sun, 25 Feb 2001 20:05:18 -0500 Message-ID: <3A99AEF2.AD972C0@ieee.org> Date: Sun, 25 Feb 2001 20:18:42 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: New RPMs based on XFS CVS (Feb24) WORK! <- Hmmm, whole else besides SourceForge.NET? References: <3A99A9D6.9A99D88D@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Re: New RPMs based on XFS CVS (Feb24) WORK! <- Hmmm, whole else besides SourceForge.NET? "Bryan J. Smith" wrote: > I was going to put them on my personal server, with a 256Kbps > connection (shared with other co-locaters), but I think that's not > going to cut it if more than 2 people download (plus I've got > bandwidth limitations). Is there somewhere at SGI or SourceForge > where these could go? I'd be interested in cutting them on a weekly > basis. I'm sending them up to my server now. ETA 1.5 hours. I'll let everyone know. [ My friend's going to hate me ... ;-PPP ] I've put in for a project at SourceForge.NET (xfs4rh -- "XFS Kernel/Support RPMs for RedHat"). Not sure they will cater to me because I'm just packinging and maintaining other people's code. Is there another site that would be better? -- TheBS How sweet it is (from RPM, mkinitrd --with=xfs --with=xfs_support for root filesystem -- no separate /boot either!) ... [local@fester local]$ cat /proc/mounts /dev/ide/host2/bus0/target0/lun0/part2 / xfs rw 0 0 none /dev devfs rw 0 0 /proc /proc proc rw 0 0 /dev/hde5 /tmp xfs rw 0 0 /dev/hde7 /usr xfs rw 0 0 /dev/hde6 /var xfs rw 0 0 /dev/hde8 /Fester xfs rw 0 0 none /dev/pts devpts rw 0 0 automount(pid429) /misc autofs rw 0 0 Did I mention I just turned off the power button and it took a whole 1 second to mount the filesystems (15GB disk, about 8GB used)?!?!?! That's including the "fsck"!!! I'm "used to" Ext3. ;-PPP -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 17:30:04 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 17:29:54 -0800 Received: from ubr-95.237.251.indiatlantic.cfl.rr.com ([24.95.237.251]:26615 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 17:29:43 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id UAA29177; Sun, 25 Feb 2001 20:24:14 -0500 Message-ID: <3A99B362.B195B1FE@ieee.org> Date: Sun, 25 Feb 2001 20:37:38 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [Off-topic] Anyone interested in RPMs build from the latest 2.4.2 kernel + XFS? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing [Off-topic] Anyone interested in RPMs build from the latest 2.4.2 kernel + XFS? Well, instead of working at my job for ~20 hours this weekend (I ended up only spending ~8 hours there, my boss is going to kill me ;-), I buckled down and messed with some of the latest 2.4.2 kernel stuff in SGI's XFS CVS repository, since the SGI Beta/Pre-Release stuff is 2.4.0 and quite "aged" now (in Linux kernel terms). The result is that I ended up cutting some RPMs (after about ~20 hours of toying with modifying SPEC file), including the various support RPMs. So, now, I've got a completely set of RPMs (146MB total, including SRPMS) that you can plop on any updated RedHat 7.0 system to get full XFS goodness. You can even have a root (/) XFS filesystem with no separate boot (simply by making an initrd with the xfs/xfs_support modules). I hope to be able to do this every week or two for those that are "kernel-build"-challenged (or those that don't want to track down all the support RPMs, etc...). I'm uploading the archive (list of files is below) to my server now. It's only a 256Kbps connection (ETA 1.5 hours to upload) I share with a couple of others (on a friend's network). Ideally, it's not going to take more than a couple of people to piss my friend off. I've put in for a project on SourceForge.NET, but all I'm doing is packaging other people's stuff. Where should I be looking for storage of just RPMs and packaged goods? Anyhoo, I'll let you'all know when its uploaded if you are interested in XFS. A number of people on the XFS list out at SGI have been showing off most excellent NFS benchmarks. I just hard powered-off twice and the mounts don't even hiccup (test server of about 8GB in use, total) and take only about a total of a second after improper shutdown. I hope XFS is as solid as I'm hearing (most issues have been with non-XFS stuff in the 2.4.x kernels). -- TheBS P.S. I have an HTML "HOWTO" on the release. I didn't want to attach it to the list because it is HTML. If anyone wants it, it'll be up on my server in a little while. [ kernel-2.4.2-xfscvs_feb24]$ tree . |-- RCS | `-- SCXFS-HOWTO.lyx,v |-- SCXFS-HOWTO.html |-- SCXFS-HOWTO.lyx |-- SPECS | `-- kernel-2.4.spec |-- SRPMS | |-- acl-1.0.1-0.src.rpm | |-- attr-1.0.1-0.src.rpm | |-- dmapi-0.1.1-0.src.rpm | |-- kernel-2.4.2-xfscvs_feb24.src.rpm | |-- mkinitrd-2.8-1XFS.src.rpm | |-- modutils-2.4.2-3.src.rpm | |-- nfs-utils-0.3.1-1.src.rpm | |-- xfsdump-1.0.2-0.src.rpm | `-- xfsprogs-1.1.2-0.src.rpm |-- athlon | |-- kernel-2.4.2-xfscvs_feb24.athlon.rpm | `-- kernel-smp-2.4.2-xfscvs_feb24.athlon.rpm |-- i386 | |-- acl-1.0.1-0.i386.rpm | |-- acl-devel-1.0.1-0.i386.rpm | |-- attr-1.0.1-0.i386.rpm | |-- attr-devel-1.0.1-0.i386.rpm | |-- devfsd-2.4.2-xfscvs_feb24.i386.rpm | |-- dmapi-0.1.1-0.i386.rpm | |-- dmapi-devel-0.1.1-0.i386.rpm | |-- kernel-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-BOOT-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-doc-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-headers-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-pcmcia-cs-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-smp-2.4.2-xfscvs_feb24.i386.rpm | |-- kernel-source-2.4.2-xfscvs_feb24.i386.rpm | |-- mkinitrd-2.8-1XFS.i386.rpm | |-- modutils-2.4.2-3.i386.rpm | |-- nfs-utils-0.3.1-1.i386.rpm | |-- xfsdump-1.0.2-0.i386.rpm | |-- xfsprogs-1.1.2-0.i386.rpm | `-- xfsprogs-devel-1.1.2-0.i386.rpm |-- i586 | |-- kernel-2.4.2-xfscvs_feb24.i586.rpm | `-- kernel-smp-2.4.2-xfscvs_feb24.i586.rpm `-- i686 |-- kernel-2.4.2-xfscvs_feb24.i686.rpm |-- kernel-enterprise-2.4.2-xfscvs_feb24.i686.rpm `-- kernel-smp-2.4.2-xfscvs_feb24.i686.rpm -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 17:31:35 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 17:31:14 -0800 Received: from ubr-95.237.251.indiatlantic.cfl.rr.com ([24.95.237.251]:27383 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 17:31:12 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id UAA29203; Sun, 25 Feb 2001 20:25:43 -0500 Message-ID: <3A99B3BB.2F437A9F@ieee.org> Date: Sun, 25 Feb 2001 20:39:07 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Anyone interested in RPMs build from the latest 2.4.2 kernel + XFS? <- WRONG LIST!!! References: <3A99B362.B195B1FE@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Re: Anyone interested in RPMs build from the latest 2.4.2 kernel + XFS? <- WRONG LIST!!! *** DOOH *** !!! I meant to send that to the SourceForge.NET NFS list! Sorry for the repetition!!! Geez! (I guess I haven't slept much) -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Sun Feb 25 19:25:56 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 19:25:36 -0800 Received: from moe.rice.edu ([128.42.5.4]:25332 "EHLO moe.rice.edu") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 19:25:13 -0800 Received: from photino.sid.rice.edu (photino.sid.rice.edu [128.42.162.116]) by moe.rice.edu (8.9.0/8.9.0) with ESMTP id VAA05842 for ; Sun, 25 Feb 2001 21:25:11 -0600 (CST) Received: (from rjain@localhost) by photino.sid.rice.edu (8.11.2/8.11.2/Debian 8.11.2-1) id f1Q3PBD00598 for linux-xfs@oss.sgi.com; Sun, 25 Feb 2001 21:25:11 -0600 Date: Sun, 25 Feb 2001 21:25:11 -0600 From: Rahul Jain To: linux-xfs@oss.sgi.com Subject: Re: xfs hang Message-ID: <20010225212511.A564@photino.sid.rice.edu> Reply-To: Rahul Jain References: <20010225050407.A393@photino.sid.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010225050407.A393@photino.sid.rice.edu>; from rahul@rice.edu on Sun, Feb 25, 2001 at 05:04:07AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, Feb 25, 2001 at 05:04:07AM -0600, Rahul Jain wrote: > > I'm using version 2.4.1 from cvs (I had just completed cvs updating the xfs > tree before this happened.) > It looks like the same hang occurs with the latest CVS version, as well, giving a nearly identical backtrace. I'll look through do_buffer_fdatasync to see if there is any obvious place to put printks for debugging. -- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request. From owner-linux-xfs@oss.sgi.com Sun Feb 25 22:45:37 2001 Received: by oss.sgi.com id ; Sun, 25 Feb 2001 22:45:17 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:50499 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 25 Feb 2001 22:44:56 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA02705 for ; Sun, 25 Feb 2001 22:43:51 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA35313; Sun, 25 Feb 2001 22:39:13 -0800 (PST) Message-ID: <3A99FADD.3F835D88@sgi.com> Date: Sun, 25 Feb 2001 22:42:37 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rahul Jain CC: linux-xfs@oss.sgi.com Subject: Re: xfs hang References: <20010225050407.A393@photino.sid.rice.edu> <20010225212511.A564@photino.sid.rice.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Rahul Jain wrote: > > On Sun, Feb 25, 2001 at 05:04:07AM -0600, Rahul Jain wrote: > > > > I'm using version 2.4.1 from cvs (I had just completed cvs updating the xfs > > tree before this happened.) > > > > It looks like the same hang occurs with the latest CVS version, as well, giving > a nearly identical backtrace. I'll look through do_buffer_fdatasync to see if > there is any obvious place to put printks for debugging. Hi, There are 6 calls to do_buffer_fdatasync() from generic_buffer_fdatasync(). I think it is the third that's in your backtrace. You can disassemble in kdb by "id generic_buffer_fdatasync" and keep issuing "id" at the kdb prompt to get more lines of dissassembled code. It's not clear if the do_buffer_fdatasync() is spinning on the same page of the locked_pages list (i.e, not making forward progress) or is it stuck in aquiring the pagecache_lock(). One way to find out, is to install a breakpoint in writeout_one_page() ... this is the fn() passed in. "bpa write_one_page+0x4" would do the trick; the 0x4 is so stack is setup correctly. If you repeatedly hit this breakpoint then its not the pagecache_lock. Another thing to check the argument to writeout_one_page, which is displayed in the "bt". A second note: we are reworking the way sync is performed as an extension of the delay-buffer patch that i've been sending out, although the sync changes are not there yet. Still, it'll be interesting to know the effect of the patch in your test system. Thanks for your feedback, ananth. -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Feb 26 03:17:16 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 03:16:57 -0800 Received: from south.orl-pub.theseus.com ([12.108.42.66]:57361 "EHLO thor.theseus.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 03:16:56 -0800 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id GAA30300; Mon, 26 Feb 2001 06:20:12 -0500 Message-ID: <3A9A3B44.67962A9A@theseus.com> Date: Mon, 26 Feb 2001 06:17:24 -0500 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: nfs@lists.sourceforge.net Subject: XFS RPMs are now at SmithConcepts.COM -- WAS: New RPMs based on XFS CVS (Feb24) WORK!] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing XFS RPMs are now at SmithConcepts.COM -- WAS: New RPMs based on XFS CVS (Feb24) WORK! Files (RPMs, SRPMs): http://www.smithconcepts.com/files/kernel-2.4.2-xfscvs_feb24/ HOWTO (HTML format): http://www.smithconcepts.com/files/kernel-2.4.2-xfscvs_feb24/SCXFS-HOWTO.html Until I can find a fast mirror or other fast host, I ask that you *ONLY DOWNLOAD WHAT YOU NEED* (e.g., the kernel and support binaries for your specific processor). If you want to recompile a custom kernel from source, please go grab XFS directly from SGI's CVS repository (see the HOWTO for info) at this time. -- Bryan P.S. If you wish to mirror these files, please contact me directly so I can directly upload them to your server from another system. P.S.S. Comments, corrections and general flammage on the files and, especially, the HOWTO (technical, non-typo comments please ;-) would be greatly appreciated. -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Mon Feb 26 03:24:37 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 03:24:16 -0800 Received: from hermes.mixx.net ([212.84.196.2]:4619 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 26 Feb 2001 03:24:07 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 15920F80C for ; Mon, 26 Feb 2001 12:24:05 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id DBF8B2CA6F; Mon, 26 Feb 2001 12:24:04 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: typo & question Date: 26 Feb 2001 11:24:04 GMT Organization: innominate AG, Berlin, Germany Lines: 21 Distribution: local Message-ID: X-Trace: mate.bln.innominate.de 983186644 12228 10.0.0.31 (26 Feb 2001 11:24:04 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.2-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing first: there's a small typo in linux/Documentation/filesystems/xfs.txt logbufsize=value should be logbsize=value second: is the kiocluster option also honoured for an XFS root fs? i ask because at least the message "XFS (dev: x/y) mounting with kiobuf I/O" is not printed for the rootfs mount - haven't looked at the code yet - but maybe someone can say something about this off mind thanks t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Mon Feb 26 04:59:49 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 04:59:38 -0800 Received: from cc19815-a.zwoll1.ov.nl.home.com ([212.204.138.247]:6389 "HELO convert rfc822-to-8bite1 wisdom.myplace.net") by oss.sgi.com with SMTP id ; Mon, 26 Feb 2001 04:59:25 -0800 Received: from LAPTOP (vp245-6.worldonline.nl [195.241.245.6]) by wisdom.myplace.net (Postfix) with SMTP id 928F0142 for ; Mon, 26 Feb 2001 13:59:23 +0100 (CET) Received: by LAPTOP with Microsoft Mail id <01C09FFB.67FC9CB0@LAPTOP>; Mon, 26 Feb 2001 13:52:49 +0100 Message-ID: <01C09FFB.67FC9CB0@LAPTOP> From: Bas To: "'linux-xfs@oss.sgi.com'" Subject: Patch for kernel 2.4.1 Date: Mon, 26 Feb 2001 13:52:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I'm looking for a patch for kernel 2.4.1. I was able to get kernel 2.4.2 through CVS, but loopback device is broken in 2.4.2 and I depend on loopback device. The patch I downloaded from oss.sgi.com gave me some errors on 2.4.1 Thanks, Bas. From owner-linux-xfs@oss.sgi.com Mon Feb 26 05:21:29 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 05:21:19 -0800 Received: from linux.CompuComIS.net ([207.8.143.10]:61705 "HELO linux.compucomis.net") by oss.sgi.com with SMTP id ; Mon, 26 Feb 2001 05:21:06 -0800 Received: by linux.compucomis.net (Postfix, from userid 501) id 456F3FB08; Mon, 26 Feb 2001 08:21:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id 41CDDBC2C; Mon, 26 Feb 2001 08:21:15 -0500 (EST) Date: Mon, 26 Feb 2001 08:21:15 -0500 (EST) From: Mike Burger To: Bas Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Patch for kernel 2.4.1 In-Reply-To: <01C09FFB.67FC9CB0@LAPTOP> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Can you recompile 2.4.1, to make sure you have loopback support compiled in, and then retry the 2.4.2? On Mon, 26 Feb 2001, Bas wrote: > Hi, > I'm looking for a patch for kernel 2.4.1. I was able to get kernel 2.4.2 through CVS, but loopback device is broken in 2.4.2 and I depend on loopback device. The patch I downloaded from oss.sgi.com gave me some errors on 2.4.1 > > Thanks, > Bas. > > From owner-linux-xfs@oss.sgi.com Mon Feb 26 05:32:58 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 05:32:39 -0800 Received: from esparrall.udg.es ([130.206.124.16]:2432 "EHLO esparrall.udg.es") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 05:32:18 -0800 Received: from gcs by esparrall.udg.es with local (Exim 3.22 #1 (Debian)) id 14XNkl-0000EG-00 for ; Mon, 26 Feb 2001 14:31:51 +0100 Date: Mon, 26 Feb 2001 14:31:50 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: Re: Patch for kernel 2.4.1 Message-ID: <20010226143150.A859@esparrall.udg.es> References: <01C09FFB.67FC9CB0@LAPTOP> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: Bas wrote on H, FEB 26, 2001 at 01:52:48 +0100: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, On H, FEB 26, 2001 at 01:52:48 +0100, Bas wrote: > I'm looking for a patch for kernel 2.4.1. I was able to get kernel 2.4.2 through CVS, but loopback device is broken in 2.4.2 and I depend on loopback device. The patch I downloaded from oss.sgi.com gave me some errors on 2.4.1 Please press enter after a line. Thanks. Anyway, as I know there is a patch for this issue - loop6 at: ftp://ftp.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.2-pre4/ Hope it helps, GCS Ps:For me it is working. From owner-linux-xfs@oss.sgi.com Mon Feb 26 08:06:49 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 08:06:30 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:10006 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 08:06:10 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA03539 for ; Mon, 26 Feb 2001 08:05:37 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA83777; Mon, 26 Feb 2001 10:04:22 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1QG3Gj12945; Mon, 26 Feb 2001 11:03:16 -0500 Message-ID: <3A9A7E44.ACA08130@thebarn.com> Date: Mon, 26 Feb 2001 11:03:16 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Juan Casero CC: james rich , linux-xfs@oss.sgi.com Subject: Re: building 2.4.2 (with XFS) fails References: <3A99469F.90F883F7@bellsouth.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Juan Casero wrote: > It's hard to understand why you are having this problem. I have not seen anything > like it > although I will say that there were a couple of occassions a few days ago when a > compile > of the previous kernel source from the SGI CVS server did fail on my box. I don't > recall > if the error was like yours though. On a much happier note I will say that I was > able to > compile the code for the 2.4.2 kernel source that I downloaded from their CVS > server. > One thing you might be failing to do is update your cvs tree. Make sure you issue > the following > commands to get the source tree > > $ cvs -z3 checkout linux-2.4-xfs > $ cvs -z3 update -d > > It is important that you not forget the second of the two commands above. I myself > am > relatively new to using CVS so I can't explain why but I am almost certain that the > update > is absolutely important for getting the latest source code. There should be no reason a 'cvs update' should be run immediately after a 'cvs checkout' If anybody has run that shows cvs update in this case producing output let me know. > > > Good Luck.... > > Juan Casero > casero@bellsouth.net > > james rich wrote: > > > On Sat, 24 Feb 2001, Juan Casero wrote: > > > > > The messages below seem to indicate there are some references in char.o to > > > functions that have not been defined. These kinds of errors usually occur at > > > the link stage of a compilation. Instead of patching a stock kernel use the > > > > > > instructions available at oss.sgi.com/projects/xfs to login to their CVS > > > server > > > and download the source code that way. After that you can make a sym link > > > /usr/src/linux-2.4-xfs/linux <-- /usr/src/linux and then recompile the code. > > > I am pretty sure you'll have no problems getting it to build. > > > > This occurred after pulling the CVS tree last night and tried it again > > this morning. I'l' try deleting my entire tree and do the CVS pull again > > (takes a *long* time over my modem :( ). > > > > James Rich > > james.rich@m.cc.utah.edu -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Feb 26 08:09:19 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 08:09:00 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:20503 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 08:08:53 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA05064 for ; Mon, 26 Feb 2001 08:08:51 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA16232; Mon, 26 Feb 2001 10:07:35 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1QG6Uj12951; Mon, 26 Feb 2001 11:06:30 -0500 Message-ID: <3A9A7F06.81427A15@thebarn.com> Date: Mon, 26 Feb 2001 11:06:30 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: GCS CC: linux-xfs@oss.sgi.com Subject: Re: XFS and Kernel 2.4.2 References: <20010225021253.A1518@esparrall.udg.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing GCS wrote: > Hello all, > > Anyone could make XFS with the newest kernel (2.4.2)? I tried, but the module > support is broken. All of the modules give me unresolved symbols (even very > basic ones like printk()). Did you use "make install" to install the kernel? If not make sure you copy the file "System.map" to the /boot directory eg. bble[10:04am]-=>ls -l /boot/System.map* lrwxrwxrwx 1 root root 20 Feb 23 16:56 /boot/System.map -> System.map-2.4.2-XFS -rw-r--r-- 1 root root 398588 Feb 21 06:07 /boot/System.map-2.4.1-22mdk -rw-r--r-- 1 root root 414222 Feb 21 05:51 /boot/System.map-2.4.1-22mdksmp -rw-r--r-- 1 root root 441506 Feb 15 19:25 /boot/System.map-2.4.1-XFS -rw-rw-r-- 1 root root 434153 Feb 14 19:40 /boot/System.map-2.4.1-XFS.old -rw-r--r-- 1 root root 442350 Feb 23 16:53 /boot/System.map-2.4.2-XFS -rw-r--r-- 1 root root 442286 Feb 22 17:40 /boot/System.map-2.4.2-XFS.old > > Ok, I said compile everything into the kernel, and > so I did. I have support for XFS, but I can not use it. When I create the > filesystem on /dev/fd0 I get: > mkfs.xfs: warning - cannot set blocksize on block device /dev/fd0: Invalid argument > meta-data=/dev/fd0 isize=256 agcount=1, agsize=4096 blks > data = bsize=4096 blocks=360, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > mkfs.xfs: device_zero write failed: Invalid argument > > The last line should be a crash, as I can not mount the floppy, the good old > message (mount: wrong fs type, ...) shows up. Check with xfs_repair: > xfs_repair: warning - cannot set blocksize on block device /dev/fd0: Invalid argument > Phase 1 - find and verify superblock... > bad primary superblock - filesystem mkfs-in-progress bit set !!! > > attempting to find secondary superblock... > .Sorry, could not find valid secondary superblock > Exiting now. > > So mkfs crash in the middle of the creation. Any workaround maybe? > Thanks, Laszlo -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Feb 26 08:39:20 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 08:39:00 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:48165 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 08:38:43 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA07346 for ; Mon, 26 Feb 2001 08:38:41 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA944583; Mon, 26 Feb 2001 10:37:24 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA95261; Mon, 26 Feb 2001 10:37:24 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1QGcVi20296; Mon, 26 Feb 2001 10:38:32 -0600 Message-Id: <200102261638.f1QGcVi20296@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: b.j.smith@ieee.org, thebs@theseus.com cc: Thomas Graichen , linux-xfs@oss.sgi.com Subject: Re: Besides the patched kernel and commands, what else is needed? In-Reply-To: Message from "Bryan J. Smith" of "Sun, 25 Feb 2001 08:25:00 EST." <3A9907AC.2ECF6D15@ieee.org> Date: Mon, 26 Feb 2001 10:38:31 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Thomas Graichen wrote: > > basically nothing else is needed > > I'm kinda wondering what all is patched in the linux kernel tree > under CVS? I know both RedHat's 2.4.0/1 kernels come with a lot of > various patches to the stock kernel tree, and the SGI PR 0.9 2.4.0 > did as well. Have these been integrated into the CVS kernel (among > other patches?). [ I'm assuming so, along with other post-2.4.2 > patches that didn't make it in. ] Just for the record, the cvs tree contains a base kernel, plus those changes need to make xfs work, and some debugging / development tools (e.g. kdb). The rpms do have extra patches included which are not directly in the cvs tree. Steve From owner-linux-xfs@oss.sgi.com Mon Feb 26 09:06:40 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 09:06:30 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:3638 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 09:06:19 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA04085 for ; Mon, 26 Feb 2001 09:06:07 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA47936; Mon, 26 Feb 2001 11:04:52 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1QH3kj13081; Mon, 26 Feb 2001 12:03:47 -0500 Message-ID: <3A9A8C72.1DB62A6B@thebarn.com> Date: Mon, 26 Feb 2001 12:03:46 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: b.j.smith@ieee.org, thebs@theseus.com CC: linux-xfs@oss.sgi.com Subject: Re: New RPMs based on XFS CVS (Feb24) WORK! <- Hmmm, whole else besides SourceForge.NET? References: <3A99A9D6.9A99D88D@ieee.org> <3A99AEF2.AD972C0@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Bryan J. Smith" wrote: Ohhh cool... save us some work. I'll give you mirror space at oss.sgi.com... well how about linux-xfs.sgi.com, which is BTW a totally XFS box serving the xfs web pages. It would be best not to have a lot of sources for XFS kernel RPMs if it isn't necessary. You can certainly put your stuff up on sourceforge but linux-xfs.sgi.com has space. > Re: New RPMs based on XFS CVS (Feb24) WORK! <- Hmmm, whole else > besides SourceForge.NET? > > "Bryan J. Smith" wrote: > > I was going to put them on my personal server, with a 256Kbps > > connection (shared with other co-locaters), but I think that's not > > going to cut it if more than 2 people download (plus I've got > > bandwidth limitations). Is there somewhere at SGI or SourceForge > > where these could go? I'd be interested in cutting them on a weekly > > basis. > > I'm sending them up to my server now. ETA 1.5 hours. I'll let > everyone know. > [ My friend's going to hate me ... ;-PPP ] > > I've put in for a project at SourceForge.NET (xfs4rh -- "XFS > Kernel/Support RPMs for RedHat"). Not sure they will cater to me > because I'm just packinging and maintaining other people's code. Is > there another site that would be better? > > -- TheBS > > How sweet it is (from RPM, mkinitrd --with=xfs --with=xfs_support > for root filesystem -- no separate /boot either!) ... > > [local@fester local]$ cat /proc/mounts > /dev/ide/host2/bus0/target0/lun0/part2 / xfs rw 0 0 > none /dev devfs rw 0 0 > /proc /proc proc rw 0 0 > /dev/hde5 /tmp xfs rw 0 0 > /dev/hde7 /usr xfs rw 0 0 > /dev/hde6 /var xfs rw 0 0 > /dev/hde8 /Fester xfs rw 0 0 > none /dev/pts devpts rw 0 0 > automount(pid429) /misc autofs rw 0 0 > > Did I mention I just turned off the power button and it took a whole > 1 second to mount the filesystems (15GB disk, about 8GB used)?!?!?! > That's including the "fsck"!!! > > I'm "used to" Ext3. ;-PPP > > -- > Bryan "TheBS" Smith, Engineer CONTACT INFO > *********************************************************** > Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) > Email: mailto:thebs@smithconcepts.com,thebs@theseus.com -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Feb 26 09:06:40 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 09:06:31 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:2614 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 09:06:17 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA01480 for ; Mon, 26 Feb 2001 09:06:14 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA52399; Mon, 26 Feb 2001 11:04:59 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1QH3sj13085; Mon, 26 Feb 2001 12:03:54 -0500 Message-ID: <3A9A8C79.CEA4BF9@thebarn.com> Date: Mon, 26 Feb 2001 12:03:54 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: b.j.smith@ieee.org CC: linux-xfs@oss.sgi.com Subject: Re: Besides the patched kernel and commands, what else is needed? References: <3A987466.4763CEEE@ieee.org> <3A9907AC.2ECF6D15@ieee.org> <3A9915CA.BD4E266@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Bryan J. Smith" wrote: > Thomas Graichen wrote: > > i run my machines at home and at work with all xfs (except /boot - > > but this is at least possible too) for over half a year now with- > > out any problems ... just as a postive point here :-) > > > If I use mkinitrd to put the XFS module inside and initrd, then I > only need /boot to not be XFS, correct? Or since XFS works with > LILO, it can be XFS as well??? > At this point the entire system can be XFS, even with XFS as a module. The kernel will be fine from an XFS partition since it simple goes out and looks for blocks on the disk. eg /dev/scsi/host0/bus0/target0/lun0/part7 on / type xfs (rw) none on /proc type proc (rw) usbdevfs on /proc/bus/usb type usbdevfs (rw) /dev/scsi/host0/bus0/target0/lun0/part5 on /boot type xfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/scsi/host2/bus0/target0/lun0/part1 on /export/xfs1 type xfs (rw) The modified mkinitrd on the CD simply forces xfs, xfs_support, and pagebuf to be included in the initial ram disk. If XFS compiles into the kernel no modifications are needed to mkinitrd. As Thomas already stated; current modutils are needed for the 2.4 kernel. > > > -- TheBS > > -- > Bryan "TheBS" Smith, Engineer CONTACT INFO > *********************************************************** > Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) > Email: mailto:thebs@smithconcepts.com,thebs@theseus.com -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Feb 26 09:36:21 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 09:36:11 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:59713 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 09:35:49 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA02975 for ; Mon, 26 Feb 2001 09:34:43 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA944694; Mon, 26 Feb 2001 11:34:30 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA60223; Mon, 26 Feb 2001 11:34:30 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1QHZbe25954; Mon, 26 Feb 2001 11:35:38 -0600 Message-Id: <200102261735.f1QHZbe25954@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: rjh@groucho.maths.monash.edu.au cc: linux-xfs@oss.sgi.com Subject: Re: NFS 0 sizes bug, high nfsd load In-Reply-To: Message from Robin Humble of "Mon, 26 Feb 2001 10:03:23 +1100." <200102252303.XAA02213@groucho.maths.monash.edu.au> Date: Mon, 26 Feb 2001 11:35:37 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Hi, > NFS problem deleted - we will have to do some investigating there. For metadata intensive runs like bonnie file creation, try building a filesystem with a bigger log than default: mkfs -t xfs -f -l size=32768b /dev/xxx and mount using mount -o logbufs=4 This will help, but not massively. You are running into the journalling features of XFS big time here, try using a larger number of files for reiserfs, it does not sync its journal out to disk more than once a minute unless it fills it, and since these are lots of empty files they take very little room in reiserfs. ext2 is just manipulating memory and not doing disk I/O much at all in this case. In ext2 if you reset the system in the middle of this you will sit in fsck for quite a while, in reiserfs I suspect you will find none of your 30000 files exists. Notice that ext2 and reiserfs are both cpu bound, xfs is disk bound. You pays your money (or not in the case of linux) and you takes your choice. Having said that, there are things which could be done to speed up the delete case in xfs, they have been written down for several years now, we just never had the internal bandwidth to implement them. If anyone is feeling really brave...... Steve > > I also ran bonnie++ (www.coker.com.au/bonnie++/) on the 2.4.2-XFS cvs > XFS partition (without any NFS this time), and then ran it again on > the same partition with ext2 and ReiserFS. XFS had the best > bandwidth (up to 30% more than the others when kio was used), but its > delete performance was pretty bad - worse even than ext2. Random > delete was kinda amazingly slow. > > ------Sequential Create------ --------Random Create-------- > -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- > files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > ext2 16 365 99 +++++ +++ 9735 98 366 99 +++++ +++ 3119 99 > xfs 16 1473 39 +++++ +++ 1360 31 1486 39 +++++ +++ 261 7 > reiser 16 8868 100 +++++ +++ 11914 99 8957 100 +++++ +++ 10379 100 > > this is with the default 16k files/dir, and the +++'s means it was > too fast to measure (a good thing! :-) > > hope this helps... let me know if I can give you more info. The full > bonnie++ info is at http://www.cita.utoronto.ca/~rjh/fs.bench.txt, but > as always YMMV. It's a datpaoint anyway. > > cheers, > robin > -- > Robin Humble http://www.cita.utoronto.ca/~rjh/ From owner-linux-xfs@oss.sgi.com Mon Feb 26 09:41:11 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 09:40:51 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:35652 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 09:40:38 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA04178 for ; Mon, 26 Feb 2001 09:39:32 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA55459; Mon, 26 Feb 2001 11:39:21 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1QHcFj13169; Mon, 26 Feb 2001 12:38:15 -0500 Message-ID: <3A9A9486.EF771870@thebarn.com> Date: Mon, 26 Feb 2001 12:38:14 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: typo & question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > first: > there's a small typo in linux/Documentation/filesystems/xfs.txt > logbufsize=value should be logbsize=value > > second: > > is the kiocluster option also honoured for an XFS root fs? > i ask because at least the message "XFS (dev: x/y) mounting > with kiobuf I/O" is not printed for the rootfs mount - haven't > looked at the code yet - but maybe someone can say something > about this off mind > Hmm good question. Obviously the initial mount of the root fs does not use kio option. Doing a mount -o remount ,kio should enable kio buf io on any already mounted fs, with hopefully no ill affects. The next question I guess would be; is kio bufs used when the flag added to the fstab entry.... don't know... will have to try it. > > thanks > > t > > -- > thomas.graichen@innominate.com > innominate AG > the linux architects > tel: +49-30-308806-13 fax: -77 http://www.innominate.com -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Feb 26 10:02:20 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 10:02:11 -0800 Received: from south.orl-pub.theseus.com ([12.108.42.66]:45584 "EHLO thor.theseus.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 10:01:58 -0800 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id NAA10685; Mon, 26 Feb 2001 13:05:07 -0500 Message-ID: <3A9A9A33.679D650F@theseus.com> Date: Mon, 26 Feb 2001 13:02:27 -0500 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: Besides the patched kernel and commands, what else is needed? References: <3A987466.4763CEEE@ieee.org> <3A9907AC.2ECF6D15@ieee.org> <3A9915CA.BD4E266@ieee.org> <3A9A8C79.CEA4BF9@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > At this point the entire system can be XFS, even with XFS as a module. > The kernel will be fine from an XFS partition since it simple goes out > and looks for blocks on the disk. Yep! Found out myself. Even using xfs/xfs_support in a initrd too! Very cool stuff indeed. -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Mon Feb 26 10:12:20 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 10:12:11 -0800 Received: from south.orl-pub.theseus.com ([12.108.42.66]:26642 "EHLO thor.theseus.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 10:12:01 -0800 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id NAA10935; Mon, 26 Feb 2001 13:15:18 -0500 Message-ID: <3A9A9C95.8216CDD0@theseus.com> Date: Mon, 26 Feb 2001 13:12:37 -0500 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: New RPMs based on XFS CVS (Feb24) WORK! <- Hmmm, whole else besides SourceForge.NET? References: <3A99A9D6.9A99D88D@ieee.org> <3A99AEF2.AD972C0@ieee.org> <3A9A8C72.1DB62A6B@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > Ohhh cool... save us some work. That was the idea, although I won't be always able to test it all as extensively (although I'm starting to run it on a number of systems, see below). Right now, if you read my HOWTO and grab my kernel-2.4.SPEC file, you can do most of it as well. Again, I'm just repackaging it. On the other hand, I've had 0 issues installing from my RPMs that some others have had on this list. And I tried it out on stock RedHat 7.0 installs -- one clean, one that has been running Ext3 for 6 months. Both worked great. No support issues. Althoguh it's nothing other than the XFS CVS stuff plus a few select choices for mkinitrd (the same in PR-0.9, only rebuilt from SRPM) and modutils (rebuilt from RedHat 7.0.91 SRPM), as well as devfsd, ALSA and other updates. As far as my "interest" in XFS, it's total production (we're a UNIX-apps driven company, hence the kNFSd compatibility need). Once I spend about 2-3 months running various XFS CVS builds on non-production systems (like our various Linux workstations), I'll move to our main servers. I did this with Ext3 as well (adopted over 6 months ago after 3 months of prior testing). XFS is definately a better choice than Ext3 in the end (and already proven on Irix). > I'll give you mirror space at oss.sgi.com... well how about > linux-xfs.sgi.com, which is BTW a totally XFS box serving > the xfs web pages. Thanx. We'll work out the details off-list. If SGI wants, I'll strip out the "SmithConcepts" label stuff. It's just an unregistered fictious name I've been using since 1992 (that probably means I should make it official someday ;-). Heck, I'm better known as "thebs" anyway. > It would be best not to have a lot of sources for XFS kernel RPMs if > it isn't necessary. You can certainly put your stuff up on sourceforge > but linux-xfs.sgi.com has space. No, I'd prefer to be on linux-xfs.sgi.com itself, or at least distro/hardware integrator. SourceForge.NET is probably more for developers anyway, not "dumb" packagers like myself. E.g., VALinux.COM itself would be better choice than their SourceForget.NET site (not that I'm trying to get VA to mirror and they've been pro-Ext3, like RedHat, anyway). -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Mon Feb 26 10:56:02 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 10:55:52 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:17770 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 10:55:43 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA22439 for ; Mon, 26 Feb 2001 10:54:20 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA57093; Mon, 26 Feb 2001 12:54:08 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1QIr3j13308; Mon, 26 Feb 2001 13:53:03 -0500 Message-ID: <3A9AA60F.51238C4C@thebarn.com> Date: Mon, 26 Feb 2001 13:53:03 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: b.j.smith@ieee.org, thebs@theseus.com CC: Thomas Graichen , linux-xfs@oss.sgi.com Subject: Re: libxfs.h and the xfsprogs-devel package? <- Er, clarification ... References: <3A947AA9.F12C2572@bellsouth.net> <3A947A20.6E79C8BF@sgi.com> <3A98B6FE.1E056F6B@bellsouth.net> <3A9948DB.993500E2@bellsouth.net> <3A994CF2.6FB00D8F@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Bryan J. Smith" wrote: > Re: libxfs.h and the xfsprogs-devel package? <- Er, clarification > ... > > Thomas Graichen wrote: > > i am always using the cvs tree (or better my checked out copy of it > > :-) ... the xfsprogs-devel rpm you get by going into the cmd/xfsprogs > > dir and running "Makepgks verbose" (the same for the other rpms and > > dirs) > > No, I'm familiar with that. I already built: > > acl-1.0.1-0.i386.rpm > acl-devel-1.0.1-0.i386.rpm > attr-1.0.1-0.i386.rpm > attr-devel-1.0.1-0.i386.rpm > dmapi-0.1.1-0.i386.rpm > dmapi-devel-0.1.1-0.i386.rpm > xfsdump-1.0.2-0.i386.rpm > xfsprogs-1.1.2-0.i386.rpm > xfsprogs-devel-1.1.2-0.i386.rpm > > What I was talking about was building _unified_ RPM akin to > "xfs-cmds-1.0.5-1.i386.rpm" like in Pre-Release 0.9. That way I > don't have to modify Anaconda to know that all those RPMs replace > that one. No modifications to anaconda are necessary. added rpm's go in RedHat/base/comps and I believe xfsprogs obsolete xfs-cmds. > > > > As such, I just suggested putting a .spec file in the "cmd" CVS root > so you can. I tried merging spec/makefiles in an attempt to create > a new "xfs-cmds-*.i386.rpm" to no avail. > > -- TheBS > > -- > Bryan "TheBS" Smith, Engineer CONTACT INFO > *********************************************************** > Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) > Email: mailto:thebs@smithconcepts.com,thebs@theseus.com -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Feb 26 11:01:32 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 11:01:23 -0800 Received: from hermes.mixx.net ([212.84.196.2]:60938 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 26 Feb 2001 11:01:15 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id A133FF820 for ; Mon, 26 Feb 2001 20:01:13 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 48A7A2CA6F; Mon, 26 Feb 2001 20:01:13 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: typo & question Date: 26 Feb 2001 19:01:13 GMT Organization: innominate AG, Berlin, Germany Lines: 45 Distribution: local Message-ID: References: <3A9A9486.EF771870@thebarn.com> X-Trace: mate.bln.innominate.de 983214073 31530 10.0.0.31 (26 Feb 2001 19:01:13 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.2-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > Thomas Graichen wrote: >> first: >> there's a small typo in linux/Documentation/filesystems/xfs.txt >> logbufsize=value should be logbsize=value >> >> second: >> >> is the kiocluster option also honoured for an XFS root fs? >> i ask because at least the message "XFS (dev: x/y) mounting >> with kiobuf I/O" is not printed for the rootfs mount - haven't >> looked at the code yet - but maybe someone can say something >> about this off mind >> > Hmm good question. > Obviously the initial mount of the root fs does not use kio option. > Doing a mount -o remount ,kio should enable kio buf io on any already > mounted fs, > with hopefully no ill affects. > The next question I guess would be; is kio bufs used when the flag added > to the > fstab entry.... don't know... will have to try it. at least it says so: graichen@orange ~ % mount | grep xfs /dev/.../part3 on / type xfs (rw,kiocluster,logbufs=4,logbsize=32768) /dev/.../part6 on /data type xfs (rw,kiocluster,logbufs=4,logbsize=32768) graichen@orange ~ % but what really happens? i don't know - this is at least what comes out of the entries in fstab t p.s.: and don't forget my typo :-) -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Mon Feb 26 14:22:42 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 14:22:33 -0800 Received: from groucho.maths.monash.edu.au ([130.194.160.211]:42256 "EHLO groucho.maths.monash.edu.au") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 14:22:31 -0800 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id WAA05663 for linux-xfs@oss.sgi.com; Mon, 26 Feb 2001 22:22:19 GMT From: Robin Humble Message-Id: <200102262222.WAA05663@groucho.maths.monash.edu.au> Subject: Re: NFS 0 sizes bug, high nfsd load To: linux-xfs@oss.sgi.com Date: Tue, 27 Feb 2001 09:22:19 +1100 (EDT) In-Reply-To: <200102261735.f1QHZbe25954@jen.americas.sgi.com> from "Steve Lord" at Feb 26, 2001 11:35:37 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve writes: >NFS problem deleted - we will have to do some investigating there. ok - thanks. Re: bonnie++ results: >You are running into the journalling features of XFS big time here, try >using a larger number of files for reiserfs, it does not sync its >journal out to disk more than once a minute unless it fills it, and since >these are lots of empty files they take very little room in reiserfs. >ext2 is just manipulating memory and not doing disk I/O much at all in >this case. ah - ok. I understand the results now. Basically it sounds like default bonnie++ behaviour is being unrealistically nice to ext2/ReiserFS and unrealistically cruel to XFS :-) Perhaps a bonnie++ run with small but non-zero size files would be more realistic, and might force ReiserFS to do more work. I'll give that a go. Can I ask what the state of software RAID0 and RAID5 is? I note from the list archives that there has been some success, but it's not clear how stable things are. cheers, robin From owner-linux-xfs@oss.sgi.com Mon Feb 26 14:29:42 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 14:29:22 -0800 Received: from esparrall.udg.es ([130.206.124.16]:14977 "EHLO esparrall.udg.es") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 14:29:15 -0800 Received: from gcs by esparrall.udg.es with local (Exim 3.22 #1 (Debian)) id 14XW8P-0003x7-00 for ; Mon, 26 Feb 2001 23:28:49 +0100 Date: Mon, 26 Feb 2001 23:28:49 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: .config file for boot image creation Message-ID: <20010226232849.A15178@esparrall.udg.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello all, May I get the .config file used to build a kernel for the RedHat-XFS boot floppy? I would like to create one for Debian, as I would like to change my root partition to xfs. Well, I do not have too much idea how to do this, but... Thanks, Laszlo From owner-linux-xfs@oss.sgi.com Mon Feb 26 14:41:42 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 14:41:25 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:2921 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 14:41:12 -0800 Received: from eagdhcp-195-23.americas.sgi.com (128-162-195-179.americas.sgi.com [128.162.195.179]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA01131 for ; Mon, 26 Feb 2001 14:40:56 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (IDENT:sandeen@localhost.localdomain [127.0.0.1]) by eagdhcp-195-23.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f1QMlSA06207; Mon, 26 Feb 2001 16:47:28 -0600 Message-ID: <3A9ADD00.11A63254@sgi.com> Date: Mon, 26 Feb 2001 16:47:28 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: GCS CC: linux-xfs@oss.sgi.com Subject: Re: .config file for boot image creation References: <20010226232849.A15178@esparrall.udg.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing If you can get it from the RPM, take a look at ftp://oss.sgi.com/projects/xfs/download/PreRelease-0.9/RH7.0-SGI-XFS_PR/SRPMS/kernel24-2.4.0-0.43.4XFS.src.rpm and look at the various configs... if you can't extract it from the RPM on your debian machine, let me know and I'll grab it for you... (this is actually a 2.4.0-test11 kernel in this src.rpm) -Eric GCS wrote: > > Hello all, > > May I get the .config file used to build a kernel for the RedHat-XFS boot > floppy? I would like to create one for Debian, as I would like to change > my root partition to xfs. Well, I do not have too much idea how to do this, > but... > > Thanks, Laszlo From owner-linux-xfs@oss.sgi.com Mon Feb 26 16:41:34 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 16:41:23 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:38941 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 16:41:18 -0800 Received: from waco.engr.sgi.com ([163.154.18.95]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA02173 for ; Mon, 26 Feb 2001 16:41:17 -0800 (PST) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.11.0/8.11.0) id f1R0eAV02973 for linux-xfs@oss.sgi.com; Mon, 26 Feb 2001 16:40:10 -0800 Date: Mon, 26 Feb 2001 16:40:10 -0800 From: Ananth Ananthanarayanan Message-Id: <200102270040.f1R0eAV02973@waco.engr.sgi.com> Subject: TAKE - Delay Buffer Changes To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Significant part of this change is to employ standard linux IO daemons & paths to handle delalloc pages by attaching buffers to all pages. This also enables handling of sync()-type operation (changes yet to come) ... Date: Mon Feb 26 16:36:49 PST 2001 Workarea: waco.engr.sgi.com:/build1/ananth/xfs-tot The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88427a linux/mm/vmscan.c - 1.50 - No special cases to handle delalloc in swap or reclaim_page or page_launder. Only special handling is to not perform any I/O when called with GFP_PAGE_IO. linux/mm/page_alloc.c - 1.38 - No special checks are need to catch delalloc pages from being freed; if page is delay it has buffers, and there is a check already for that. linux/kernel/ksyms.c - 1.77 - Remove symbols from linux no longer used by xfs. linux/include/linux/mm.h - 1.50 - Remove page flag to mark delay; the associated buffer now has the flag. linux/include/linux/fs.h - 1.81 - Add a flag to buffers to mark it delay. linux/fs/buffer.c - 1.57 - Use a write_buffer helper function to write out delay buffers. linux/drivers/block/ll_rw_blk.c - 1.62 - Add a bug test so Delay buffers don't pass through. linux/drivers/scsi/scsi_merge.c - 1.25 - Fix a bug in printing the bh-chain; this should be submitted to the base kernel. linux/fs/xfs/xfs_log.c - 1.228 - Add PF_MEMALLOC to log sync'ing operation. This may be removed later if no more deadlocks are seen. linux/fs/xfs/linux/xfs_iops.c - 1.94 - Add a writepage routine that doesn't unlock the page on return; used by page_launder->try_to_free_buffers->write_buffer->writepage. linux/include/linux/page_buf.h - 1.76 - Prototype for writepage that doesn't unlock page on return. Other cleanups to reflect removal of page_cleaner_daemon. linux/kdb/modules/kdbm_pg.c - 1.29 - Display more fields in bh. linux/fs/pagebuf/page_buf.c - 1.59 linux/fs/pagebuf/page_buf_io.c - 1.56 - Primary change is to attach buffers to delalloc pages. Page cleaner deamon is no longer needed as linux IO daemons will see the buffers and perform conversions through write_buffer() -> writepage(). Also fix a bug in writepage() of a page containing EOF. Remove code associated with page_cleaner_daemon. From owner-linux-xfs@oss.sgi.com Mon Feb 26 18:11:24 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 18:11:14 -0800 Received: from mail3.mia.bellsouth.net ([205.152.144.15]:45460 "EHLO mail3.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 18:10:58 -0800 Received: from spruce (adsl-61-5-192.mia.bellsouth.net [208.61.5.192]) by mail3.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id VAA11062; Mon, 26 Feb 2001 21:10:25 -0500 (EST) From: "Juan Casero" To: "Russell Cattelan" Cc: "james rich" , Subject: RE: building 2.4.2 (with XFS) fails Date: Mon, 26 Feb 2001 21:02:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A9A7E44.ACA08130@thebarn.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Shortly after the message anouncing the release of the 2.4.2 code with the XFS patches on the CVS server I logged in to the CVS server and grabbed a copy. I performed the update as per the syntax below and I did get lots of output so something was happening. I admit to being something of a novice with CVS (nothing to be ashamed of really) but that might suggest there was something to update. My intention here is to be helpful though so don't take my comments as being smug wise cracks. I was genuiunely interested in helping the person who was having problems compiling the kernel. Cheers.... -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On Behalf Of Russell Cattelan Sent: Monday, February 26, 2001 11:03 AM To: Juan Casero Cc: james rich; linux-xfs@oss.sgi.com Subject: Re: building 2.4.2 (with XFS) fails Juan Casero wrote: > It's hard to understand why you are having this problem. I have not seen anything > like it > although I will say that there were a couple of occassions a few days ago when a > compile > of the previous kernel source from the SGI CVS server did fail on my box. I don't > recall > if the error was like yours though. On a much happier note I will say that I was > able to > compile the code for the 2.4.2 kernel source that I downloaded from their CVS > server. > One thing you might be failing to do is update your cvs tree. Make sure you issue > the following > commands to get the source tree > > $ cvs -z3 checkout linux-2.4-xfs > $ cvs -z3 update -d > > It is important that you not forget the second of the two commands above. I myself > am > relatively new to using CVS so I can't explain why but I am almost certain that the > update > is absolutely important for getting the latest source code. There should be no reason a 'cvs update' should be run immediately after a 'cvs checkout' If anybody has run that shows cvs update in this case producing output let me know. > > > Good Luck.... > > Juan Casero > casero@bellsouth.net > > james rich wrote: > > > On Sat, 24 Feb 2001, Juan Casero wrote: > > > > > The messages below seem to indicate there are some references in char.o to > > > functions that have not been defined. These kinds of errors usually occur at > > > the link stage of a compilation. Instead of patching a stock kernel use the > > > > > > instructions available at oss.sgi.com/projects/xfs to login to their CVS > > > server > > > and download the source code that way. After that you can make a sym link > > > /usr/src/linux-2.4-xfs/linux <-- /usr/src/linux and then recompile the code. > > > I am pretty sure you'll have no problems getting it to build. > > > > This occurred after pulling the CVS tree last night and tried it again > > this morning. I'l' try deleting my entire tree and do the CVS pull again > > (takes a *long* time over my modem :( ). > > > > James Rich > > james.rich@m.cc.utah.edu -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Feb 26 19:05:15 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 19:05:06 -0800 Received: from mail0.mia.bellsouth.net ([205.152.144.12]:52623 "EHLO mail0.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 19:04:44 -0800 Received: from cedar.alpine.com (adsl-61-5-192.mia.bellsouth.net [208.61.5.192]) by mail0.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id WAA06229 for ; Mon, 26 Feb 2001 22:04:31 -0500 (EST) From: Juan Casero To: Subject: XFS ready for primte time? Date: Mon, 26 Feb 2001 22:18:20 -0500 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: <01022622182000.12545@cedar.alpine.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have read the caveats posted on the SGI OSS web site regarding XFS but I still want to get some opinions from the members on the list (especially the developers) regarding the readiness of XFS for some serious work. I have started working for a web hosting firm. This company uses a large number of Linux servers to host thousands of web sites for thousands of customers. I was thinking that XFS could be really helpful for us given the large number of users and files. Currently all the systems use ext2 file systems. My questions is simple; how long before the XFS developers feel it might be safe to put XFS to in an environment like this? Certainly the journaling features of XFS is the most important thing we need but there is also the performace issue to consider (I believe XFS is slightly faster than ext2) and the maturity of the code. If XFS is not currently recommended for a web hosting service (as the SGI OSS web pages seem to suggest) then when (at the release 1.0 or later ?) is it likely to be given the green light for this? Thanks.... -- Juan Casero casero@bellsouth.net From owner-linux-xfs@oss.sgi.com Mon Feb 26 19:05:15 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 19:05:06 -0800 Received: from mail0.mia.bellsouth.net ([205.152.144.12]:19344 "EHLO mail0.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 19:04:56 -0800 Received: from cedar.alpine.com (adsl-61-5-192.mia.bellsouth.net [208.61.5.192]) by mail0.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id WAA06370 for ; Mon, 26 Feb 2001 22:04:40 -0500 (EST) From: Juan Casero To: Subject: XFS ready for primte time? Date: Mon, 26 Feb 2001 22:28:09 -0500 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: <01022622182000.12545@cedar.alpine.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have read the caveats posted on the SGI OSS web site regarding XFS but I still want to get some opinions from the members on the list (especially the developers) regarding the readiness of XFS for some serious work. I have started working for a web hosting firm. This company uses a large number of Linux servers to host thousands of web sites for thousands of customers. I was thinking that XFS could be really helpful for us given the large number of users and files. Currently all the systems use ext2 file systems. My questions is simple; how long before the XFS developers feel it might be safe to put XFS to in an environment like this? Certainly the journaling features of XFS is the most important thing we need but there is also the performace issue to consider (I believe XFS is slightly faster than ext2) and the maturity of the code. If XFS is not currently recommended for a web hosting service (as the SGI OSS web pages seem to suggest) then when (at the release 1.0 or later ?) is it likely to be given the green light for this? Thanks.... -- Juan Casero casero@bellsouth.net From owner-linux-xfs@oss.sgi.com Mon Feb 26 19:07:45 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 19:07:36 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11042 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 19:07:19 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA09745 for ; Mon, 26 Feb 2001 19:16:52 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA18873; Tue, 27 Feb 2001 14:06:00 +1100 (EST) Date: Tue, 27 Feb 2001 14:06:00 +1100 (EST) From: Nathan Scott Message-Id: <200102270306.OAA18873@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, mann@sgi.com Subject: TAKE - root quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This fixes the problem Thomas reported about not being able to mount root XFS filesystems with quota enabled (see quotaon.8). The rootdev changes also affect xfs_force_shutdown() - the "if" test in xfs_rw.c, line 436, should now be doing the right thing. (but I think the cmn_err call on the next line will not panic as expected? Mark? - need an extension to cmn_err to handle CE_PANIC?). cheers. Date: Mon Feb 26 18:43:46 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88444a linux/fs/dquot.c - 1.25 - push the 2^16 uid/gid check down below the sb quotactl vector so that xfs gets through with int-sized uids. linux/fs/xfs/xfs_log_recover.c - 1.201 - use updated readonly test function name, fix spacing. linux/fs/xfs/xfs_qm.c - 1.61 linux/fs/xfs/linux/xfs_lrw.h - 1.16 linux/fs/xfs/linux/xfs_lrw.c - 1.76 - like recovery, the in-kernel xfs quotacheck needs to run on a readonly-mounted root fs with (temporary) write access. linux/fs/xfs/linux/xfs_globals.c - 1.23 linux/fs/xfs/linux/xfs_globals.h - 1.5 - remove rootdev, twas wrong (uninited). linux/fs/xfs/linux/xfs_linux.h - 1.42 - make rootdev point to the real root device. cmd/quota/quotaon.c - 1.9 - fixups to allow quota on the root filesystem to be enabled. From owner-linux-xfs@oss.sgi.com Mon Feb 26 19:57:06 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 19:56:47 -0800 Received: from ubr-95.237.251.oviedo.cfl.rr.com ([24.95.237.251]:11252 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 19:56:25 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id WAA13423; Mon, 26 Feb 2001 22:49:09 -0500 Message-ID: <3A9B26E9.DA6DF6DB@ieee.org> Date: Mon, 26 Feb 2001 23:02:49 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juan Casero CC: linux-xfs@oss.sgi.com Subject: Re: XFS ready for primte time? References: <01022622182000.12545@cedar.alpine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Juan Casero wrote: > I have read the caveats posted on the SGI OSS web site regarding > XFS but I still want to get some opinions from the members on the > list (especially the developers) regarding the readiness of XFS > for some serious work ... ... Currently all the systems use > ext2 file systems. My questions is simple; how long before the XFS > developers feel it might be safe to put XFS to in an environment > like this? Certainly the journaling features of XFS is the most > important thing we need but there is also the performace issue to > consider (I believe XFS is slightly faster than ext2) and the > maturity of the code. As a non-developer/sysadmin with about 9 months of Ext3 usage (6 months on production fileservers), and a recent adopter of XFS (testing right now), I can offer the following pointers and advise: 1. Personal testing and experience is the only way to find out if something is _right_for_you_. Again, I tested Ext3 for 3 months on less important servers and workstations before adopting it on my heavily used workstations and main file servers. 2. Your JFS options will be limited by your system application and kernel (even GLibC). One JFS may work great for some applications (e.g., ReiserFS for Linux workstations), but be a total no-no on others (e.g., ReiserFS for Linux NFS fileservers). And some JFS are kernel/GLibC-dependent (Ext3 is 2.2-only right now, and kernel 2.4 + GLibC 2.2 -- i.e. RedHat 7 -- is recommended for XFS). 3. If you want my "'biased', 'quickie' breakdown" of the 4 major JFS for Linux -- they are as follows: Tweedie@RedHat's Ext3 is remedially "evolutionary" (fully reversable, it's Ext2 with journaling slapped on) Namesys' ReiserFS is very "revolutionary" for Linux (and hasn't been proven anywhere but on Linux, if that) SGI's XFS is a port to Linux (powerful, feature-rich yet still legacy UNIX compatible) IBM's JFS seems to be no sparsely available? (Possible IBM hardware/support-focused?) 4. Performance is a non-issue for web servers IMHO Unless you have a fast connection, or a serious database back-end, your bottleneck is not going to be the filesystem, but the Internet connection. I could be wrong, but I wouldn't worry about performance. With that said, XFS is the fastest of the four JFS in most apps, and Ext3 is just as fast as Ext2 for _reads_. So its depends on how much disk I/O and static v. dynamic content you will have (or be generating in the case of the latter). 5. Personal Experiences - NFS (and SMB) Fileservers with Linux 2.2 + Ext3 + NFS3 I have production NFS fileservers, including Linux (which are also SMB fileservers via Samba). As such ReiserFS is NOT an option (not even with the 2.4.x patches for kNFSd IMHO). For kernel 2.2, I ended up adopting Ext3 (along with the NFS3 backport to 2.2) for a good, solid and reliable JFS. I _always_ run in the V1 mode (full data journaling) instead of trying to use the newer meta-data-only modes. That also means write performance is effectively _halfed_ with Ext3 (for reads, Ext3 = Ext2). [ It's definately NOT the performance route for fileservers! ] - Kernel 2.4 limits your options, but introduces XFS Now when it comes to kernel 2.4, Ext3 is finally getting ported by Tweedie (the man is bogged down with a crapload from my understanding -- and waited for the official 2.4.0 release before starting to address it, which is probably smart). That leaves ReiserFS and XFS. Unlike XFS, ReiserFS is also supported on kernel 2.2 (albeit somewhat limited in features though). - ReiserFS _may_ work for you Now you may be able to get away with ReiserFS. It is designed to be dynamically self-upgrading (including from Ext2) which may be a nice, gradual way for you to upgrade over time (making lesser important partitions ReiserFS, and converting others to Ext2 later). Most of ReiserFS' issues (other than the fact that its a from-the-ground-up filesystem and relatively new compared to Ext2/Ext3 and XFS) is with NFS services. If you aren't going to use kNFSd on your web servers (for sharing information between each other), then it might be a viable option. - XFS is the 2.4 "bomb" and its most feature rich/working on Linux On the other hand, XFS is here for kernel 2.4 and has the richest feature set, the most capabilities working _now_ in 2.4, and I have a bunch of XFS-enable kernel 2.4.2 and support RPMs "ready to plop down" on a stock RedHat 7.0 install (URL below). As such, it might be _easiest_ to just setup a couple of test RedHat 7.0 + my XFS RPMs and run for a couple of months (FYI, I plan to release new XFS "snapshot" RPM releases from CVS every week or two) serving out your least critical stuff. - But only personal, first-hand testing will tell you Again, you need to test it yourself, in your environment, to see if it works for you. After 3 months, you'll know if it works for you. -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Mon Feb 26 20:00:35 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 20:00:16 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:10619 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 20:00:12 -0800 Received: from sherman.melbourne.sgi.com ([134.14.55.175]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA09670 for ; Mon, 26 Feb 2001 20:00:06 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA02807; Tue, 27 Feb 2001 14:59:03 +1100 Date: Tue, 27 Feb 2001 14:59:03 +1100 From: Keith Owens Message-Id: <200102270359.OAA02807@sherman.melbourne.sgi.com> Subject: TAKE - Use mkdep from 2.4.2-ac kernel To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Replace the XFS specific changes to mkdep with the version of mkdep from 2.4.2-ac5. This version of mkdep will eventually appear in base 2.4 kernels, when AC sends it to Linus. Date: Mon Feb 26 19:57:03 PST 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/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:88448a linux/scripts/mkdep.c - 1.12 linux/Rules.make - 1.12 linux/Makefile - 1.82 linux/fs/xfs/Makefile - 1.116 linux/fs/xfs/linux/Makefile - 1.39 linux/fs/xfs/dmapi/Makefile - 1.9 linux/fs/xfs/support/Makefile - 1.5 From owner-linux-xfs@oss.sgi.com Mon Feb 26 20:12:35 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 20:12:16 -0800 Received: from mail5.mia.bellsouth.net ([205.152.144.17]:16320 "EHLO mail5.mia.bellsouth.net") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 20:12:00 -0800 Received: from cedar.alpine.com (adsl-61-5-192.mia.bellsouth.net [208.61.5.192]) by mail5.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id XAA13432; Mon, 26 Feb 2001 23:17:52 -0500 (EST) From: Juan Casero To: b.j.smith@ieee.org, thebs@theseus.com, "Bryan J. Smith" Subject: Re: XFS ready for primte time? Date: Mon, 26 Feb 2001 23:04:48 -0500 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="us-ascii" Cc: linux-xfs@oss.sgi.com References: <01022622182000.12545@cedar.alpine.com> <3A9B26E9.DA6DF6DB@ieee.org> In-Reply-To: <3A9B26E9.DA6DF6DB@ieee.org> MIME-Version: 1.0 Message-Id: <01022623044800.00781@cedar.alpine.com> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ok. Thanks for the info. I use XFS on my home systems (I got a home LAN with some NFS mounting and a IP masquerading to the internet through a xDSL modem) and it has worked exceedingly well so far. For workstation use I will go with XFS from here on out. I will take your advice and set up some non essential systems in the office with different file systems and give them each a try. I used ReiserFS briefly some months ago and while it seemed ok I was not terribly excited about it. At the time it was hard to find ReiserFS patches for the curent releases of the linux kernel so I finally just gave up on ReiserFS and moved back to ext2. This list and the active development of XFS are what convinced me to try a JFS again. So far I am very satisfied with XFS. Thanks for the info. Juan. On Monday 26 February 2001 23:02, Bryan J. Smith wrote: > Juan Casero wrote: > > I have read the caveats posted on the SGI OSS web site regarding > > XFS but I still want to get some opinions from the members on the > > list (especially the developers) regarding the readiness of XFS > > for some serious work ... ... Currently all the systems use > > ext2 file systems. My questions is simple; how long before the XFS > > developers feel it might be safe to put XFS to in an environment > > like this? Certainly the journaling features of XFS is the most > > important thing we need but there is also the performace issue to > > consider (I believe XFS is slightly faster than ext2) and the > > maturity of the code. > > As a non-developer/sysadmin with about 9 months of Ext3 usage (6 > months on production fileservers), and a recent adopter of XFS > (testing right now), I can offer the following pointers and advise: > > 1. Personal testing and experience is the only way to find out if > something is _right_for_you_. Again, I tested Ext3 for 3 months on > less important servers and workstations before adopting it on my > heavily used workstations and main file servers. > > 2. Your JFS options will be limited by your system application and > kernel (even GLibC). One JFS may work great for some applications > (e.g., ReiserFS for Linux workstations), but be a total no-no on > others (e.g., ReiserFS for Linux NFS fileservers). And some JFS are > kernel/GLibC-dependent (Ext3 is 2.2-only right now, and kernel 2.4 + > GLibC 2.2 -- i.e. RedHat 7 -- is recommended for XFS). > > 3. If you want my "'biased', 'quickie' breakdown" of the 4 major > JFS for Linux -- they are as follows: > > Tweedie@RedHat's Ext3 is remedially "evolutionary" > (fully reversable, it's Ext2 with journaling slapped on) > > Namesys' ReiserFS is very "revolutionary" for Linux > (and hasn't been proven anywhere but on Linux, if that) > > SGI's XFS is a port to Linux > (powerful, feature-rich yet still legacy UNIX compatible) > > IBM's JFS seems to be no sparsely available? > (Possible IBM hardware/support-focused?) > > 4. Performance is a non-issue for web servers IMHO > > Unless you have a fast connection, or a serious database back-end, > your bottleneck is not going to be the filesystem, but the Internet > connection. I could be wrong, but I wouldn't worry about > performance. > > With that said, XFS is the fastest of the four JFS in most apps, and > Ext3 is just as fast as Ext2 for _reads_. So its depends on how > much disk I/O and static v. dynamic content you will have (or be > generating in the case of the latter). > > 5. Personal Experiences > > - NFS (and SMB) Fileservers with Linux 2.2 + Ext3 + NFS3 > > I have production NFS fileservers, including Linux (which are also > SMB fileservers via Samba). As such ReiserFS is NOT an option (not > even with the 2.4.x patches for kNFSd IMHO). For kernel 2.2, I > ended up adopting Ext3 (along with the NFS3 backport to 2.2) for a > good, solid and reliable JFS. I _always_ run in the V1 mode (full > data journaling) instead of trying to use the newer meta-data-only > modes. That also means write performance is effectively _halfed_ > with Ext3 (for reads, Ext3 = Ext2). [ It's definately NOT the > performance route for fileservers! ] > > - Kernel 2.4 limits your options, but introduces XFS > > Now when it comes to kernel 2.4, Ext3 is finally getting ported by > Tweedie (the man is bogged down with a crapload from my > understanding -- and waited for the official 2.4.0 release before > starting to address it, which is probably smart). That leaves > ReiserFS and XFS. Unlike XFS, ReiserFS is also supported on kernel > 2.2 (albeit somewhat limited in features though). > > - ReiserFS _may_ work for you > > Now you may be able to get away with ReiserFS. It is designed to be > dynamically self-upgrading (including from Ext2) which may be a > nice, gradual way for you to upgrade over time (making lesser > important partitions ReiserFS, and converting others to Ext2 > later). Most of ReiserFS' issues (other than the fact that its a > from-the-ground-up filesystem and relatively new compared to > Ext2/Ext3 and XFS) is with NFS services. If you aren't going to use > kNFSd on your web servers (for sharing information between each > other), then it might be a viable option. > > - XFS is the 2.4 "bomb" and its most feature rich/working on Linux > > On the other hand, XFS is here for kernel 2.4 and has the richest > feature set, the most capabilities working _now_ in 2.4, and I have > a bunch of XFS-enable kernel 2.4.2 and support RPMs "ready to plop > down" on a stock RedHat 7.0 install (URL below). As such, it might > be _easiest_ to just setup a couple of test RedHat 7.0 + my XFS RPMs > and run for a couple of months (FYI, I plan to release new XFS > "snapshot" RPM releases from CVS every week or two) serving out your > least critical stuff. > > - But only personal, first-hand testing will tell you > > Again, you need to test it yourself, in your environment, to see if > it works for you. After 3 months, you'll know if it works for you. > > -- TheBS -- Juan Casero casero@bellsouth.net From owner-linux-xfs@oss.sgi.com Mon Feb 26 21:09:56 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 21:09:36 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:60479 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 21:09:06 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA28576 for ; Mon, 26 Feb 2001 21:08:00 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA27466; Tue, 27 Feb 2001 16:08:03 +1100 Date: Tue, 27 Feb 2001 16:08:03 +1100 From: Keith Owens Message-Id: <200102270508.QAA27466@sherman.melbourne.sgi.com> Subject: TAKE - Sync 2.4.2-xfs and kdb v1.8 To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Sync 2.4.2-xfs and kdb v1.8 Date: Mon Feb 26 21:07:04 PST 2001 Workarea: sherman.melbourne.sgi.com:/build/kaos/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:88454a linux/arch/i386/kernel/msr.c - 1.7 linux/include/linux/kdb.h - 1.15 linux/kdb/kdbmain.c - 1.18 linux/Documentation/kdb/kdb.mm - 1.11 linux/arch/i386/kdb/kdbasupport.c - 1.13 linux/kernel/kallsyms.c - 1.9 linux/include/linux/kallsyms.h - 1.7 linux/kdb/ChangeLog - 1.6 From owner-linux-xfs@oss.sgi.com Mon Feb 26 23:05:16 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 23:04:56 -0800 Received: from cc19815-a.zwoll1.ov.nl.home.com ([212.204.138.247]:49144 "HELO wisdom.myplace.net") by oss.sgi.com with SMTP id ; Mon, 26 Feb 2001 23:04:45 -0800 Received: from ws1 (unknown [192.168.1.15]) by wisdom.myplace.net (Postfix) with SMTP id 34AFE142 for ; Tue, 27 Feb 2001 08:04:44 +0100 (CET) Message-ID: <003e01c0a0d6$fefb4720$0f01a8c0@myplace.net> From: "Bas" To: Subject: Linux 2.4.2 - XFS Date: Tue, 27 Feb 2001 08:04:42 -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.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I downloaded the tree through CVS, but anybody got any idea about which patches are installed or is there a way for me to check ? I'm not familiar with CVS... For instance: are the latest reiserfs patches applied or is this kernel the default kernel with xfs added - if yes, can I get a patch (only a patch) for 2.4.2 to add xfs ? I thought the best place to get answers to questions like these was here... Thanks, Bas From owner-linux-xfs@oss.sgi.com Mon Feb 26 23:24:56 2001 Received: by oss.sgi.com id ; Mon, 26 Feb 2001 23:24:47 -0800 Received: from nic-31-c12-219.mn.mediaone.net ([24.31.12.219]:41740 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Mon, 26 Feb 2001 23:24:37 -0800 Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130]) by lupo.thebarn.com (8.11.2/8.11.0) with ESMTP id f1R7OTf61010; Tue, 27 Feb 2001 01:24:29 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <3A9B5634.150D701D@thebarn.com> Date: Tue, 27 Feb 2001 01:24:37 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bas CC: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.2 - XFS References: <003e01c0a0d6$fefb4720$0f01a8c0@myplace.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Bas wrote: > Hi, > > I downloaded the tree through CVS, but anybody got any idea about which > patches are installed or is there a way for me to check ? I'm not familiar > with CVS... The cvs tree is only linux 2.4.2 + kbd 1.8 + XFS current > > > For instance: are the latest reiserfs patches applied or is this kernel the > default kernel with xfs added - if yes, can I get a patch (only a patch) for > 2.4.2 to add xfs ? I thought the best place to get answers to questions like > these was here... Somewhat current patches are keep at ftp://oss.sgi.com/projects/xfs/download/patches. The patches are primarily snapshots of the cvs tree at any given time, and should be used to "seed" a cvs tree. (cvs checkouts can take a long time) Since the RCS version numbers are the only way at the moment for the XFS development team to track exactly what people are running cvs checkouts are recommended. > > > Thanks, > Bas From owner-linux-xfs@oss.sgi.com Tue Feb 27 00:21:37 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 00:21:18 -0800 Received: from hermes.mixx.net ([212.84.196.2]:43532 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 27 Feb 2001 00:21:05 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 39034F80C for ; Tue, 27 Feb 2001 09:21:03 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id F1F702CA6F; Tue, 27 Feb 2001 09:21:02 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: loop-6 and the XFS tree Date: 27 Feb 2001 08:21:02 GMT Organization: innominate AG, Berlin, Germany Lines: 32 Distribution: local Message-ID: X-Trace: mate.bln.innominate.de 983262062 875 10.0.0.31 (27 Feb 2001 08:21:02 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.2-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing just tried to apply the loop-6 patch to the XFS tree (which works fine with plain 2.4.2) i ran into the following: kgcc -D__KERNEL__ -I/tmp/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -march=i686 -c -o rd.o rd.c rd.c: In function `rd_init': rd.c:408: warning: passing arg 2 of `blk_queue_make_request' from incompatible pointer type kgcc -D__KERNEL__ -I/tmp/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -march=i686 -DEXPORT_SYMTAB -c loop.c loop.c: In function `loop_make_request': loop.c:451: too few arguments to function `generic_make_request' loop.c: In function `loop_init': loop.c:954: warning: passing arg 2 of `blk_queue_make_request' from incompatible pointer type make[3]: *** [loop.o] Error 1 make[3]: Leaving directory `/tmp/linux/drivers/block' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/tmp/linux/drivers/block' make[1]: *** [_subdir_block] Error 2 make[1]: Leaving directory `/tmp/linux/drivers' make: *** [_dir_drivers] Error 2 ... and because i think jens is lurking around here i try to ask first before looking into it ... maybe he already has a fix handy thanks in advance t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Tue Feb 27 06:40:10 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 06:39:52 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:56072 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 06:39:47 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.22 #4) id 14XlH2-0001nd-00; Tue, 27 Feb 2001 15:38:44 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14XlGx-0004YA-00; Tue, 27 Feb 2001 15:38:39 +0100 Date: Tue, 27 Feb 2001 15:38:39 +0100 From: Jens Axboe To: Thomas Graichen Cc: linux-xfs@oss.sgi.com Subject: Re: loop-6 and the XFS tree Message-ID: <20010227153839.D16652@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from news-innominate.list.sgi.xfs@innominate.de on Tue, Feb 27, 2001 at 08:21:02AM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Feb 27 2001, Thomas Graichen wrote: > just tried to apply the loop-6 patch to the XFS tree (which works > fine with plain 2.4.2) i ran into the following: > > kgcc -D__KERNEL__ -I/tmp/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -march=i686 -c -o rd.o rd.c > rd.c: In function `rd_init': > rd.c:408: warning: passing arg 2 of `blk_queue_make_request' from incompatible pointer type > kgcc -D__KERNEL__ -I/tmp/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -march=i686 -DEXPORT_SYMTAB -c loop.c > loop.c: In function `loop_make_request': > loop.c:451: too few arguments to function `generic_make_request' > loop.c: In function `loop_init': > loop.c:954: warning: passing arg 2 of `blk_queue_make_request' from incompatible pointer type > make[3]: *** [loop.o] Error 1 > make[3]: Leaving directory `/tmp/linux/drivers/block' > make[2]: *** [first_rule] Error 2 > make[2]: Leaving directory `/tmp/linux/drivers/block' > make[1]: *** [_subdir_block] Error 2 > make[1]: Leaving directory `/tmp/linux/drivers' > make: *** [_dir_drivers] Error 2 > > ... and because i think jens is lurking around here i try to > ask first before looking into it ... maybe he already has > a fix handy Yeah, the lurker, that's me :-) Anways, change the generic_make_request in loop to something like: generic_make_request(rw, bh, NULL, 0, 0, 0); return 0; and loop_make_request definition to: static int loop_make_request(request_queue_t *q, int rw, struct buffer_head *rbh, struct kio_buf *kio, kdev_t dev, unsigned long block, size_t bsize) and it should work. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Tue Feb 27 11:44:34 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 11:44:24 -0800 Received: from jeremi.jeremi.pl ([212.160.232.2]:51602 "EHLO jeremi.jeremi.pl") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 11:44:15 -0800 Received: from localhost (linux-xfs@localhost) by jeremi.jeremi.pl (8.11.0/8.11.0) with ESMTP id f1RLjiY03683; Tue, 27 Feb 2001 22:45:44 +0100 Date: Tue, 27 Feb 2001 22:45:44 +0100 (CET) From: To: lord@sgi.com cc: linux-xfs@oss.sgi.com Subject: Re: Hardware fault intolerance... In-Reply-To: <1101.212.160.232.15.983306572.squirrel@mail.jeremi.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 27 Feb 2001, Irresponsible & Crazy wrote: > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hda: dma_intr: error=0x40{UncorrectableError},LBAsect=1877374,sector=1877304 > end_request: I/O error, dev 03:01 (hda) , sector 1877304 > end_pg_buffer_io_async not uptodate 0 page 0xc1032d68 > kernel BUG at page_buf_io.c:896! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] > EFLAGS: 00010092 > eax: 00000021 > ebx: c0dbf480 > ecx: c3856000 > edx: 00000001 > esi: c1032d68 > edi: 00000008 > ebp: 00000000 > esp: c027bea8 > ds: 0018 > es: 0018 > ss: 0018 > Process swapper (pid:0, stacppage=c027b000) > Stack: > c023f9c5 c023fb07 00000380 c0dbf480 c11483a0 00000008 00000000 c01c87c3 > c0dbf480 00000000 c11483a0 00000246 c114c060 00000040 c01e3044 c11483a0 > 00000000 c02cec70 c0274c60 c02ceb80 00000008 c01e6ddd 00000000 c114c060 > Call trace: (brackets went away) > c01c87c3 c01e3044 c01e6ddd c01e3bcb c01e7b64 c01e99a4 c01e4957 > c01e7ac0 c010a01d c010a187 c0107160 c0108ea0 c0107160 c0107183 c01071da > c0105000 c0100191 > Code: > 0f 0b 83 c4 0c 8d 76 00 9c 5f fa b8 02 00 00 00 0f b3 43 18 > Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing > (and thats all) I've restarted and ran test once more and when i dd (nomen omen) scsi_debug.c ;) into dev/null i have that oops again with everything identical except ebx ecx esi and few values in stack Hmm my mailer died (netscape 6) whet reply was being send and probably attachment didn't make it.If you lack something notify me. Filip From owner-linux-xfs@oss.sgi.com Tue Feb 27 12:03:04 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 12:02:54 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:58688 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 12:02:39 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA03201 for ; Tue, 27 Feb 2001 12:02:36 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA53295 for ; Tue, 27 Feb 2001 14:01:20 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1RK0Ej18686 for ; Tue, 27 Feb 2001 15:00:14 -0500 Message-ID: <3A9C074D.9C3EC60C@thebarn.com> Date: Tue, 27 Feb 2001 15:00:14 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Testing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ok this is a real test of the new mail route. If this works this should be the only test message if is doesn't work.... well then you never saw anything. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Tue Feb 27 13:12:44 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 13:12:34 -0800 Received: from is.rice.edu ([128.42.42.24]:65416 "EHLO is.rice.edu") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 13:12:12 -0800 Received: from is.rice.edu (penguin.is.rice.edu [128.42.42.201]) by is.rice.edu (8.9.0/8.9.0) with SMTP id PAA18743 for ; Tue, 27 Feb 2001 15:12:10 -0600 (CST) Message-Id: <200102272112.PAA18743@is.rice.edu> Date: Tue, 27 Feb 2001 21:15:09 -0000 To: Subject: not a valid block device From: X-Mailer: TWIG 2.5.1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I am in a bind, and I feel like I am really close to a solution, but I can't wrap my brain around it. Anyways, here is my situation. I removed two disks off of an Indigo2. They were formatted with the SGI XFS filesystem. I have a RedHat 6.2 system that I needed to put the disks onto. I followed all of the instructions at http://linux-xfs.sgi.com/projects/xfs/pr_rpm.html, and everything went smoothly. I rebooted with the XFS kernel, and I don't receive any error messages. I load the kernel module for my SCSI adapter, and everything works fine. I used fdisk to get a look at the partition map for the drives, and they look like this: Script started on Tue Feb 27 15:03:29 2001 [root@afni arnold]# /sbin/fdisk /dev/sda Command (m for help): p Disk /dev/sda (SGI disk label): 10 heads, 320 sectors, 11201 cylinders Units = cylinders of 3200 * 512 bytes ----- partitions ----- Device Info Start End Sectors Id System /dev/sda8 2 11201 35839574 a SGI xfs /dev/sda9 0 1 4096 0 SGI volhdr /dev/sda11 0 11201 35843670 6 SGI volume ----- bootinfo ----- Bootfile: /unix ----- directory entries ----- Command (m for help): q Script started on Tue Feb 27 15:04:23 2001 [root@afni arnold]# /sbin/fdisk /dev/sdb Command (m for help): p Disk /dev/sdb (SGI disk label): 10 heads, 218 sectors, 8188 cylinders Units = cylinders of 2180 * 512 bytes ----- partitions ----- Device Info Start End Sectors Id System /dev/sdb8 2 8188 17845904 a SGI xfs /dev/sdb9 0 1 4096 0 SGI volhdr /dev/sdb11 0 8188 17850000 6 SGI volume ----- bootinfo ----- Bootfile: /unix ----- directory entries ----- Command (m for help): q So, I can see the disks. However, when I try to mount them, my system returns the error: [root@afni arnold]# /bin/mount -t xfs /dev/sda8 /mnt/disk2 mount: /dev/sda8 is not a valid block device an lsmod shows: [root@afni arnold]# /sbin/lsmod Module Size Used by vfat 13397 0 (autoclean) fat 39567 0 (autoclean) [vfat] xfs 429502 0 (autoclean) (unused) pagebuf 42047 0 (autoclean) [xfs] aic7xxx 140890 0 3c59x 24785 1 (autoclean) es1371 27339 0 soundcore 6614 5 [es1371] ac97_codec 8448 0 [es1371] For documentation purposes, here is my kernel version: [root@afni arnold]# uname -a Linux afni 2.4.0-XFS_BETA_4 #1 Tue Nov 28 08:08:58 CST 2000 i686 unknown I'd appreciate any thoughts anyone might have. From owner-linux-xfs@oss.sgi.com Tue Feb 27 13:18:24 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 13:18:14 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:58694 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 13:18:08 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA02934 for ; Tue, 27 Feb 2001 13:17:03 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA961805; Tue, 27 Feb 2001 15:16:50 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA05913; Tue, 27 Feb 2001 15:16:50 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1RLHZx01611; Tue, 27 Feb 2001 15:17:35 -0600 Message-Id: <200102272117.f1RLHZx01611@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: arnold@is.rice.edu cc: linux-xfs@oss.sgi.com Subject: Re: not a valid block device In-Reply-To: Message from of "Tue, 27 Feb 2001 21:15:09 GMT." <200102272112.PAA18743@is.rice.edu> Date: Tue, 27 Feb 2001 15:17:35 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Did you build SGI partition table support into your kernel? Down at the bottom of the filesystems menu in the kernel config interfaces is a partition types menu, in here you can add SGI partition support. I suspect the kernels we ship do not have it on. Steve > > Hi, > > I am in a bind, and I feel like I am really close to a solution, but I can't > wrap my brain around it. Anyways, here is my situation. I removed two > disks off of an Indigo2. They were formatted with the SGI XFS filesystem. > I have a RedHat 6.2 system that I needed to put the disks onto. I followed > all of the instructions at http://linux-xfs.sgi.com/projects/xfs/pr_rpm.html, > and everything went smoothly. I rebooted with the XFS kernel, and I don't > receive any error messages. I load the kernel module for my SCSI adapter, > and everything works fine. I used fdisk to get a look at the partition map > for the drives, and they look like this: > > Script started on Tue Feb 27 15:03:29 2001 > [root@afni arnold]# /sbin/fdisk /dev/sda > > Command (m for help): p > > Disk /dev/sda (SGI disk label): 10 heads, 320 sectors, 11201 cylinders > Units = cylinders of 3200 * 512 bytes > > ----- partitions ----- > Device Info Start End Sectors Id System > /dev/sda8 2 11201 35839574 a SGI xfs > /dev/sda9 0 1 4096 0 SGI volhdr > /dev/sda11 0 11201 35843670 6 SGI volume > ----- bootinfo ----- > Bootfile: /unix > ----- directory entries ----- > > Command (m for help): q > > > Script started on Tue Feb 27 15:04:23 2001 > [root@afni arnold]# /sbin/fdisk /dev/sdb > > Command (m for help): p > > Disk /dev/sdb (SGI disk label): 10 heads, 218 sectors, 8188 cylinders > Units = cylinders of 2180 * 512 bytes > > ----- partitions ----- > Device Info Start End Sectors Id System > /dev/sdb8 2 8188 17845904 a SGI xfs > /dev/sdb9 0 1 4096 0 SGI volhdr > /dev/sdb11 0 8188 17850000 6 SGI volume > ----- bootinfo ----- > Bootfile: /unix > ----- directory entries ----- > > Command (m for help): q > > So, I can see the disks. However, when I try to mount them, my system return > s > the error: > > [root@afni arnold]# /bin/mount -t xfs /dev/sda8 /mnt/disk2 > mount: /dev/sda8 is not a valid block device > > an lsmod shows: > > [root@afni arnold]# /sbin/lsmod > Module Size Used by > vfat 13397 0 (autoclean) > fat 39567 0 (autoclean) [vfat] > xfs 429502 0 (autoclean) (unused) > pagebuf 42047 0 (autoclean) [xfs] > aic7xxx 140890 0 > 3c59x 24785 1 (autoclean) > es1371 27339 0 > soundcore 6614 5 [es1371] > ac97_codec 8448 0 [es1371] > > For documentation purposes, here is my kernel version: > [root@afni arnold]# uname -a > Linux afni 2.4.0-XFS_BETA_4 #1 Tue Nov 28 08:08:58 CST 2000 i686 unknown > > I'd appreciate any thoughts anyone might have. From owner-linux-xfs@oss.sgi.com Tue Feb 27 13:23:24 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 13:23:15 -0800 Received: from ubr-95.237.251.oviedo.cfl.rr.com ([24.95.237.251]:40952 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 13:23:08 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id QAA22903; Tue, 27 Feb 2001 16:15:45 -0500 Message-ID: <3A9C1C35.AB6A323D@ieee.org> Date: Tue, 27 Feb 2001 16:29:25 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juan Casero CC: Russell Cattelan , james rich , linux-xfs@oss.sgi.com Subject: Re: building 2.4.2 (with XFS) fails <- Useful CVS commands for update checking ... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Re: building 2.4.2 (with XFS) fails <- Useful CVS commands for update checking ... Juan Casero wrote: > Shortly after the message anouncing the release of the 2.4.2 code with > the XFS patches on the CVS server I logged in to the CVS server and > grabbed a copy. I performed the update as per the syntax below and I > did get lots of output so something was happening. I admit to being > something of a novice with CVS (nothing to be ashamed of really) but > that might suggest there was something to update. My intention here is > to be helpful though so don't take my comments as being smug wise cracks. > I was genuiunely interested in helping the person who was having problems > compiling the kernel. For future reference, I recommend the following CVS commands for checking for updates to a CVS repository, without changing the contents of your current working directory. A good way to remember these commands is simply by making aliases for them with your shell's "alias" command. Again, these commands do *NOT* modify your working directory (hence the use of the "-n" option). The output of the two commands are discussed below ... cvs -n -q update -I '! CVS' -r HEAD cvs -n -q update -r HEAD The first command will report on every file in the respository, including files/types normally filtered by CVS (e.g., .bak, .o, etc...), except the CVS status directories themselves (e.g., ./CVS in each working directory). The second command applies the CVS files/types filter list. The report is a simple output of the status of each file, one file per line. If the working directory and repository match, no output is made for that file. If there is a difference, there is a leading "status letter" before the filename. "status letters" are as follows: ? File only in working directory A File only in working directory, to be added to repository on next commit operation ("cvs add" wo/"cvs commit") C Conflict between changes in working directory and new revision in repository (cvs commit will entail issues) M Changes in working directory, will send new revision to to repository on next commit. Could also mean that the newer revision in repository will merge perfectly with your changes. P Newer revision in repository, only needs partial file patch U Newer revision in repository, needs complete file update For an example, I will use the second command against the source tarball located in my kernel-2.4.2-xfscvs_feb24.src.rpm: # cvs -n -q update -r HEAD ? devfsd ? pcmcia-cs-3.1.24 ? alsa-driver-0.5.10b ? configs ? .depend ? .hdepend ? .config ? .version ? vmlinux ? System.map ? arch/i386/boot/bbootsect.s ? arch/i386/boot/bbootsect ? arch/i386/boot/bsetup.s ? arch/i386/boot/bsetup ? arch/i386/boot/bzImage ? arch/i386/boot/compressed/bvmlinux ? arch/i386/boot/compressed/bvmlinux.out ? arch/i386/boot/tools/build [ ^ These are all locally modified files in the build ] ? arch/i386/kernel/.depend ? arch/i386/kernel/.process.o.flags ? arch/i386/kernel/.semaphore.o.flags ? arch/i386/kernel/.signal.o.flags <... ^ cut a lot of "*.o.flags" and ".depend" files ...> [ Side note: Sounds like these should be added to the "cvsignore" file in the repository CVSROOT??? ] ? drivers/net/hamradio/soundmodem/gentbl ? drivers/net/hamradio/soundmodem/sm_tbl_afsk1200.h ? drivers/net/hamradio/soundmodem/sm_tbl_afsk2666.h ? drivers/net/hamradio/soundmodem/sm_tbl_psk4800.h ? drivers/net/hamradio/soundmodem/sm_tbl_hapn4800.h ? drivers/net/hamradio/soundmodem/sm_tbl_fsk9600.h ? drivers/net/hamradio/soundmodem/sm_tbl_afsk2400_8.h ? drivers/net/hamradio/soundmodem/sm_tbl_afsk2400_7.h <... cut more .o.flags/.depend files ... > ? include/config ? include/linux/modules ? include/linux/autoconf.h ? include/linux/version.h ? include/linux/compile.h ? include/linux/modversions.h <... cut more .o.flags/.depend files ... > ? scripts/mkdep ? scripts/split-include RCS file: /cvs/linux-2.4-xfs/linux/Makefile,v retrieving revision 1.81 retrieving revision 1.82 Merging differences between 1.81 and 1.82 into Makefile M Makefile U Rules.make U Documentation/filesystems/xfs.txt M arch/i386/defconfig [ ^ Ahhh, note a couple of merges and updates now ] U Documentation/kdb/kdb.mm U arch/i386/kdb/kdbasupport.c U arch/i386/kernel/msr.c U arch/s390x/Makefile U arch/s390x/boot/Makefile U arch/s390x/kernel/Makefile U arch/s390x/lib/Makefile U arch/s390x/mm/Makefile U arch/s390x/tools/dasdfmt/Makefile U arch/s390x/tools/silo/Makefile U drivers/block/ll_rw_blk.c U drivers/scsi/scsi_merge.c U fs/buffer.c U fs/dquot.c U fs/pagebuf/page_buf.c U fs/pagebuf/page_buf_io.c U fs/xfs/Makefile U fs/xfs/xfs_log.c U fs/xfs/xfs_log_recover.c U fs/xfs/xfs_qm.c U fs/xfs/dmapi/Makefile U fs/xfs/linux/Makefile U fs/xfs/linux/xfs_globals.c U fs/xfs/linux/xfs_globals.h U fs/xfs/linux/xfs_iops.c U fs/xfs/linux/xfs_linux.h U fs/xfs/linux/xfs_lrw.c U fs/xfs/linux/xfs_lrw.h U fs/xfs/support/Makefile U include/asm-alpha/fcntl.h U include/asm-i386/fcntl.h U include/asm-ia64/fcntl.h U include/asm-s390x/a.out.h U include/asm-sparc/fcntl.h U include/asm-sparc64/fcntl.h U include/linux/fs.h U include/linux/kallsyms.h U include/linux/kdb.h U include/linux/mm.h U include/linux/page_buf.h U kdb/ChangeLog U kdb/kdbmain.c U kdb/modules/kdbm_pg.c U kernel/kallsyms.c U kernel/ksyms.c U mm/page_alloc.c U mm/vmscan.c U scripts/mkdep.c Now with the "U" (as well as "P" if they existed) we see all the files that would need to be updated in the repository. Again, these simple aliases go a _long_way_ to looking at the various files updated before you actually commit yourself to them. -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Tue Feb 27 13:32:14 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 13:31:54 -0800 Received: from ubr-95.237.251.oviedo.cfl.rr.com ([24.95.237.251]:43768 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 13:31:48 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id QAA22998; Tue, 27 Feb 2001 16:26:16 -0500 Message-ID: <3A9C1EAC.100BFFE9@ieee.org> Date: Tue, 27 Feb 2001 16:39:56 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: arnold@is.rice.edu, linux-xfs@oss.sgi.com Subject: Re: not a valid block device <- Oh, I need to modify my .configs in my SRPMs and rebuild ... References: <200102272117.f1RLHZx01611@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Re: not a valid block device <- Oh, I need to modify my .configs in my SRPMs and rebuild ... Steve Lord wrote: > Did you build SGI partition table support into your kernel? Down at the > bottom of the filesystems menu in the kernel config interfaces is a > partition types menu, in here you can add SGI partition support. I suspect > the kernels we ship do not have it on. Let's see ... File systems -> Partition Types -> [ ] Advanced partition selection Nope! Ahhh ... that's a good think to know! I need to change my *.config files the next time I rebuild my [S]RPMs. Now the list is ... [*] Advanced partition selection [ ] Acorn partition support (NEW) [ ] Alpha OSF partition support (NEW) [ ] Amiga partition table support (NEW) [ ] Atari partition table support (NEW) [ ] Macintosh partition map support (NEW) [*] PC BIOS (MSDOS partition tables) support [ ] BSD disklabel (FreeBSD partition tables) support (NEW) [ ] Minix subpartition support (NEW) [ ] Solaris (x86) partition table support (NEW) [ ] Unixware slices support (NEW) [ ] SGI partition support (NEW) [ ] Ultrix partition table support (NEW) [ ] Sun partition tables support (NEW) Third one from the bottom. Does anyone know if there are "issues" with being "too liberal" with the partition support here? -- TheBS P.S. If someone would let me know when the date/timestamp of a "good" CVS repository to build another set of RPMs from occurs, I'd greatly appreciate it! -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Tue Feb 27 13:40:15 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 13:40:05 -0800 Received: from ubr-95.237.251.oviedo.cfl.rr.com ([24.95.237.251]:47352 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 13:39:53 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id QAA23064; Tue, 27 Feb 2001 16:33:17 -0500 Message-ID: <3A9C2051.6511ECE6@ieee.org> Date: Tue, 27 Feb 2001 16:46:57 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juan Casero CC: Russell Cattelan , james rich , linux-xfs@oss.sgi.com Subject: Re: building 2.4.2 (with XFS) fails <- Useful CVS commands for update checking (2) References: <3A9C1C35.AB6A323D@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Re: building 2.4.2 (with XFS) fails <- Useful CVS commands for update checking (2) "Bryan J. Smith" wrote: > <... ^ cut a lot of "*.o.flags" and ".depend" files ...> > [ Side note: Sounds like these should be added to > the "cvsignore" file in the repository CVSROOT??? ] You can do this on the "client side" by setting your shell's environment with "CVSIGNORE" and a string of files/wildcards. E.g., bash users: export CVSIGNORE=".depend *.o.flags" [t]csh users: setenv CVSIGNORE ".depend *.o.flags" Now the "cvs -n -q update -r HEAD" is a little "cleaner": # cvs -n -q update -r HEAD ? devfsd ? pcmcia-cs-3.1.24 ? alsa-driver-0.5.10b ? configs ? .hdepend ? .config ? .version ? vmlinux ? System.map ? arch/i386/boot/bbootsect.s ? arch/i386/boot/bbootsect ? arch/i386/boot/bsetup.s ? arch/i386/boot/bsetup ? arch/i386/boot/bzImage ? arch/i386/boot/compressed/bvmlinux ? arch/i386/boot/compressed/bvmlinux.out ? arch/i386/boot/tools/build ? arch/i386/lib/.lib.a.flags ? drivers/atm/fore200e_mkfirm ? drivers/atm/pca200e.bin ? drivers/atm/fore200e_pca_fw.c ? drivers/atm/.fore200e_pca_fw.c.fw ? drivers/char/conmakehash ? drivers/char/consolemap_deftbl.c ? drivers/char/defkeymap.c ? drivers/net/hamradio/soundmodem/gentbl ? drivers/net/hamradio/soundmodem/sm_tbl_afsk1200.h ? drivers/net/hamradio/soundmodem/sm_tbl_afsk2666.h ? drivers/net/hamradio/soundmodem/sm_tbl_psk4800.h ? drivers/net/hamradio/soundmodem/sm_tbl_hapn4800.h ? drivers/net/hamradio/soundmodem/sm_tbl_fsk9600.h ? drivers/net/hamradio/soundmodem/sm_tbl_afsk2400_8.h ? drivers/net/hamradio/soundmodem/sm_tbl_afsk2400_7.h ? drivers/pci/gen-devlist ? drivers/pci/devlist.h ? drivers/pci/classlist.h ? drivers/sound/pss_boot.h ? drivers/sound/.pss_boot.h.boot ? drivers/sound/trix_boot.h ? drivers/sound/.trix_boot.h.boot ? drivers/sound/maui_boot.h ? drivers/sound/.maui_boot.h.boot ? fs/xfs/.hdepend ? fs/xfs/linux/.hdepend ? include/config ? include/linux/modules ? include/linux/autoconf.h ? include/linux/version.h ? include/linux/compile.h ? include/linux/modversions.h ? lib/.lib.a.flags ? net/khttpd/make_times_h ? net/khttpd/times.h ? scripts/mkdep ? scripts/split-include RCS file: /cvs/linux-2.4-xfs/linux/Makefile,v retrieving revision 1.81 retrieving revision 1.82 Merging differences between 1.81 and 1.82 into Makefile M Makefile U Rules.make U Documentation/filesystems/xfs.txt M arch/i386/defconfig U Documentation/kdb/kdb.mm U arch/i386/kdb/kdbasupport.c U arch/i386/kernel/msr.c U arch/s390x/Makefile U arch/s390x/boot/Makefile U arch/s390x/kernel/Makefile U arch/s390x/lib/Makefile U arch/s390x/mm/Makefile U arch/s390x/tools/dasdfmt/Makefile U arch/s390x/tools/silo/Makefile U drivers/block/ll_rw_blk.c U drivers/scsi/scsi_merge.c U fs/buffer.c U fs/dquot.c U fs/pagebuf/page_buf.c U fs/pagebuf/page_buf_io.c U fs/xfs/Makefile U fs/xfs/xfs_log.c U fs/xfs/xfs_log_recover.c U fs/xfs/xfs_qm.c U fs/xfs/dmapi/Makefile U fs/xfs/linux/Makefile U fs/xfs/linux/xfs_globals.c U fs/xfs/linux/xfs_globals.h U fs/xfs/linux/xfs_iops.c U fs/xfs/linux/xfs_linux.h U fs/xfs/linux/xfs_lrw.c U fs/xfs/linux/xfs_lrw.h U fs/xfs/support/Makefile U include/asm-alpha/fcntl.h U include/asm-i386/fcntl.h U include/asm-ia64/fcntl.h U include/asm-s390x/a.out.h U include/asm-sparc/fcntl.h U include/asm-sparc64/fcntl.h U include/linux/fs.h U include/linux/kallsyms.h U include/linux/kdb.h U include/linux/mm.h U include/linux/page_buf.h U kdb/ChangeLog U kdb/kdbmain.c U kdb/modules/kdbm_pg.c U kernel/kallsyms.c U kernel/ksyms.c U mm/page_alloc.c U mm/vmscan.c U scripts/mkdep.c -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Tue Feb 27 19:14:26 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 19:14:16 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:11129 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 19:14:06 -0800 Received: from waco.engr.sgi.com ([163.154.18.95]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA01327 for ; Tue, 27 Feb 2001 19:14:05 -0800 (PST) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.11.0/8.11.0) id f1S3Bxr23152 for linux-xfs@oss.sgi.com; Tue, 27 Feb 2001 19:11:59 -0800 Date: Tue, 27 Feb 2001 19:11:59 -0800 From: Ananth Ananthanarayanan Message-Id: <200102280311.f1S3Bxr23152@waco.engr.sgi.com> Subject: TAKE - remove unnecessary diffs with 2.4.2 To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Reduce differences with 2.4.2 Date: Tue Feb 27 19:12:02 PST 2001 Workarea: waco.engr.sgi.com:/build1/ananth/xfs-tot The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88516a linux/mm/filemap.c - 1.69 linux/include/linux/fs.h - 1.82 linux/drivers/scsi/scsi_merge.c - 1.26 From owner-linux-xfs@oss.sgi.com Tue Feb 27 21:05:06 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 21:04:56 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:61726 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 21:04:34 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA08605 for ; Tue, 27 Feb 2001 21:04:32 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA41009 for linux-xfs@oss.sgi.com; Wed, 28 Feb 2001 16:03:16 +1100 (EST) Date: Wed, 28 Feb 2001 16:03:16 +1100 (EST) From: Nathan Scott Message-Id: <200102280503.QAA41009@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Feb 26 21:03:06 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88453a cmd/xfsprogs/logprint/xfs_log_recover.c - 1.2 - sync changes to kernel version of xlog_find_verify_cycle. Date: Tue Feb 27 20:36:56 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88519a linux/fs/xfs/xfs_mount.c - 1.248 linux/fs/xfs/xfs_qm.c - 1.62 - minor reworking of initial mount of root with quota enabled - this prevents us enabling writes on every root mount with quota, now just the first time. cmd/quota/quotactl.c - 1.2 - get quota userspace up and stumbling on ia64. cmd/quota/quotaon.c - 1.10 - fix some compile warnings, make xfs less verbose at startup, and make it easier to delete quota inodes (previously required -u flag too). cmd/quota/quotaio.c - 1.4 cmd/quota/quotastats.c - 1.3 cmd/quota/repquota.c - 1.13 - fix some compile warnings under glibc2.2/ia64 (one/the other). From owner-linux-xfs@oss.sgi.com Tue Feb 27 21:08:06 2001 Received: by oss.sgi.com id ; Tue, 27 Feb 2001 21:07:46 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:16699 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 27 Feb 2001 21:07:32 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA28266 for ; Tue, 27 Feb 2001 21:06:25 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA28964; Wed, 28 Feb 2001 16:06:14 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA75481; Wed, 28 Feb 2001 16:06:12 +1100 (EDT) From: "Nathan Scott" Message-Id: <10102281606.ZM163349@wobbly.melbourne.sgi.com> Date: Wed, 28 Feb 2001 16:06:09 -0400 In-Reply-To: Blizbor "About quotas ... (Was: TAKE - root quota)" (Feb 27, 10:36am) References: <5.0.0.25.0.20010227103306.01afaaf0@195.117.13.2> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Blizbor Subject: Re: About quotas ... (Was: TAKE - root quota) Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Feb 27, 10:36am, Blizbor wrote: > Subject: About quotas ... (Was: TAKE - root quota) > At 2/27/01 04:06 AM, you wrote: > >This fixes the problem Thomas reported about not being able to > >mount root XFS filesystems with quota enabled (see quotaon.8). > > Hi, > > Did you have some more information about quota in the XFS ? > I'll try to write a howto sometime in the next few weeks. The quota man pages (see cmd/quota/*) have been updated to reflect the changes made to the Linux quota tools to support the XFS quota model as well, so you may be able to glean all the info you need from them. > Especially > - what isn't implemented yet > - when groupquota wil be on group quota is pretty much all thats left now, plus fixes to any new bugs that crop up, of course - I don't know of any bugs currently though. group quota support in the XFS kernel code isn't started yet - its probably a month/two away, once someone starts on it (and it is unlikely to be started immediately). Userspace is done from this perspective, the changes will all be in the kernel (unless I've overlooked something). > - if dirquota will be supported No - if I understand what you mean by "dirquota", neither XFS nor ext2 quota support this. They use inode and block based quota enforcement mechanisms, and limits are set at the filesystem level. > - how compatible it's with ext2fs quotas Depends how you look at it ... from a users point of view, there should be very little difference between XFS and ext2 quota - the same tools can be used for both (provided you used the patched cmd/quota/* tools, of course). The big differences, I guess, are that there are no user visible quota files in XFS and quotacheck(8) runs very fast on XFS filesystems, much like fsck.xfs(8). ;-) Under the hood, the implementation is completely different. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 28 02:01:49 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 02:01:39 -0800 Received: from hermes.mixx.net ([212.84.196.2]:60682 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 28 Feb 2001 02:01:14 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 2C8BAF825 for ; Wed, 28 Feb 2001 11:01:08 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 396622CA71; Wed, 28 Feb 2001 11:01:06 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: loop-6 and the XFS tree Date: 28 Feb 2001 10:01:05 GMT Organization: innominate AG, Berlin, Germany Lines: 50 Distribution: local Message-ID: References: <20010227153839.D16652@suse.de> X-Trace: mate.bln.innominate.de 983354465 13044 10.0.0.31 (28 Feb 2001 10:01:05 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.2-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jens Axboe wrote: > On Tue, Feb 27 2001, Thomas Graichen wrote: >> just tried to apply the loop-6 patch to the XFS tree (which works >> fine with plain 2.4.2) i ran into the following: >> >> kgcc -D__KERNEL__ -I/tmp/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -march=i686 -c -o rd.o rd.c >> rd.c: In function `rd_init': >> rd.c:408: warning: passing arg 2 of `blk_queue_make_request' from incompatible pointer type >> kgcc -D__KERNEL__ -I/tmp/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -march=i686 -DEXPORT_SYMTAB -c loop.c >> loop.c: In function `loop_make_request': >> loop.c:451: too few arguments to function `generic_make_request' >> loop.c: In function `loop_init': >> loop.c:954: warning: passing arg 2 of `blk_queue_make_request' from incompatible pointer type >> make[3]: *** [loop.o] Error 1 >> make[3]: Leaving directory `/tmp/linux/drivers/block' >> make[2]: *** [first_rule] Error 2 >> make[2]: Leaving directory `/tmp/linux/drivers/block' >> make[1]: *** [_subdir_block] Error 2 >> make[1]: Leaving directory `/tmp/linux/drivers' >> make: *** [_dir_drivers] Error 2 >> >> ... and because i think jens is lurking around here i try to >> ask first before looking into it ... maybe he already has >> a fix handy > Yeah, the lurker, that's me :-) > Anways, change the generic_make_request in loop to something like: > generic_make_request(rw, bh, NULL, 0, 0, 0); > return 0; > and loop_make_request definition to: > static int loop_make_request(request_queue_t *q, int rw, > struct buffer_head *rbh, struct kio_buf *kio, > kdev_t dev, unsigned long block, size_t bsize) i assume the kio_buf is kiobuf above? - then it compiles fine (only sidething is: loop.c: In function `loop_init': loop.c:956: warning: passing arg 2 of `blk_queue_make_request' from incompatible pointer type ... same for rd.c) t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Wed Feb 28 02:40:38 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 02:40:19 -0800 Received: from ubr-95.237.251.oviedo.cfl.rr.com ([24.95.237.251]:59631 "EHLO home.smithconcepts.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 02:39:47 -0800 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id FAA30408; Wed, 28 Feb 2001 05:34:19 -0500 Message-ID: <3A9CD764.EC3C5F98@ieee.org> Date: Wed, 28 Feb 2001 05:48:04 -0500 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Anyone running my RPMs? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Anyone running my RPMs? Just kinda want to know if anyone is running into any issues. Also, for the initrd, does "pagebuf" have to be in there? I was booting just fine with "xfs" and "xfs_support" only on a XFS root (/ -- no separate /boot partition). -- TheBS -- Bryan "TheBS" Smith, Engineer CONTACT INFO *********************************************************** Chat: thebs413 @ AOL/MSN/Yahoo (see http://Everybuddy.com) Email: mailto:thebs@smithconcepts.com,thebs@theseus.com From owner-linux-xfs@oss.sgi.com Wed Feb 28 04:39:08 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 04:38:59 -0800 Received: from h00059aa0e40d.ne.mediaone.net ([66.31.89.164]:5374 "EHLO flowers.house.larsshack.org") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 04:38:37 -0800 Received: from localhost (lars@localhost) by flowers.house.larsshack.org (8.11.0/8.11.0) with ESMTP id f1SCcQ902091 for ; Wed, 28 Feb 2001 07:38:26 -0500 X-Authentication-Warning: flowers.house.larsshack.org: lars owned process doing -bs Date: Wed, 28 Feb 2001 07:38:26 -0500 (EST) From: Lars Kellogg-Stedman X-Sender: To: Subject: Interactions between XFS and software RAID? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Howdy all, I have a single XFS filesystem, mounted on a 4 disk software RAID5 array. It's been working just fine, until yesterday when a forced reboot rendered the raid in need of a resync. The resync starts just fine when the raid device is brought up, but as soon as the filesystem is mounted, the resync gets stuck -- the resync thread is still running, but nothing happens. It chews up CPU time and renders the system almost unuseable. Unmounting the filesystem, stopping the raid array (raidstop) and restarting will get the resync going again (until the filesystem is mounted, or the resync completes). Has anyone else encountered this problem? I'm running the XFS snapshot from Feb 23. -- Lars -- Lars Kellogg-Stedman --> http://www.larsshack.org/ From owner-linux-xfs@oss.sgi.com Wed Feb 28 04:45:39 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 04:45:30 -0800 Received: from hermes.mixx.net ([212.84.196.2]:2065 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 28 Feb 2001 04:45:14 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 44EF2F82E for ; Wed, 28 Feb 2001 13:45:12 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 1C2722CA6F; Wed, 28 Feb 2001 13:45:11 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: Interactions between XFS and software RAID? Date: 28 Feb 2001 12:45:11 GMT Organization: innominate AG, Berlin, Germany Lines: 31 Distribution: local Message-ID: References: X-Trace: mate.bln.innominate.de 983364311 12527 10.0.0.31 (28 Feb 2001 12:45:11 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.2-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Lars Kellogg-Stedman wrote: > Howdy all, > I have a single XFS filesystem, mounted on a 4 disk software RAID5 array. > It's been working just fine, until yesterday when a forced reboot rendered > the raid in need of a resync. > The resync starts just fine when the raid device is brought up, but as > soon as the filesystem is mounted, the resync gets stuck -- the resync > thread is still running, but nothing happens. It chews up CPU time and > renders the system almost unuseable. > Unmounting the filesystem, stopping the raid array (raidstop) and > restarting will get the resync going again (until the filesystem is > mounted, or the resync completes). > Has anyone else encountered this problem? I'm running the XFS snapshot > from Feb 23. for XFS on SW RAID5 you need the experimental patch postet here some time ago from either Martin K. Petersen or Russel Cattleman - i'm now shure who it was ... just look for it in the archives of the list t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Wed Feb 28 04:46:38 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 04:46:29 -0800 Received: from hermes.mixx.net ([212.84.196.2]:3857 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 28 Feb 2001 04:46:16 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id B6798F830 for ; Wed, 28 Feb 2001 13:46:13 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 927B62CA6F; Wed, 28 Feb 2001 13:46:13 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: Interactions between XFS and software RAID? Date: 28 Feb 2001 12:46:13 GMT Organization: innominate AG, Berlin, Germany Lines: 16 Distribution: local Message-ID: References: <97irsn$c7f$3@mate.bln.innominate.de> X-Trace: mate.bln.innominate.de 983364373 12527 10.0.0.31 (28 Feb 2001 12:46:13 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.2-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > for XFS on SW RAID5 you need the experimental patch postet here > some time ago from either Martin K. Petersen or Russel Cattleman > - i'm now shure who it was ... just look for it in the archives > of the list ok - it was russel and subject was: raid5 patch t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Wed Feb 28 05:01:59 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 05:01:39 -0800 Received: from 66-2-81-26.customer.algx.net ([66.2.81.26]:43618 "EHLO wiley.ceo.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 05:01:35 -0800 Received: from mindspring.com (IDENT:danny@localhost [127.0.0.1]) by wiley.ceo.com (8.9.3/8.9.3) with ESMTP id IAA02337; Wed, 28 Feb 2001 08:13:39 -0500 Message-ID: <3A9CF982.18BFE19@mindspring.com> Date: Wed, 28 Feb 2001 08:13:38 -0500 From: Danny Reply-To: dcox@connex.com Organization: Connex Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Ananth Ananthanarayanan CC: Linux-XFS Subject: Re: TAKE - Delay Buffer Changes References: <200102270040.f1R0eAV02973@waco.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ananth, Ananth Ananthanarayanan wrote: > > Significant part of this change is to employ standard > linux IO daemons & paths to handle delalloc pages by > attaching buffers to all pages. This also enables > handling of sync()-type operation (changes yet to come) ... I just wanted everyone to know: this change has enabled me to run two Bonnies overnight with XFS on RAID1. The machine DID become unusable at one point yesterday. I had a shell prompt, but any command other than a shell built-in immediatly got a core dump(!). After that, however, it ran just fine. From about 1:30 PM through now (~ 8:00 AM), the two Bonnies have been running great. I've been having some RAM problems too, and this "hang" may have been due to that. I've NOT seen the "0-order allocation failed" messages, which was my main sticking point. Also, either because I'm using the "-o logbufs=4,logbsize=32768" mount option, or the recent changes, or both, the Bonnie block writes went from 14+ MB/sec to 20+, and the block reads went from 9+ MB/sec to 10+. Yesterday I was "cautiously optimistic". Today, I'm "comfortably optimistic". Great work, Ananth! Thanks! -- "Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill Danny From owner-linux-xfs@oss.sgi.com Wed Feb 28 05:27:59 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 05:27:49 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:8719 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 05:27:37 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.22 #4) id 14Y6dX-0008Jn-00; Wed, 28 Feb 2001 14:27:23 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14Y6dM-0005Ne-00; Wed, 28 Feb 2001 14:27:12 +0100 Date: Wed, 28 Feb 2001 14:27:12 +0100 From: Jens Axboe To: Thomas Graichen Cc: linux-xfs@oss.sgi.com Subject: Re: loop-6 and the XFS tree Message-ID: <20010228142712.N453@suse.de> References: <20010227153839.D16652@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from news-innominate.list.sgi.xfs@innominate.de on Wed, Feb 28, 2001 at 10:01:05AM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Feb 28 2001, Thomas Graichen wrote: > > static int loop_make_request(request_queue_t *q, int rw, > > struct buffer_head *rbh, struct kio_buf *kio, > > kdev_t dev, unsigned long block, size_t bsize) > > i assume the kio_buf is kiobuf above? - then it compiles fine Yes of course, sorry. > (only sidething is: loop.c: In function `loop_init': loop.c:956: > warning: passing arg 2 of `blk_queue_make_request' from incompatible > pointer type ... same for rd.c) Maybe because the xfs tree doesn't quite agree on what make_request_fn should look like. Make the size_t unsigned int instead in loop and rd. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Feb 28 05:50:59 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 05:50:49 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:20751 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 05:50:28 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.22 #4) id 14Y6zp-0000AR-00; Wed, 28 Feb 2001 14:50:25 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14Y6zl-0005S4-00; Wed, 28 Feb 2001 14:50:21 +0100 Date: Wed, 28 Feb 2001 14:50:21 +0100 From: Jens Axboe To: Thomas Graichen Cc: linux-xfs@oss.sgi.com Subject: Re: loop-6 and the XFS tree Message-ID: <20010228145021.P453@suse.de> References: <20010227153839.D16652@suse.de> <20010228142712.N453@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010228142712.N453@suse.de>; from axboe@suse.de on Wed, Feb 28, 2001 at 02:27:12PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Feb 28 2001, Jens Axboe wrote: > > (only sidething is: loop.c: In function `loop_init': loop.c:956: > > warning: passing arg 2 of `blk_queue_make_request' from incompatible > > pointer type ... same for rd.c) > > Maybe because the xfs tree doesn't quite agree on what make_request_fn > should look like. Make the size_t unsigned int instead in loop > and rd. My mistake, I was looking at the wrong function. There's no mixup in the xfs tree. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Feb 28 05:57:29 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 05:57:20 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:24847 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 05:57:05 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.22 #4) id 14Y76E-0000Ge-00; Wed, 28 Feb 2001 14:57:02 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14Y76A-0005Uy-00; Wed, 28 Feb 2001 14:56:58 +0100 Date: Wed, 28 Feb 2001 14:56:58 +0100 From: Jens Axboe To: Thomas Graichen Cc: linux-xfs@oss.sgi.com Subject: Re: loop-6 and the XFS tree Message-ID: <20010228145658.Q453@suse.de> References: <20010227153839.D16652@suse.de> <20010228142712.N453@suse.de> <20010228145021.P453@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010228145021.P453@suse.de>; from axboe@suse.de on Wed, Feb 28, 2001 at 02:50:21PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Feb 28 2001, Jens Axboe wrote: > > should look like. Make the size_t unsigned int instead in loop > > and rd. > > My mistake, I was looking at the wrong function. There's no > mixup in the xfs tree. I would provide a patch for rd too, but the tree still has the kgcc stupidity that prevents me from compiling. Yes I could fix it easily, but it annoys me heavily that such a change was made blindly assuming that we all need kgcc. So I'm holding further contributions for now until this is fixed -- yes I'm silly, but so is this assumption. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Feb 28 06:32:59 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 06:32:49 -0800 Received: from edge.coltex.nl ([194.151.97.115]:14354 "EHLO mail.coltex.nl") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 06:32:27 -0800 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f1SDVgu14172 for ; Wed, 28 Feb 2001 14:31:43 +0100 Message-Id: <4.3.2.7.2.20010228153003.0418dde0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Feb 2001 15:32:37 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: loop-6 and the XFS tree In-Reply-To: <20010228145658.Q453@suse.de> References: <20010228145021.P453@suse.de> <20010227153839.D16652@suse.de> <20010228142712.N453@suse.de> <20010228145021.P453@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 14:56 28-2-2001 +0100, you wrote: >On Wed, Feb 28 2001, Jens Axboe wrote: > > > should look like. Make the size_t unsigned int instead in loop > > > and rd. > > > > My mistake, I was looking at the wrong function. There's no > > mixup in the xfs tree. > >I would provide a patch for rd too, but the tree still has the kgcc >stupidity that prevents me from compiling. Yes I could fix it easily, >but it annoys me heavily that such a change was made blindly >assuming that we all need kgcc. So I'm holding further contributions >for now until this is fixed -- yes I'm silly, but so is this >assumption. I agree, I build the tree more often on non redhat 7 boxes. Btw, gcc 2.95.2 seems to work under debian 2.2_r2. Not really tested, but it compiles and mounting worked. >-- >Jens Axboe -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Wed Feb 28 07:00:09 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 06:59:59 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:46150 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 06:59:47 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA03163 for ; Wed, 28 Feb 2001 07:09:23 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA969003 for ; Wed, 28 Feb 2001 08:58:30 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA96198 for ; Wed, 28 Feb 2001 08:58:30 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f1SEx8O18793; Wed, 28 Feb 2001 08:59:08 -0600 Message-Id: <200102281459.f1SEx8O18793@jen.americas.sgi.com> Date: Wed, 28 Feb 2001 08:59:08 -0600 Subject: TAKE - fall back from kgcc to gcc -V.... To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing When you check in 7 or 8 hundred files at once, a one line slip up is not a deliberate snub to those not running RedHat 7 or Mandrake, but a slight typo. Going back to the old settings to keep some people happy (you know who you are ;-) Steve p.s. I am sure someone who understood ia32 assembler volunteered to fix up the do_div problems several months ago..... Date: Wed Feb 28 06:55:01 PST 2001 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:88550a linux/Makefile - 1.83 - Back to non kgcc by default From owner-linux-xfs@oss.sgi.com Wed Feb 28 07:23:00 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 07:22:50 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:62288 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 07:22:38 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA01568 for ; Wed, 28 Feb 2001 07:22:37 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA968983; Wed, 28 Feb 2001 09:21:21 -0600 (CST) Received: from sgi.com (sandeen@eagdhcp-195-23.americas.sgi.com [128.162.195.179]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA08963; Wed, 28 Feb 2001 09:21:21 -0600 (CST) Message-ID: <3A9D1902.14A2FC89@sgi.com> Date: Wed, 28 Feb 2001 09:28:02 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: b.j.smith@ieee.org, thebs@theseus.com CC: linux-xfs@oss.sgi.com Subject: Re: Anyone running my RPMs? References: <3A9CD764.EC3C5F98@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Bryan J. Smith" wrote: > Also, for the initrd, does "pagebuf" have to be in there? yep > I was > booting just fine with "xfs" and "xfs_support" only on a XFS root (/ > -- no separate /boot partition). Really? The xfs module does depend on the pagebuf module. From modules.dep: /lib/modules/2.4.2-XFS/kernel/fs/xfs/xfs.o: \ /lib/modules/2.4.2-XFS/kernel/fs/xfs/support/xfs_support.o \ /lib/modules/2.4.2-XFS/kernel/fs/pagebuf/pagebuf.o -Eric From owner-linux-xfs@oss.sgi.com Wed Feb 28 07:30:09 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 07:30:00 -0800 Received: from hermes.mixx.net ([212.84.196.2]:58888 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 28 Feb 2001 07:29:48 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 90CD4F834 for ; Wed, 28 Feb 2001 16:29:45 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id CEE012CA6F; Wed, 28 Feb 2001 16:29:43 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: mysterious dbench results Date: 28 Feb 2001 15:29:43 GMT Organization: innominate AG, Berlin, Germany Lines: 22 Distribution: local Message-ID: References: <200102221504.f1MF41r20047@jen.americas.sgi.com> X-Trace: mate.bln.innominate.de 983374183 19184 10.0.0.31 (28 Feb 2001 15:29:43 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.2-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > I have been out for a while, or I would have posted something on this earlier. > The default mkfs options for xfs are not optimal for heavy I/O load, they are > somewhat historical and should probably be changed. > On mkfs try some options like this: > mkfs -t xfs -f -l size=32768b /dev/xxx just out of couriosity: would this work after fs creation time with the xfs_growfs -L option (which does not seem to work so far) - or only together with extending the size of the under- lying device? t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Wed Feb 28 07:35:00 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 07:34:49 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:60489 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 07:34:33 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA04803 for ; Wed, 28 Feb 2001 07:44:07 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA965529; Wed, 28 Feb 2001 09:33:13 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA87955; Wed, 28 Feb 2001 09:33:13 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1SFXoL08392; Wed, 28 Feb 2001 09:33:50 -0600 Message-Id: <200102281533.f1SFXoL08392@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Thomas Graichen cc: linux-xfs@oss.sgi.com Subject: Re: mysterious dbench results In-Reply-To: Message from Thomas Graichen of "28 Feb 2001 15:29:43 GMT." Date: Wed, 28 Feb 2001 09:33:50 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > > I have been out for a while, or I would have posted something on this earli > er. > > The default mkfs options for xfs are not optimal for heavy I/O load, they a > re > > somewhat historical and should probably be changed. > > > On mkfs try some options like this: > > > mkfs -t xfs -f -l size=32768b /dev/xxx > > just out of couriosity: would this work after fs creation time > with the xfs_growfs -L option (which does not seem to work so > far) - or only together with extending the size of the under- > lying device? Unfortunately, you can only extend the size of the log when the log is on an external device. By default the log is in the middle of the filesystem, and changing its size could well involve moving things out of the way, it would certainly involve removing the newly used space from the available free spare. All technically feasable, but not there in the code as it. Steve From owner-linux-xfs@oss.sgi.com Wed Feb 28 07:38:30 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 07:38:20 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:17482 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 07:38:12 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA09921 for ; Wed, 28 Feb 2001 07:47:48 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA961369 for ; Wed, 28 Feb 2001 09:36:55 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA92181 for ; Wed, 28 Feb 2001 09:36:55 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f1SFbWb08514; Wed, 28 Feb 2001 09:37:32 -0600 Message-Id: <200102281537.f1SFbWb08514@jen.americas.sgi.com> Date: Wed, 28 Feb 2001 09:37:32 -0600 Subject: TAKE - fix merge error To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Just in case someone wants xfs on an IBM 390x Steve Date: Wed Feb 28 07:36:10 PST 2001 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:88557a linux/arch/s390x/kernel/Makefile - 1.2 linux/arch/s390x/tools/dasdfmt/Makefile - 1.2 linux/arch/s390x/mm/Makefile - 1.2 linux/arch/s390x/lib/Makefile - 1.2 linux/include/asm-s390x/a.out.h - 1.2 linux/arch/s390x/tools/silo/Makefile - 1.2 linux/arch/s390x/boot/Makefile - 1.2 linux/arch/s390x/Makefile - 1.2 - Fix zero length file From owner-linux-xfs@oss.sgi.com Wed Feb 28 07:45:30 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 07:45:21 -0800 Received: from south.orl-pub.theseus.com ([12.108.42.66]:40994 "EHLO thor.theseus.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 07:45:15 -0800 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id KAA04222; Wed, 28 Feb 2001 10:48:30 -0500 Message-ID: <3A9D1D2A.80E97D38@theseus.com> Date: Wed, 28 Feb 2001 10:45:46 -0500 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Anyone running my RPMs? References: <3A9CD764.EC3C5F98@ieee.org> <3A9D1902.14A2FC89@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Eric Sandeen wrote: > yep Any problems? > Really? > The xfs module does depend on the pagebuf module. From modules.dep: > /lib/modules/2.4.2-XFS/kernel/fs/xfs/xfs.o: \ > /lib/modules/2.4.2-XFS/kernel/fs/xfs/support/xfs_support.o \ > /lib/modules/2.4.2-XFS/kernel/fs/pagebuf/pagebuf.o Dooh! There's my ignorance for you! It's probably in there (how do you list the contents of an initrd?). I did see it on startup, but wasn't sure if it was pulling it from the root filesystem (after accessing it). -- TheBS, XFS "newbie" -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Wed Feb 28 08:35:10 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 08:34:50 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:6192 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 08:34:35 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA24540 for ; Wed, 28 Feb 2001 08:33:18 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA38379; Wed, 28 Feb 2001 08:28:31 -0800 (PST) Message-ID: <3A9D27FF.957F4FF5@sgi.com> Date: Wed, 28 Feb 2001 08:31:59 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686) X-Accept-Language: en MIME-Version: 1.0 To: dcox@connex.com CC: Linux-XFS Subject: Re: TAKE - Delay Buffer Changes References: <200102270040.f1R0eAV02973@waco.engr.sgi.com> <3A9CF982.18BFE19@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Danny wrote: [ ... ] > too, and this "hang" may have been due to that. I've NOT seen the > "0-order allocation failed" messages, which was my main sticking point. Memory balancing is handled much better now that XFS plays "by the rules" of Linux using standard IO paths & daemons. It's still possible to get allocation failures on HIGHMEM (> 900M memory) systems on allocations of bounce buffers ... again this is a problem in linux HIGHMEM IO, there are some discussions on linux-kernel about reserving a pool of lowmem to allocate for bouncing. > > Also, either because I'm using the "-o logbufs=4,logbsize=32768" mount > option, or the recent changes, or both, the Bonnie block writes went > from 14+ MB/sec to 20+, and the block reads went from 9+ MB/sec to 10+. Any sequential IO changes are not likely due to log changes. After the delay buffer change I'm seeing close to raw I/O speeds on my scsi disk on sequential writes (reads were already close to optimal). thanks, ananth. -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Feb 28 09:37:00 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 09:36:50 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:27661 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 09:36:43 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA02450 for ; Wed, 28 Feb 2001 09:36:36 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA967683 for ; Wed, 28 Feb 2001 11:35:20 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA85943 for ; Wed, 28 Feb 2001 11:35:20 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f1SHZu112461; Wed, 28 Feb 2001 11:35:56 -0600 Message-Id: <200102281735.f1SHZu112461@jen.americas.sgi.com> Date: Wed, 28 Feb 2001 11:35:56 -0600 Subject: TAKE - remove more merge cruft To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing get a couple of unneeded diffs out of our tree Date: Wed Feb 28 09:34:44 PST 2001 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:88571a linux/arch/ppc/kernel/misc.S - 1.26 linux/arch/mips64/sgi-ip22/ip22-int.c - 1.5 - remove merge difference From owner-linux-xfs@oss.sgi.com Wed Feb 28 09:54:00 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 09:53:41 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:7241 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 09:53:38 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA06134 for ; Wed, 28 Feb 2001 09:52:32 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA971040 for ; Wed, 28 Feb 2001 11:52:21 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA70430 for ; Wed, 28 Feb 2001 11:52:21 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f1SHqvN14201; Wed, 28 Feb 2001 11:52:57 -0600 Message-Id: <200102281752.f1SHqvN14201@jen.americas.sgi.com> Date: Wed, 28 Feb 2001 11:52:57 -0600 Subject: TAKE - do not export __wake_up_sync to modules, not used anymore To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Feb 28 09:52:02 PST 2001 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:88574a linux/kernel/ksyms.c - 1.78 - No need to export __wake_up_sync anymore From owner-linux-xfs@oss.sgi.com Wed Feb 28 11:26:01 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 11:25:50 -0800 Received: from esparrall.udg.es ([130.206.124.16]:29834 "EHLO esparrall.udg.es") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 11:25:39 -0800 Received: from gcs by esparrall.udg.es with local (Exim 3.22 #1 (Debian)) id 14YCDZ-0005Qg-00 for ; Wed, 28 Feb 2001 20:24:57 +0100 Date: Wed, 28 Feb 2001 20:24:57 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: OFFTOPIC-O2 and audio Message-ID: <20010228202457.A20859@esparrall.udg.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, This list is about XFS, but as there are a lot of SGI employee on this list, may I ask how to disable all the sound on SGI O2s? I mean to do quiet, like when a machine does not have sound device at all. Thanks, and sorry. Laszlo From owner-linux-xfs@oss.sgi.com Wed Feb 28 11:43:50 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 11:43:30 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:50799 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 11:43:03 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA24013 for ; Wed, 28 Feb 2001 11:41:58 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA42835 for ; Wed, 28 Feb 2001 13:41:46 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1SJeej22548 for ; Wed, 28 Feb 2001 14:40:40 -0500 Message-ID: <3A9D5436.915F68B2@thebarn.com> Date: Wed, 28 Feb 2001 14:40:38 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: CVSup =?ISO-8859-1?Q?Server.=0E?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing As an experiment a cvsup server has been set up on linux-xfs.sgi.com. CVSup is a very fast file distribution system: http://www.polstra.com/projects/freeware/CVSup/ Linux binaries at: ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/binaries/ This is an alternative to cvs for keeping current with the latest development changes. The main downside is normal cvs options are not available "cvs log", "cvs diff" etc etc, but the cvsweb interface should cover most of that any ways. The basic config file looks like this. gibble[1:36pm]-=>less supfile *default host=linux-xfs.sgi.com *default base=. *default release=cvs tag=. *default delete use-rel-suffix *default prefix=/tmp/cvsupit linux-xfs Change prefix to a dest dir of you liking then run cvsup supfile hit the start button once the window pops up. Note the cvs tree may also be keep current with this method simple drop the "tag=." flag e.g. *default host=linux-xfs.sgi.com *default base=. *default release=cvs *default delete use-rel-suffix *default prefix=/tmp/cvsupit linux-xfs Please let me know if you find this useful. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Feb 28 11:56:52 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 11:56:42 -0800 Received: from cortex.ama.ttuhsc.edu ([168.49.129.1]:16144 "EHLO cortex.ama.ttuhsc.edu") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 11:56:20 -0800 Received: (from sean@localhost) by cortex.ama.ttuhsc.edu (8.10.2/8.10.2) id f1SJtKD20217; Wed, 28 Feb 2001 13:55:20 -0600 (CST) Date: Wed, 28 Feb 2001 13:55:20 -0600 (CST) From: Sean Dougherty To: linux-xfs@oss.sgi.com Subject: XFS weirdness In-Reply-To: <20010228202457.A20859@esparrall.udg.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This might be an xfs issue or not. I am not sure. The following only seems to happen when I have files over 2G in size, hence I only see it on the XFS partitions. I am using the cvs as of 2/27/01. Any partitions are created with mkfs -t -f -d unwritten=0 -l size=32768b /dev/hdxx they are mounted with mount -t -o logbufs=4,logbsize=32768 /dev/hdxx /xfs these are ide drives with both dma and multi count on (all maxtor drives at the moment) I create a directory under /xfs called test then export /xfs/test as an NFS file system to a sun box 5.8 (I have nfs3 compiled in the kernel of the xfs box). Now it gets weird. >From the sun box I nfs mount xfs-server:/xfs/test to /testxfs that works fine from the sun box I tar some files to the /testxfs. All is fine and dandy...then at some point, and no it never happens at the same place twice, the tar dies with a write error. usually rpc timeout. >From the sun box I do a df or an ls of /testxfs and after a fashion I get another rpc timeout. But on the xfs-server, if I cd to /xfs/test and try to do an ls 9 times out of 10 ls will hang. Nothing short of rebooting the box will bring it back. Also nfs is also hung (cannot kill rpc.nfsd). The 10th time though I get from the ls "cannot stat ." also nfs if hung. After this reboot I have to do an xfs_repair. One of the many strange things is, I can ls /xfs all day...it is just the /xfs/test that is broken. Has anyone else seen this? Does anyone have any ideas. I have tried with ext2 file systems and they seem to work...but again I never move a 2G+ file to them. I am checking with samba next to see if this is an nfs ism. Sean Manager of way too much TTUHSC At Amarillo sean@ama.ttuhsc.edu From owner-linux-xfs@oss.sgi.com Wed Feb 28 12:07:51 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 12:07:32 -0800 Received: from pike.sover.net ([209.198.87.34]:49881 "EHLO pike.sover.net") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 12:07:22 -0800 Received: from surreal.localdomain (pm1a30.stj.sover.net [209.198.94.30]) by pike.sover.net (8.9.3/8.9.3) with ESMTP id PAA27381; Wed, 28 Feb 2001 15:06:59 -0500 (EST) Comments: SoVerNet Verification (on pike.sover.net) surreal.localdomain from pm1a30.stj.sover.net [209.198.94.30] 209.198.94.30 Wed, 28 Feb 2001 15:06:59 -0500 (EST) Date: Wed, 28 Feb 2001 14:55:06 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Sean Dougherty cc: linux-xfs@oss.sgi.com Subject: Re: XFS weirdness In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Just a little FYI, EXT2 does not have a 2GB file size limit on 2.4.x kernels. Perhaps trying the same thing with ext2 would help determine the problem. I didn't beleive it when people said I coudl make larger files on ext2, so I tried it myself. and indeed, they were right! I hope this help you figure out the real source of the problem. RegEx On Wed, 28 Feb 2001, Sean Dougherty wrote: > > This might be an xfs issue or not. I am not sure. The following only > seems to happen when I have files over 2G in size, hence I only see it > on the XFS partitions. > > I am using the cvs as of 2/27/01. Any partitions are created with > > mkfs -t -f -d unwritten=0 -l size=32768b /dev/hdxx > they are mounted with > mount -t -o logbufs=4,logbsize=32768 /dev/hdxx /xfs > > these are ide drives with both dma and multi count on (all maxtor drives > at the moment) > > I create a directory under /xfs called test then export /xfs/test as an > NFS file system to a sun box 5.8 (I have nfs3 compiled in the kernel of > the xfs box). Now it gets weird. > > >From the sun box I nfs mount xfs-server:/xfs/test to /testxfs that works fine > from the sun box I tar some files to the /testxfs. All is fine and > dandy...then at some point, and no it never happens at the same place twice, > the tar dies with a write error. usually rpc timeout. > > >From the sun box I do a df or an ls of /testxfs and after a fashion I get > another rpc timeout. But on the xfs-server, if I cd to /xfs/test and try > to do an ls 9 times out of 10 ls will hang. Nothing short of rebooting > the box will bring it back. Also nfs is also hung (cannot kill rpc.nfsd). > The 10th time though I get from the ls "cannot stat ." also nfs if hung. > After this reboot I have to do an xfs_repair. One of the many strange > things is, I can ls /xfs all day...it is just the /xfs/test that is broken. > > Has anyone else seen this? Does anyone have any ideas. > > I have tried with ext2 file systems and they seem to work...but again I > never move a 2G+ file to them. > > I am checking with samba next to see if this is an nfs ism. > > Sean > Manager of way too much > TTUHSC At Amarillo > sean@ama.ttuhsc.edu > -- Jason Walker -- unseen@sover.net /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \ From owner-linux-xfs@oss.sgi.com Wed Feb 28 12:26:53 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 12:26:34 -0800 Received: from south.orl-pub.theseus.com ([12.108.42.66]:44578 "EHLO thor.theseus.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 12:26:06 -0800 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id PAA13575; Wed, 28 Feb 2001 15:29:14 -0500 Message-ID: <3A9D5EF4.27B8B394@theseus.com> Date: Wed, 28 Feb 2001 15:26:28 -0500 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Jason Walker CC: Sean Dougherty , linux-xfs@oss.sgi.com Subject: Re: XFS weirdness <- GLibC, LFS and NFS ... oh my! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jason Walker wrote: > Just a little FYI, EXT2 does not have a 2GB file size limit on 2.4.x > kernels. Perhaps trying the same thing with ext2 would help determine the > problem. I didn't beleive it when people said I coudl make larger files on > ext2, so I tried it myself. and indeed, they were right! I hope this help > you figure out the real source of the problem. It's known as LFS (large file support). It is a workaround for POSIX UNIX systems (meaning it affects other platforms than just Linux) on 32-bit processors (so there are NO issues on Linux/Alpha, SPARC64, etc...). >From my understanding, LFS support on Linux requires: Local: Kernel 2.4.x (or LFS kernel 2.2.x backport + filesystem w/LFS) GLibC 2.2.x Utility/App: Linked against GLibC 2.2.x Remote via NFS: Kernel 2.4.x (or LFS 2.2.x backport) kNFSd 2.4.x (or NFS v3 2.2.x backport w/LFS patch) Client: 64-bit platform or 32-bit/LFS-linked LibC/utils I have kernel 2.2.x systems with Ext3+LFS & NFS3+LFS applied that allows my Solaris clients to create >2GB files (even though the local Linux utilities are GLibC 2.1.x and cannot). As such, in this gentleman's case, I concur that he should try creating the file via his NFS client only to an Ext2-exported filesystem. It could be the utilities on his client. -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Wed Feb 28 12:46:53 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 12:46:34 -0800 Received: from south.orl-pub.theseus.com ([12.108.42.66]:40486 "EHLO thor.theseus.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 12:46:11 -0800 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id PAA14257; Wed, 28 Feb 2001 15:49:35 -0500 Message-ID: <3A9D63B4.E428CD2@theseus.com> Date: Wed, 28 Feb 2001 15:46:44 -0500 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Jason Walker , linux-xfs@oss.sgi.com Subject: Re: XFS weirdness <- GLibC, LFS and NFS ... oh my! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jason Walker wrote: > um..I just used a standard 2.4.x kernel. 2.4's VFS changed the > addressing from 32bit to 64bit, I believe. It's a 2.4 thing. Yes, it's called LFS. Kernel 2.2.x (or 2.0.x for that matter) had no issues on 64-bit platforms (like Linux/Alpha). As such, it's not an VFS-specific issue. Again, LFS is the reference POSIX implementation for 32-bit POSIX architectures to overcome the integer limitations of 32-bit processors, namely the 2GB (2^31, 32-bit signed integer) limitation. OSes that adopt LFS address the 32-bit limitations at both the kernel and C Libraries. On 64-bit POSIX systems (like Linux/Alpha), both the kernel and C libraries are already 64-bit and do not have such limitations. In the case of NFS clients, instead of the server's C libraries being used, the clients C libraries (and tools they are linked against) are the issue. That's how some of us running Linux 2.2.x with LFS added plus the NFSv3 + LFS backport, could allow >2GB files from 64-bit client architectures (like Solaris/SPARC). If you used "dump" for your backup, you had no issues (whereas tar and other utilities might). -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Wed Feb 28 14:30:12 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 14:29:53 -0800 Received: from cortex.ama.ttuhsc.edu ([168.49.129.1]:35081 "EHLO cortex.ama.ttuhsc.edu") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 14:29:38 -0800 Received: (from sean@localhost) by cortex.ama.ttuhsc.edu (8.10.2/8.10.2) id f1SMSpa07861; Wed, 28 Feb 2001 16:28:51 -0600 (CST) Date: Wed, 28 Feb 2001 16:28:51 -0600 (CST) From: Sean Dougherty To: Jason Walker cc: linux-xfs@oss.sgi.com Subject: Re: XFS weirdness In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 28 Feb 2001, Jason Walker wrote: > > Just a little FYI, EXT2 does not have a 2GB file size limit on 2.4.x > kernels. Perhaps trying the same thing with ext2 would help determine the > problem. I didn't beleive it when people said I coudl make larger files on > ext2, so I tried it myself. and indeed, they were right! I hope this help > you figure out the real source of the problem. right you are. I am running the tests now...and so far (about 20G moved so far...little files and big ones) and no problems with the ext2 system. Samba, proved to be a different joy. Using smbtar (I do seem fixated on tar tests :-)) I can get the same "cant stat ." error after a run of smbtar errors. But not at the same point or time (oh and I am testing several machines at once here). But so far the smbtar is running ok on ext2. (moved about 10G). Also 2 twice the smbtar seemed to finish correctly on the xfs volumn, but untaring the resulting file failed with tar read errors...now this might just be a tarism...I am not to a point to test the ext2 yet. I am not sure if someone that knows infinately more than I do wants specific log information or debug information to see if this is really an xfs problem...I do plan to keep testing different combinations. Thanks for the tip Jason. Sean > > RegEx > > On Wed, 28 Feb 2001, Sean Dougherty wrote: > > > > > This might be an xfs issue or not. I am not sure. The following only > > seems to happen when I have files over 2G in size, hence I only see it > > on the XFS partitions. > > > > I am using the cvs as of 2/27/01. Any partitions are created with > > > > mkfs -t -f -d unwritten=0 -l size=32768b /dev/hdxx > > they are mounted with > > mount -t -o logbufs=4,logbsize=32768 /dev/hdxx /xfs > > > > these are ide drives with both dma and multi count on (all maxtor drives > > at the moment) > > > > I create a directory under /xfs called test then export /xfs/test as an > > NFS file system to a sun box 5.8 (I have nfs3 compiled in the kernel of > > the xfs box). Now it gets weird. > > > > >From the sun box I nfs mount xfs-server:/xfs/test to /testxfs that works fine > > from the sun box I tar some files to the /testxfs. All is fine and > > dandy...then at some point, and no it never happens at the same place twice, > > the tar dies with a write error. usually rpc timeout. > > > > >From the sun box I do a df or an ls of /testxfs and after a fashion I get > > another rpc timeout. But on the xfs-server, if I cd to /xfs/test and try > > to do an ls 9 times out of 10 ls will hang. Nothing short of rebooting > > the box will bring it back. Also nfs is also hung (cannot kill rpc.nfsd). > > The 10th time though I get from the ls "cannot stat ." also nfs if hung. > > After this reboot I have to do an xfs_repair. One of the many strange > > things is, I can ls /xfs all day...it is just the /xfs/test that is broken. > > > > Has anyone else seen this? Does anyone have any ideas. > > > > I have tried with ext2 file systems and they seem to work...but again I > > never move a 2G+ file to them. > > > > I am checking with samba next to see if this is an nfs ism. > > > > Sean > > Manager of way too much > > TTUHSC At Amarillo > > sean@ama.ttuhsc.edu > > > > -- > Jason Walker -- unseen@sover.net > > /"\ > \ / ASCII RIBBON CAMPAIGN > X AGAINST HTML MAIL > / \ > > > From owner-linux-xfs@oss.sgi.com Wed Feb 28 14:37:22 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 14:37:12 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40317 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 14:37:00 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA08686 for ; Wed, 28 Feb 2001 14:46:36 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA977434; Wed, 28 Feb 2001 16:35:42 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA23528; Wed, 28 Feb 2001 16:35:37 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f1SMaCE22863; Wed, 28 Feb 2001 16:36:12 -0600 Message-Id: <200102282236.f1SMaCE22863@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Sean Dougherty cc: Jason Walker , linux-xfs@oss.sgi.com Subject: Re: XFS weirdness In-Reply-To: Message from Sean Dougherty of "Wed, 28 Feb 2001 16:28:51 CST." Date: Wed, 28 Feb 2001 16:36:11 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This all begs the question of what happens if you just use xfs locally to do this? Also, where does smbtar run (is it just a user app?) and what exactly does it do? We need to get less variables in the picture, not more, try the local XFS case and let us know if you can copy and untar the file there - this will give use a better idea of where to look. Steve > > right you are. I am running the tests now...and so far (about 20G moved > so far...little files and big ones) and no problems with the ext2 system. > > Samba, proved to be a different joy. Using smbtar (I do seem fixated on > tar tests :-)) I can get the same "cant stat ." error after a run of > smbtar errors. But not at the same point or time (oh and I am testing > several machines at once here). But so far the smbtar is running ok on ext2. > (moved about 10G). Also 2 twice the smbtar seemed to finish correctly on > the xfs volumn, but untaring the resulting file failed with tar read > errors...now this might just be a tarism...I am not to a point to test > the ext2 yet. > > I am not sure if someone that knows infinately more than I do wants > specific log information or debug information to see if this is really an > xfs problem...I do plan to keep testing different combinations. > > Thanks for the tip Jason. > Sean > > > > > RegEx > > > > On Wed, 28 Feb 2001, Sean Dougherty wrote: > > > > > > > > This might be an xfs issue or not. I am not sure. The following only > > > seems to happen when I have files over 2G in size, hence I only see it > > > on the XFS partitions. > > > > > > I am using the cvs as of 2/27/01. Any partitions are created with > > > > > > mkfs -t -f -d unwritten=0 -l size=32768b /dev/hdxx > > > they are mounted with > > > mount -t -o logbufs=4,logbsize=32768 /dev/hdxx /xfs > > > > > > these are ide drives with both dma and multi count on (all maxtor drives > > > at the moment) > > > > > > I create a directory under /xfs called test then export /xfs/test as an > > > NFS file system to a sun box 5.8 (I have nfs3 compiled in the kernel of > > > the xfs box). Now it gets weird. > > > > > > >From the sun box I nfs mount xfs-server:/xfs/test to /testxfs that works > fine > > > from the sun box I tar some files to the /testxfs. All is fine and > > > dandy...then at some point, and no it never happens at the same place twi > ce, > > > the tar dies with a write error. usually rpc timeout. > > > > > > >From the sun box I do a df or an ls of /testxfs and after a fashion I ge > t > > > another rpc timeout. But on the xfs-server, if I cd to /xfs/test and try > > > > to do an ls 9 times out of 10 ls will hang. Nothing short of rebooting > > > the box will bring it back. Also nfs is also hung (cannot kill rpc.nfsd) > . > > > The 10th time though I get from the ls "cannot stat ." also nfs if hung. > > > > After this reboot I have to do an xfs_repair. One of the many strange > > > things is, I can ls /xfs all day...it is just the /xfs/test that is broke > n. > > > > > > Has anyone else seen this? Does anyone have any ideas. > > > > > > I have tried with ext2 file systems and they seem to work...but again I > > > never move a 2G+ file to them. > > > > > > I am checking with samba next to see if this is an nfs ism. > > > > > > Sean > > > Manager of way too much > > > TTUHSC At Amarillo > > > sean@ama.ttuhsc.edu > > > > > > > -- > > Jason Walker -- unseen@sover.net > > > > /"\ > > \ / ASCII RIBBON CAMPAIGN > > X AGAINST HTML MAIL > > / \ > > > > > > From owner-linux-xfs@oss.sgi.com Wed Feb 28 15:25:03 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 15:24:53 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:6922 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 15:24:34 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00772 for ; Wed, 28 Feb 2001 15:34:10 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA74577 for ; Wed, 28 Feb 2001 17:23:17 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1SNMAj23141 for ; Wed, 28 Feb 2001 18:22:10 -0500 Message-ID: <3A9D8822.5D8FBA89@thebarn.com> Date: Wed, 28 Feb 2001 18:22:10 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: make tarballs fails Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing it is necessary to rpm -e attr* each time make tarballs is run. this seems to suggest the build process is installing the rpm's on the build system. I assume is not the intended behavior? Finding Provides: (using /usr/lib/rpm/find-provides)... Finding Requires: (using /usr/lib/rpm/find-requires)... PreReq: rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: attr make[2]: *** [dist] Error 1 Done make[1]: Leaving directory `/build/x2.4-xfs-clean/cmd/attr/build' Wrote: /build/x2.4-xfs-clean/cmd/attr/build/tar/attr-1.0.1.tar.gz package attr-1.0.1-0 is already installed package attr-devel-1.0.1-0 is already installed make: *** [cmds] Error 1 chuckle[5:20pm]#rm attr/config.cache -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Feb 28 15:30:03 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 15:29:53 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:10812 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 15:29:43 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA00516 for ; Wed, 28 Feb 2001 15:28:37 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05914; Thu, 1 Mar 2001 10:28:25 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA75675; Thu, 1 Mar 2001 10:28:21 +1100 (EDT) From: "Nathan Scott" Message-Id: <10103011028.ZM166428@wobbly.melbourne.sgi.com> Date: Thu, 1 Mar 2001 10:28:19 -0400 In-Reply-To: Russell Cattelan "make tarballs fails" (Feb 28, 6:22pm) References: <3A9D8822.5D8FBA89@thebarn.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: make tarballs fails Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Feb 28, 6:22pm, Russell Cattelan wrote: > Subject: make tarballs fails > it is necessary to rpm -e attr* each time make tarballs is run. > this seems to suggest the build process is installing the rpm's on > the build system. > I assume is not the intended behavior? > How are you building? using cmd/attr/Makepkgs does not install on the build system. The toplevel Makefile (i.e. the propack Makefile) assumes a chroot'ed propack build environment and does indeed need to install the attr rpm, in order to build xfsdump which depends on it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 28 15:54:03 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 15:53:54 -0800 Received: from mail.connex.com ([216.100.236.3]:21768 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 15:53:37 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 15:49:26 -0800 Message-ID: From: Scott Smyth To: "'linux-xfs@oss.sgi.com '" Cc: 'Jason Walker ' , 'Steve Lord ' , 'Sean Dougherty ' Subject: RE: XFS weirdness Date: Wed, 28 Feb 2001 15:49:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0A1E1.1192F0D0" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing 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_01C0A1E1.1192F0D0 Content-Type: text/plain; charset="iso-8859-1" Hi; The problem may be with Samba in that you have to make it look for the 64-bit file size ability (in a header file). Samba (even recent 2.2.x) does not do it for Linux by default. A patch to the 2.2.x Samba tree (SAMBA_2_2) attached makes Samba look when it compiles. Scott -- http://www.connex.com sbsmyth@connex.com -----Original Message----- From: Steve Lord To: Sean Dougherty Cc: Jason Walker; linux-xfs@oss.sgi.com Sent: 2/28/01 2:36 PM Subject: Re: XFS weirdness This all begs the question of what happens if you just use xfs locally to do this? Also, where does smbtar run (is it just a user app?) and what exactly does it do? We need to get less variables in the picture, not more, try the local XFS case and let us know if you can copy and untar the file there - this will give use a better idea of where to look. Steve > > right you are. I am running the tests now...and so far (about 20G moved > so far...little files and big ones) and no problems with the ext2 system. > > Samba, proved to be a different joy. Using smbtar (I do seem fixated on > tar tests :-)) I can get the same "cant stat ." error after a run of > smbtar errors. But not at the same point or time (oh and I am testing > several machines at once here). But so far the smbtar is running ok on ext2. > (moved about 10G). Also 2 twice the smbtar seemed to finish correctly on > the xfs volumn, but untaring the resulting file failed with tar read > errors...now this might just be a tarism...I am not to a point to test > the ext2 yet. > > I am not sure if someone that knows infinately more than I do wants > specific log information or debug information to see if this is really an > xfs problem...I do plan to keep testing different combinations. > > Thanks for the tip Jason. > Sean > > > > > RegEx > > > > On Wed, 28 Feb 2001, Sean Dougherty wrote: > > > > > > > > This might be an xfs issue or not. I am not sure. The following only > > > seems to happen when I have files over 2G in size, hence I only see it > > > on the XFS partitions. > > > > > > I am using the cvs as of 2/27/01. Any partitions are created with > > > > > > mkfs -t -f -d unwritten=0 -l size=32768b /dev/hdxx > > > they are mounted with > > > mount -t -o logbufs=4,logbsize=32768 /dev/hdxx /xfs > > > > > > these are ide drives with both dma and multi count on (all maxtor drives > > > at the moment) > > > > > > I create a directory under /xfs called test then export /xfs/test as an > > > NFS file system to a sun box 5.8 (I have nfs3 compiled in the kernel of > > > the xfs box). Now it gets weird. > > > > > > >From the sun box I nfs mount xfs-server:/xfs/test to /testxfs that works > fine > > > from the sun box I tar some files to the /testxfs. All is fine and > > > dandy...then at some point, and no it never happens at the same place twi > ce, > > > the tar dies with a write error. usually rpc timeout. > > > > > > >From the sun box I do a df or an ls of /testxfs and after a fashion I ge > t > > > another rpc timeout. But on the xfs-server, if I cd to /xfs/test and try > > > > to do an ls 9 times out of 10 ls will hang. Nothing short of rebooting > > > the box will bring it back. Also nfs is also hung (cannot kill rpc.nfsd) > . > > > The 10th time though I get from the ls "cannot stat ." also nfs if hung. > > > > After this reboot I have to do an xfs_repair. One of the many strange > > > things is, I can ls /xfs all day...it is just the /xfs/test that is broke > n. > > > > > > Has anyone else seen this? Does anyone have any ideas. > > > > > > I have tried with ext2 file systems and they seem to work...but again I > > > never move a 2G+ file to them. > > > > > > I am checking with samba next to see if this is an nfs ism. > > > > > > Sean > > > Manager of way too much > > > TTUHSC At Amarillo > > > sean@ama.ttuhsc.edu > > > > > > > -- > > Jason Walker -- unseen@sover.net > > > > /"\ > > \ / ASCII RIBBON CAMPAIGN > > X AGAINST HTML MAIL > > / \ > > > > > > ------_=_NextPart_000_01C0A1E1.1192F0D0 Content-Type: application/octet-stream; name="samba-2.2.x-configure.in-LFS.patch.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="samba-2.2.x-configure.in-LFS.patch.bz2" QlpoOTFBWSZTWfZf67YAAHffgHcwXH//33//3iq/595qQAH9tpE2uEokmT1GptJk2o8oNMjIA00M TT1MNT1DRk2k0EqmTKfqKY2qeUY0JpppjUAxAyGQaMAmgOMmTQxGJowCMBMIAwE00aZGgGEkhQ9Q 0n6p6E0xAGgaAGQADIPUAIiU40S56vszlvBqv83WXsmi8/ezRMm3ltVa1OQldvOBPRzmLAUKUdg6 aR86Lp8toIbZPWGDcfYkcz1KE0bkNUUC2LbSYp2acMTqDEIykC8KrssscaSxkh36AVb1+xFUwYdh InYGaTBWURxdGgpyfCali+FBPSJzE1ZsW+PXSvu0SkvUpApcxBhR5IS11jCrRdxVmlwuG5f5GXVg QXnTVeHLWDBgpsmQSVDQGkjJEYqjxJmQzIWwzg+shyqYmXsIpAYyCzOZNImEXgmIoyr0LpAeIqK2 oDhSRQPeDoECSKwMkoiKSCmV1Qh2lXKqGZFAQC0MiCLOaMntK8SHsiuFsfxFNKmGDIySdzbXPVNJ jUfiQHT9jHiug7rH9ik5sHDWZ3j7Mks55zOxvpqoN7asWkolImKDW6sa7Spb+iFMTTlKwouIWNKU MJs2yEbqLAgqqZOOtIpiImecVDidUlp74jGcRczPqvH39BxYx53XGZXA/gv6Y4JgsAyJFR4Orot0 8lsiNapoUEYLeW+KskH8+EAyU4RHE8XVprzWC7kinChIey/12wA= ------_=_NextPart_000_01C0A1E1.1192F0D0-- From owner-linux-xfs@oss.sgi.com Wed Feb 28 16:02:03 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 16:01:43 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:14901 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 16:01:35 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA03861 for ; Wed, 28 Feb 2001 16:01:34 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA977499; Wed, 28 Feb 2001 18:00:17 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA47844; Wed, 28 Feb 2001 18:00:17 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f2100oo26264; Wed, 28 Feb 2001 18:00:50 -0600 Message-Id: <200103010000.f2100oo26264@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Sean Dougherty cc: linux-xfs@oss.sgi.com Subject: Re: XFS weirdness In-Reply-To: Message from Sean Dougherty of "Wed, 28 Feb 2001 13:55:20 CST." Date: Wed, 28 Feb 2001 18:00:50 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > This might be an xfs issue or not. I am not sure. The following only > seems to happen when I have files over 2G in size, hence I only see it > on the XFS partitions. > > I am using the cvs as of 2/27/01. Any partitions are created with > > mkfs -t -f -d unwritten=0 -l size=32768b /dev/hdxx > they are mounted with > mount -t -o logbufs=4,logbsize=32768 /dev/hdxx /xfs > > these are ide drives with both dma and multi count on (all maxtor drives > at the moment) > > I create a directory under /xfs called test then export /xfs/test as an > NFS file system to a sun box 5.8 (I have nfs3 compiled in the kernel of > the xfs box). Now it gets weird. > > >From the sun box I nfs mount xfs-server:/xfs/test to /testxfs that works fin > e > from the sun box I tar some files to the /testxfs. All is fine and > dandy...then at some point, and no it never happens at the same place twice, > the tar dies with a write error. usually rpc timeout. > Can you be more explicit - are you just untaring into xfs, or are you copying the tar file into xfs and then untaring it? Steve From owner-linux-xfs@oss.sgi.com Wed Feb 28 16:07:33 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 16:07:13 -0800 Received: from south.orl-pub.theseus.com ([12.108.42.66]:14375 "EHLO thor.theseus.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 16:07:00 -0800 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id TAA04957; Wed, 28 Feb 2001 19:10:23 -0500 Message-ID: <3A9D92C9.4324DAC3@theseus.com> Date: Wed, 28 Feb 2001 19:07:37 -0500 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Sean Dougherty CC: Jason Walker , linux-xfs@oss.sgi.com Subject: Re: XFS weirdness References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Sean Dougherty wrote: > Samba, proved to be a different joy. FYI, Win9x/ME clients *DO* have a 2GB file size limit. Haven't tried NT clients with Samba though. -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Wed Feb 28 16:18:03 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 16:17:44 -0800 Received: from mail.connex.com ([216.100.236.3]:54537 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 16:17:38 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 15:58:27 -0800 Message-ID: From: Scott Smyth To: "''linux-xfs@oss.sgi.com ' '" Cc: ''Jason Walker ' ' , ''Steve Lord ' ' , ''Sean Dougherty ' ' Subject: RE: XFS weirdness Date: Wed, 28 Feb 2001 15:58:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Oops. Didn't see that it was working ok with ext2. You must have already had Samba working. Scott -----Original Message----- From: Scott Smyth To: 'linux-xfs@oss.sgi.com ' Cc: 'Jason Walker '; 'Steve Lord '; 'Sean Dougherty ' Sent: 2/28/01 3:49 PM Subject: RE: XFS weirdness Hi; The problem may be with Samba in that you have to make it look for the 64-bit file size ability (in a header file). Samba (even recent 2.2.x) does not do it for Linux by default. A patch to the 2.2.x Samba tree (SAMBA_2_2) attached makes Samba look when it compiles. Scott -- http://www.connex.com sbsmyth@connex.com -----Original Message----- From: Steve Lord To: Sean Dougherty Cc: Jason Walker; linux-xfs@oss.sgi.com Sent: 2/28/01 2:36 PM Subject: Re: XFS weirdness This all begs the question of what happens if you just use xfs locally to do this? Also, where does smbtar run (is it just a user app?) and what exactly does it do? We need to get less variables in the picture, not more, try the local XFS case and let us know if you can copy and untar the file there - this will give use a better idea of where to look. Steve > > right you are. I am running the tests now...and so far (about 20G moved > so far...little files and big ones) and no problems with the ext2 system. > > Samba, proved to be a different joy. Using smbtar (I do seem fixated on > tar tests :-)) I can get the same "cant stat ." error after a run of > smbtar errors. But not at the same point or time (oh and I am testing > several machines at once here). But so far the smbtar is running ok on ext2. > (moved about 10G). Also 2 twice the smbtar seemed to finish correctly on > the xfs volumn, but untaring the resulting file failed with tar read > errors...now this might just be a tarism...I am not to a point to test > the ext2 yet. > > I am not sure if someone that knows infinately more than I do wants > specific log information or debug information to see if this is really an > xfs problem...I do plan to keep testing different combinations. > > Thanks for the tip Jason. > Sean > > > > > RegEx > > > > On Wed, 28 Feb 2001, Sean Dougherty wrote: > > > > > > > > This might be an xfs issue or not. I am not sure. The following only > > > seems to happen when I have files over 2G in size, hence I only see it > > > on the XFS partitions. > > > > > > I am using the cvs as of 2/27/01. Any partitions are created with > > > > > > mkfs -t -f -d unwritten=0 -l size=32768b /dev/hdxx > > > they are mounted with > > > mount -t -o logbufs=4,logbsize=32768 /dev/hdxx /xfs > > > > > > these are ide drives with both dma and multi count on (all maxtor drives > > > at the moment) > > > > > > I create a directory under /xfs called test then export /xfs/test as an > > > NFS file system to a sun box 5.8 (I have nfs3 compiled in the kernel of > > > the xfs box). Now it gets weird. > > > > > > >From the sun box I nfs mount xfs-server:/xfs/test to /testxfs that works > fine > > > from the sun box I tar some files to the /testxfs. All is fine and > > > dandy...then at some point, and no it never happens at the same place twi > ce, > > > the tar dies with a write error. usually rpc timeout. > > > > > > >From the sun box I do a df or an ls of /testxfs and after a fashion I ge > t > > > another rpc timeout. But on the xfs-server, if I cd to /xfs/test and try > > > > to do an ls 9 times out of 10 ls will hang. Nothing short of rebooting > > > the box will bring it back. Also nfs is also hung (cannot kill rpc.nfsd) > . > > > The 10th time though I get from the ls "cannot stat ." also nfs if hung. > > > > After this reboot I have to do an xfs_repair. One of the many strange > > > things is, I can ls /xfs all day...it is just the /xfs/test that is broke > n. > > > > > > Has anyone else seen this? Does anyone have any ideas. > > > > > > I have tried with ext2 file systems and they seem to work...but again I > > > never move a 2G+ file to them. > > > > > > I am checking with samba next to see if this is an nfs ism. > > > > > > Sean > > > Manager of way too much > > > TTUHSC At Amarillo > > > sean@ama.ttuhsc.edu > > > > > > > -- > > Jason Walker -- unseen@sover.net > > > > /"\ > > \ / ASCII RIBBON CAMPAIGN > > X AGAINST HTML MAIL > > / \ > > > > > > <> From owner-linux-xfs@oss.sgi.com Wed Feb 28 16:28:13 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 16:28:04 -0800 Received: from south.orl-pub.theseus.com ([12.108.42.66]:36369 "EHLO thor.theseus.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 16:27:52 -0800 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id TAA05335; Wed, 28 Feb 2001 19:31:17 -0500 Message-ID: <3A9D97B0.3593BA1D@theseus.com> Date: Wed, 28 Feb 2001 19:28:32 -0500 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Jason Walker , linux-xfs@oss.sgi.com Subject: Re: XFS weirdness <- GLibC, LFS and NFS ... oh my! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jason Walker wrote: > Ahh..ok, thanks for the info. I stand corrected. this is good to know. Of course I could be pulling it out of my @$$ (so you should always research it itself to be sure). But there is a lot of core UNIX info here: http://www.opengroup.org/platform/lfs.html And a good Linux-specific page is here: http://www.suse.de/~aj/linux_lfs.html -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Wed Feb 28 17:35:07 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 17:34:58 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:18285 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 17:34:36 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA24215 for ; Wed, 28 Feb 2001 17:33:29 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA41142 for linux-xfs@oss.sgi.com; Thu, 1 Mar 2001 12:33:17 +1100 (EST) Date: Thu, 1 Mar 2001 12:33:17 +1100 (EST) From: Nathan Scott Message-Id: <200103010133.MAA41142@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ugh, caused me to botch a .deb upload. Date: Wed Feb 28 17:31:21 PST 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88637a cmd/acl/build/Makefile - 1.2 cmd/attr/build/Makefile - 1.2 cmd/dmapi/build/Makefile - 1.2 cmd/xfsdump/build/Makefile - 1.2 cmd/xfsprogs/build/Makefile - 1.3 - ensure make clean gets rid of all build leftovers. cmd/xfsprogs/doc/CHANGES - 1.4 cmd/xfsprogs/debian/changelog - 1.4 cmd/xfsprogs/VERSION - 1.4 - update for minor build/Makefile change. cmd/xfstests/018.usrquota - 1.2 - update after recent logprint changes (via xfs_log_recover.c). From owner-linux-xfs@oss.sgi.com Wed Feb 28 19:20:27 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 19:20:17 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:63267 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 19:20:03 -0800 Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA00653 for ; Wed, 28 Feb 2001 19:29:40 -0800 (PST) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.11.0/8.11.0) id f213HsA17195 for linux-xfs@oss.sgi.com; Wed, 28 Feb 2001 19:17:54 -0800 Date: Wed, 28 Feb 2001 19:17:54 -0800 From: Ananth Ananthanarayanan Message-Id: <200103010317.f213HsA17195@waco.engr.sgi.com> Subject: TAKE - code shuffling to make xfs changes more acceptable To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Export find_get_page_simple for clustering Date: Wed Feb 28 19:17:37 PST 2001 Workarea: waco.engr.sgi.com:/build1/ananth/xfs-tot The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:88648a linux/mm/filemap.c - 1.70 linux/kernel/ksyms.c - 1.79 linux/include/linux/pagemap.h - 1.23 linux/fs/pagebuf/page_buf_io.c - 1.57